6 ms·

Git is far from perfect. But, there's roughly half bullshit, half "yes but is it really an issue?" things here to me. Things like detailing the github process

by zobzu 14y ago

Git is far from perfect. But, there's roughly half bullshit, half "yes but is it really an issue?" things here to me. Things like detailing the github process and blaming git just does not work for example. Blaming additional git features that svn simply does not have.. is also nonsense to me. Finally, you CAN rewrite history in svn, its just extremely painful. In git it's not and.. its a good thing. I prefer USEABLE history than trashy commits. And don't tell me its about having proper devs making commits. As pointed out, you get external commits in git. You can't control them without refusing them and then what? In svn you don't even have the possibility to refuse them. Don't get me started on how svn is way more about the maintainer due to this...

lotyrin 14y ago
Yep. SVN having a culture where history is expected to be full of junk commits is not a feature. Pretty much all of the points here are things I love about git. I'd personally hate working in this author's ideal repository: too many people with direct commit access, no tracking of feature branches, messy merges, noisy history.
- eli 14y ago
  Well that's unfair. I think there are legitimate arguments to be made against rewriting history besides "I've been brainwashed by SVN."
  - clhodapp 14y ago
    Assuming that you restrict your rewriting to your own local repository (as is the widely-agree-upon best practice), what are some of these arguments?
michaelmior 14y ago
Rewriting history is probably the best part about git. Yes, it can be dangerous if you're not careful but I've found a clean history is very important. I regularly use the history as a view of what others on the team have been up to and to find when bugs were introduced. If many people are developing on the same branch, rebasing makes the history so much easier to read than having to parse merge commits and trying to mentally reconstruct the state of the individual developer's code base before the merge.
dasil003 14y ago
> I prefer USEABLE history than trashy commits. Yeah the other day I got into an extended debate about rebasing with another dev who just didn't get this. He maintained that it should not be possible to modify history because it all may be relevant later. I rebutted with a question: do you want a commit every time you type a character in your text editor? Version control is just another tool for code craftsmanship. You should strive to make your commits as atomic and well-described as humanly possible. git-add -i and git-rebase -i are tools that allow you to approach a more perfect history.
- smsm42 14y ago
  Exactly right. I commit very often when I develop something, and I can have typo commits, test fix commits, really fix it now commits, etc. But nobody really wants to see that when code goes into main project branch - my fellow developers want to see one clean commit that says "fix bug #1234" or "introduce FooBar functionality" and don't care about seeing the tiny details of my process. Rewriting history works wonderful for that.
  - grannyg00se 14y ago
    Alternatively, could you do your trashing about in a development branch and then once you're done make one merge into your main branch? That way looking at the history of your main branch, you'll only see the clean commit merged in, but if people wanted to, they could look at your development branch as well to see how that clean commit came about. If they don't care, they can just ignore that branch.
    - ashray 14y ago
      The histories actually get merged in when you do a merge between branches. However, it's possible to squash your commits before doing a merge to achieve this effect.
      - smsm42 14y ago
        Right, that's what I mean by rewriting history.
__david__ 14y ago
Rewriting history was the motivation behind commit-patch [1]. Granted, it doesn't actually let you rewrite history per-se, but it allows you to selectively check in parts of a file, which is very similar--You're effectively saying, "checkpoint this portion of a file, even though I've not really ever had the file in this particular state". It allows nice, fine grained commits even on version control systems like CVS and SVN. > In svn you don't even have the possibility to refuse them. Too true. One thing we did to try to fix the trashy commit issue was to mail out patches of each commit to a team mailing list. That allowed 2 things to happen: First, just seeing your trashy commit next to a commit to which someone has payed attention motivated you to be a little more careful next time. If you're just sending your commits into the void you behave differently than if you know what you commit will have a bunch of eyes on it. Secondly, anyone on the team could just reply to the email and suggest that it be split in 2 commits next time. [1] http://porkrind.org/commit-patch http://porkrind.org/commit-patch

by zobzu 14y ago

lotyrin 14y ago

Yep. SVN having a culture where history is expected to be full of junk commits is not a feature. Pretty much all of the points here are things I love about git. I'd personally hate working in this author's ideal repository: too many people with direct commit access, no tracking of feature branches, messy merges, noisy history.

eli 14y ago
Well that's unfair. I think there are legitimate arguments to be made against rewriting history besides "I've been brainwashed by SVN."
- clhodapp 14y ago
  Assuming that you restrict your rewriting to your own local repository (as is the widely-agree-upon best practice), what are some of these arguments?

michaelmior 14y ago

Rewriting history is probably the best part about git. Yes, it can be dangerous if you're not careful but I've found a clean history is very important. I regularly use the history as a view of what others on the team have been up to and to find when bugs were introduced. If many people are developing on the same branch, rebasing makes the history so much easier to read than having to parse merge commits and trying to mentally reconstruct the state of the individual developer's code base before the merge.

dasil003 14y ago

> I prefer USEABLE history than trashy commits. Yeah the other day I got into an extended debate about rebasing with another dev who just didn't get this. He maintained that it should not be possible to modify history because it all may be relevant later. I rebutted with a question: do you want a commit every time you type a character in your text editor? Version control is just another tool for code craftsmanship. You should strive to make your commits as atomic and well-described as humanly possible. git-add -i and git-rebase -i are tools that allow you to approach a more perfect history.

smsm42 14y ago
Exactly right. I commit very often when I develop something, and I can have typo commits, test fix commits, really fix it now commits, etc. But nobody really wants to see that when code goes into main project branch - my fellow developers want to see one clean commit that says "fix bug #1234" or "introduce FooBar functionality" and don't care about seeing the tiny details of my process. Rewriting history works wonderful for that.
- grannyg00se 14y ago
  Alternatively, could you do your trashing about in a development branch and then once you're done make one merge into your main branch? That way looking at the history of your main branch, you'll only see the clean commit merged in, but if people wanted to, they could look at your development branch as well to see how that clean commit came about. If they don't care, they can just ignore that branch.
  - ashray 14y ago
    The histories actually get merged in when you do a merge between branches. However, it's possible to squash your commits before doing a merge to achieve this effect.
    - smsm42 14y ago
      Right, that's what I mean by rewriting history.

__david__ 14y ago

Rewriting history was the motivation behind commit-patch [1]. Granted, it doesn't actually let you rewrite history per-se, but it allows you to selectively check in parts of a file, which is very similar--You're effectively saying, "checkpoint this portion of a file, even though I've not really ever had the file in this particular state". It allows nice, fine grained commits even on version control systems like CVS and SVN. > In svn you don't even have the possibility to refuse them. Too true. One thing we did to try to fix the trashy commit issue was to mail out patches of each commit to a team mailing list. That allowed 2 things to happen: First, just seeing your trashy commit next to a commit to which someone has payed attention motivated you to be a little more careful next time. If you're just sending your commits into the void you behave differently than if you know what you commit will have a bunch of eyes on it. Secondly, anyone on the team could just reply to the email and suggest that it be split in 2 commits next time. [1] http://porkrind.org/commit-patch http://porkrind.org/commit-patch