3 ms·
> The other has a git log that looks like this That's because, like GitHub itself, the documentation for them is not in the commit messages but in the pull-req
by rakoo 8y ago
> The other has a git log that looks like this
That's because, like GitHub itself, the documentation for them is not in the commit messages but in the pull-requests. Look at their PR page (https://github.com/pypa/pipenv/pulls https://github.com/pypa/pipenv/pulls) and individual PRs, you'll see that it's much better organized.
The difference is that now the source of truth is not git itself, but wherever the pull-requests are.
- ajmurmann 8y agoThat really ruins a lot of tooling. Going back through history to see when a bug might have been introduced; doing git blame to find out why a line of code is like it is... If you write his commit messages, you also get good PR messages for free.
- ajross 8y ago> the source of truth is not git itself, but wherever the pull-requests are. And you think storing that source of truth separately from the code is... a good thing?
- rakoo 8y agoI personally don't, that was just a way to explain the whys. But this whole thing is probably a good reason to ask whether staying in git, the completely decentralized VCS, to work in a centralized manner, is the best way to go. As the sibling comment evocated, our traditional tooling is limited in that way of working but that doesn't mean it's inherently bad; maybe we need new tools?