From: Junio C Hamano <gitster@pobox•com>
To: "Kyle J. McKay" <mackyle@gmail•com>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: Any chance for a Git v2.1.5 release?
Date: Thu, 26 Feb 2015 12:54:59 -0800 [thread overview]
Message-ID: <xmqqvbiol7fg.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <DCB8EEAA-F6C3-4321-833E-39B80673C7E9@gmail.com> (Kyle J. McKay's message of "Wed, 25 Feb 2015 23:40:53 -0800")
"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.
next prev parent reply other threads:[~2015-02-26 20:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <C5211E53-8905-41C9-9D28-26D7BB51E76A@gmail.com>
[not found] ` <xmqqk2z7qe8s.fsf@gitster.dls.corp.google.com>
2015-02-25 0:55 ` Any chance for a Git v2.1.5 release? Kyle J. McKay
2015-02-25 5:13 ` Junio C Hamano
2015-02-26 7:40 ` Kyle J. McKay
2015-02-26 20:54 ` Junio C Hamano [this message]
2015-02-26 23:38 ` Kyle J. McKay
2015-02-26 23:51 ` Junio C Hamano
2015-02-27 22:49 ` Philip Oakley
2015-03-12 1:23 ` Kyle J. McKay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqvbiol7fg.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mackyle@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox