4 ms·

>There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than

>There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people. Such a view seems like insanity to me. Git merges files, not file-histories. Git's behavior is simple, clear, and easy to understand. I can see why you might expect merges to be transitive like this (it would be an elegant property, if it were true), but why does it matter to you? In what way do you use merges that could rely on this expectation?

JoeAltmaier 16y ago
There are so many theories of "source control" that none of them are "simple clear and easy". They take study, and if you start from a different place, a new paradigm will be hard to learn and internalize. That said: An elegant property? Are you kidding? That is intrinsic to most tools that dare call themselves "source control". Git requires extraordinary explanation if it behaves in an extraordinary fashion.
- nevinera 16y ago
  >That is intrinsic to most tools that dare call themselves "source control". Bullshit. 'Merge' is one of the most complicated operations in every versioning system. I'm pretty confident svn is 'inconsistent'. Or is that too niche?
  - JoeAltmaier 16y ago
    Merge is a tool. The issue is, can you reproduce source accurately, from a variety of starting points, and be sure you have some canonical thing (release x.y). Do I understand you right? This is not the expectation for a source control tool?
    - nevinera 16y ago
      You can reproduce any repository state that you (or anyone else) have stored. You can do it simply, reliably, and quickly. That is not in doubt. Merge is not a tool for reproducing a canonical state, it's a tool for combining two or more of them, an entirely different topic. Any other straw men you'd like to hold up real fast?
      - JoeAltmaier 16y ago
        Got it, thanks.
Peaker 16y ago
Here's a quote from the article explaining what would rely on this expectation: > There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people. Such a view seems like insanity to me.
- jerf 16y ago
  I think I kind of know what the author was getting at, but I'm not sure, and ending with the moral equivalent of "If you disagree with me, I guess you're just stupid" was a bit disappointing. I think the idea is the potential problems with this could emerge if you have two people simultaneously doing somewhat larger complicated merges that have this core problem perhaps more than once. I think that may be true, but the probability of this occurring is well below just plain-old-fashioned human screwups, and the solution to both ("laborious history comparison, examination, and a reset --hard to a hash by somebody") is the same in both. I really don't see how fixing this would solve any real-world problem.
  - copper 16y ago
    I thought the author was trying to get at the old Babbage quote on confusion of ideas. FWIW, I use git-svn to handle complex merges in svn because git has a better merge algorithm. While this particular situation doesn't affect that use case - I think it could, but it should be rare with (svn) branch discipline - the fact that it might is something to keep in mind.
- nevinera 16y ago
  That quote by the author says 'I expect this behavior'. It does not give some use-case that would rely on it, aside from the use case of 'I use git, and incorrectly assume that merges are transitive.' More specifically, if they pulled the same patches, the outcome would be identical. What he wants to be able to do is pull the same history by pulling different patches in that history. A patch is the diff between two repository states, and that's all it is. Sadly, diffs are intransitive.

JoeAltmaier 16y ago

There are so many theories of "source control" that none of them are "simple clear and easy". They take study, and if you start from a different place, a new paradigm will be hard to learn and internalize. That said: An elegant property? Are you kidding? That is intrinsic to most tools that dare call themselves "source control". Git requires extraordinary explanation if it behaves in an extraordinary fashion.

nevinera 16y ago
>That is intrinsic to most tools that dare call themselves "source control". Bullshit. 'Merge' is one of the most complicated operations in every versioning system. I'm pretty confident svn is 'inconsistent'. Or is that too niche?
- JoeAltmaier 16y ago
  Merge is a tool. The issue is, can you reproduce source accurately, from a variety of starting points, and be sure you have some canonical thing (release x.y). Do I understand you right? This is not the expectation for a source control tool?
  - nevinera 16y ago
    You can reproduce any repository state that you (or anyone else) have stored. You can do it simply, reliably, and quickly. That is not in doubt. Merge is not a tool for reproducing a canonical state, it's a tool for combining two or more of them, an entirely different topic. Any other straw men you'd like to hold up real fast?
    - JoeAltmaier 16y ago
      Got it, thanks.

Peaker 16y ago

Here's a quote from the article explaining what would rely on this expectation: > There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people. Such a view seems like insanity to me.

jerf 16y ago
I think I kind of know what the author was getting at, but I'm not sure, and ending with the moral equivalent of "If you disagree with me, I guess you're just stupid" was a bit disappointing. I think the idea is the potential problems with this could emerge if you have two people simultaneously doing somewhat larger complicated merges that have this core problem perhaps more than once. I think that may be true, but the probability of this occurring is well below just plain-old-fashioned human screwups, and the solution to both ("laborious history comparison, examination, and a reset --hard to a hash by somebody") is the same in both. I really don't see how fixing this would solve any real-world problem.
- copper 16y ago
  I thought the author was trying to get at the old Babbage quote on confusion of ideas. FWIW, I use git-svn to handle complex merges in svn because git has a better merge algorithm. While this particular situation doesn't affect that use case - I think it could, but it should be rare with (svn) branch discipline - the fact that it might is something to keep in mind.
nevinera 16y ago
That quote by the author says 'I expect this behavior'. It does not give some use-case that would rely on it, aside from the use case of 'I use git, and incorrectly assume that merges are transitive.' More specifically, if they pulled the same patches, the outcome would be identical. What he wants to be able to do is pull the same history by pulling different patches in that history. A patch is the diff between two repository states, and that's all it is. Sadly, diffs are intransitive.