4 ms·

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.

solutionyogi 11y ago
Then rebase interactive is your friend. Clean up your feature branch BEFORE merging in to the release branch.
chaitanya 11y ago
So do a clean up before broadcasting your history to others. See https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net... One trick that can really help with this is `git commit --amend`, which allows you to amend the last commit. If you encounter a bug or a typo in the your last commit, add your fix to the index and then do `git commit --amend`. This will replace your last commit with a new one that contains your latest fix. Of course, this should only be done if you did not push your last commit to remote. For fixes to earlier commits, I don't bother much, and just live with the trivial commit. Though if I end up making several trivial commits in one setting, I do a cleanup and merge this fixes in one commit before pushing.
gingerlime 11y ago
slightly OT, but I wonder if anyone has an answer for this. We use feature branches and rebase before merging to master (mostly for the reason stated above - keep things clean and treating the branch as a single logical unit, not caring about higher-resolution history within the branch). However, some times, especially since we typically merge on Github from a PR, it's easy to forget to rebase, or notice that there are more commits. So our history is mostly clean, but occasionally contain some "messy" commits. I know we can reset master, but it feels a bit too risky compared to living with a bit of noise when mistakes happen. Anyone knows of some way to prevent / alert / notify or otherwise help us avoid this rather common mistake before it happens?
- kansface 11y ago
  Stop merging from Github?
  - gingerlime 11y ago
    Yes, that's one possible solution, but feels like we're punishing ourselves for every merge for the sake of avoiding a reasonably-rare issue. We're reviewing PRs on github, so it's much more convenient to merge them on the spot.
- jes5199 11y ago
  when you look at the PR in github it doesn't look obvious that some of the commits are bad?
  - gingerlime 11y ago
    The commits aren't bad as such, just noisy, typically. Github gives you a nice diff of the whole branch against master, so we normally don't pay attention to individual commits. We look at the change as a whole before merging it. There is an indicator for the number of commits and you can view each one individually, but somehow it's so easy to forget.
- hayd 11y ago
  I recommend regularly updating your branch of master via fast-forward. That way if you are working with a slightly different git history, git will complain loudly (refuse to update). This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master. Catch it early. https://leanpub.com/sanegit https://leanpub.com/sanegit (I consult/train on this in SF/Bay area.)
  - gingerlime 11y ago
    I'm not sure I understand how this will solve my problem to be honest, and unfortunately it's not something we would seek to hire a consultant for.
aikah 11y ago
ask committers to use git rebase.

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.

solutionyogi 11y ago

Then rebase interactive is your friend. Clean up your feature branch BEFORE merging in to the release branch.

chaitanya 11y ago

So do a clean up before broadcasting your history to others. See https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net... One trick that can really help with this is `git commit --amend`, which allows you to amend the last commit. If you encounter a bug or a typo in the your last commit, add your fix to the index and then do `git commit --amend`. This will replace your last commit with a new one that contains your latest fix. Of course, this should only be done if you did not push your last commit to remote. For fixes to earlier commits, I don't bother much, and just live with the trivial commit. Though if I end up making several trivial commits in one setting, I do a cleanup and merge this fixes in one commit before pushing.

gingerlime 11y ago

slightly OT, but I wonder if anyone has an answer for this. We use feature branches and rebase before merging to master (mostly for the reason stated above - keep things clean and treating the branch as a single logical unit, not caring about higher-resolution history within the branch). However, some times, especially since we typically merge on Github from a PR, it's easy to forget to rebase, or notice that there are more commits. So our history is mostly clean, but occasionally contain some "messy" commits. I know we can reset master, but it feels a bit too risky compared to living with a bit of noise when mistakes happen. Anyone knows of some way to prevent / alert / notify or otherwise help us avoid this rather common mistake before it happens?

kansface 11y ago
Stop merging from Github?
- gingerlime 11y ago
  Yes, that's one possible solution, but feels like we're punishing ourselves for every merge for the sake of avoiding a reasonably-rare issue. We're reviewing PRs on github, so it's much more convenient to merge them on the spot.
jes5199 11y ago
when you look at the PR in github it doesn't look obvious that some of the commits are bad?
- gingerlime 11y ago
  The commits aren't bad as such, just noisy, typically. Github gives you a nice diff of the whole branch against master, so we normally don't pay attention to individual commits. We look at the change as a whole before merging it. There is an indicator for the number of commits and you can view each one individually, but somehow it's so easy to forget.
hayd 11y ago
I recommend regularly updating your branch of master via fast-forward. That way if you are working with a slightly different git history, git will complain loudly (refuse to update). This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master. Catch it early. https://leanpub.com/sanegit https://leanpub.com/sanegit (I consult/train on this in SF/Bay area.)
- gingerlime 11y ago
  I'm not sure I understand how this will solve my problem to be honest, and unfortunately it's not something we would seek to hire a consultant for.

aikah 11y ago

ask committers to use git rebase.