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

Re: git workflow (was Re: git?)

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
November 14, 2008 09:24
Subject:
Re: git workflow (was Re: git?)
Message ID:
20081114182403.2863b878@pc09.procura.nl
On Fri, 14 Nov 2008 11:10:14 -0600, "Craig A. Berry"
<craig.a.berry@gmail.com> wrote:

> 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>?

If you have X11, the most user-friendly next step is 'git-gui'
After the clone, you just patcherdypatch away, and when you're
satisfied with that part, start git-gui

It'll show you what files are changed and the changes since you started
You fill in the commit message, click on the files that are to be
included in that commit and click the commit button. When all commits
are done, you hit the push button to upload to the main repository

> 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.

I strictly split 5.8, 5.10, and blead, and have a clone/working copy
for each

> 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.
> 


-- 
H.Merijn Brand          Amsterdam Perl Mongers  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

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