6 ms·

I'm surprised there is no "commit tree" drawing to illustrate this. Basically it adds the commits to the master branch without a merge commit: e.g.: maste

by dorianm 10y ago

I'm surprised there is no "commit tree" drawing to illustrate this. Basically it adds the commits to the master branch without a merge commit: e.g.: master: A - B - C feature: D - E master (after merge): A - B - C - D - E See: https://help.github.com/articles/about-pull-request-merges https://help.github.com/articles/about-pull-request-merges

mfontani 10y ago
Merging with --no-ff the just-rebased branch would've had the effect of adding a merge commit detailing what branch was indeed merged then.
misnome 10y ago
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 with no conflicts) and then merged e.g. master: A - B - C feature: D - E post-master: A - B - C --------- F \- D - E -/ So in the view of the master the entire branch is one clean commit, but the branch history is still preserved.
- 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).

by dorianm 10y ago

mfontani 10y ago

Merging with --no-ff the just-rebased branch would've had the effect of adding a merge commit detailing what branch was indeed merged then.

misnome 10y ago

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 with no conflicts) and then merged e.g. master: A - B - C feature: D - E post-master: A - B - C --------- F \- D - E -/ So in the view of the master the entire branch is one clean commit, but the branch history is still preserved.

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).