Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > On Fri, 4 Sep 2009, Junio C Hamano wrote: > >> Because the theme of the topic does not have anything to do with fixing >> the deepening of shallow clones nor giving an extended error message from >> non-fast-forward git-push, I queued the series after reverse-rebasing onto >> old db/vcs-helper~8, in order to keep the topic branch pure, instead of >> merging unrelated topics from maint, master or next into it. The result >> merged in 'pu' obviously has to match what you expected by applying the >> patches on top of 'next', and I am reasonably sure it does. > > I'd thought that topics in pu were carried as based on next, particularly > once they depend on something (e.g., the beginning of the series) in next. > I suppose there's better options, but what do you do to find them? (Feel > free to refer me to the "note from the maintainer" if it's there, but I > don't remember that detail) Oh, I was *not* complaining that you gave a patch based on 'next'. I was merely explaining what I did to your patch, in case somebody wonders why the output of "log -p -8 db/vcs-helper" looks different from what you posted on the list. I also wanted you to verify the result. > FWIW, there was a semantic mismerge in the original basing of this series > on 07a4a3b496, which I finally fixed in this version; the code to handle > NULL urls in builtin-fetch was after a new conversion of the url. > > In any case, I think both the reverse-rebase and merge are correct. Thanks. Actually, the fact your patch was based on 'next' did help me verify the result of the rebase and the merge. It is a good discipline to spend some extra effort to keep a topic pure if and only if the other topics that the topic textually depends on were of more dubious quality than the topioc itself. In such a case, there is no guarantee that they graduate ever, and the topic will be blocked without major effort later. It does not matter in practice when we are reasonably sure that other topics that the topic depends on are likely to be already in when the topic is completed. In this particular case, many of the changes the reverse rebase needed to remove are in fact already in master and some are even in maint, and in retrospect, there was not much point doing this only to risk mistakes. In fact, I originally merged the commits whose changes overlapped and were already in master (Nico's "deepening shallow", Matthieu's "give better warning to non-fast-forward push", to name a few) on top of the part of db/vcs-helper that was already in 'next', and then applied your patches on top of the result, as a middle ground solution. The topic would not have been as pure as the result I pushed out, but it would still have been much better than merging the whole master before applying the series. The principle of keeping the topic branch pure in this case may fall into my OCD ;-). -- 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