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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 26, 2015, 20:54 UTC
Message-ID: <xmqqvbiol7fg.fsf@gitster.dls.corp.google.com>
In-Reply-To: <DCB8EEAA-F6C3-4321-833E-39B80673C7E9@gmail.com>

"Kyle J. McKay" <mackyle@gmail.com> writes:

Show 5 quoted lines

> 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

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