Easily exclude commits on a merge based on some condition

Question

My eyes are destroyed. I am using a screen reader.

We are using git as our version control system on our project. We host our own server and use ssh to access it. We put each module under separate branches, then merge them all to a branch called dev for testing. Then when we determined that everything is stable, we merge dev to master.

Lately I am finding we are using remote branches in an unusual way. For example, suppose my partner found a bug he couldn't fix. Tipically I would ask him to read the code and suggest some fixes. If that is imposible (e.g. he does not know what to read or code is too long), we do the following.

• He commits the file containing the bug and pushes it to the remote branch.
• I would then pull his last commit and read his code and try to understand the bug.
• This repeats over and over until the bug is fixed. Sometimes I would ask him to push related files to the current file (E.G. maybe the problem is how json data is formatted so I have to read the file that submits the json object to the current file.)

For me, Git made this process very easy. I now have a way to personally inspect someones code without annoying people to reread a large portion of their code to me if I want something clarified. However, I believe we are using commits in a very bad way. I couldn't easily delete those commits in the local branch because they are already pushed into the remote branch.

My first solution is: when merging my module to dev, I would exclude all commits that are not real commits using some identifier or some range. The problem is the commits are scattered depending on when the bug occurred and what time. Rebasing them could be very time consuming and unproductive to the other developers on the team. I don't know how to achieve what I want.

What should I do?

• Becuzz: So am I understanding you correctly that you don't want to do an interactive rebase (git rebase -i) because of the time commitment? Or is it because of the lack of value for the effort and time expended? If it is the former, I'm not sure there is anything you can do short of writing a script to download your repo periodically, looking for commits with some identifier and squashing / removing the commits then force pushing (which will cause so many other problems). If it's the latter (low value), then what's the harm of just leaving them there?
• Becuzz: Another alternative is to do a squashed merge (git merge --squash) if you are OK with turning the whole branch into a single commit when you merge.
• lightning_missile: @Becuzz "If it's the latter (low value), then what's the harm of just leaving them there?" - I always thought of commits as iterations (how code evolves). I don't think there are really some harm, but commit messages like "change index to 0" or "check for null" looks like garbage if the only thing I'm doing on those commits is something like "change first pagination number to 1".
• Becuzz: Sounds like better commit messages might be a solution. Rather than "change index to 0", how about "Fixed bug in the FooBar module / feature where indexing was starting at the wrong number to fix bug XXX". Make the commit messages meaningful so that someone can get an accurate idea of what prompted the changes (or what changed) from reading the message. If I'm coming back in 3 months to see why some **** dev broke some function, it'll be nice to see that bug 123456 prompted the change. Then I can check if the bug was fixed incorrectly or if the client just can't decide what they want.
• Bart van Ingen Schenau: @Becuzz: As I understand it, these commits are not proper bug fixes, but rather attempts at a bugfix that are communicated between developers by means of git.

Answer 1

Keep the commits. They are REAL commits.

When viewing the history, only look at the branch merge commits. These contain all the changes in one commit.

git log --merges

Check out the other advanced git log features which might help with a screen reader.

https://www.atlassian.com/git/tutorials/git-log

• lightning_missile: But how about other developers? For example, I asked a friend to give me his version of file1.php to find what the problem is. What kind of message would be appropriate for such a commit given it's wierd to be a commit anyway? I can probably ask them to do as I do and just look at the merged commits, but they might want to look at a single commit they made. Most importantly, I fear by keepping the rubbish commits, I am making their life a little bit harder because those commits are only for my benifit.
• Ewan: maybe i don't understand how you are using git. for me it is normal to commit every few minutes. pushing those commits to a remote repo so someone else can view my code, for code review or a PR is a normal part of work, not 'rubbish commits'
• lightning_missile: I am blind. I use a screen reading software to write code. Sometimes one of developers on my team would ask for my help in fixing his bug. He could read the code to me, or if the code is large, I would ask him to push the buggy file to the remote branch so I can pull it and read it on my machine which has the screen reader. So you see those commits aren't real commits, I just use git to help me read other people's code easier if they want me too. Their machines does not have a screen reader. My problem is how can I disregard those useless commits during a merge. Hope this is clearer now.
• Ewan: when you say 'push the buggy file' you mean the dev isnt pushing his whole branch?
• Ewan: I would say, 'push your branch, I will look at the file in context'