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

[Junio C Hamano <gitster@pobox.com>]

"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'.

https://github.com/gitster/git.git has these topic branches broken
out and you can observe how they change over time from your local
reflog for refs/remotes/<that repository>/<topic branches>.

> I vaguely recall you may have explained some of this in more detail in
> the context of explaining how you used the scripts in todo to put
> everything together when someone asked a question about it on the
> list.  But I can't seem to find that message anymore.  :(

There may be a copy in Documentaiton/howto/ somewhere.

> I think I mostly understand how master, next and pu are maintained.
> But MaintNotes says "Whenever a feature release is made, 'maint'
> branch is forked off from 'master' at that point."  What happens to
> the previous maint at that time?  Is it just renamed to maint-X.X?

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

> 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.