Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git undo: We can do better

blog.waleedkhan.name

Post reply on HN
Print view View original

481–490 of 490 posts

Re: Git undo: We can do better

#481

Post by lmm »

lisper wrote: post #466
lmm wrote: post #441

Earlier quoted context omitted.

> 2. Git's merge is not smart enough to realize that identical changes in two branches are not actually a conflict. I've often ended up in situations where a small bug has been fixed in two branches which then won't merge without manual intervention. This is incredibly annoying. (To be fair, this is not unique to git. But because git encourages branching more than other systems, I encounter it more when using git in…

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 ide…

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.

Re: Git undo: We can do better

#482

Post by lisper »

lmm wrote: post #481
lisper wrote: post #466

Earlier quoted context omitted.

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 ide…

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.

> 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.

Re: Git undo: We can do better

#483

Post by lmm »

lisper wrote: post #482
lmm wrote: post #481

Earlier quoted context omitted.

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.

> 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.

> 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.

Re: Git undo: We can do better

#484

Post by lisper »

lmm wrote: post #483
lisper wrote: post #482

Earlier quoted context omitted.

> 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.

> 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.

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. ;-)

Re: Git undo: We can do better

#485

Post by lmm »

lisper wrote: post #484
lmm wrote: post #483

Earlier quoted context omitted.

> 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.

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 t…

> 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.

Re: Git undo: We can do better

#486

Post by lisper »

lmm wrote: post #485
lisper wrote: post #484

Earlier quoted context omitted.

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 t…

> 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 re…

> 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.

Re: Git undo: We can do better

#487

Post by lanstin »

pja wrote: post #458
marton78 wrote: post #408

Earlier quoted context omitted.

I would if I used Emacs

Plenty of people run Emacs purely in order to use Magit & don’t use it for anything else. That’s how good Magit is.

It is excellent, and you can use it well without reading anything (assuming you know git, and I know emacs so maybe that too, although it has the pleasant property of listing a lot of keyboard commands in the UI).

Re: Git undo: We can do better

#488

Post by CRConrad »

npteljes wrote: post #410
u801e wrote: post #390

Earlier quoted context omitted.

Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.

My env doesn't do this. Here's what I did: git checkout -b test git push And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test" But in this situation, we actually push with "git push -u origin branchname". After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a pus…

AIUI the problem there wasn't with the branch name, but that the "-origin" bit -- the reference for where to push to / pull from -- was missing. The -u parameter someone else suggested apparently sets that at the same time as pushing/pulling, so it combines the effect of "--set-upstream" suggested in the error message you got and then push/pull. (A bit like "checkout -b newbranchname" combines creating and then switching to a branch; there is some consistency to the UI, but it's weird and spotty.)

I've almost never had this problem; nearly all branches I've come across usually "know all by themselves" where their remote is. I suspect they inherit it from a global or repository-level setting that might be missing from your setup. Have you tried executing that "--set-upstream" it suggests? Maybe that sets it for the whole repo, or have you had to repeat it for each branch (like the "-u" parameter for the push seems to imply)?

Or maybe, even if you have the remote set correctly on the repo level, branches just somehow don't "inherit" that...? Idunno, maybe some magic setting missing. Aha, one further possibility: If you set the remote on the "master" (or "main") branch, maybe branches branched off from that (and others branched off from those, etc) "inherit" the remote setting?

Finally: Creating a git repo by cloning in stead of from scratch (git clone in stead of git init) automagically sets the remote for the master branch of the newly cloned repo to the master of the repo it was cloned from. Maybe, if this is how it works, that's why it's always worked for me: I've worked mainly with cloned repositories, and my branches are almost always -- albeit sometimes indirectly -- branched, ultimately, from "master".

Anyway, I think somewhere among all that there should be something that fixes your problem once and for all (i.e. for all future branches once it's correctly set for a repo). I'm sure your problem isn't standard behaviour. HTH!

Re: Git undo: We can do better

#489

Post by CRConrad »

yarg wrote: post #220
alkonaut wrote: post #181

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like t…

There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and ga…

> I don't always want a branch to descend from a commit

What does this even mean?

> sometimes I want it to descend from another (less featureful) branch.

Yeah, so? Just do that, then. Checkout the branch you want to descend from, create your new branch, and it's descended from the branch you checked out. (That's literally the default for how branching works in git, so... What are you actually asking about?)

Re: Git undo: We can do better

#490

Post by GordonS »

abdusco wrote: post #106
OhNoMyqueen wrote: post #70

The most painful mistakes beginers endure with git are irrevocable code removal from the current working directory because of bad usage of `git clean`, `git reset` (or `git merge` if you're brutish enough). This problem cannot be solved by using git, because git doesn't have any reference to such code.

If you're using JetBrains products, you can view the history of the changes for the whole project and revert mistakes by right-clicking the project > Show Local Changes. https://twitter.com/abdusdev/status/1403050600925962247

I use Rider, and this has saved me multiple times!

JetBrains IDEs also have the best UI I've come across for conflict merges.

Post reply on HN