4 ms·

So tell me, this is readable for you? https://imgur.com/GCWsFwU https://imgur.com/GCWsFwU And I'm not cherry-picking... I usually see much, much worse git log

So tell me, this is readable for you? https://imgur.com/GCWsFwU https://imgur.com/GCWsFwU And I'm not cherry-picking... I usually see much, much worse git logs than this from merge-commit users. In fact, if I scroll down, this is what it looks like: https://imgur.com/a/nQXWa4Q https://imgur.com/a/nQXWa4Q Edit: For a point of comparison, here's one of my projects using atomic commits and rebases: https://imgur.com/a/vTZ5qxT https://imgur.com/a/vTZ5qxT

monsieurbanana 8y ago
Let me fix this for you... git log --first-parent With that switch and writing correct merge-commit messages you get the best of both approaches.
- scrollaway 8y ago
  "And correct merge-commit messages" -- I've NEVER seen those. In 99.99999% of projects, this is what you'll get: https://imgur.com/a/4f6Hw2w https://imgur.com/a/4f6Hw2w
  - monsieurbanana 8y ago
    You're moving goalposts. Yes almost nobody changes the default merge-commit message. But that's because, like you, they don't know about --first-parent (or they just don't care about commit history) That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.
    - scrollaway 8y ago
      … am I moving goalposts? I do know about --first-parent and it is not intended to be a feature to make git logs readable. It gets rid of nearly the entire git history. At this point, you might as well simply go to the github page and look at merged PRs; that will actually get you something readable. I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue. --first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?
      - btschaegg 8y ago
        Not to argue in either direction, but I think you should be able to "fix" the bisect problem with a script like this: #!/bin/bash bad=$(git rev-parse "$1") good=$(git rev-parse "${@:2}") git bisect start "$bad" $good filter=$(echo "$good" | sed 's/^/^/' | cat <(echo "$bad") - | xargs) comm -13 \ <(git rev-list --first-parent $filter | sort) \ <(git rev-list $filter | sort) \ | xargs git bisect skip I haven't tested it all too thoroughly, but from what `git bisect view` tells me, this seems to work like a `git bisect --first-parent`. I'm wondering why there is no such option... For anyone unfamiliar with git extension scripts: You should be able to put it in an executable (`chmod +x`) file (say `git-bisect-branch`) in your $PATH to make it usable (`git bisect-branch $bad $good...`).
  - gdfasfklshg4 8y ago
    Good branch names end up in the default commit by default...
deleted 8y ago
[deleted]
gdfasfklshg4 8y ago
The first example does not rebase first... My projects also have a linear progression. They look like... * -- Bugfix * -- Feature B | \ | * -- Implement some other logical part of feature B | * -- Implement first logical part feature B | / * -- Feature A
- MayeulC 8y ago
  I am curious as to why this is downvoted? This can be a valid answer to the parent's concern.
  - deleted 8y ago
    [deleted]
mkesper 8y ago
You'd want to use a repo that only allows fast-forward and rebase everything that would be a merge. We use Gerrit for that.
- scrollaway 8y ago
  Yup, that's what I'm arguing in favour of. I systematically disable merge commits on every repo I manage. I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.
  - gdfasfklshg4 8y ago
    > I systematically disable merge commits on every repo I manage. Do you have buy in from other team members for this? Also what do you do if master needs to be merged back into develop? Do you really rebase develop and make everyone fiddle with all their feature branches?
    - scrollaway 8y ago
      There is no develop, master is continuously deployed. Users can create feature branches and PR them but there is just no merge commit, they are pulled in fast-forward. In projects where I need stable releases, I create stable/1.2.x type branches off of master at a point in time. I cherry-pick commits onto it after the first release if there are subsequent ones. You can see this in action here: https://github.com/dj-stripe/dj-stripe/commits/master https://github.com/dj-stripe/dj-stripe/commits/master https://github.com/dj-stripe/dj-stripe/commits/stable/1.2 https://github.com/dj-stripe/dj-stripe/commits/stable/1.2
  - u801e 8y ago
    Though fast forward merge commits (where the referenced tree is the same as referenced by the second parent) can be useful because they provide a way for you to group related commits for a feature together (git log merge_commit^..merge_commit^2). There are features that require more than a single commit to implement.
vsl 8y ago
Let me this fix for you too: don’t merge master into featur branches. What kind of insanity is that?

monsieurbanana 8y ago

Let me fix this for you... git log --first-parent With that switch and writing correct merge-commit messages you get the best of both approaches.

scrollaway 8y ago
"And correct merge-commit messages" -- I've NEVER seen those. In 99.99999% of projects, this is what you'll get: https://imgur.com/a/4f6Hw2w https://imgur.com/a/4f6Hw2w
- monsieurbanana 8y ago
  You're moving goalposts. Yes almost nobody changes the default merge-commit message. But that's because, like you, they don't know about --first-parent (or they just don't care about commit history) That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.
  - scrollaway 8y ago
    … am I moving goalposts? I do know about --first-parent and it is not intended to be a feature to make git logs readable. It gets rid of nearly the entire git history. At this point, you might as well simply go to the github page and look at merged PRs; that will actually get you something readable. I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue. --first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?
    - btschaegg 8y ago
      Not to argue in either direction, but I think you should be able to "fix" the bisect problem with a script like this: #!/bin/bash bad=$(git rev-parse "$1") good=$(git rev-parse "${@:2}") git bisect start "$bad" $good filter=$(echo "$good" | sed 's/^/^/' | cat <(echo "$bad") - | xargs) comm -13 \ <(git rev-list --first-parent $filter | sort) \ <(git rev-list $filter | sort) \ | xargs git bisect skip I haven't tested it all too thoroughly, but from what `git bisect view` tells me, this seems to work like a `git bisect --first-parent`. I'm wondering why there is no such option... For anyone unfamiliar with git extension scripts: You should be able to put it in an executable (`chmod +x`) file (say `git-bisect-branch`) in your $PATH to make it usable (`git bisect-branch $bad $good...`).
- gdfasfklshg4 8y ago
  Good branch names end up in the default commit by default...

deleted 8y ago

[deleted]

gdfasfklshg4 8y ago

The first example does not rebase first... My projects also have a linear progression. They look like... * -- Bugfix * -- Feature B | \ | * -- Implement some other logical part of feature B | * -- Implement first logical part feature B | / * -- Feature A

MayeulC 8y ago
I am curious as to why this is downvoted? This can be a valid answer to the parent's concern.
- deleted 8y ago
  [deleted]

mkesper 8y ago

You'd want to use a repo that only allows fast-forward and rebase everything that would be a merge. We use Gerrit for that.

scrollaway 8y ago
Yup, that's what I'm arguing in favour of. I systematically disable merge commits on every repo I manage. I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.
- gdfasfklshg4 8y ago
  > I systematically disable merge commits on every repo I manage. Do you have buy in from other team members for this? Also what do you do if master needs to be merged back into develop? Do you really rebase develop and make everyone fiddle with all their feature branches?
  - scrollaway 8y ago
    There is no develop, master is continuously deployed. Users can create feature branches and PR them but there is just no merge commit, they are pulled in fast-forward. In projects where I need stable releases, I create stable/1.2.x type branches off of master at a point in time. I cherry-pick commits onto it after the first release if there are subsequent ones. You can see this in action here: https://github.com/dj-stripe/dj-stripe/commits/master https://github.com/dj-stripe/dj-stripe/commits/master https://github.com/dj-stripe/dj-stripe/commits/stable/1.2 https://github.com/dj-stripe/dj-stripe/commits/stable/1.2
- u801e 8y ago
  Though fast forward merge commits (where the referenced tree is the same as referenced by the second parent) can be useful because they provide a way for you to group related commits for a feature together (git log merge_commit^..merge_commit^2). There are features that require more than a single commit to implement.

vsl 8y ago

Let me this fix for you too: don’t merge master into featur branches. What kind of insanity is that?