develooper Front page | perl.perl5.porters | Postings from November 2008

Re: git workflow (was Re: git?)

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
November 14, 2008 09:10
Subject:
Re: git workflow (was Re: git?)
Message ID:
c9ab31fc0811140910k4ef8e82ds28c4cc9f44b9f8c1@mail.gmail.com
On Fri, Nov 14, 2008 at 3:59 AM, David Golden <xdaveg@gmail.com> wrote:
> On Fri, Nov 14, 2008 at 4:32 AM, Nicholas Clark <nick@ccl4.org> wrote:
>> One part of the documentation I know is missing is:
>>
>>  There are no instructions on how to commit back to the repository.
>
> More importantly, there are no instructions yet on what the "workflow"
> should be.

And there's more than one workflow.  Before I commit back to the
repository, I have to know how to maintain my local repository.  In
other words, what comes after C<git clone>?

Lets say I'm interested in being able to track both blead and
maint-5.10 and to test merges back to maint-5.10 from blead.  I would
hope one of the things a new VCS would help with is increasing the
likelihood that major patches come in with integration implications
already worked out: does it break binary compatibility?  what
dependencies does it have? etc.  Maybe I'm dreaming, but  let's assume
for the sake of argument that some people will do this and we need to
make it as easy as possible for them to know how.

So following the official git documentation, I've done a clone and
created local branches named blead (tracking origin/blead) and
maint-5.10 (tracking origin/maint-5.10).  Of course my two local
branches share a working directory (as the documentation emphasizes,
the repository actually sits inside the working directory), which is a
bit awkward since I can therefore only work on one branch at a time.
People who use git in their day jobs laugh and say, "Don't do that."
When I ask what to do instead, I get vigorous handwaving and something
mumbled about using hard links to fake multiple working directories.
If that's a good way to do things, why doesn't the official
documentation describe how to do it that way (or does it, and I missed
it)?

The other obvious path to take is to maintain two completely separate
copies of the repository and keep each one checked out to a different
branch.  Is that what people do?  If so, how do you test merging your
blead changes back to 5.10.x without simply submitting a patch to
yourself (which kind of defeats the purpose of having a tool with
highly touted merge capabilities)?  Do I have to set up my local maint
repository to track my local blead repository as if it were "remote"?
If so, how exactly do I do that?  If not, what should I do instead?

Only at the end of this process does the question of how to push to
the official repository become relevant.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About