6 ms·

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort." I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja and don't want to loose any work. There is probably proper command for it, but I sometimes get into a git mess that I cannot get out of. (reading stack overflow, trying get reset, git checkout, git reset --hard and so on)

globular-toast 5y ago
"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?
- erwincoumans 5y ago
  Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.
  - globular-toast 5y ago
    You misunderstand. Do you think I was born understanding how git works? I've messed up at least as much as you, but I spent the time learning how it works rather than going nuclear and deleting the repository. I can't relate to how you think about git because it's been too long for me, that's why I asked if you could explain it from your point of view.
    - seized 5y ago
      Ooof. What a useful contribution to the discussion.
  - MarkSweep 5y ago
    This sort of use case makes sense to make a copy of the .git folder. When you are trying to rewrite the history of a whole Git repo, throwing away the repo and starting for a backup is often easier than trying to unwind changes. Though in this specific case of rewriting emails, there is a way in git to do it without rewriting history: https://git-scm.com/docs/gitmailmap https://git-scm.com/docs/gitmailmap
- dec0dedab0de 5y ago
  Are you really shocked that someone would make a backup before doing something they are unsure of? Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.
  - globular-toast 5y ago
    > Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être. If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from.
    - erwincoumans 5y ago
      Git is a popular distributed versioning tool, but some commands have obscure syntax that is easy to get wrong, leading you into a mess that becomes a time drain. Creating a zip file of a git root folder takes seconds, and can get you out of the mess in seconds, rather than spending minutes or hours to undo some mess. If you can foresee git getting into a mess (and I can, after > 10 years of git experience), you can just take that backup to save time 'just in case' your git repo gets into that mess again. Changing the git commit history (for example because you made a commit under the wrong name/email address) in particular can cause huge headaches. Doing a git merge with tons of changes (think of clang-format white space changes in combination with various other commits) is another one. This is not about the specific cases where your git repo can become a mess, but more about having a simple safety mechanism to always get you out of the mess.
    - nkozyra 5y ago
      > If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from. All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. I also understand git fear - some of the stuff is a little arcane, and organizations are often very dogmatic and loud about their usage and approaches to git. It leads to a lot of gatekeeping. Do we rebase here? Do we never rebase? Linear history? Rebase feature branches or merge directly into main? It makes the fear of the tool that much stronger. `cp`, on the other hand, is pretty straightforward. There are no local approaches to using it, there's no real `cp` expert in-house at most places. It does what it says on the box without a lot of frills or options. git is a complex tool. It becomes easier the longer you use it, like most things, but it can be very intimidating to new or intermediate users.
- meepmorp 5y ago
  > Could you tell me what you think git is for and why you use it? Maybe it's not your intent, but you're coming off as a bit of a git yourself. He lacks your confidence.
  - globular-toast 5y ago
    > He lacks your confidence. But why? I'm trying to learn here. I'm know I'm autistic and don't understand anyone. It's clear that there's a huge difference in how I perceive git versus how a lot of people apparently perceive it. I'm trying to understand how other people perceive it but nobody will tell me!
balefrost 5y ago
Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_branch_backup. This same pattern is useful for other dangerous commands, like rebases or filter-branch. When you're done, just delete blah_branch_backup.
- altonen 5y ago
  You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.
  - balefrost 5y ago
    That's true! I personally prefer having a symbolic name for my backup, but the reflog is also very useful for "oops" moments.
  - zelphirkalt 5y ago
    Afaik git branches are merely pointers to commits, so it makes sense, that one can go back finding the correct commit id.
  - 5e92cb50239222b 5y ago
    reflog saved me a few times, just remember that commits not referenced by a pointer (like HEAD or branch) can be GCed and disappear at any point. They are likely to be there right after a merge/rebase is finished, but may not be there anymore an hour later.
- icedchai 5y ago
  I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!
dahart 5y ago
> There is probably a proper command for it Before you merge, the command is “git merge --abort”. After you merge, the command is “git reflog” to show your history, and then something like “git reset --hard HEAD@{1}” where the number in braces is the reflog entry you want to restore. Reflog is the ultimate undo tool for work that’s been committed, it’s like having an infinite Ctrl-Z. If you use reflog to restore before your merge, you can even use it again to restore your mess, or to restore a different merge before the one you made a mess of. The one thing you can’t recover using reflog is an accidentally dropped git stash. This is one reason I try to avoid stashes, and just use lots of one-off branches instead.
commandlinefan 5y ago
I'm the same - although I've had many experiences in the past where I avoided the time-saving tools because they were too complex in the moment and then kicked myself later on when I realized just how much time I had been wasting by avoiding spending ten minutes learning the time saving tools, every time I try to do a git merge "the right way", I end up with conflicts that shouldn't be conflicts and changes that I didn't want to pull in that I have to manually undo until I just give up and "manually" merge.
deleted 5y ago
[deleted]

globular-toast 5y ago

"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?

erwincoumans 5y ago
Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.
- globular-toast 5y ago
  You misunderstand. Do you think I was born understanding how git works? I've messed up at least as much as you, but I spent the time learning how it works rather than going nuclear and deleting the repository. I can't relate to how you think about git because it's been too long for me, that's why I asked if you could explain it from your point of view.
  - seized 5y ago
    Ooof. What a useful contribution to the discussion.
- MarkSweep 5y ago
  This sort of use case makes sense to make a copy of the .git folder. When you are trying to rewrite the history of a whole Git repo, throwing away the repo and starting for a backup is often easier than trying to unwind changes. Though in this specific case of rewriting emails, there is a way in git to do it without rewriting history: https://git-scm.com/docs/gitmailmap https://git-scm.com/docs/gitmailmap
dec0dedab0de 5y ago
Are you really shocked that someone would make a backup before doing something they are unsure of? Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.
- globular-toast 5y ago
  > Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être. If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from.
  - erwincoumans 5y ago
    Git is a popular distributed versioning tool, but some commands have obscure syntax that is easy to get wrong, leading you into a mess that becomes a time drain. Creating a zip file of a git root folder takes seconds, and can get you out of the mess in seconds, rather than spending minutes or hours to undo some mess. If you can foresee git getting into a mess (and I can, after > 10 years of git experience), you can just take that backup to save time 'just in case' your git repo gets into that mess again. Changing the git commit history (for example because you made a commit under the wrong name/email address) in particular can cause huge headaches. Doing a git merge with tons of changes (think of clang-format white space changes in combination with various other commits) is another one. This is not about the specific cases where your git repo can become a mess, but more about having a simple safety mechanism to always get you out of the mess.
  - nkozyra 5y ago
    > If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from. All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. I also understand git fear - some of the stuff is a little arcane, and organizations are often very dogmatic and loud about their usage and approaches to git. It leads to a lot of gatekeeping. Do we rebase here? Do we never rebase? Linear history? Rebase feature branches or merge directly into main? It makes the fear of the tool that much stronger. `cp`, on the other hand, is pretty straightforward. There are no local approaches to using it, there's no real `cp` expert in-house at most places. It does what it says on the box without a lot of frills or options. git is a complex tool. It becomes easier the longer you use it, like most things, but it can be very intimidating to new or intermediate users.
meepmorp 5y ago
> Could you tell me what you think git is for and why you use it? Maybe it's not your intent, but you're coming off as a bit of a git yourself. He lacks your confidence.
- globular-toast 5y ago
  > He lacks your confidence. But why? I'm trying to learn here. I'm know I'm autistic and don't understand anyone. It's clear that there's a huge difference in how I perceive git versus how a lot of people apparently perceive it. I'm trying to understand how other people perceive it but nobody will tell me!

balefrost 5y ago

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit: git branch blah_branch_backup Later, if your merge gets completely messed up, you can do: git merge --abort git reset --hard blah_branch_backup That final command will restore the current branch's HEAD to point to the same commit as blah_branch_backup. This same pattern is useful for other dangerous commands, like rebases or filter-branch. When you're done, just delete blah_branch_backup.

altonen 5y ago
You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.
- balefrost 5y ago
  That's true! I personally prefer having a symbolic name for my backup, but the reflog is also very useful for "oops" moments.
- zelphirkalt 5y ago
  Afaik git branches are merely pointers to commits, so it makes sense, that one can go back finding the correct commit id.
- 5e92cb50239222b 5y ago
  reflog saved me a few times, just remember that commits not referenced by a pointer (like HEAD or branch) can be GCed and disappear at any point. They are likely to be there right after a merge/rebase is finished, but may not be there anymore an hour later.
icedchai 5y ago
I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!

dahart 5y ago

> There is probably a proper command for it Before you merge, the command is “git merge --abort”. After you merge, the command is “git reflog” to show your history, and then something like “git reset --hard HEAD@{1}” where the number in braces is the reflog entry you want to restore. Reflog is the ultimate undo tool for work that’s been committed, it’s like having an infinite Ctrl-Z. If you use reflog to restore before your merge, you can even use it again to restore your mess, or to restore a different merge before the one you made a mess of. The one thing you can’t recover using reflog is an accidentally dropped git stash. This is one reason I try to avoid stashes, and just use lots of one-off branches instead.

commandlinefan 5y ago

I'm the same - although I've had many experiences in the past where I avoided the time-saving tools because they were too complex in the moment and then kicked myself later on when I realized just how much time I had been wasting by avoiding spending ten minutes learning the time saving tools, every time I try to do a git merge "the right way", I end up with conflicts that shouldn't be conflicts and changes that I didn't want to pull in that I have to manually undo until I just give up and "manually" merge.

deleted 5y ago

[deleted]