3 ms·

In a given team, mandating the squashing of commits essentially means admitting that pull requests' branch histories tend to be far from semantically valuable.

by vemv 6y ago

In a given team, mandating the squashing of commits essentially means admitting that pull requests' branch histories tend to be far from semantically valuable. Which can be perfectly fine, as it's hard to ensure that all developers use Git in an optimal way (I'm thinking of intentful use of interactive rebasing), uniformly. The only problem I find is when squash proponents claim their choice is superior. It's not; it's only superior if you aren't willing to maintain great history as you work on a given branch. Of course there are also added benefits to a fine-grained history, as the article mentions. My experience having maintained a production app with a fine-grained semantic history for 5 years is overwhelmingly positive. Understanding root causes, confidently reverting things etc becomes a much quicker job - particularly important when production is red.

josephg 6y ago
Right. The problem is that are two use cases for commits: - a historical, fine grained log of changes - and a log of merged features. There's value in keeping both of these data sets. But the commit log as it stands can't easily serve both masters. Once you can see the problem for what it is, the solution is simple. Instead of conflating these two use cases into the concept of a 'commit', we need separate tooling for each of these use cases. The commit log should probably house the historical record. And then we need a way to mark a set of commits as belonging to a particular feature's development. That could be achieved either by adding special support in git or via convention using commit messages. Either way, I want to be able to see the commits in my repository grouped by the feature that they belong to. And I want that data set browsable on github, referenced against the corresponding github issues when thats appropriate.
- avar 6y ago
  If you consistently use feature branches and have meaningful summary commit messages in the merge commits as they land on the mainline branch what you're describing is simply: git log --max-parents=1 git log --min-parents=2 E.g. try this on the git.git repository (not perfect there, since Junio doesn't use this pattern all the time), but it's good enough for a quick demo. The most useful convention in a DAG like git is to have the topology of your commits reflect your workflow.

by vemv 6y ago

josephg 6y ago

Right. The problem is that are two use cases for commits: - a historical, fine grained log of changes - and a log of merged features. There's value in keeping both of these data sets. But the commit log as it stands can't easily serve both masters. Once you can see the problem for what it is, the solution is simple. Instead of conflating these two use cases into the concept of a 'commit', we need separate tooling for each of these use cases. The commit log should probably house the historical record. And then we need a way to mark a set of commits as belonging to a particular feature's development. That could be achieved either by adding special support in git or via convention using commit messages. Either way, I want to be able to see the commits in my repository grouped by the feature that they belong to. And I want that data set browsable on github, referenced against the corresponding github issues when thats appropriate.

avar 6y ago
If you consistently use feature branches and have meaningful summary commit messages in the merge commits as they land on the mainline branch what you're describing is simply: git log --max-parents=1 git log --min-parents=2 E.g. try this on the git.git repository (not perfect there, since Junio doesn't use this pattern all the time), but it's good enough for a quick demo. The most useful convention in a DAG like git is to have the topology of your commits reflect your workflow.