"Kyle J. McKay" <mackyle@xxxxxxxxx> 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.
--
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