![]() This makes it a lot harder to see that there were 3 commits that went together. * 0f94937 Pull gmaya for a huge number of changes * db092d0 Remove unused functions in hackxprt.py * bc6f1cd Refactor hackxprt.py against new chan data type Had I not used the -no-ff flag, I would have had this history: * 728168e Get rednose working in mayapy through runtests.py I used git merge -no-ff fixHackExport from master to leave that little bubble there so I could see that those 3 commits went together, and were at one point their own little branch, even though they never diverged, because the parent branch didn't create anything new before I merged back in. * c607517 Update hackxprt against the latest in gmaya | * 0f94937 Pull gmaya for a huge number of changes | * db092d0 Remove unused functions in hackxprt.py | * bc6f1cd Refactor hackxprt.py against new chan data type Here's an example: * 728168e Get rednose working in mayapy through runtests.py ![]() I've done this quite often on my own projects. ![]() You may want to create the bubble anyway, though. The bottom branch was merged back in before the top branch could diverge with its own, new commits. It wasn't necessary to make a merge bubble here, because the branch at the bottom doesn't diverge from the branch at the top. You can of course use the -no-ff flag to make the commit bubble, even if there are no divergent commits: *-*-*-* There's no reason to create a new bubble around which divergent lines describe alternate histories. There are no divergent commits in a potential FF merge situation, so there's no need to make a new commit in which to tie together the discrepancies. The "merge bubble" created when you do a normal merge is itself information it tells you that the commits on either branch surrounding the bubble were made independently of each other, and were then merged/resolved at the end of the bubble: *-*-*-*-*-* An FF merge does this by just moving the ancestor to point at the same commit as its descendant, and it only works when they're in a straight line with each other, as above. The point of a merge is to bring two lines of development back into sync. It hasn't diverged from M's history in any way, and therefore there's 0 possibility of conflict, and thus nothing to resolve. F can't provide any new information to M. Here, doing a git merge F while on M can do an FF merge, because F is one of M's ancestors. There is only one situation where an FF merge can happen: F M Git rebase feature in my second repo produces a tree that looks like this: * 9c85e7d (HEAD, master, feature) File4 onto feature Git merge feature in my first repo produces a tree that looks like this: * 9c85e7d (HEAD, master, feature) File4 onto feature ![]() I then make a copy of this repo (using cp, if that matters), to run my experiment: * dae9b14 (HEAD, master) File2 onto master My git-tree looks like this: * 9c85e7d (feature) File4 onto feature Let's say I create a repo with two branches, master and feature: file1 and file2 are added onto master and file3 and file4 are added onto feature. It appears to me that fast-forward merging and rebasing are the same. Sorry if this is a basic question, but I'm a beginner trying to understanding the differences between merging and rebasing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |