3 ms·

A thought not universally shared. Intel was our biggest customer and when they saw the quality of the breadcrumbs produced by our gui check in tool vs the comm

A thought not universally shared. Intel was our biggest customer and when they saw the quality of the breadcrumbs produced by our gui check in tool vs the command line checkins they were smart enough to push hard that everyone used the guis. I get why, as a dev, you want git commit -m'Fixed bug' but as the debugger guy, the reviewer gui, anyone who reads the code, that's a horrible thing to do to those readers. Who, if you wait long enough, will be you. And I'll laugh my ass off at all the lazy committers who really could use more breadcrumbs when they have to debug their code later. Been there, done that, I haven't worked with people that lazy in decades. edit: since HN won't let me extend the thread, let me reply to the comment below because BK does do something special. The GUI for checkins presents you with a list of files, a place to type comments, and a big pane that shows the diffs. You type in comments for the first file, go to the next, type in comments (yes, there is a way to say use the previous comments). As you move from file to file, the bottom pane shows the diffs for that file so you can see what changed in that file. The special sauce, that Git most definitely does not have, is when you get to the last file, which in BK is the ChangeSet file, this is where you would type the commit message. What are the diffs? There aren't any so we stuff all the comments you just typed on individual files. What does that do? Well, on the files you are usually typing in details of how you did this or that, when you get to all of those comments, you naturally uplevel and type in why you were doing all that. It dramatically increases the usefulness of commit messages. That's why Intel pretty much mandated the use of the gui checkin vs the command line checkin.

kadenshep 9y ago
To anyone reading, bitkeeper does nothing special in this regard. Enforce commit message standards, plenty of platforms and systems built around git (and literally every other SCM) have support for this. Here's what he's taking about: http://www.bitkeeper.org/man/citool.html http://www.bitkeeper.org/man/citool.html and http://www.bitkeeper.org/man/templates.html http://www.bitkeeper.org/man/templates.html Here is git's analogous feature: https://robots.thoughtbot.com/better-commit-messages-with-a-gitmessage-template https://robots.thoughtbot.com/better-commit-messages-with-a-... It's possibly the least interesting and least unique selling point an SCM can have. It's really funny that you keep bringing up this example around the thread. EDIT: To respond to the above edit: Again, he's Proving The Point. Commits should be atomic. If you have to individually comment on file changes then the correct thing to do would be to put those in their own commit, no? I'm not really sure what's being described is necessarily a cool feature, but rather a way to avoid making sure your changes are truly related. I honestly don't see the point. This seems like a feature that was written because of the decisions that were made into how BitKeeper works internally, not because it's a fantastic idea. You can get the same thing with atomic commits in git. You comment per file, because BK tracks changes per file. Git does not do this. You should be making your commits atomic because git is tracking the actual content. Atomic commits will accurately describe what's being changed, and then of course those all get lumped together in a patch/PR. Git isn't lacking the feature you're describing, it just kind of is there without any extra data tracking required, because it's not making up for technical design decisions.

kadenshep 9y ago

To anyone reading, bitkeeper does nothing special in this regard. Enforce commit message standards, plenty of platforms and systems built around git (and literally every other SCM) have support for this. Here's what he's taking about: http://www.bitkeeper.org/man/citool.html http://www.bitkeeper.org/man/citool.html and http://www.bitkeeper.org/man/templates.html http://www.bitkeeper.org/man/templates.html Here is git's analogous feature: https://robots.thoughtbot.com/better-commit-messages-with-a-gitmessage-template https://robots.thoughtbot.com/better-commit-messages-with-a-... It's possibly the least interesting and least unique selling point an SCM can have. It's really funny that you keep bringing up this example around the thread. EDIT: To respond to the above edit: Again, he's Proving The Point. Commits should be atomic. If you have to individually comment on file changes then the correct thing to do would be to put those in their own commit, no? I'm not really sure what's being described is necessarily a cool feature, but rather a way to avoid making sure your changes are truly related. I honestly don't see the point. This seems like a feature that was written because of the decisions that were made into how BitKeeper works internally, not because it's a fantastic idea. You can get the same thing with atomic commits in git. You comment per file, because BK tracks changes per file. Git does not do this. You should be making your commits atomic because git is tracking the actual content. Atomic commits will accurately describe what's being changed, and then of course those all get lumped together in a patch/PR. Git isn't lacking the feature you're describing, it just kind of is there without any extra data tracking required, because it's not making up for technical design decisions.