4 ms·

was hoping to see the deadly recursive merge disabled as a default and a one step mechanism to revert a branch. instead a lot of relatively minor things i don'

by jheriko 13y ago

was hoping to see the deadly recursive merge disabled as a default and a one step mechanism to revert a branch. instead a lot of relatively minor things i don't really care about (i'm sure its useful) - also seeing 'something now implemented in C' instead of 'something now 30% faster (because implemented in C)' is slightly worrying because users don't care about implementation details unless you get something else very very wrong... my issue with recursive merge is that 'works for 90% of linux kernel changes' or whatever it is is just not the same as 'works reliably'. git fails to meet my minimum requirements for usable source control because of the extreme difficulties I seem to have with undoing a merge if i don't change settings ahead of time (i.e. there is a bug which is a bad choice of defaults). i give it a good go, i get help from the community, i exhaust documentation and google - it doesn't work for me. maybe i don't understand something - i don't want to understand it, i want it to 'just work' and 'be user friendly'.

justinhj 13y ago
I'd say I'm quite proficient with git but undoing merges is something I dread having to do because the documentation for it is so complicated.
- Osiris 13y ago
  What do you mean by undoing a merge? I assume you're talking about something more complicated than what I usually do git reset --hard HEAD~ That just kicks you back to the commit just prior to your current (merge) commit. Are you talking about trying to undo a merge further back in the commit history?
  - jheriko 13y ago
    nope. if i merge two branches, push that to the remote and i wan't to undo it.
    - Crito 13y ago
      So push your fix? Push hard if necessary, and if your remote forbids non-fastforward pushes even with force, then delete the remote branch and recreate it under the same name with the commit that you want.
      - jgraham 13y ago
        In cases where forced pushes are disabled, deleting whole branches are typically disabled too, and generally for good reason (if someone else already pulled the branch with the removed commit they can end up in a mess and/or just repushing the unwanted thing by accident. So actually reverting a merge in git isn't that painful. It's typically just git revert -m 1 sha_1_of_merge_commit The problem is that if you then do more work on the branch and fix the problems that caused the merge to be reverted, redoing the merge doesn't work the way you expect; the commits that were previously merged don't get re-merged. So re-merging the branch consists of reverting the revert and then merging to get the new commits. Which is painful in-as-much as it requires you to know about the previous revert. My favoured solution to this is to never merge, always rebase, which also has the property of giving a nice linear history that can actually be understood. However some people prefer a merge-based workflow (and if you happen to use github it is very difficult to enforce anything else, due to the Big Green Button), so it is a real problem.
        MatthewPhillips 13y ago
        Interesting. Can you explain your rebase workflow a bit? I never thought of merge and rebase as overlapping that much, although I only use rebase to combine commits together.
        weaksauce 13y ago
        I'd imagine that the gp is working in a collaborative environment and before pushing to the origin for a merge commit if the ancestors are different, that gp will instead rebate on whatever changes have been made in the origin repo first so that the repo maintainer can just do a fast forward merge.
  - justinhj 13y ago
    The scenario is something I try very hard to avoid via workflow, but sometimes it still happens. Somebody merges something and pushes it to the master branch of the repo before it's ready. Now you want to pretend that never happened. You can't just revert it. If anyone can post instructions for easily getting the master branch back to how it was before the merge let me know.
    - Osiris 13y ago
      Your problem is not undoing merges, but allowing people to merge that shouldn't. A good solution like GitHub Enterprise or Stash will allow you to use pull requests, so you can require that code gets reviewed by a third-party before merging. In the case of Atlassian Stash, you can set branch permissions, which allow only certain users to commit/merge to that branch, and you can also require that a merge request be reviewed by specific individuals before the system allows it to be merged. Preventing the merge problem in the first place is a much better approach than trying to fix it afterwards.
      - thinkpad20 13y ago
        > Preventing the merge problem in the first place is a much better approach than trying to fix it afterwards. In a perfect world, all problems would be prevented. Unfortunately, we live in the real world, where being able to fix it afterwards is very important.
      - justinhj 13y ago
        Exactly. We use github enterprise. Our normal workflow prevents this problem, but shit happens.
    - justinmk 13y ago
      > Somebody merges something and pushes it to the master branch of the repo before it's ready. Now you want to pretend that never happened. Say 'abc123' is the commit immediately before the merge commit. Run this: git rebase -i abc123 In the editor window that appears, delete the commit(s) that you want to "pretend never happened". Exit the editor. Git then replays the commits from abc123 up to HEAD, except without the commits you deleted. Now your local branch is in a state that omits the premature merge commit.
ethomson 13y ago
I'd be interested to hear your complaints with git-merge-recursive. Unless your common ancestor is multiple ancestors (eg, criss-cross merges), which I can't imagine is really commmon, it shouldn't differ appreciably from git-merge-resolve except that it can do rename detection.
- qznc 13y ago
  My guess would be the default "fast-forward merge when possible". In this case there is no merge commit. When more is committed on top, you can see no trace of a merge anymore.
- jheriko 13y ago
  my complaint is exactly the comment i made. 'works most of the time in one situation' is not working. its a bit magical - i've only seen it do something insane once and i can't remember the specifics, but it introduced me to the concept and made me want to turn it off. i really don't mind conflicts. safety over rushing every time...

by jheriko 13y ago

justinhj 13y ago

I'd say I'm quite proficient with git but undoing merges is something I dread having to do because the documentation for it is so complicated.

Osiris 13y ago
What do you mean by undoing a merge? I assume you're talking about something more complicated than what I usually do git reset --hard HEAD~ That just kicks you back to the commit just prior to your current (merge) commit. Are you talking about trying to undo a merge further back in the commit history?
- jheriko 13y ago
  nope. if i merge two branches, push that to the remote and i wan't to undo it.
  - Crito 13y ago
    So push your fix? Push hard if necessary, and if your remote forbids non-fastforward pushes even with force, then delete the remote branch and recreate it under the same name with the commit that you want.
    - jgraham 13y ago
      In cases where forced pushes are disabled, deleting whole branches are typically disabled too, and generally for good reason (if someone else already pulled the branch with the removed commit they can end up in a mess and/or just repushing the unwanted thing by accident. So actually reverting a merge in git isn't that painful. It's typically just git revert -m 1 sha_1_of_merge_commit The problem is that if you then do more work on the branch and fix the problems that caused the merge to be reverted, redoing the merge doesn't work the way you expect; the commits that were previously merged don't get re-merged. So re-merging the branch consists of reverting the revert and then merging to get the new commits. Which is painful in-as-much as it requires you to know about the previous revert. My favoured solution to this is to never merge, always rebase, which also has the property of giving a nice linear history that can actually be understood. However some people prefer a merge-based workflow (and if you happen to use github it is very difficult to enforce anything else, due to the Big Green Button), so it is a real problem.
      - MatthewPhillips 13y ago
        Interesting. Can you explain your rebase workflow a bit? I never thought of merge and rebase as overlapping that much, although I only use rebase to combine commits together.
        weaksauce 13y ago
        I'd imagine that the gp is working in a collaborative environment and before pushing to the origin for a merge commit if the ancestors are different, that gp will instead rebate on whatever changes have been made in the origin repo first so that the repo maintainer can just do a fast forward merge.
- justinhj 13y ago
  The scenario is something I try very hard to avoid via workflow, but sometimes it still happens. Somebody merges something and pushes it to the master branch of the repo before it's ready. Now you want to pretend that never happened. You can't just revert it. If anyone can post instructions for easily getting the master branch back to how it was before the merge let me know.
  - Osiris 13y ago
    Your problem is not undoing merges, but allowing people to merge that shouldn't. A good solution like GitHub Enterprise or Stash will allow you to use pull requests, so you can require that code gets reviewed by a third-party before merging. In the case of Atlassian Stash, you can set branch permissions, which allow only certain users to commit/merge to that branch, and you can also require that a merge request be reviewed by specific individuals before the system allows it to be merged. Preventing the merge problem in the first place is a much better approach than trying to fix it afterwards.
    - thinkpad20 13y ago
      > Preventing the merge problem in the first place is a much better approach than trying to fix it afterwards. In a perfect world, all problems would be prevented. Unfortunately, we live in the real world, where being able to fix it afterwards is very important.
    - justinhj 13y ago
      Exactly. We use github enterprise. Our normal workflow prevents this problem, but shit happens.
  - justinmk 13y ago
    > Somebody merges something and pushes it to the master branch of the repo before it's ready. Now you want to pretend that never happened. Say 'abc123' is the commit immediately before the merge commit. Run this: git rebase -i abc123 In the editor window that appears, delete the commit(s) that you want to "pretend never happened". Exit the editor. Git then replays the commits from abc123 up to HEAD, except without the commits you deleted. Now your local branch is in a state that omits the premature merge commit.

ethomson 13y ago

I'd be interested to hear your complaints with git-merge-recursive. Unless your common ancestor is multiple ancestors (eg, criss-cross merges), which I can't imagine is really commmon, it shouldn't differ appreciably from git-merge-resolve except that it can do rename detection.

qznc 13y ago
My guess would be the default "fast-forward merge when possible". In this case there is no merge commit. When more is committed on top, you can see no trace of a merge anymore.
jheriko 13y ago
my complaint is exactly the comment i made. 'works most of the time in one situation' is not working. its a bit magical - i've only seen it do something insane once and i can't remember the specifics, but it introduced me to the concept and made me want to turn it off. i really don't mind conflicts. safety over rushing every time...