4 ms·

Yes, but to make that work you must do it for every change you want to make, even the most trivial. Find a typo while you're working on something else? You ca

by lisper 5y ago

Yes, but to make that work you must do it for every change you want to make, even the most trivial. Find a typo while you're working on something else? You can't just fix it. You have to branch, edit, cherry pick, commit, and then push to make sure someone else doesn't find and fix the same typo. It's damned annoying because it would be so simple to fix: just tweak the diff algorithm to check if the conflicts are identical and auto-merge them if they are. How hard can that be?

lmm 5y ago
There shouldn't be a cherry pick involved, and my protip would be that you don't actually need to make a local branch for small changes; quite often I'll just do `git checkout origin/master`, make the fix, commit, and `git push mine HEAD:refs/heads/quickfix`. But yeah, it would be nice to have a way to just commit a diff at a different point in history without having to check it out.
- lisper 5y ago
  > There shouldn't be a cherry pick involved There is if you discover the typo in the middle of working on something else, which is usually the case for me.
  - lmm 5y ago
    > There is if you discover the typo in the middle of working on something else, which is usually the case for me. Why/how? If I had other uncommitted changes when I found the typo I'd stash or commit them so that I had a clean checkout to do the typo fix from, but can't think of any case where cherry pick is the right answer.
    - lisper 5y ago
      Yeah, but I find that can be pretty disruptive to my flow. You have to: 1. Switch from your editor to a shell 2. Stash 3. Switch from your shell back to your editor 4. Revert the editor buffer 5. Fix the typo 6. Save 7. Switch back to your shell 8. Commit Now you have to push that fix into all the upstream branches (because the whole point of this exercise is to avoid merge commits from someone else fixing the same typo), so: 9. Checkout 10. Pull 11. Merge the typo fix (at which point you might discover that someone else has already fixed this typo, or that you have an actual conflict that needs to be dealt with) 12. Commit 13. Push (at which point you might discover that someone else was in the process of fixing the same typo and just happened to push before you did. This is unlikely, but it becomes more likely the longer you wait between step 10 and 11 because there is a race condition here.) 14. Repeat for every upstream branch in which anyone could have already fixed the same typo Then, finally: N. Stash pop N+1. Switch back to your editor N+2. Revert your editor buffer N+3. Try to remember what you were working on before you started this process. It's a hell of a lot easier to just fix the typo and say, "ah, fuck it", and then curse at git for not being smart enough to figure out that identical changes aren't conflicts. ;-)
      - lmm 5y ago
        > Yeah, but I find that can be pretty disruptive to my flow. Well, I think it's very much worth having git support integrated into your editing tool, so for me the workflow is more: 1. Shelve current changes, if any 2. (Optional) fetch origin 3. Switch branch 4. Make the fix 5. Commit-push 6. Merge this branch upstream 7. Switch branch back 8. Pull upstream master 9. Unshelve if necessary I wouldn't consider it my responsibility to apply the fix to anyone else's branch - rather every branch has an owner and it's their responsibility to update from origin master at whatever frequency suits them - and if someone else has fixed the problem in parallel then either I notice at stage 4, or, if they did it in between me reaching 2 and me reaching 6 then 6 fails harmlessly (I just continue to 7 and 8 and I pick up their version of the fix, no need to resolve any conflict). This does rely on having a single shared "origin master" (whether that's your git hosting system, your release manager's machine, or something else) that can do step 6 atomically - if you really want a 100% decentralised system then yeah the price of that is eventual consistency. All that said, git merge absolutely does treat a byte-for-byte identical change as not a conflict (I just confirmed with git merge-file), and will treat an identical-except-for-whitespace fix as not a conflict if you pass it the appropriate flags, so I think something else must be going on to cause the problem you're seeing.
        lisper 5y ago
        > I wouldn't consider it my responsibility to apply the fix to anyone else's branch I guess my situation is a bit unusual. We have two production branches because we're running our code in two different environments. So we have two branches that are effectively origin/masters. > git merge absolutely does treat a byte-for-byte identical change as not a conflict That's news to me. I guess I'll have to try that again because I have a very clear memory of seeing this happen and thinking WTF? But that could have been a long time ago.

by lisper 5y ago

lmm 5y ago

There shouldn't be a cherry pick involved, and my protip would be that you don't actually need to make a local branch for small changes; quite often I'll just do `git checkout origin/master`, make the fix, commit, and `git push mine HEAD:refs/heads/quickfix`. But yeah, it would be nice to have a way to just commit a diff at a different point in history without having to check it out.

lisper 5y ago
> There shouldn't be a cherry pick involved There is if you discover the typo in the middle of working on something else, which is usually the case for me.
- lmm 5y ago
  > There is if you discover the typo in the middle of working on something else, which is usually the case for me. Why/how? If I had other uncommitted changes when I found the typo I'd stash or commit them so that I had a clean checkout to do the typo fix from, but can't think of any case where cherry pick is the right answer.
  - lisper 5y ago
    Yeah, but I find that can be pretty disruptive to my flow. You have to: 1. Switch from your editor to a shell 2. Stash 3. Switch from your shell back to your editor 4. Revert the editor buffer 5. Fix the typo 6. Save 7. Switch back to your shell 8. Commit Now you have to push that fix into all the upstream branches (because the whole point of this exercise is to avoid merge commits from someone else fixing the same typo), so: 9. Checkout 10. Pull 11. Merge the typo fix (at which point you might discover that someone else has already fixed this typo, or that you have an actual conflict that needs to be dealt with) 12. Commit 13. Push (at which point you might discover that someone else was in the process of fixing the same typo and just happened to push before you did. This is unlikely, but it becomes more likely the longer you wait between step 10 and 11 because there is a race condition here.) 14. Repeat for every upstream branch in which anyone could have already fixed the same typo Then, finally: N. Stash pop N+1. Switch back to your editor N+2. Revert your editor buffer N+3. Try to remember what you were working on before you started this process. It's a hell of a lot easier to just fix the typo and say, "ah, fuck it", and then curse at git for not being smart enough to figure out that identical changes aren't conflicts. ;-)
    - lmm 5y ago
      > Yeah, but I find that can be pretty disruptive to my flow. Well, I think it's very much worth having git support integrated into your editing tool, so for me the workflow is more: 1. Shelve current changes, if any 2. (Optional) fetch origin 3. Switch branch 4. Make the fix 5. Commit-push 6. Merge this branch upstream 7. Switch branch back 8. Pull upstream master 9. Unshelve if necessary I wouldn't consider it my responsibility to apply the fix to anyone else's branch - rather every branch has an owner and it's their responsibility to update from origin master at whatever frequency suits them - and if someone else has fixed the problem in parallel then either I notice at stage 4, or, if they did it in between me reaching 2 and me reaching 6 then 6 fails harmlessly (I just continue to 7 and 8 and I pick up their version of the fix, no need to resolve any conflict). This does rely on having a single shared "origin master" (whether that's your git hosting system, your release manager's machine, or something else) that can do step 6 atomically - if you really want a 100% decentralised system then yeah the price of that is eventual consistency. All that said, git merge absolutely does treat a byte-for-byte identical change as not a conflict (I just confirmed with git merge-file), and will treat an identical-except-for-whitespace fix as not a conflict if you pass it the appropriate flags, so I think something else must be going on to cause the problem you're seeing.
      - lisper 5y ago
        > I wouldn't consider it my responsibility to apply the fix to anyone else's branch I guess my situation is a bit unusual. We have two production branches because we're running our code in two different environments. So we have two branches that are effectively origin/masters. > git merge absolutely does treat a byte-for-byte identical change as not a conflict That's news to me. I guess I'll have to try that again because I have a very clear memory of seeing this happen and thinking WTF? But that could have been a long time ago.