Hi, On Thu, 15 Jan 2009, Michael J Gruber wrote: > I'm not sure what -p is supposed to do: > > A) Should it preserve all merge commits which it would need to rewrite? > That is lot to ask. Previous behaviour (intended or not) seemed to be to > do nothing in this case where the merge connects master and work. > > B) Should it preserve only merges in side branches? I seem to mean by > that branches where the parents are on work and other branches but not > on master. The intention was this: $ git rebase -p master would need to rewrite _all_ commits that are in "master..". All of them, including the merge commits. The fact that I implemented it as "-i -p" is only due to technical reasons; I know (ahem, now I should put that into the past tense) the code base pretty well. An additional shortcut was to avoid rewriting commits when they did not need rewriting. IOW if the commit-to-pick has only parents that were _not_ rewritten, we can avoid cherry-picking or merging, and just reset --hard <original commit>. There was a problem, though; for some reason, the code as I did it fscked up the order of the commits when -p was specified. Therefore, rewritten commits had the wrong parents. I thought it should be easy to fix, but then I got a job that I actually like, so my Git time budget was tremendously reduced. > > The more I think about it, I think it's possible I broke it with the > > introduction of the "noop". > > It certainly worked after the noop introduction before the r-i-p series, > but not any more after. Umm... which rebase -i -p series do you mean? "noop" was introduced pretty recently if my Alzheimered brain does not fool me. Ciao, Dscho -- 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
