3 ms·

Not sure why you are downvoted. I thought exactly the same thing after looking at the commit. As a software developer, the habit committing smaller changes has

by vog 9y ago

Not sure why you are downvoted. I thought exactly the same thing after looking at the commit. As a software developer, the habit committing smaller changes has saved me a lot of time. Even more so, a clean distinction between refactorings (e.g. moving or renaming things) and functional changes (e.g. adding or fixing things) is vital to any large code base. As the saying goes: "for each desired change, make the change easy (warning: this may be hard), then make the easy change" (Kent Beck)

blueflow 9y ago
I wonder what the creators of git think about your opinion on how to use it properly... Jokes aside, what you see it usually just the squashed commit submitted for merge. With 6 million git objects, you reconsider twice having each change in a single commit.
- bonzini 9y ago
  That's absolutely wrong. Linux never squashes merge commits. With my Linux maintainer hat on, I would have never accepted that commit.
  - deleted 9y ago
    [deleted]
- lomnakkus 9y ago
  > I wonder what the creators of git think about your opinion on how to use it properly... Are you the creator of git? If not, how exactly are you qualified to judge "proper" usage -- by YOUR standard you're not qualified yourself, so...? (I realized it was a joke, but I offer the above as a counterpoint to the satirical/ironic element of the joke. My opinion is that the originator doesn't get special treatment. But then the point wasn't git, it was what/how things get merged into the Linux kernel. The mechanism is entirely immaterial.) Squashing commits for merge into Linux is not standard practice AFAIK... and happily I see an Linux committer has async'ly backed me up on this. Generally the preference I see, where git is concerned (not sure about the kernel), is that everything is rebased right into the master branch to avoid merge graphs getting absurd.
  - blueflow 9y ago
    I meant squashing before sending upstream, not all kernel development happens in public. Still, i think squashing still happens in the public trees: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c609698569578913ad40bb160b97c3f6cfa15ec https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... EDIT: Actually, thats indeed a merge, but the diff is still showed with it, which confused me (because conflict-less merges are usually +0/-0).
    - lomnakkus 9y ago
      OK, that's fair enough. Let's not be enemies :)
- vog 9y ago
  > what you see it usually just the squashed commit submitted for merge Then __david__'s argument "could you spot the error?" is moot, because the squashed commit (hopefully!) was not the subject of review, but the smaller commits.

by vog 9y ago

blueflow 9y ago

I wonder what the creators of git think about your opinion on how to use it properly... Jokes aside, what you see it usually just the squashed commit submitted for merge. With 6 million git objects, you reconsider twice having each change in a single commit.

bonzini 9y ago
That's absolutely wrong. Linux never squashes merge commits. With my Linux maintainer hat on, I would have never accepted that commit.
- deleted 9y ago
  [deleted]
lomnakkus 9y ago
> I wonder what the creators of git think about your opinion on how to use it properly... Are you the creator of git? If not, how exactly are you qualified to judge "proper" usage -- by YOUR standard you're not qualified yourself, so...? (I realized it was a joke, but I offer the above as a counterpoint to the satirical/ironic element of the joke. My opinion is that the originator doesn't get special treatment. But then the point wasn't git, it was what/how things get merged into the Linux kernel. The mechanism is entirely immaterial.) Squashing commits for merge into Linux is not standard practice AFAIK... and happily I see an Linux committer has async'ly backed me up on this. Generally the preference I see, where git is concerned (not sure about the kernel), is that everything is rebased right into the master branch to avoid merge graphs getting absurd.
- blueflow 9y ago
  I meant squashing before sending upstream, not all kernel development happens in public. Still, i think squashing still happens in the public trees: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c609698569578913ad40bb160b97c3f6cfa15ec https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... EDIT: Actually, thats indeed a merge, but the diff is still showed with it, which confused me (because conflict-less merges are usually +0/-0).
  - lomnakkus 9y ago
    OK, that's fair enough. Let's not be enemies :)
vog 9y ago
> what you see it usually just the squashed commit submitted for merge Then __david__'s argument "could you spot the error?" is moot, because the squashed commit (hopefully!) was not the subject of review, but the smaller commits.