6 ms·

I'm guessing the reason you're getting downvoted is because it sounds like you don't know how to use git. That may not be true, it just sounds that way. > the

I'm guessing the reason you're getting downvoted is because it sounds like you don't know how to use git. That may not be true, it just sounds that way. > the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. Please explain. How is it dangerous? How can it leave you in an unrecoverable state? > why can't i roll back a merge in one step if i didn't configure things to be able to do that? Depending on how many commits the merge had it'd be something like git reset HEAD^^ --hard > why does my branch disappear when i merge? What do you mean? That the branch you merged into doesn't indicate which commits were done on the other branch? Branches don't disappear.

rallison 13y ago
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
This is precisely true. I don't know how to use git. That's a big part of the problem I have with it, I get much more bang for my buck in terms of time spent working things out if I don't use git.
- jlgreco 13y ago
  I don't know how to operate a airplane, but that isn't a problem I have with airplanes. That is a problem I have with myself.
  - jheriko 13y ago
    this is a terrible analogy, its more like 'i can't drive this car if i don't do an engine rebuild myself - maybe i'll drive this car that already works the way i want' tbh, i started a place they used git, i started learning it but nobody already there knew a damned thing about it and they should have been using it at all. they used it because it was more popular, despite having history with mercurial. we now use mercurial. no need to be condescending. i did just point out not knowing it was precisely my problem
    - jlgreco 13y ago
      Engine rebuild of git? You mean "learn how to use it". If you want to go with a car analogy, then it is more like you are going to keep on driving one car because you don't know how to drive the other. Git isn't broken just because you don't know how to use it.
      - jheriko 13y ago
        yes, but i also i mean configuring it. its not just that i don't know how to drive the other car, but to make it drive in a way which allows me to reach my destination i need to make changes to its configuration - rebuild the engine might be harsh, so lets say adjust the timing belt instead... or change my tires or something. analogies suck. learning curve is important for tools. the biggest problem was that (before i was even there) someone decided to use a tool they didn't understand instead of a tool that they did. learning git as i went along turned out to be a dangerous path compared to learning svn, p4 or hg as i went along - especially in an environment where everyone else was learning as they went along. i regret my initial harsh wording because it really isn't broken and in many respects its a fantastic tool, its just poorly designed - and this is very obvious if you look at any of the help pages - there are very few commands which perform common tasks without excessive options. i don't want to configure my tools that much when i don't need to (i.e. when other tools don't need that and provide the functionality i care about). implementation details shouldn't pollute my user experience. so, how do you revert a branch commit? every answer i've seen required considerably more knowledge and effort than any other source control solution i've used.
jheriko 13y ago
so, git reset was not able to solve my problem, nor was git revert, git gave me an error message explicitly stating that branch merges can not be reverted. when i researched it i came to the conclusion that the a configuration change was required to prevent this problem going forwards. i came to the conclusion that git had bad defaults for what i consider a critical function of source control - i consider this dangerous. i was able to solve our problem at the time, but the amount of time i wasted investigating a 'correct' solution using git exceeded the amount of time it took me to later create an 'anti-merge' commit myself (the fix) and move over to hg (prevent recurrance). i also chastised everyone for using something they didn't understand instead of the familiar well known tool because it was more popular (curing the cause). i am going to investigate reproing this since everyone is in such a state of disbelief and a good proportion seem to think i am completely inexperienced and stupid. the branch disappearing is a small thing thats confusing, but it comes down to the implementation details of git - because its all just a pile of diffs with labels and such when i merge it seems like the 'branch' disappears, even though its exactly the same data that was there before, just organised into a different hierarchy of changes. this is quite confusing, but it also means that, e.g. producing the anti-merge change, required more effort than it should have.

rallison 13y ago

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

This is precisely true. I don't know how to use git. That's a big part of the problem I have with it, I get much more bang for my buck in terms of time spent working things out if I don't use git.

jlgreco 13y ago
I don't know how to operate a airplane, but that isn't a problem I have with airplanes. That is a problem I have with myself.
- jheriko 13y ago
  this is a terrible analogy, its more like 'i can't drive this car if i don't do an engine rebuild myself - maybe i'll drive this car that already works the way i want' tbh, i started a place they used git, i started learning it but nobody already there knew a damned thing about it and they should have been using it at all. they used it because it was more popular, despite having history with mercurial. we now use mercurial. no need to be condescending. i did just point out not knowing it was precisely my problem
  - jlgreco 13y ago
    Engine rebuild of git? You mean "learn how to use it". If you want to go with a car analogy, then it is more like you are going to keep on driving one car because you don't know how to drive the other. Git isn't broken just because you don't know how to use it.
    - jheriko 13y ago
      yes, but i also i mean configuring it. its not just that i don't know how to drive the other car, but to make it drive in a way which allows me to reach my destination i need to make changes to its configuration - rebuild the engine might be harsh, so lets say adjust the timing belt instead... or change my tires or something. analogies suck. learning curve is important for tools. the biggest problem was that (before i was even there) someone decided to use a tool they didn't understand instead of a tool that they did. learning git as i went along turned out to be a dangerous path compared to learning svn, p4 or hg as i went along - especially in an environment where everyone else was learning as they went along. i regret my initial harsh wording because it really isn't broken and in many respects its a fantastic tool, its just poorly designed - and this is very obvious if you look at any of the help pages - there are very few commands which perform common tasks without excessive options. i don't want to configure my tools that much when i don't need to (i.e. when other tools don't need that and provide the functionality i care about). implementation details shouldn't pollute my user experience. so, how do you revert a branch commit? every answer i've seen required considerably more knowledge and effort than any other source control solution i've used.

jheriko 13y ago

so, git reset was not able to solve my problem, nor was git revert, git gave me an error message explicitly stating that branch merges can not be reverted. when i researched it i came to the conclusion that the a configuration change was required to prevent this problem going forwards. i came to the conclusion that git had bad defaults for what i consider a critical function of source control - i consider this dangerous. i was able to solve our problem at the time, but the amount of time i wasted investigating a 'correct' solution using git exceeded the amount of time it took me to later create an 'anti-merge' commit myself (the fix) and move over to hg (prevent recurrance). i also chastised everyone for using something they didn't understand instead of the familiar well known tool because it was more popular (curing the cause). i am going to investigate reproing this since everyone is in such a state of disbelief and a good proportion seem to think i am completely inexperienced and stupid. the branch disappearing is a small thing thats confusing, but it comes down to the implementation details of git - because its all just a pile of diffs with labels and such when i merge it seems like the 'branch' disappears, even though its exactly the same data that was there before, just organised into a different hierarchy of changes. this is quite confusing, but it also means that, e.g. producing the anti-merge change, required more effort than it should have.