Re: "Branch objects" (was: Re: cherry picking and merge)

From: Nico Williams <nico@cryptonector.com>
Date: Aug 7, 2014, 17:22 UTC
Message-ID: <20140807172207.GP23449@localhost>
In-Reply-To: <alpine.LSU.2.00.1408071735410.23775@hermes-1.csi.cam.ac.uk>

On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:

Show 13 quoted lines

> Nico Williams <nico@cryptonector.com> wrote:
> > On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:
> > > But [a rebasing workflow] is inconvenient for deploying the patched
> > > version to production (which is the point of developing the fixes) - I
> > > want a fast-forwarding branch for that.
> >
> > I'm not sure I follow this.  You deploy what you build, and you build
> > the HEAD of the production branch, whatever that is.  If it gets
> > rebased, so it it does.
> 
> The problem is that the production branch gets copied around: pushed to
> the repo server, pulled by other team members, etc. Forced pushes
> are accident-prone, as is resetting a rebased branch after a pull.

When I rebase and I need the old HEAD around I do something like this:

$ git checkout $branch_to_rebase $ ver=${branch_to_rebase##*-} $ git checkout -b ${branch_to_rebase%-${ver}}-$((ver+1)) $ git rebase ...

or like this:

$ git checkout $branch_to_rebase $ git branch ${branch_to_rebase}-$(date +%Y-%m-%d) $ git rebase ...

Either way I retain the old HEAD with some name. This requires discipline, so scripting it is useful. But if you want discipline then you want git to know that "for this branch, don't prune/gc old HEADs orphaned after rebases" and "push the rebase history for this branch".

Show 5 quoted lines

> > > https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git
> >
> > Yeah, that's useful.
> 
> Glad you think so :-)

Thank you.

Nico