5 ms·

I would never ever rewrite the public history. The public history is what ends up on the repository from where we deploy from. Whenever a commit is pushed ther

by pilif 15y ago

I would never ever rewrite the public history. The public history is what ends up on the repository from where we deploy from. Whenever a commit is pushed there, it stays there. There will never be any rebasing (minus emergencies like removing accidentally committed files for which we don't own a license for - didn't happen so far though). "rebase -i" is a tool for personal development use. It's not a tool to use on a public repository as it will make following history incredibly hard and it will screw with the clones other developers might have. Conversely though, what I do on my personal development machine or on my personal public clone (everyone of us has a personal public clone we use for code reviews or discussions around code), is my business. Nobody is telling me which editor to use and nobody is telling me whether I can clean up my commits or not. Now in general, since learning that having clean commits is possible (it's not in subversion for example), I encourage my fellow developers to have clean commits and I discourage them from committing those famous "oops - removed typo" or "oops - added forgotten file" commits as they are completely useless for the overall history of the project. Two months from now, nobody is going to care about you forgetting to add a file. But I'm likely going to care about when a feature has been added and why some lines have changed. So that's what I want to have in the public repository. Not a history of your personal forgetfulness. If they manage to do that without ever rebasing (you can do it with add -p, it's just easy to make a mistake), then fine. In the end, I only care about a clean history on our public repository.

eropple 15y ago
IMO, that's really the wrong way to go, and it's one of the big reasons I absolutely loathe git. I want any changes that are in my tree, ever, to be in the order and position in which they happened. If somebody screwed up and forgot to add a file, fine--add it in another commit. It's not like commits cost money. As far as rolling back later--meh? I've never had a trouble in 300Krev heavily branched SVN barf, I strongly doubt it's suddenly harder in a DVCS. Merge tags are your friend, and indelible history is a good thing.
- tomjen3 15y ago
  Commits don't cost money, but they increase complexity which takes brain power away from the development process. Second, git won't change anything by itself, so things will always be exectly where you left them; so I am really interested in why you think rewriting is a bad idea.
- 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. =)
- gruseom 15y ago
  Why, then, not commit every keystroke? After all, you're losing history every time someone types backspace. I imagine the reason that seems absurd is that you don't consider all the false steps and reworking that go on while a commit is crafted to be part of its official meaning. The working set is malleable until it's ready, and then you commit it. Well, private branches as pilif describes them are malleable in just this way. In both cases, you work your code like clay until it's ready to be presented and then bake it in to the public history.
  - eropple 15y ago
    I strongly dispute the assertion that a private clone is malleable in the way you're describing. I consider all history important enough to be committed to be "public" history. But (apparently unlike folks who are fast with their downvote buttons) I certainly acknowledge that it is a matter of taste.
    - gruseom 15y ago
      I consider all history important enough to be committed to be "public" history This argument seems to me to boil down to an attachment to a single meaning (the traditional one) of the word "commit". p.s. Instead of complaining about being downvoted, it would be better to make your tone less aggressive in the first place. None of your other comments made it clear that you regard this as taste; actually quite the opposite.
- pyre 15y ago
  > I want any changes that are in my tree, ever, > to be in the order and position in which they > happened. Could you explain this better. When I read this I hear, "I absolutely loathe modern operating systems, I think that all code should go in ~/code and all documents in ~/Documents, but modern operating systems allow you to put things anywhere. The horror!" Do you really loathe the tool because it allows for flexibility? Do you have so little faith in the end-user? Do you really understand git, or only at a cursory level? (That isn't meant to be an insult) > indelible history is a good thing So long as you have a central git repository and manage it so that no one can rewrite the master/trunk branch, then you have that. If someone screws up the history in their local tree, then it won't allow them to overwrite the history on the canonical version. (If you say, "well someone with access to the canonical version could do X," then you're just trolling, because someone with access to the central SVN repo could 'rm -rf' it too. It's the same issue.)

by pilif 15y ago

eropple 15y ago

IMO, that's really the wrong way to go, and it's one of the big reasons I absolutely loathe git. I want any changes that are in my tree, ever, to be in the order and position in which they happened. If somebody screwed up and forgot to add a file, fine--add it in another commit. It's not like commits cost money. As far as rolling back later--meh? I've never had a trouble in 300Krev heavily branched SVN barf, I strongly doubt it's suddenly harder in a DVCS. Merge tags are your friend, and indelible history is a good thing.

tomjen3 15y ago
Commits don't cost money, but they increase complexity which takes brain power away from the development process. Second, git won't change anything by itself, so things will always be exectly where you left them; so I am really interested in why you think rewriting is a bad idea.
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. =)
gruseom 15y ago
Why, then, not commit every keystroke? After all, you're losing history every time someone types backspace. I imagine the reason that seems absurd is that you don't consider all the false steps and reworking that go on while a commit is crafted to be part of its official meaning. The working set is malleable until it's ready, and then you commit it. Well, private branches as pilif describes them are malleable in just this way. In both cases, you work your code like clay until it's ready to be presented and then bake it in to the public history.
- eropple 15y ago
  I strongly dispute the assertion that a private clone is malleable in the way you're describing. I consider all history important enough to be committed to be "public" history. But (apparently unlike folks who are fast with their downvote buttons) I certainly acknowledge that it is a matter of taste.
  - gruseom 15y ago
    I consider all history important enough to be committed to be "public" history This argument seems to me to boil down to an attachment to a single meaning (the traditional one) of the word "commit". p.s. Instead of complaining about being downvoted, it would be better to make your tone less aggressive in the first place. None of your other comments made it clear that you regard this as taste; actually quite the opposite.
pyre 15y ago
> I want any changes that are in my tree, ever, > to be in the order and position in which they > happened. Could you explain this better. When I read this I hear, "I absolutely loathe modern operating systems, I think that all code should go in ~/code and all documents in ~/Documents, but modern operating systems allow you to put things anywhere. The horror!" Do you really loathe the tool because it allows for flexibility? Do you have so little faith in the end-user? Do you really understand git, or only at a cursory level? (That isn't meant to be an insult) > indelible history is a good thing So long as you have a central git repository and manage it so that no one can rewrite the master/trunk branch, then you have that. If someone screws up the history in their local tree, then it won't allow them to overwrite the history on the canonical version. (If you say, "well someone with access to the canonical version could do X," then you're just trolling, because someone with access to the central SVN repo could 'rm -rf' it too. It's the same issue.)