bill lam <cbill.lam@xxxxxxxxx> writes: > Thank you for detail explanation. From what you described, I begin > with master commit D, > $ git checkout -b deploy > $ git commit --allow-empty -m deploy But why on earth would you want to use --allow-empty? There is no reason for that. Just let deploy be where it is when you created it (until you actually add something to it). > E > /^ deploy > ---A---B---C---D > ^ master > > $ git rebase -i A > > v deploy > B'--C'--D'--E' > / > ---A---B---C---D > ^ master > > since E is an empty commit, I suppose content of D' E' and D are > identical at this point. Is that correct? Assuming you didn't intentionally change it during rebase, yes. > If several months later, I forget which is the common ancestor for > master and deploy, how do I generate the above graph or identify > commit A as the common ancestor for these two branches? That is exactly what git does all the time. You can use many command. For instance git log --graph master...deply whill show you both branches, starting from their common ancestor. "git merge-base deploy master" will tell you that the common ancestor is. Etc. -- David Kågedal -- 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