3 ms·

Personally I like the combined approach where the feature is first rebased (which I think should be done if possible because then it guarantees a clean commit w

• masklinn 10y ago
  That would be more useful, as git log tools tend not to deal fantastically well with concurrently running branch, especially with interleaved side-branches (fork branch 1, fork branch 2, merge branch 1, merge branch 2, history looks like garbage in most Git tools)
  • geofft 10y ago
    You can get a lot better results with `git log -m --first-parent`, which effectively shows you only the merge commits, and shows all changes that were merged in as if they belonged to the merge commit. I have a `git log0` alias for this, as well as `git blame0` and `git show0`.
    • masklinn 10y ago
      > You can get a lot better results with `git log -m --first-parent` Yes, however that only works in the CLI, not in any Git GUI I know of (though GTK Bazaar log would pretty much do that, folding merge commits & following the mainline by default).
• eridius 10y ago
  I don't understand why you want to rebase in this scenario. All you're doing is throwing away information (the point where the branch diverged), but you're not recovering anything or making the history any "cleaner". Not only this, but you're introducing a potential for error, because a branch that merges cleanly may not necessarily rebase cleanly (e.g. if the branch made a change that would conflict, but then backed out that change in a subsequent commit).