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

2014-08-07 Thread Tony Finch
Nico Williams n...@cryptonector.com 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 n...@cryptonector.com wrote: My proposal was to put this sort of ancillary history info in a branch object (and that branches should

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

2014-08-07 Thread Nico Williams
On Thu, Aug 07, 2014 at 12:38:48PM +0100, Tony Finch wrote: 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

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

2014-08-07 Thread Tony Finch
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

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

2014-08-07 Thread Nico Williams
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

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

2014-08-07 Thread Tony Finch
Nico Williams n...@cryptonector.com wrote: On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote: 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

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

2014-08-07 Thread Nico Williams
On Thu, Aug 7, 2014 at 12:47 PM, Tony Finch d...@dotat.at wrote: Nico Williams n...@cryptonector.com wrote: Either way I retain the old HEAD with some name. Hmm, yes, I can see that would work. However my previous workflow was rather branch-heavy and I found the accumulation of names

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

2014-08-07 Thread Nico Williams
On Thu, Aug 7, 2014 at 6:38 AM, Tony Finch d...@dotat.at wrote: 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 ... though the structure of the

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

2014-08-06 Thread Nico Williams
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 n...@cryptonector.com wrote: My proposal was to put this sort of ancillary history info in a branch object (and that branches should be objects). This would have a number of