Re: How does Git's maintenance policy handle topics that don't start from "master?"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 29, 2012, 23:06 UTC
- Message-ID
- <7vzk8q1t9r.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <m2sjei4pvq.fsf@Spindle.sehlabs.com>
"Steven E. Harris" <seh@panix.com> writes:
Show 17 quoted lines
> What isn't so clear to me, though, is /why/ this don't-merge-from-"next" > rule is so important. Say that we had one topic "t1" depart from "next," > and then another topic "t2" depart from "t1," and both have been cooking > in "next," with good results. > > ---o---o---o---o master > \ > o---o---o---o---o---M---o---o next > \ / / > o---o t1 / > \ / > o---o t2 > > If we wanted to graduate these two topics to "master," we /could/ merge > from commit M back to "master," though here I deliberately included the > nefarious commit X, which shows other interleaved contributions along > "next" that are also part of the M commit.
I do not see any X above, but I think you meant the commits in master..M that are not reachable from either t1 and t2.
And I think you answered your own question. These "master..M ^t1 ^t2" commits are topics that are *not* part of t1 nor t2. If you deem all of them are good enough for your master, it is perfectly fine to merge M to master. In reality, it is more cumbersome to think about what is and what is not yet in M and decide if the set of changes that happen to be in M match exactly what you want to merge, than knowing that you exactly want to have t1 and t2 and nothing else in your master during this integration run and merge only these two topics.
The same answer to the other picture. If you can figure out an appropriate commit M that has what you want, go right ahead and merge that to 'master'; I do not see any harm there. I personally do not think it is worth the effort to figure out which commit between master..next that M is, and verify master..M contains everything you want and nothing you don't. Merging t1 and t2 explicitly, when you know they are the only thing you want to merge, is much simpler and less error prone.
Show 15 quoted lines
> What about this case, where topics "t1" and "t2" did depart from > "master," and are doing well along "next" together as of commit M. > > ---o---o---o---o master > \ \ \ > \ o---o---o---M---o---o next > \ / / > o---o t1 / > \ / > o---o---o t2 > > The Git policy as I understand it prescribes that we merge from the tips > of "t1" and "t2" back to master, not from a commit like M. What harm > would come from merging from M in this case? Future archaeology of topic > provenance?