Re: git-branch, older repos and more confusion

From: Jeff King <peff@peff.net>
Date: Apr 12, 2007, 05:21 UTC
Message-ID: <20070412052118.GA30459@coredump.intra.peff.net>
In-Reply-To: <46a038f90704112205g53ab4750s673f449ee40165b4@mail.gmail.com>

On Thu, Apr 12, 2007 at 05:05:24PM +1200, Martin Langhoff wrote:

> Which means I'll have to write a little list that goes "if your git is
> version X, do this, if it's version Y do that". :-(

Yes, that is frustrating. If you are just working with master/origin, I think you can get away with it due to the default configuration created, but otherwise I'm not sure it's avoidable. I seem to recall a thread about this a few months ago (between me and Bill Lear, maybe?), but I don't recall that there was any especially good conclusion.

Show 14 quoted lines

> For example, creating a new "custom" branch on the repo used to be
> trivial and left us with a setup that was simple and safe. For
> example, if you wanted to work on a custom v1.9:
> 
> - cg-clone <repo>#v1.9-maint mydir
> - cd mydir
> - cg-branch-chg origin <repo>#1.9-clientname
> - cg-push     ## this creates the new head on the repo
> - cg-branch-add v1.9-maint <repo>#v1.9-maint mydir
> 
> and from there onwards cg-update / cg-push worked on the custom
> branch, and cg-update v1.9-maint would merge from the maint branch.
> 
> Any hints as to how to run such workflow on v1.5.x?

This will seem like repetition, but it's like this:

  git-clone <repo> mydir
  cd mydir
  git-checkout --track -b v1.9-clientname origin/v1.9-maint
  git-push origin v1.9-clientname    # to create the new head remotely

When you do a git-pull without arguments from the v1.9-clientname branch, it will first do a fetch of origin (grabbing the entire state, including the v1.9-maint branch) and then merge in origin's v1.9-maint.

When you do a push without arguments, it will push every head you have in common with origin. Because we pushed the v1.9-clientname branch once, it was created and will be part of subsequent pushes.

-Peff