Junio C Hamano <gitster@xxxxxxxxx> writes: > "David Jeske" <jeske@xxxxxxxxxxxxxx> writes: > ... >> (2) From the documentation diagrams, it looks like the rebased A' has >> only (G) as a parent, not (A,G). If this is the case, why? (i.e. not >> connecting those nodes throws away useful information) > > You would rebase ONLY WHEN the project as the whole (either "other people > in the project", or "yourself down the road one year from now") is > interested mostly in the progress of 'master' D-E-F-G, and nobody cares > whether you developed your A (or B or C) on top of E or G. So the answer > is definite "no" --- the line you drew between A and A' is a useless > information. Nobody cares you did it first on top of E but then you have > redone the patches based on G (because things changed between E and G). The last sentence came out in somewhat inappropriate way. In the situation "rebase" (which is a way to help you pretend you did not start building on a stale codebase) is appropriate, nobody wants to know you did it first on E is what I meant. More importantly, _you_ do not want anybody to know. That is the whole reason you would rebase. With that clarification in mind, the explanation would flow more smoothly to this part... > If the fact that parallel developments have happened is important, instead > of the second picture like you drew, you will just do the real merge > naturally to create a merge "M" like the picture I drew above. So you have a choice between merging and rebasing. And your extra parents goes against the reason you chose rebasing in the first place. That is why we do not record the original parents anywhere. -- 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
