On Feb 26, 2015, at 12:54, Junio C Hamano wrote:
"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'.
Thanks. That's helpful.
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.
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
--
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