6 ms·

Commits don't cost money, but time wasted on "added forgotten files"-commits while parsing the history to trace a bug does cost money, so I'd rather not have th

by pilif 15y ago

Commits don't cost money, but time wasted on "added forgotten files"-commits while parsing the history to trace a bug does cost money, so I'd rather not have the commits. Additionally, it's impossible for you or anybody else to find out whether I have rebased my personal history before pushing. As such, it's totally inconsequential for the main repository whether I rebased or not. As I said: I think rebase is a personal development tool, not one you would alter public history with.

eropple 15y ago
I dunno, I think the claim that those commits "waste time" (in the sense of any meaningful amount of time, even cumulatively) is a little hyperbolic. I guess you view history differently than I do: I consider all development history to be "public history" regardless of whether it was pulled in from a clone or not. If you commit it to a repository I am going to be fulfilling a pull request from, I want the history there.
- pilif 15y ago
  and you will get that history. But you will get it in the form that I would like you to have it, not as it happened. But there is no way for you to know besides the fact that all commits you are going to pull are self-contained and none of them breaks the build. Would you reject perfect looking commits, self-contained, perfectly documented and forming a perfect temporal history based on the fact that they are too perfect not to have been created using rebase? Because that's the only indication you have that rebase was used.
  - eropple 15y ago
    > But you will get it in the form that I would like you to have it, not as it happened. And that's actually a very large part of why I don't use something that makes rebase easy. Because, fundamentally, I do not care how you "want" me to get it. I want to get it how it was put into the repository to begin with. I want to get it how it was committed--because how it was done matters to me, as a developer and as a person. This is an entirely emotional position and I don't care: show me how it was done. It matters to me, and given my personal axioms there is a decent argument, in my mind, that doing otherwise is disrespecting people who might want to see how you "put it all together." You're certainly welcome to disagree. But because I use Hg for my projects and for any project I contribute to, and because my usual co-workers aren't going to go through the hassle of enabling Hg's rebase extension and using it just for the hell of it, I generally get what I want in the areas I care about. =)
    - fr0sty 15y ago
      If your workflow or VCS doesn't allow rebase natively then people will implement it in the filesystem by never committing. Git's approach to committing is: "commit early, commit often". The coro;lary is: "don't worry about perfection, we can fix it later". Such flexibility to me is very enabling and allows for a lot of very beneficial experimentation in the process of developing features. Honestly, I don't understand your fascination with the sausage-making. If I were to give you the pre-rebase and post-rebase version of patches I would wager you would find much more value in the latter. And if not. Even if seeing the wandering, hacking, slashing, typoing, re-indenting, etc. is instructive to you, any future maintainer of the code will be far less pleased.
    - astine 15y ago
      "I want to get it how it was committed--because how it was done matters to me, as a developer and as a person." Or as a micro-managing boss. I don't need someone staring over my shoulder as I work or after I work. My mistakes aren't your business and I find your attitude unpleasant.
- westi 15y ago
  I completely agree with this. If a change was worth committing then it is worth sharing that commit with everyone. Otherwise you run the very real risk of loosing important information about the design of a feature the bugs that were found and addressed during development. Every change should been accompanied by a well described commit message and big changes are much harder to review. I can see a very small positive in "hiding" the commits which resolve process issues like forgetting to add a file but in the long run you shouldn't have very many of these anyway so you should worry about them.
  - pyre 15y ago
    > If a change was worth committing then it is worth > sharing that commit with everyone You're misunderstanding some of the workflows that people are discussing. Sometimes I commit things that are half-finished, or even half-baked because I know that when it comes time to push I can rewrite things into a set of commits that makes sense. This workflow makes sense because rewriting is easy enough. Obviously, I might not do this if I had to publish every commit that I made. But then I would just resort to using something like quilt to manage patches onto of SVN, which is ridiculous. You VCS is a patch management system. The idea that someone would use a patch management system on top of a patch management system suggests that something is broken (yes, I have had people on HN claim that git sucks because SVN + quilt 'work for me').
    - westi 15y ago
      My point is that these interim commits are useful information for other people too not just you. They help show how the feature developed, what other implementation ideas you tried along the way etc.
      - chousuke 15y ago
        How are they useful? Why would anyone care about how you developed a single bugfix or a feature? In your model, often the commits are not even sequential in the log because you might find a mistake only after committing several other changes. I can't see how not rebasing makes commit history better in any way at all. I would like to hear your reasoning. The way I see it, instead of a series of commits that implement something, you could have a single patch (commit) that implements something, making it much easier to 0) find all the code that implements a certain feature, because it's a self-contained commit, 1) find bugs via bisection, 2) port to other versions via cherry-picking and 3) read the changelog and figure out what the hell is actually happening because there are no trash commits around obscuring things. EDIT: Just to clarify, I do not think that this is a matter of opinion or preference. That would imply that both approaches are equally valid. I consider rebasing a tool that enables a vastly superior workflow. I have given a few reasons why I think it is superior and I am interested in counterarguments or at least reasoning as to why not making perfect commits (to the best of your ability) is preferable or even acceptable at all.
- planckscnst 15y ago
  So, let's get down to business here, then. What specifically is better about this: commit 123facdf Add asynchThingerBopper() to Thinger class. commit 9f9babd8 Forgot to add Thinger.h file to 1123facdf compared with this: commit 123facdf Add asynchThingerBopper() to Thinger class. What specific value does the first scenario add that the second does not?
  - koopajah 15y ago
    It can help for git bisect for example to avoid having half of your commit not compiling properly because half the time you forgot to add one of the files to your commit.
    - fr0sty 15y ago
      > It can help for git bisect Not if the first commit doesn't compile. Indelible history is good for public projects (and no one is arguing about that) and for change control systems but less good, in my estimation, in cases where mistakes are easily made, have small to non-existent consequenses, and serve no historic purpose.

by pilif 15y ago

eropple 15y ago

I dunno, I think the claim that those commits "waste time" (in the sense of any meaningful amount of time, even cumulatively) is a little hyperbolic. I guess you view history differently than I do: I consider all development history to be "public history" regardless of whether it was pulled in from a clone or not. If you commit it to a repository I am going to be fulfilling a pull request from, I want the history there.

pilif 15y ago
and you will get that history. But you will get it in the form that I would like you to have it, not as it happened. But there is no way for you to know besides the fact that all commits you are going to pull are self-contained and none of them breaks the build. Would you reject perfect looking commits, self-contained, perfectly documented and forming a perfect temporal history based on the fact that they are too perfect not to have been created using rebase? Because that's the only indication you have that rebase was used.
- eropple 15y ago
  > But you will get it in the form that I would like you to have it, not as it happened. And that's actually a very large part of why I don't use something that makes rebase easy. Because, fundamentally, I do not care how you "want" me to get it. I want to get it how it was put into the repository to begin with. I want to get it how it was committed--because how it was done matters to me, as a developer and as a person. This is an entirely emotional position and I don't care: show me how it was done. It matters to me, and given my personal axioms there is a decent argument, in my mind, that doing otherwise is disrespecting people who might want to see how you "put it all together." You're certainly welcome to disagree. But because I use Hg for my projects and for any project I contribute to, and because my usual co-workers aren't going to go through the hassle of enabling Hg's rebase extension and using it just for the hell of it, I generally get what I want in the areas I care about. =)
  - fr0sty 15y ago
    If your workflow or VCS doesn't allow rebase natively then people will implement it in the filesystem by never committing. Git's approach to committing is: "commit early, commit often". The coro;lary is: "don't worry about perfection, we can fix it later". Such flexibility to me is very enabling and allows for a lot of very beneficial experimentation in the process of developing features. Honestly, I don't understand your fascination with the sausage-making. If I were to give you the pre-rebase and post-rebase version of patches I would wager you would find much more value in the latter. And if not. Even if seeing the wandering, hacking, slashing, typoing, re-indenting, etc. is instructive to you, any future maintainer of the code will be far less pleased.
  - astine 15y ago
    "I want to get it how it was committed--because how it was done matters to me, as a developer and as a person." Or as a micro-managing boss. I don't need someone staring over my shoulder as I work or after I work. My mistakes aren't your business and I find your attitude unpleasant.
westi 15y ago
I completely agree with this. If a change was worth committing then it is worth sharing that commit with everyone. Otherwise you run the very real risk of loosing important information about the design of a feature the bugs that were found and addressed during development. Every change should been accompanied by a well described commit message and big changes are much harder to review. I can see a very small positive in "hiding" the commits which resolve process issues like forgetting to add a file but in the long run you shouldn't have very many of these anyway so you should worry about them.
- pyre 15y ago
  > If a change was worth committing then it is worth > sharing that commit with everyone You're misunderstanding some of the workflows that people are discussing. Sometimes I commit things that are half-finished, or even half-baked because I know that when it comes time to push I can rewrite things into a set of commits that makes sense. This workflow makes sense because rewriting is easy enough. Obviously, I might not do this if I had to publish every commit that I made. But then I would just resort to using something like quilt to manage patches onto of SVN, which is ridiculous. You VCS is a patch management system. The idea that someone would use a patch management system on top of a patch management system suggests that something is broken (yes, I have had people on HN claim that git sucks because SVN + quilt 'work for me').
  - westi 15y ago
    My point is that these interim commits are useful information for other people too not just you. They help show how the feature developed, what other implementation ideas you tried along the way etc.
    - chousuke 15y ago
      How are they useful? Why would anyone care about how you developed a single bugfix or a feature? In your model, often the commits are not even sequential in the log because you might find a mistake only after committing several other changes. I can't see how not rebasing makes commit history better in any way at all. I would like to hear your reasoning. The way I see it, instead of a series of commits that implement something, you could have a single patch (commit) that implements something, making it much easier to 0) find all the code that implements a certain feature, because it's a self-contained commit, 1) find bugs via bisection, 2) port to other versions via cherry-picking and 3) read the changelog and figure out what the hell is actually happening because there are no trash commits around obscuring things. EDIT: Just to clarify, I do not think that this is a matter of opinion or preference. That would imply that both approaches are equally valid. I consider rebasing a tool that enables a vastly superior workflow. I have given a few reasons why I think it is superior and I am interested in counterarguments or at least reasoning as to why not making perfect commits (to the best of your ability) is preferable or even acceptable at all.
planckscnst 15y ago
So, let's get down to business here, then. What specifically is better about this: commit 123facdf Add asynchThingerBopper() to Thinger class. commit 9f9babd8 Forgot to add Thinger.h file to 1123facdf compared with this: commit 123facdf Add asynchThingerBopper() to Thinger class. What specific value does the first scenario add that the second does not?
- koopajah 15y ago
  It can help for git bisect for example to avoid having half of your commit not compiling properly because half the time you forgot to add one of the files to your commit.
  - fr0sty 15y ago
    > It can help for git bisect Not if the first commit doesn't compile. Indelible history is good for public projects (and no one is arguing about that) and for change control systems but less good, in my estimation, in cases where mistakes are easily made, have small to non-existent consequenses, and serve no historic purpose.