On Thu, Aug 7, 2014 at 6:38 AM, Tony Finch 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 publication
On Thu, Aug 7, 2014 at 12:47 PM, Tony Finch wrote:
> Nico Williams 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 annoying. I have
> not yet had enough
Nico Williams 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 branch after a
On Thu, Aug 07, 2014 at 05:42:34PM +0100, Tony Finch wrote:
> Nico Williams 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
Nico Williams 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 fol
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
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 so
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). This would
> > have a number of benefits, not the l
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams wrote:
> On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski wrote:
>> W dniu 2014-08-01 22:55, Nico Williams pisze:
>>>
>>> It would help if cherry-pick history where recorded somewhere (beyond
>>> the reflog)...
>>>
>>> Cherry-picks should record two pa
9 matches
Mail list logo
