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

From: Nico Williams <nico@cryptonector.com>
Date: Aug 7, 2014, 15:58 UTC
Message-ID: <20140807155828.GM23449@localhost>
In-Reply-To: <alpine.LSU.2.00.1408071222510.13901@hermes-1.csi.cam.ac.uk>

On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote:

Show 6 quoted lines

> I have been fiddling around in this area.
> 
> What I want to be able to do is develop fixes for open source code
> that I run, and get those fixes upstream. This means I need a rebasing
> workflow, to keep the patches up-to-date and to deal with code review
> feedback.

Right.

> But this is inconvenient for deploying the patched version to
> production (which is the point of developing the fixes) - I want a

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.

> fast-forwarding branch for that. And it would be nice to be able to
> share the history of the patch series, so others can see what changed
> between revisions more easily.

But yes, it's nice to have a history of all the rebases. For example: so you can show the work you've done (rebasing to please an upstream is work).

The reflog does this, of course, but you can't push it. Of course, my conception of branch object wouldn't push rebase history to an upstream that doesn't want it, but you could push it to repos that do.

Show 5 quoted lines

> So I have a small tool which maintains a publication branch which
> tracks the head of a rebasing branch. It's reasonably satisfactory so
> far...
> 
> https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git

Yeah, that's useful.

Nico