On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
> Nico Williams <n...@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".
> > > https://git.csx.cam.ac.uk/x/ucs/git/git-repub.git
> >
> > Yeah, that's useful.
>
> Glad you think so :-)
Thank you.
Nico
--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
