Re: [PATCH 12/20] remote-bzr: split marks file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Apr 28, 2013 at 1:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>>
>>> And in case anybody is thinking that remote-bzr is really a too fast
>>> moving target; even if this managed to land in 'master', it's likely
>>> that people were not able to push at all, and in fact, many were not
>>> even able to clone in 1.8.2. So, hardly could be considered a
>>> regression. Nevertheless, I caught it in time.
>>
>> You didn't.  I am already way too deep into today's 1.8.3-rc0
>> integration cycle and I won't waste a couple of hours work just to
>> revert this.
>
> Oh, I was lucky ;-) I mistook this with the other 9-patch bzr
> clean-up series that I applied to 'master' for -rc0.
>
> Pushing out a tagged-tip takes a lot longer than the normal tip
> because a lot more than what people see have to happen on my end.
>
> Reverting a single patch is simple, but we do not want to do that on
> top of "Git 1.8.3-rc0" commit and move the unpublished tag to point
> at the revert.
>
> Which means pretty much everything needs to be redone (one example
> among many is that the tagname will propagate to the htmldocs and
> manpages repositories, so their unpublished histories need to be
> rewound).
>
> But I didn't have to do that in the end ;-)

Yeah, I realized you were talking about that one later on. I haven't
heard anything bad from this new branch from emacs developers, so I
think it's OK to merge it.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]