Re: Any chance for a Git v2.1.5 release?

From: Kyle J. McKay <mackyle@gmail.com>
Date: Feb 26, 2015, 23:38 UTC
Message-ID: <35E11B78-6FF8-41DE-BBF5-8978DA2F87A6@gmail.com>
In-Reply-To: <xmqqvbiol7fg.fsf@gitster.dls.corp.google.com>

On Feb 26, 2015, at 12:54, Junio C Hamano wrote:

Show 37 quoted lines

> "Kyle J. McKay" <mackyle@gmail.com> writes:
>
>> I would like to better understand how the various heads are
>> maintained.  I've read MaintNotes and I've got the concepts, but I'm
>> still a little fuzzy on some details.  It looks to me like all topics
>> still only in pu after master has been updated are then rebased onto
>> the new master and then pu is rebuilt.
>
> Topics in 'pu' not yet in 'next' _can_ be rebased, but unless there
> is a good reason to do so, I wouldn't spend extra cycles necessary
> to do such thing.  I even try to keep the same base when replacing
> the contents of a branch with a rerolled series.  For example, today
> I have this:
>
>    $ git config alias.lgf
>    log --oneline --boundary --first-parent
>    $ git lgf master..nd/slim-index-pack-memory-usage
>    3538291 index-pack: kill union delta_base to save memory
>    7b4ff41 FIXUP
>    45b6b71 index-pack: reduce memory footprint a bit
>    - 9874fca Git 2.3
>
> and Duy has a newer iteration of it starting at $gmane/264429.  What
> I would do, after saving these patches in a mbox +nd-index-pack,
> would be to
>
>    $ git checkout 9874fca
>    $ git am -s3c ./+nd-index-pack
>    $ git show-branch HEAD nd/slim-index-pack-memory-usage
>    ... compare corresponding changes between the old and the new
>    ... until I am satisified; otherwise I may tweak the new one
>    $ git rebase -i 9874fca
>    ... and then finally
>    $ git branch -f nd/slim-index-pack-memory-usage HEAD
>
> to update the topic.  Of course, it would be necessary to rebuild
> 'pu' by merging all the topics that are in it on top of 'master'.

Thanks.  That's helpful.

Show 5 quoted lines

> After finishing 2.3.0 release, at some point while 'master' is still
> at 2.3.0, something like this would happen:
>
>    $ git branch -m maint maint-2.2
>    $ git branch maint master

So the reason I don't notice force-updates to maint when this happens is because of the "Sync with maint" commits that make sure the new maint contains the old one.

Show 19 quoted lines

>> Also, how do you handle a down merge to maint when you have this:
>>
>> * (master)
>> * merge topic foo
>> |\
>> | * topic foo
>> |/
>> * c
>> * b
>> * a
>> * (tag: vX.X.X, maint)
>> *
>
> I don't, and this is done by making sure I do not get into such a
> situation in the first place.
>
> A general rule of thumb when applying a set of patches that are
> fixes eventually worth having in older maintenance tracks is to find
> the oldest maintenance branch and apply them there.

If I were to keep a maint-lts branch somewhere I would need to cherry- pick topics with desired fixes that fall into that situation. That's what I expected but when you mentioned down merging the fixes I wanted to make sure I wasn't overlooking something.

I'll see about setting up a maint-lts in a local git repository clone and tracking LTS fixes. If I'm able to keep that going without it becoming a black-hole of temporal need that sucks the life right out of me ;) then perhaps we can have a discussion at a future date about what would be needed for you to consider pulling from it and issuing LTS releases off it. :)

-Kyle