4 ms·

I think this gets to one of the issues people who have previous source control experience have with git. They apply the concepts from, say, subversion to git, a

I think this gets to one of the issues people who have previous source control experience have with git. They apply the concepts from, say, subversion to git, and then have trouble. Take branches for example. In subversion, branches were heavyweight, scary things. In git, they are extremely lightweight, in that they are really nothing more than a pointer to a specific commit. They almost shouldn't even share the same name, they are so different. Basically, I found that I got much better once I stopped trying to apply my old understanding of subversion to git, and especially once I just started playing around with git commands on a dummy repo, to fully understand what was going on. Now that I've done that, I would never switch back to subversion. Perforce, maybe, but only for certain very specific scenarios.

jlgreco 13y ago
"Perforce, maybe, but only for certain very specific scenarios." These days you can get a lot done using git as your perforce client but.... ick.
matwood 13y ago
They apply the concepts from, say, subversion to git, and then have trouble. I have found this to be true. I helped a lot of people at work switch from svn to git. As I showed people what to do the biggest problem was trying to make git fit in with what they knew from svn. Now I start every conversation with forget svn :)
jheriko 13y ago
The specific experience I have is being able to revert a merge painlessly with a single operation out of the box. This was unreasonably challenging with git. AFAIK there is no command for this out of the box and my research led me to believe I could only fix it for future commits by making other changes. That's not acceptable and utterly destroyed my confidence in every other feature. Why in as source control solution would you ever implement a feature which makes changes unrevertable by default? Its also a great example of the implementation impacts ng the user when it shouldn't - the only reason I need to know anything beyond what command to use here is poor design. My problem is not from applying svn logic to git... Its from not knowing it well enough and expecting convenient defaults out of the box. Just using Mercurial solves this for me.
- rallison 13y ago
  Oh, reverting merges! I've been there, and it is completely possible, out of the box, with git. But! It requires a relatively thorough understanding of how it works, or you will definitely mess it up. I wrote up this summary a while back for our company wiki: Imagine this scenario: - Team Sandy does a ton of work on branch foo. - Team Sandy ensures the release manager that branch foo is perfect and bug free. - Team Sandy merges branch foo into branch develop and pushes. - Other developers continue committing to develop. - Massive devastation and destruction start occurring due to massive bugs scattered throughout Sandy's code. At this point, we want to get all of Sandy's code out of develop, as we can't post to production until develop is Sandy-free. What do we do? - Revert the merge commit The important thing to note here is that this basically undoes the effect of the merge, but NOT the history. If you were to try to merge branch foo back in at a later date, git would do nothing and tell you that everything is already merged in. This is technically correct, but confusing. Let's imagine that Sandy goes back to branch foo and commits bug fixes to fix the devastation. Now, branch foo is ready to be merged back in. What do we do? - Revert the revert commit (yes, really). This basically undoes the effect of our original undo. At this moment, develop has all of branch foo's code pre-bug fixes. - Merge foo into develop. This merges the subsequent bug fix commits into develop. A much more thorough discussion can be enjoyed here (I highly recommend the read): https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt https://www.kernel.org/pub/software/scm/git/docs/howto/rever... -- Basically, it can be done with one line on the commandline, but I wouldn't recommend anyone do it unless they've read the above (specifically, the discussion I've linked to).
  - jheriko 13y ago
    '- Revert the merge commit' this is what i had problems with. i got an error message back from git that you can't revert a branch commit and when i googled it the conclusion i came to was i needed to go back in time and change our configuration to make this possible. its entirely possible that i ended up down the wrong path from google searching. now, googling around i find some stack overflow answers and such i'm pretty sure i found at the time i had the issue. when i am next there (at work) i'll see if i can find a copy of that repo or recreate the same problem so that i can show what happened and why it is difficult to solve and dangerous in a production environment. actually... i might just try and repro it now, but my connection is so poor here (at home) that even installing git is likely to be painful. however, ignoring that, the process you describe is horribly counter intuitive. well done for working it out in the first place, although i do see this suggested in a few of the stack overflow answers... :)

jlgreco 13y ago

"Perforce, maybe, but only for certain very specific scenarios." These days you can get a lot done using git as your perforce client but.... ick.

matwood 13y ago

They apply the concepts from, say, subversion to git, and then have trouble. I have found this to be true. I helped a lot of people at work switch from svn to git. As I showed people what to do the biggest problem was trying to make git fit in with what they knew from svn. Now I start every conversation with forget svn :)

jheriko 13y ago

The specific experience I have is being able to revert a merge painlessly with a single operation out of the box. This was unreasonably challenging with git. AFAIK there is no command for this out of the box and my research led me to believe I could only fix it for future commits by making other changes. That's not acceptable and utterly destroyed my confidence in every other feature. Why in as source control solution would you ever implement a feature which makes changes unrevertable by default? Its also a great example of the implementation impacts ng the user when it shouldn't - the only reason I need to know anything beyond what command to use here is poor design. My problem is not from applying svn logic to git... Its from not knowing it well enough and expecting convenient defaults out of the box. Just using Mercurial solves this for me.

rallison 13y ago
Oh, reverting merges! I've been there, and it is completely possible, out of the box, with git. But! It requires a relatively thorough understanding of how it works, or you will definitely mess it up. I wrote up this summary a while back for our company wiki: Imagine this scenario: - Team Sandy does a ton of work on branch foo. - Team Sandy ensures the release manager that branch foo is perfect and bug free. - Team Sandy merges branch foo into branch develop and pushes. - Other developers continue committing to develop. - Massive devastation and destruction start occurring due to massive bugs scattered throughout Sandy's code. At this point, we want to get all of Sandy's code out of develop, as we can't post to production until develop is Sandy-free. What do we do? - Revert the merge commit The important thing to note here is that this basically undoes the effect of the merge, but NOT the history. If you were to try to merge branch foo back in at a later date, git would do nothing and tell you that everything is already merged in. This is technically correct, but confusing. Let's imagine that Sandy goes back to branch foo and commits bug fixes to fix the devastation. Now, branch foo is ready to be merged back in. What do we do? - Revert the revert commit (yes, really). This basically undoes the effect of our original undo. At this moment, develop has all of branch foo's code pre-bug fixes. - Merge foo into develop. This merges the subsequent bug fix commits into develop. A much more thorough discussion can be enjoyed here (I highly recommend the read): https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt https://www.kernel.org/pub/software/scm/git/docs/howto/rever... -- Basically, it can be done with one line on the commandline, but I wouldn't recommend anyone do it unless they've read the above (specifically, the discussion I've linked to).
- jheriko 13y ago
  '- Revert the merge commit' this is what i had problems with. i got an error message back from git that you can't revert a branch commit and when i googled it the conclusion i came to was i needed to go back in time and change our configuration to make this possible. its entirely possible that i ended up down the wrong path from google searching. now, googling around i find some stack overflow answers and such i'm pretty sure i found at the time i had the issue. when i am next there (at work) i'll see if i can find a copy of that repo or recreate the same problem so that i can show what happened and why it is difficult to solve and dangerous in a production environment. actually... i might just try and repro it now, but my connection is so poor here (at home) that even installing git is likely to be painful. however, ignoring that, the process you describe is horribly counter intuitive. well done for working it out in the first place, although i do see this suggested in a few of the stack overflow answers... :)