10 ms·

Yay now it's only missing rebase then merge with --no-ff to be useful to me!

by mfontani 10y ago

deleted 10y ago
[deleted]
lmm 10y ago
Your use case is super weird. If you're going to do a --no-ff merge why would you rebase?
- tylorr 10y ago
  My guess is it keeps the history as linear as possible while still being able to undo the merge if necessary.
  - mfontani 10y ago
    Precisely correct, rebasing prior to merging ensures the branch about to be merged has no conflicts with the one being merged to, or that conflicts have been fixed in the branch prior to the merge… and merging with --no-ff ensures that the history of the branch gets kept "visually" when doing Git archaeology, as well as that the merge was "wanted"
    - eridius 10y ago
      > […] ensures the branch about to be merged has no conflicts with the one being merged to So does merging. > or that conflicts have been fixed in the branch prior to the merge Conflicts that show up in rebasing may not necessarily show up during a merge. Having to fix a bunch of conflicts that only occur because you rebased is tedious and introduces a source of potential error.
- rchipman 10y ago
  It is useful for when you want the commits to be clearly grouped in the log (because they belong together conceptually), but you don't want to squash them all together (because, for example, you still want to be able to browse/bisect/revert some of those commits in the future). Also, it is easy to revert the merge commit if you want to undo the whole group at once.
  - lmm 10y ago
    > It is useful for when you want the commits to be clearly grouped in the log (because they belong together conceptually) Surely there must be a way to tell git to show history in that form even with branches that haven't been rebased?
    - falsedan 10y ago
      Tell git? sure. Tell git CLI tools? …
      - eridius 10y ago
        It's easy. Use the --topo-order flag. This makes it show commits in topological order, which should group all commits on the branch together.
- stormbrew 10y ago
  I guess it could be useful for putting conflict fixes in the commits themselves rather than all in a lump in the merge commit. And it could also help have useful commits for bisecting. From an aesthetic perspective, rebasing and ff merging also destroys the history of what commit is related to what work branch.
- rdtsc 10y ago
  It is to have a single merge commit which is simpler to revert.
  - falsedan 10y ago
    It also stored metadata about the branch (its name) so that you can recover and recreate it if necessary: imagine if you found out that two branches had been merged in the wrong order, and the refs had been deleted. With rebase && --no-ff, the merge commit literally tells you the ref that was attached to the second parent when the merge occurred.
- jgraham 10y ago
  After being initially skeptical I was convinced by a colleague that this is a good model. The merge commit acts as a kind of "pushlog"; it tells you what actually landed together as a single unit. It probably also tells you what passed CI; although many projects state that you shouldn't have individual commits that don't pass CI it's rare that this is enforced below the level of the PR. That should be good for bisection. Because the commits are always rebased onto master (and of course you never allow merge commits other than from code being integrated into master) your history is relatively clean, you don't get multiple overlapping branches, but something like M1 ------- M2 -------- M3 \ B1 - B2 / \ C1 - C2 / Because the merges are --ff-only you don't get the confusing situation where the merge commits themselves contain changes. In principle this seems like the ideal way to use the tools git provides. However I understand there are some minor rough edges e.g. with magic needed to tell git bisect how to only try the merge commits.
  - rdtsc 10y ago
    Yeah, looking at the commit history tree visually convinced me. Then was convinced even more after having to revert a ff merge.
  - lmm 10y ago
    > your history is relatively clean, you don't get multiple overlapping branches Right, but what's the benefit of that? You still need to understand a history with merges in, in which case it seems like you might as well get the safety advantages of not rebasing.
    - wanderr 10y ago
      what are the safety advantages?
      - lmm 10y ago
        Rebasing tends to induce more conflicts than merging, tends to lead to force-pushing which is often dangerous ( "--force-with-lease" is safer but a lot longer than "-f" ), and has to be done after PR review which bypasses one set of checks particularly in the case where conflicts have to be fixed.
wanderr 10y ago
I came here to say the same thing. The rebase option is awesome IMO because it causes git to show the commits in the chronological position of when they were added to master rather than jumbled in back to when the author originally started working on it. But we still want merge commits to make it easy to find the pull request that introduced the change.

Yay now it's only missing rebase then merge with --no-ff to be useful to me!

deleted 10y ago

[deleted]

lmm 10y ago

Your use case is super weird. If you're going to do a --no-ff merge why would you rebase?

tylorr 10y ago
My guess is it keeps the history as linear as possible while still being able to undo the merge if necessary.
- mfontani 10y ago
  Precisely correct, rebasing prior to merging ensures the branch about to be merged has no conflicts with the one being merged to, or that conflicts have been fixed in the branch prior to the merge… and merging with --no-ff ensures that the history of the branch gets kept "visually" when doing Git archaeology, as well as that the merge was "wanted"
  - eridius 10y ago
    > […] ensures the branch about to be merged has no conflicts with the one being merged to So does merging. > or that conflicts have been fixed in the branch prior to the merge Conflicts that show up in rebasing may not necessarily show up during a merge. Having to fix a bunch of conflicts that only occur because you rebased is tedious and introduces a source of potential error.
rchipman 10y ago
It is useful for when you want the commits to be clearly grouped in the log (because they belong together conceptually), but you don't want to squash them all together (because, for example, you still want to be able to browse/bisect/revert some of those commits in the future). Also, it is easy to revert the merge commit if you want to undo the whole group at once.
- lmm 10y ago
  > It is useful for when you want the commits to be clearly grouped in the log (because they belong together conceptually) Surely there must be a way to tell git to show history in that form even with branches that haven't been rebased?
  - falsedan 10y ago
    Tell git? sure. Tell git CLI tools? …
    - eridius 10y ago
      It's easy. Use the --topo-order flag. This makes it show commits in topological order, which should group all commits on the branch together.
stormbrew 10y ago
I guess it could be useful for putting conflict fixes in the commits themselves rather than all in a lump in the merge commit. And it could also help have useful commits for bisecting. From an aesthetic perspective, rebasing and ff merging also destroys the history of what commit is related to what work branch.
rdtsc 10y ago
It is to have a single merge commit which is simpler to revert.
- falsedan 10y ago
  It also stored metadata about the branch (its name) so that you can recover and recreate it if necessary: imagine if you found out that two branches had been merged in the wrong order, and the refs had been deleted. With rebase && --no-ff, the merge commit literally tells you the ref that was attached to the second parent when the merge occurred.
jgraham 10y ago
After being initially skeptical I was convinced by a colleague that this is a good model. The merge commit acts as a kind of "pushlog"; it tells you what actually landed together as a single unit. It probably also tells you what passed CI; although many projects state that you shouldn't have individual commits that don't pass CI it's rare that this is enforced below the level of the PR. That should be good for bisection. Because the commits are always rebased onto master (and of course you never allow merge commits other than from code being integrated into master) your history is relatively clean, you don't get multiple overlapping branches, but something like M1 ------- M2 -------- M3 \ B1 - B2 / \ C1 - C2 / Because the merges are --ff-only you don't get the confusing situation where the merge commits themselves contain changes. In principle this seems like the ideal way to use the tools git provides. However I understand there are some minor rough edges e.g. with magic needed to tell git bisect how to only try the merge commits.
- rdtsc 10y ago
  Yeah, looking at the commit history tree visually convinced me. Then was convinced even more after having to revert a ff merge.
- lmm 10y ago
  > your history is relatively clean, you don't get multiple overlapping branches Right, but what's the benefit of that? You still need to understand a history with merges in, in which case it seems like you might as well get the safety advantages of not rebasing.
  - wanderr 10y ago
    what are the safety advantages?
    - lmm 10y ago
      Rebasing tends to induce more conflicts than merging, tends to lead to force-pushing which is often dangerous ( "--force-with-lease" is safer but a lot longer than "-f" ), and has to be done after PR review which bypasses one set of checks particularly in the case where conflicts have to be fixed.

wanderr 10y ago

I came here to say the same thing. The rebase option is awesome IMO because it causes git to show the commits in the chronological position of when they were added to master rather than jumbled in back to when the author originally started working on it. But we still want merge commits to make it easy to find the pull request that introduced the change.