Nico Williams <> wrote:
> On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
> > On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams <> wrote:
> > >
> > > My proposal was to put this sort of ancillary history info in a
> > > "branch object" (and that branches should be objects).
> >
> > Is it something like object-ified reflog, similar to how replacement
> > objects (git-replace) can be thought to be object-ified grafts (I know
> > they are more)? Do I understand it correctly?
> Yes, per-branch.  At push time a commit would be pushed to the upstream
> branch listing the commits pushed now (and who by).  Locally every
> rebase/cherry-pick/merge/commit onto the branch would appear in the
> branch object's history, kinda just like the reflog.  The main
> difference is that the upstream branch's history could be viewed.
> > With rebases the problem is that it would be nice to have (at least
> > for a short time) the history of series of patches (the metahistory,
> > or history of a branch), but usually one doesn't need old pre-rebase
> > version after cleaning up the history for publishing.
> Right.

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.

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

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

... though the structure of the publication branch is weird and not very
easy to navigate. You can see it in action in my git.git repo:

f.anthony.n.finch  <>
Irish Sea: Variable 4. Slight. Showers. Good.

Reply via email to