7 ms·

I feel tempted to just answer the question using the Betteridge Law of Headlines: Why is git pull considered harmful? It isn't. - nonlinearities aren't intrins

I feel tempted to just answer the question using the Betteridge Law of Headlines: Why is git pull considered harmful? It isn't. - nonlinearities aren't intrinsically bad. If they represent the actual history they are ok. - accidental reintroduction of commits rebased upstream are the result of wrongly rewriting history upstream. You can't rewrite history when history is replicated along several repos. - modifying the working directory is an expected result; of debatable usefulness, namely in the face of the behaviour of hg/monotone/darcs/other_dvcs_predating_git, but again not intrinsically bad. - pausing to review others' work is needed for a merge, again an expected behaviour on git pull - making it hard to rebase against a remote branch is good. Don't rewrite history unless you absolutely need to. I can't for the life of me understand this pursuit of a (fake) linear history - Not cleaning up branches is good. Each repo knows what it wants to hold. Git has no notion of master-slave relationships.

tvon 13y ago
Perhaps you should post a response to keep things from being so one-sided.
- Linell 13y ago
  Someone definitely should. For those of us who aren't super experienced, it would be good to hear both sides of the story in the same place.
- mcv 13y ago
  Yeah, I'd vote that answer up. If sergiosgc won't post it on stackoverflow, maybe I will. (My notice my comment there has already been upvoted quite a bit.)
- haptiK 13y ago
  I agree. This retort should be posted for a balanced view of the topic.
- sergiosgc 13y ago
  Thanks for the suggestion. I just posted the answer there [1]. [1] http://stackoverflow.com/a/22355851/383868 http://stackoverflow.com/a/22355851/383868
jheriko 13y ago
>I can't for the life of me understand this pursuit of a (fake) linear history. me too... i really enjoy history being immutable and accurate. all of the arguments i've heard for pruning history tend to boil down to ease of use - but i strongly suspect its a spurious argument, and that the perceived ease of use stems from not even having considered the alternatives and following the crowd (which is afaik why most people using git are using it broadly)
- jarrett 13y ago
  My policy is this: You may rewrite commits you've made to your local repo since your last push, but you may never rewrite a commit that has been pushed. Your teammates don't care much if you do the former. From their perspective, it's the same as if you'd committed at different points in your development process. So long as your final, rewritten history doesn't violate your team's preferences as to the granularity of commits, you're fine. So go ahead and rewrite your local, un-pushed changes if you feel it makes the history more organized. But if you do the latter--rewriting history that has been pushed--you're in trouble. All developers should be able to assume that the history in the central repo is immutable. Most likely, they will rely on that assumption.
  - icambron 13y ago
    I'd like to separate private from local. I allow for private branches on the central repo to be mutable. (By "private", I just mean marked in such a way that its clear it's owned by a particular user.) Otherwise, people end up keeping their changes local until they're ready to merge and you lose the backup aspect of git. But no one should be merging private branches (regardless of location) without their author giving an explicit OK anyway, so this doesn't seem dangerous.
    - jarrett 13y ago
      That's a good point. How do you synchronize history rewriting across the local and remote copies of the private branches? Do you have a formalized way to ensure it doesn't get messed up?
jenius 13y ago
Ok so let me post an opinion from the other side. I think that histories that represent actual history in git are actually not useful at all. Let's look at an example. I make a commit that introduces a bug and contains a typo. Someone else points out the bug, so I fix the bug. Then someone else points out the typo so I fix the typo, one small commit for each fix. While this is indeed an accurate depiction of history, having three commits (one broken, and two silly short one character/line changes) in your commit history instead of one commit is not in any way useful here. For anyone reviewing a pull request or doing anything else that involved looking through the history (that's what history is for, right?), this is a waste of time, and unnecessarily sloppy. Or if you need to cherry-pick or bisect, for example, you now have three commits that represent one change, rather than one commit for one change. Let's say someone makes a pull request to one of my projects for a change they made that ends up having 5 commits fixing things they did wrong initially, that could be 1 or 2 commits. There is zero chance I'm going to say "Ah well, I guess that's an accurate representation of history! Let's merge it!" I'm going to tell them to squash and rebase their commits to clean it up, then force push. And to be honest, I think anyone who didn't do this would be doing it wrong, promoting a messy history in their project. Generally, this whole debate within git is referred to as whether you should "hide the sausage" or not. Further discussion can be found here, with lots of arguments I didn't touch on at all in this comment: http://sethrobertson.github.io/GitBestPractices/#sausage http://sethrobertson.github.io/GitBestPractices/#sausage
- sergiosgc 13y ago
  In the precise case of the bug and typo, you should probably use git commit --amend. Anyhow, generically, while your changes are local, rewrite history to your hearts content. Have it tell a development story that makes sense. The real important part is: you can rewrite history only while it is private. When you push the commits, never ever rewrite history. Namely, rebasing is not a replacement for merging.
  - kmowery 13y ago
    git commit --amend is rewriting history, just not very much of it. If you --amend after pushing, you run into the exact same problems mentioned before.
dazmax 13y ago
It's not just the excessive number of merges that git pull creates – they also have the wrong orientation. Since pull merges others' commits on top of yours, the diff it creates is full of their changes but has your name on it, which clouds blame and history and makes conflict resolution more difficult. I think this is something git should fix. See this article about merge direction: http://tech.novapost.fr/merging-the-right-way-en.html http://tech.novapost.fr/merging-the-right-way-en.html
__david__ 13y ago
> I can't for the life of me understand this pursuit of a (fake) linear history. Because we, the rebasers, don't consider the repository to be "history". If you stop thinking of it as history, your whole perspective changes. It may fool you into thinking that it's history because there are dates everywhere, but it's really just a big collection of ordered changesets. With that in mind: > - accidental reintroduction of commits rebased upstream are the result of wrongly rewriting history upstream. You can't rewrite history when history is replicated along several repos. Of course you can. Your local repo and the remote servers you have access to are malleable and can manipulated however you'd like. I happily force push when the situation calls for it. However, it does place a burden on everyone else who fetches/pulls from that repo and so one need to take that into consideration. For major screwups (like the 50gb file accidental checkin from the article), it's very, very good that this can happen. For one of my projects I'm using git-multimail[1] on our "master" repo and it handles force pushes brilliantly (sends out emails with a list of commits removed/added). This is a great way to communicate with the rest of the team when you have a rewrite-after-push culture. [1] https://github.com/mhagger/git-multimail https://github.com/mhagger/git-multimail
- sergiosgc 13y ago
  If there is such a thing as rebasers, git-rebase man page reading should be mandatory for admittance: „Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.“--https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html https://www.kernel.org/pub/software/scm/git/docs/git-rebase....
InclinedPlane 13y ago
> I can't for the life of me understand this pursuit of a (fake) linear history Git is a highly useful tool but it's also an incredibly flawed one, especially in that most critical aspect for all software: the merger of technical and human concerns. Git is a useful set of source control primitives but it's lacking the cohesion necessary to make it a truly great tool. The fact that it's so popular is largely a consequence of the state of competition rather than its own internal awesomeness. One consequence of this is that instead of a robust, well thought out set of use cases which mesh well with various real-world applications git instead has a few hacky workarounds for certain scenarios. This results in the inevitable wobbliness of any system built on top of hacks and leaky abstractions. Rebasing being perhaps the ultimate example of just that. Personally I think history should largely be treated as immutable (it's funny how in programming we've become more and more attuned to the values of immutability while in source control we've become more amenable to mutability) but with some sort of system designed to make viewing history easier for the user (lots of other source control products have precisely this, it's sort of silly that git doesn't).

tvon 13y ago

Perhaps you should post a response to keep things from being so one-sided.

Linell 13y ago
Someone definitely should. For those of us who aren't super experienced, it would be good to hear both sides of the story in the same place.
mcv 13y ago
Yeah, I'd vote that answer up. If sergiosgc won't post it on stackoverflow, maybe I will. (My notice my comment there has already been upvoted quite a bit.)
haptiK 13y ago
I agree. This retort should be posted for a balanced view of the topic.
sergiosgc 13y ago
Thanks for the suggestion. I just posted the answer there [1]. [1] http://stackoverflow.com/a/22355851/383868 http://stackoverflow.com/a/22355851/383868

jheriko 13y ago

>I can't for the life of me understand this pursuit of a (fake) linear history. me too... i really enjoy history being immutable and accurate. all of the arguments i've heard for pruning history tend to boil down to ease of use - but i strongly suspect its a spurious argument, and that the perceived ease of use stems from not even having considered the alternatives and following the crowd (which is afaik why most people using git are using it broadly)

jarrett 13y ago
My policy is this: You may rewrite commits you've made to your local repo since your last push, but you may never rewrite a commit that has been pushed. Your teammates don't care much if you do the former. From their perspective, it's the same as if you'd committed at different points in your development process. So long as your final, rewritten history doesn't violate your team's preferences as to the granularity of commits, you're fine. So go ahead and rewrite your local, un-pushed changes if you feel it makes the history more organized. But if you do the latter--rewriting history that has been pushed--you're in trouble. All developers should be able to assume that the history in the central repo is immutable. Most likely, they will rely on that assumption.
- icambron 13y ago
  I'd like to separate private from local. I allow for private branches on the central repo to be mutable. (By "private", I just mean marked in such a way that its clear it's owned by a particular user.) Otherwise, people end up keeping their changes local until they're ready to merge and you lose the backup aspect of git. But no one should be merging private branches (regardless of location) without their author giving an explicit OK anyway, so this doesn't seem dangerous.
  - jarrett 13y ago
    That's a good point. How do you synchronize history rewriting across the local and remote copies of the private branches? Do you have a formalized way to ensure it doesn't get messed up?

jenius 13y ago

Ok so let me post an opinion from the other side. I think that histories that represent actual history in git are actually not useful at all. Let's look at an example. I make a commit that introduces a bug and contains a typo. Someone else points out the bug, so I fix the bug. Then someone else points out the typo so I fix the typo, one small commit for each fix. While this is indeed an accurate depiction of history, having three commits (one broken, and two silly short one character/line changes) in your commit history instead of one commit is not in any way useful here. For anyone reviewing a pull request or doing anything else that involved looking through the history (that's what history is for, right?), this is a waste of time, and unnecessarily sloppy. Or if you need to cherry-pick or bisect, for example, you now have three commits that represent one change, rather than one commit for one change. Let's say someone makes a pull request to one of my projects for a change they made that ends up having 5 commits fixing things they did wrong initially, that could be 1 or 2 commits. There is zero chance I'm going to say "Ah well, I guess that's an accurate representation of history! Let's merge it!" I'm going to tell them to squash and rebase their commits to clean it up, then force push. And to be honest, I think anyone who didn't do this would be doing it wrong, promoting a messy history in their project. Generally, this whole debate within git is referred to as whether you should "hide the sausage" or not. Further discussion can be found here, with lots of arguments I didn't touch on at all in this comment: http://sethrobertson.github.io/GitBestPractices/#sausage http://sethrobertson.github.io/GitBestPractices/#sausage

sergiosgc 13y ago
In the precise case of the bug and typo, you should probably use git commit --amend. Anyhow, generically, while your changes are local, rewrite history to your hearts content. Have it tell a development story that makes sense. The real important part is: you can rewrite history only while it is private. When you push the commits, never ever rewrite history. Namely, rebasing is not a replacement for merging.
- kmowery 13y ago
  git commit --amend is rewriting history, just not very much of it. If you --amend after pushing, you run into the exact same problems mentioned before.

dazmax 13y ago

It's not just the excessive number of merges that git pull creates – they also have the wrong orientation. Since pull merges others' commits on top of yours, the diff it creates is full of their changes but has your name on it, which clouds blame and history and makes conflict resolution more difficult. I think this is something git should fix. See this article about merge direction: http://tech.novapost.fr/merging-the-right-way-en.html http://tech.novapost.fr/merging-the-right-way-en.html

__david__ 13y ago

> I can't for the life of me understand this pursuit of a (fake) linear history. Because we, the rebasers, don't consider the repository to be "history". If you stop thinking of it as history, your whole perspective changes. It may fool you into thinking that it's history because there are dates everywhere, but it's really just a big collection of ordered changesets. With that in mind: > - accidental reintroduction of commits rebased upstream are the result of wrongly rewriting history upstream. You can't rewrite history when history is replicated along several repos. Of course you can. Your local repo and the remote servers you have access to are malleable and can manipulated however you'd like. I happily force push when the situation calls for it. However, it does place a burden on everyone else who fetches/pulls from that repo and so one need to take that into consideration. For major screwups (like the 50gb file accidental checkin from the article), it's very, very good that this can happen. For one of my projects I'm using git-multimail[1] on our "master" repo and it handles force pushes brilliantly (sends out emails with a list of commits removed/added). This is a great way to communicate with the rest of the team when you have a rewrite-after-push culture. [1] https://github.com/mhagger/git-multimail https://github.com/mhagger/git-multimail

sergiosgc 13y ago
If there is such a thing as rebasers, git-rebase man page reading should be mandatory for admittance: „Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.“--https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html https://www.kernel.org/pub/software/scm/git/docs/git-rebase....

InclinedPlane 13y ago

> I can't for the life of me understand this pursuit of a (fake) linear history Git is a highly useful tool but it's also an incredibly flawed one, especially in that most critical aspect for all software: the merger of technical and human concerns. Git is a useful set of source control primitives but it's lacking the cohesion necessary to make it a truly great tool. The fact that it's so popular is largely a consequence of the state of competition rather than its own internal awesomeness. One consequence of this is that instead of a robust, well thought out set of use cases which mesh well with various real-world applications git instead has a few hacky workarounds for certain scenarios. This results in the inevitable wobbliness of any system built on top of hacks and leaky abstractions. Rebasing being perhaps the ultimate example of just that. Personally I think history should largely be treated as immutable (it's funny how in programming we've become more and more attuned to the values of immutability while in source control we've become more amenable to mutability) but with some sort of system designed to make viewing history easier for the user (lots of other source control products have precisely this, it's sort of silly that git doesn't).