Git undo: We can do better
blog.waleedkhan.name
blog.waleedkhan.name
The truth is, while we use git every day, most people really don't understand how it works.
There I said it. And I'm not ashamed.
I don't really know how Git works. And I think I'm not the only one.
What does "git reflog" or "git reset --hard ...." do? What are the implications?
We don't really know.
I feel stupid. But hey, at least I'm honest.
But why is one popular when the other one is so much better? I guess we will never know
Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication & collaboration, those things really matter.
But you do know how to pronounce "Unnecessarily"?
This happens all the time
Mercurial is less intimidating if you don't know much about internals. But tbh, when I use Mercurial I still find myself searching which command to do things. As a frequent power user, I find the Git CLI to be more useable.
I once knew how it worked with moderate level of detail, but I simply do not need anything advanced for my day-to-day work.
Maybe you've already read it, but this is what let me grok the underlying data.
Comments like this, which points to a resource intended to help people "grok the underlying data", has the effect of seizing the focus of conversation and implicitly retargeting it to be concerned with with people who don't understand the underlying data model. When you been through this enough times, it just comes off as incredibly annoying and a source of tiresomeness.
Even worse, I'm not sure I correctly remembered the weird combination of actions and flags to use to get back to the state where I can continue with what I wanted to do in the first place.
That article is a good example of the problem. It tells me `git rebase` is an easy thing to do but I better not use that distributed VCS to publish my work that way, where 'publish' probably also applies to different machines of mine.
It's just that the command-line interface is very opaque regarding what it does to that data.
For instance, say I want to apply the last three commits I made in one branch to another branch. It's a very simple operation conceptually.
Good luck remembering that the command that does it is rebase, and what the arguments for it are.
git init --submodule --recursive
Or is it
git submodule --init --recursive?
God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands.
And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?
This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.
I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull`
Or:
> git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD'
From:
You probably also want:
git config --global rebase.autostash true
[pull]
ff = only
I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.
Git submodule runs commands on submodules.
What is hard about this UX?
And it's not punishing you, its doing what you asked, to pull into a non matching head, how does it know you're not using git in the intended and distributed way?
Btw, just quit the editor without saving, it aborts.
What they're saying is: if you quit that editor without saving the commit message, git will abort.
AFAIK whatever's opened does need to block the CLI, so you can't use a command that opens a GUI editor then returns immediately or git will interpret that as your having closed the file without saving, but otherwise any editor should work, CLI or GUI, and can be assigned in your git config.
Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.
On the contrary, you want those commits for bisection, which is the main reason to have a VCS history at all.
> Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.
People think they want that, but I've never seen a convincing case for why. Bisect works better if you use merge. Blame works better if you use merge. And if you really want to see the history without merges (why?), it's one flag to do that.
I think I know git well, but you got me confused. I've never heard of pushes causing merges. Surely you are talking about pulls, right?
The only theory that makes sense is that this person doesn't know how to `pull --rebase`, but the order of `push` vs `pull` wouldn't change the presence of merge commits, so I'm still confused.
If I pull from origin before making my changes, I don’t have to merge, obviously.
But correct me if I’m wrong: I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched.
This is a common scenario for me. Correct some typos in comments for example, and I get forced to figure out how to merge using vim, which I don’t know how to use at all (being a nano user). I’m sure I could and should switch to at least using nano by default, but I don’t know how merging really works, either.
What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.
I do understand the problem being discussed; what I don't understand is what it has to do with pushing first. You have the same problem no matter which order you use `git push` vs `git pull`.
> I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched.
Yes, that's true.
> What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.
You can do that with `git pull --rebase`, which, as others have mentioned, you can set as the default behavior of `git pull` like this:
1. After making a PR, there are conflicts when merging into main. In a merge-based workflow, I would merge main into the feature branch, resolve any conflicts, then push. In a rebase-based workflow, I rebase the branch onto main, resolve any conflicts, but now I need to push --force. As some of the other comments have mentioned, this can be improved with --force-with-lease, but still isn't the greatest.
2. After making a PR, there are some typos that need to be fixed. Fix these in an interactive rebase, to edit the same commit that introduced the typos. Also requires either --force or --force-with-lease.
3. When the PR is accepted, the result is rebased on top of main. My local branch still exists, and must be deleted. I would prefer to use `git branch -d` to delete the feature branch, but this rightfully says that the feature branch hasn't been merged in. I instead need to use `git branch -D` to forcefully delete it, introducing a point of human error. (There are some cases where git can delete the branch safely, which I think occurs either when the feature branch has only a single commit, or when the feature branch can be applied on top of main without a rebase, but I haven't exactly determined it.)
#1 and #3 are cases where a safer option cannot be used due to a rebase-workflow. #2 would exist in either case, since even in a merge workflow, rebasing of branches before they are pulled makes sense to do.
FWIW: it occurs when the feature branch was based on the tip of master (because no-one else has committed to master since you branched/since you rebased onto master) - in this case rebasing your feature branch onto master is a no-op and the commits that go into master have the same hashes as they had on your feature branch.
Like, I've had to explain a lot of times why you `git pull origin master` but when you want to interact with that remote branch otherwise it's `origin/master` instead. The lack of clarity is in what commands operate on what levels, with many of them operating on several at once.
There have been some efforts to reform the command set to be more clear, like `git switch`, but the old commands will persist forever along with a lot of other footguns (like `git push --force` really ought to be replaced with `git push --force-with-lease` and moved to `git push --force-I-really-mean-it` so it hardly matters.
`git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`.
Everything under `origin/` (or really `refs/heads/origin/`) is just a cached pointer to the last known state of that ref on the remote.
All other commands operate only on these local references. So when you want to refer to what you know to be the state of things on `origin`, you can use `origin/master`. Otherwise that command has no particular knowledge of how to talk to origin.
Incidentally this is a shortcut I use all the time to update my local master from a remote:
`git fetch origin master:master`
Which is super unclear in its meaning but it means fetch origin's master HEAD and put it in my local master ref. I actually use this more often than git pull nowadays.
Pushing merges is great. Pushing random (unreviewed) local commits directly to master is bad, but it's no worse when those commits are merges than when they're not. Conversely, rebasing master (which is quite easy to do if you're inexperienced but have been advised to use git pull --rebase) and pushing that creates a self-perpetuating mess that is very hard to fix (because even if you fix what you did, any other user who did a rebase-pull of master in the meantime is going to reintroduce the problem). Using rebase also trains you to force-push which makes messing up published branches much easier.
It is worth the time to fully understand refspecs. Once people do, they tend to understand all essential ramifications of branch and repository naming.
- origin master <=== the actual remote version of the master branch
- origin/master <=== a local branch that you cached from the "origin master" remote, may or may not be in sync with the real "origin master"
`git pull remote_repository_name branch_name` is the generic way to look at it instead of some magic incantation.
I like to call origin "upstream" to differentiate them.
and then git pull is another way to think of git fetch and git merge as one command roughly.
Comparing against that locally cached ref is also what git uses to tell you how far behind/ahead of the upstream you are in `git status` or whatever. Fetch and push are the only git commands that actually talk to a remote (at the "user level" of the command set anyways, those are also composed of lower level commands).
If it's difficult to keep your mental model of some system up to date, I doubt that doing bigger steps at once makes things easier.
So
1. run `git fetch`
2. if the textual output does not tell you what has happened, run `gitk -all`
3. Decide what to do. Rebase, merge, whatever.
Of course if you know exactly what you are doing, pull can be fine. If you changed the repo yourself on another computer that is the case. Otherwise, how can you know your second step, before having even seen the data you are operating on? Well, it can work, but if it doesn't, don't complain.
I agree. For a DVCS like git, separating the network transaction from updating the working copy on disk is the best way to go about it. Going in the other direction, this is the default since git add, git commit and git push are executed separately.
Essentially the whole concept of "upstream" is weird and non-orthogonal. Another one that bothers me is that as far as I can see there's no way to globally turn off setting an upstream on newly created branches (I can pass a flag to the specific "git branch" command, but that's tedious and error-prone).
This is the crux for me. Command naming is completely unrelated to and unindicative of state.
It feels like surely there's an opportunity for the basic CRUD operations to be collapsed down into a standard "{action} {source} {target}" style.
There will be nuances, specifically around branching, but the basics should be basic. As opposed to a Swiss Army knife, where you have to pull out the scissors and squeeze them three times before you can unfold and use the blade.
As part of a security-related project some years ago, my team and I hacked jgit to use SHA256, which required changing the length of pretty much every on-disk data structure. Sadly, there was (probably still is) no HASH_LEN constant, just a lot of magic offsets strewn throughout the code. I had to compare lengths against the git spec at every step.
And yet I still scramble for stackoverflow every time something goes slightly amiss.
It was actually a pretty cool system. I don't think it was ever sold though.
Wow, that description feels spot on.
jGit is actually a separate project from core Git, but once it gets adopted into core Git we can expect that jGit will follow suite, given that it's critical to Gerrit and other projects.
[1] https://lore.kernel.org/git/20191223011306.GF163225@camp.cru...
All it does is add this simple check before actually pushing:
if (remote_ref("blah") != local_ref("remote/blah"))
fail();
I try to be pragmatic about this sort of thing yet push —force is one of those cultural no-no’s for me.
For the rest, there's shell autocomplete and muscle memory.
I'm the guy people go to fix Git screw ups at my jobs but I just click a few buttons or drag a few commits...
Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository.
I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.
EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.
git commit -v
git config commit.verbose true
There's a user request that's been sitting around for a while to pull it out into a dedicated application, which I could personally get behind since we have one project at work that's pretty difficult to run outside of Eclipse
Then there's 'git add -i' to easily choose which files to add
Not GP, but I find it extremely hard to parse visually even after having had to do it a lot. Something like git-delta makes it bearable, but a decent syntax-highlighted, color-coded, side-by-side diff view with proper keyboard navigation (next diff, next file) is a huge quality of life boost for me.
> Then there's 'git add -i' to easily choose which files to add
Didn't know that, just tried it, and, wow, that's easily the most unintuitive and inscrutable TUI since vi. I haven't been able to make it show a simple diff; someone else also tried, failed as well.
git diff
git diff --staged
git restore --staged --partial
git commit
Git is really weird but useful.
[core]
editor = vimFor example in ubuntu you can do
sudo update-alternatives --config editor
export EDITOR=vi
git config --global core.editor viThere are days where I daydream of Clearcase when dealing with git.
If you wrote git 2.whatever from scratch would you structure rhe commands a bit differently? Yeah, sure, probably; but I always think these threads are way overblown. The common stuff that you use frequently.. well you use it frequently, so either you remember it as a result or you use the alias feature so that you can. For the less common stuff.. if you have to look it up in the excellent documentation, is that a failing?
Yes, if we ever want version control to become mainstream.
Version control is a very practical, day to day concept.
It's just almost unusable for regular folks.
And regular folks for sure won't use CLIs (unless you point a gun to their heads).
Who's trying to make 'regular folks' use git, with or without a gun?
I would have loved to have that option quite a few times. Lots of projects that involve software, but also get contributions from non-developers, or need almost no user-facing config, but not exactly zero. If git wasn't so hostile, quite a few tiny config web UIs I've built over the years could have been SublimeText or the like and a very userfriendly git client. It's kind of frustrating to have a repository with a directory full of .sql files, a CI pipeline that versions and verifies those and deploys the updated app, but the domain expert who is perfectly capable of writing the SQL still needs me to put the file in the right place and commit+push it, because they (understandably) just won't use git on Windows.
I'm not sure how understandable that is, especially in the age of WSL - but I just won't use Windows so what do I know :)
I do most of my git through one or another UI (right now, mainly the integrated functionality in VSCode, a gitflow workflow extension for VSCode, and repository history graph extension for VSCode that supports doing operations against branches/tags/commits from the graph.) I feel loke I’m thriving that way.
Its not a substitute for knowing git, though, and I think that people who lean on a UI as a substitute for knowing what is going on underneath rather than as a convenience layer are not likely to thrive.
Same for VSCode on non-Windows.
I only mention this because I came to hate Sourcetree in its newer iterations on Windows so much that I tried out Visual Studio's support and was pleasantly surprised.
First of all, a well-designed Git GUI (examples below) exposes the git's underlying data model to you; in contrast, the CLI obscures it until something breaks and you're forced into it without context. Git operates on a graph and there is simply no way around it. The more you're exposed to the graph, the better you can mentally model it and ask it to do the right things.
While there are many half-baked Electron-based UIs that only unnecessarily complicates things, there are good ones too:
On Windows (and Linux thru Mono), I use GitExtensions. The visualizations are sane and discover-friendly. It will tell you what to expect.
When I work on C++ projects, the one built into CLion (JetBrains family; as mentioned by a sibling comment) is very good on its own. What impresses me the most is that has good visual support of a patch-oriented workflow. You can work with multiple "changelists" offline, shuffle individual changes around, seamlessly convert between changelists and patch files, and (most importantly) still work nice with the vanilla git model as the "actual history". It also works transparently with conceptually monorepo projects that have multiple physical repos, allowing you to do simultaneous commits.
I feel VSCode, GitHub client, Kraken, and several other Electron-based stuff, are too focused on the "polish" than substance, or are too opinionated to be used across repos I don't own.
All GUIs are not created equal. The JetBRains GUIs are pretty good. Others try and impose git "their way" and just invite creating a mess.
Basically the IDE has its own revision history of your project’s files that it stores and you can recover your files from it. So when you accidentally revert instead of undo or use —-hard when you didn’t really mean to, Local History comes and saves the day.
It's something I use all day, every day. I'd say it's worthwhile to learn if your daily job involves working under source control
Recloning to me is a bit like tearing your house down and rebuilding it just because you painted your living room the wrong colour (in most cases!)
And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development.
Unfortunely.
Sure, recloning and cp your changes to a fresh local repo will _work_, but what happens on the day you don't have access to the remote? What happens when you have to work on a repo that takes minutes to clone from the remote? All of those lost minutes because you don't understand how to use your tools means you aren't getting work done.
> memorize an obscure set of incantations like some kind of D&D wizard
If you're using Git then you're probably someone that works on software, isn't our whole job memorizing and reproducing permutations of obscure incantations to produce business value? Knowing how to use your tools provides business value, that's not some hot take but literally how you provide value to whoever pays you.
1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with.
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 idiomatic ways.)
3. This is the biggie: translating the abstract idea of what I want to do into an actual git command is a black art. The underlying model is beautiful, but the UI is atrocious. The plumbing is great. The porcelain is cracked and mildewy. There are mysterious valves and pipes all over the place when all I want is one control for the hot water and another one for the cold.
The similar project [Jujube](https://github.com/martinvonz/jj) has experimented with backing up even unstaged changes after every command, and apparently it works well for them, so we could do the same in the above design.
Undoing even untracked changes might be a bit much.
Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like:
git branch list
git branch create [name]
git branch delete [name]
git branch rename [old-name] [new-name]
None of these things are actually the case. Git checkout will clobber unsaved changes in my working directory. "Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. Minor variations on a theme can result in radically different commands with various mysterious arguments. There is no rhyme or reason or regularity. The only way to know is to look it up.
As a counter-opinion, I actually like it this way. Especially since it's the rule and not the exception. When one makes the small effort to learn the commands, the payoff in saved keystrokes from avoiding typing the redundant pieces is great.
As a painfully simplified justification: Directory listing is "ls" and removing a directory is "rmdir" - I much prefer that to typing a hypothetical "directory list" and "directory delete", even if the later fits some nice consistent shape.
It's one of the reasons I hate powershell/windows-style CLI and its 60-character long arguments for every function.
I've been using Git professionally for of a decade and you just taught me something new. I always use `git checkout -b [name]` (which is a completely bananas UX, but it's the one I know).
Contrast that with TFVC which tries its best to nuke everything within it's reach (that is not under version control) in inexplicably stupid ways.
tf reconcile . -r -clean
git reset --hard origin/head && git clean -fdx
tf reconcile . -r -i clean
How about if you pipe a list of files into tf reconcile, to avoid it's idiotic behavior? Say
git ls-tree HEAD -z | xargs -0 tf reconcile -r -clean
rm -rf .
It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.
The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case.
That's reality in engineering.
If developers want to call themself "engineers" they should behave as such.
On the other side you don't let people without special training even close to industrial machines! The risk they could get killed by an accident is just to high.
Here lies the discrepancy actually: "Software industry" is as much an industry as running a kindergarten is. Also there is the most time no "engineering" at all in "software engineering"… Just trail and error until "something works" (or at least looks on the surface like it would, no matter how broken it is on the inside).
As long as people are supposed to "learn on the job", and there are no clear quality / security standards in this "industry", and stuff is called "engineering" even no true engineering approaches are followed, nothing will change. Machines will continue to kill people in completely avoidable accidents (virtually)…
But that's in my opinion a fully homemade misery actually.
When I started web dev, I earned $15/hr. Beat the $8/hr I was making before that in landscaping. Now I make a little more than that, which still isn't much. My clients/employers don't pay crazy wages and they don't expect crazy quality work. They know they get what they pay for, and it works out for both parties.
Maybe's OK to have shitty, mediocre code for 90% of the world's needs... a small biz website, with the ecommerce/PCI bits outsourced? Sure, why not. It mostly works, and if it goes down for a few hours a year, maybe that doesn't meet super-reliability standards (can we count 8s instead of 9s?) but it gets the job done well enough? Shrug.
Sure, proper engineer techniques matter for certain applications. I would never want to touch industrial machines, or medical, or space, or automobiles... anything that could blow up and/or kill someone. But most code out there is just for some local, small-scale use, mostly temporary anyhow and bound to obsolete in a few years if not months. There will always be mediocre businesses needing mediocre devs for mediocre pay, just as there will be elite enterprises that require the world's smartest people.
Problem is, git was designed by the super smart for the super smart, great engineering with terrible UX. And it was kinda just trickled down to the rest of us, and it feels a bit like trying to teach Mom to use DOS and edit config.sys just to play a game. Now consumer software UX has leaped forward by decades and it shows, but a lot of the command-line dev tools are still incredibly arcane. They don't have to be, but it's not a priority to fix/improve their UX because, I suppose, it's engineers who are proud of their engineering, not proud of their ability to dumb it down for the rest of us. I don't blame them, I just know I can't meaningfully contribute to git (the project) because I'm not smart enough, well trained enough, whatever, and that complaints would fall on deaf ears like yours. It's an altogether different culture. Elitist by design, or meritocratic if you will.
And believe or not, I've probably spent more time learning git -- reading documentation, diagramming it out with coworkers, cloning repos and experimenting with commands, etc., following a shit-ton of tutorials -- than any other skill I've ever had to learn. It was quicker to learn Perl and regex than mid-level git.
If you want to pay for the world's would-be engineers to receive all the training to go from mere dev to proper "software engineers", by all means please do. But otherwise, well... you know what? World's gonna keep producing mediocrity. Most of us are just average.
Documenting poor design rather than improving it is lazy, bad engineering. Requiring rote learning of an very complex interface that poorly represents a moderately complex data structure is lazy, bad engineering. Macho, hyperbolic, gatekeeping arguments for non-design as a design philosophy is advocating for bad engineering. Being mad that people want products with interfaces that make sense is being mad that people want an important facet of good engineering.
We are discussing designing the machine in a way that removes these options altogether.
This is objectively and obviously a better strategy because humans are fallible, even when well trained, and the time put into safety training can now be put into an actually productive direction.
You're working from the perspective that machines and git must be dangerous to be effective. This is an assumption that should be challenged before the enormous waste of safety training is accepted.
It is not a different league it is a different sport. If a factory was designed with the equivalent of gits usabilty today, it wouldn't even get a permission to be built based on the plans alone. Also the person who planned it would have a hard time ever doing so again.
If git was a bridge it would have no handrails and it would oscillate in certain winds and for some odd reason there is a roundabout in the middle.
It is still better than no bridge for sure. As one of the first of its kind a lot can be excused, but fundamentally better engineering is possible as well.
The only single-operator machine I can think of which has an interface even 1/10th as complex as git is an automobile. The number of fatal accidents that could be remedied by reading the manual is vanishingly small.
Also, git reset ---hard HEAD^ deletes nothing. The commit HEAD was pointing is not deleted. You have to work really hard to delete that commit accidentally
If you type in "rm -rf ." there will also be no "warning" about what happens next…
I for my part don't like systems that after giving it a command very explicitly asks me whether it should really execute that command. "You just pressed the button to delete those files. Do you really want to delete those files?" "Oh, no sorry. I'm the operator of this system but I press buttons randomly just for fun. Actually I have no clue what I'm doing. Thanks for that pointer! Please ask me also the next time, as I'm not going to remember what this button does. In fact I have no clue at all what I'm doing." Dude…
Git is not a backup tool. (Even you could use it as such).
If you need a backup, make a backup.
I'm aware of the fact this this comment may sound impolite to some. But out of my perspective it's a feature and not a bug that unixy systems traditionally don't ask stupid questions after you told them to do something. It's an attitude of respect towards the operator: The system assumes that the operator knows what he is doing. Asking questions in the style of "do you really, really want me to do what you just said" is on the other hands side just extremely rude against the operator—as the systems assumes the persons in front of the keyboard does not know what he is doing at all! I hate systems with build in "support wheels". The creators of such systems obviously thinks their users are cretins, and that's very annoying.
By the way, have you ever run across a situation where the standardized behaviour of rm without -f (to wit, check the permissions of each non-directory, and, if it's not writable, prompt if stdin is a terminal)?
Well, that's the purpose or "reset --hard". "reset" alone doesn't do that. That's the difference with "rm". With "rm" you expect something to be removed. "rm" may fail because you gave it a directory but you forgot "-r". Or it may fail because you don't have the right to the parent directory or something. But it is pretty much expected that something will be deleted if you run "rm".
From the perspective of people who don't understand the difference between "git reset", "git reset --hard", etc., that some of those will destroy their data but not others, is part of the confusion. And when they picked one instead of the other and lose their modifications, they'll blame git from being confusing to use, not themselves for not doing a backup before running a command in their source directory with a program that is used to manage source directories.
it'd be trivial to modify that behavior to refuse to continue in such a case if you want double seatbelts
also, if the changes were staged they were recorded in the database and remain there
I definitely agree. The UI is terrible. But it is learnable.
I would recommend using a GUI initially so you can learn what the operations are and do without having to figure out that it's not `git remote list` it's `git remote -v`; it's not `git clean` it's `git checkout . && git clean -fdx` and a million other paper cuts.
I think this is part of a downside of rebase-centric workflows, since it encourages making multiple branches with identical changes, but no shared history. At some point I want to read more pros/cons on different workflows. My current thinking is that rebase-only sacrifices far too much on the altar of a clean-but-inaccurate commit history, but I don't yet know enough to say for certain.
https://www.git-scm.com/book/en/v2/Git-Tools-Rerere
If you have a lot of long-lived branches that don't merge and get deleted you have a whole different world of pain from normal git usage, and need some resources designed as SCM experts to manage this stuff. But really short lived branches that deliver net steps forward are the way to live.
I hate branches because it breaks git-bisect. Linux kernel history has lived without it, so I'm guessing the "our code is so complex we need it" is a false idea.
Also, the actual history of what main/master points to is linear. If the bit-post merge are identical, it doesn't matter if they were rebased or not except having 2 ancestors for HEAD is a lie.
Can you explain what you mean by git merge breaking bisect? I've never run into that problem at all. And sure, it might bounce between the branches as you bisect, it still identifies the commit that introduced a bug. The only issue is if one of the commits on the branch fails to compile/test, which is poor commit hygiene, but can be excluded from the bisect.
I still need to do more research, but I think I'd lean toward having a merge workflow, but with no fast-forward commits. That leaves a clean history on main with --first-parent, but still leaves the details available in the branches as needed.
Those guys are still sending commits (patches) to each other by mail, I think they willingly live in such a special and weird bubble that it just can't be compared to any "real life industry project".
We've recently started to enforce linear history on our main branches at work, because it makes analyzing broken builds such a breeze. The mantra is "Insertion is hard, analyzing/understanding is easy" (for a merge-based history, it's pretty much the other way around), and so far it's quite the success.
It did take quite a bit of effort though to get everyone up to speed, and it still requires the occasional help to clean up the commit history of some merge request, but it was well-worth the trouble so far.
You might enjoy using Magit.
I agree with your other criticisms, but IME git's branching-heavy approach makes this one easier to avoid: it's natural and easy to create a separate branch for that bugfix and then merge it everywhere that it's wanted. Or to just merge your colleague's feature branch that has the fix on into your own feature branch, if you know their branch doesn't contain any dangerous changes / will hit master ahead of yours.
(If the diff is actually bit-for-bit identical I think it doesn't conflict? But obviously that doesn't happen so much in practice. git merge -Xignore-all-space can be helpful in some cases).
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.
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. ;-)
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.
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.
Most people don't know how the Internet works and yet it's widely used.
You don't need to understand the inner workings of git. You just need to know some commands and some basic concepts.
Yeah. I've met many developers who have no idea what a cookie even is, people who have never read a single IETF RFC.
`git reflog` shows the commits where your current branch pointer has been.
`git reset --hard` moves your current branch pointer and to the given commit, then modifies your working directory to match that commit. `--soft` moves the branch pointer and does not modify your working directory. `--mixed` moves the branch pointer, does not modify your working directory, but does clear staging.
Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education?
Do you treat a new programming language or framework with the same disdain?
I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A workflow that hamstrings yourself to git stash as a poor man's branch. I get it, I used that as crutch for years, then I spent some time learning git properly.
Most people haven't even watched the one hour talk where Linus talks about the design and building of git.
One hour might sound like a lot to understand why branching is so amazing, and why distributed source control is hard but it's a tool I've used for almost a decade and won't stop using for the next decade. I think it was worth it.
I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.
Maybe git isn't the right tool for you?
I have a set of commands I use multiple times a day, for everything else there are manuals and docs to reference.
Git branch, commit, rebase, merge, clone, check out, pull, push, submodule, remote, and maybe a couple more, are there specific commands you don't use daily? Other than remote and submodule I use all of those almost daily.
Git is highly professionalized. It has layers of modal state. That is built into the operating model. It is made for Linus Torvalds, a professional merger of code. If you are using all of those commands "almost daily", you are a professional code-merger too.
And again, maybe git is the wrong tool for you, that was kind of my point, use cvs or svn it's much closer to what you seem to want.
Some sort of basic version control is definitely important.
> Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education?
Seeking out that training would be useless since I don't use git enough.
> Maybe git isn't the right tool for you?
Git is definitely the tool for me. It's better than any other available tool for my situation.
Why the hell would I branch more? Just to get better at git? Sorry, I'm sorry that I work on a small team! Maybe I should go back to CVS?
Stop gate keeping.
You don't want branching and you still think git is the tool for you? Compared to say svn?
Honestly, use svn, its the better tool for your use case.
You don't have to use git.
Don't gaslight me by saying you don't need gits main feature and then suggest I'm gstekeeping, I'm not, youre welcome to use git, just don't complain about your lack of ability to RTFM.
I use a modified gitflow. The article and this thread are about how when you get into trouble, git quickly becomes complicated. It’s not about branching being too hard or whatever you turned this conversation into in your head.
I have multiple branches on the go in a one-person project. I find that very useful. But if you don't, maybe you should go back to SVN? Using git without merging between branches seems like you're making your life complicated for no gain - like using a distributed system framework to run a single-node system.
The comment I'm replying to said "branch more" as if that would solve some kind of problem with edge case complexity.
FYI, the branchless workflow linked to in the post is really the opposite of this. It encourages making commits even more often than you would in the traditional branching workflow, and discourages using the staging area or stashes when commits would work fine.
This is supposed to be covered in `man git reflog` and `man git reset --hard`. I admit that it could be more readable though. Currently, it's more of a technically-correct introduction than a layman's. I guess it's really more of a documentation for experts. Some have made fun of this: https://git-man-page-generator.lokaltog.net/
In layman's terms, `git reflog` is the history of the positions you were at: you'll see every commit you've visited recently, so as long as something was committed, you won't lose it. It's here in case you lose some commit identifier (for instance you finished rebasing but are not happy with the result: the branch now points to the sad commit. Grab the reflog, copy the commit identifier and reset the branch to point it to where it was before).
And `git reset --hard`... `git reset` changes the branch "tip" (pointer) to another commit: the commit tree always exists. Branches are "named commits". `git reset` moves these tags around. The `--hard` part "just" replaces the entire content of your working directory (including non-committed changes) to the commit you give as a parameter. With no parameters, it just resets to the latest commit in that branch, so it's like saying "clean my working directory back to what was committed, discard my changes". Perfect for losing work.
I agree that git "porcelain" commands are sometimes ill-named and a bit counter-intuitive to grasp. For me, learning git paid of (sort of: I don't spend time fighting my issues, I spend it helping others fix theirs).
I'm keeping an eye on better-designed alternatives like pijul. mercurial is interesting and has better-named command, but I sunk some time learning git already, and know it better, so hg has very little more to offer to me.
I wonder if it is possible for someone to write a meta-CLI that works on top of git like “git for humans”. While, still leaving the power for expert users
[1]: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/us...
It is a tool. One should not need to understand the inner workings of a tool to use it. How many APIs do we use where knowing how it does what it does is required? Whether it's Stripe or Node or Bundler or ..., the user does not have to know what happens inside. The need for incantations makes some people feel powerful or exclusive. I just want my tools to do their job so I can focus on doing mine.
FYI: `git reflog` saves your ass when you accidentally delete a branch locally, only to then realize there were valuable commits yet to be pushed to master! How it does it is another matter.
Systems enabling high usefulness with little education (i.e. shallow learning curve, at least initially) and then incremental education are ideal. This isn't essential, just desirable. Git can err a little on the steep learning curve/mystery black box side of things a bit. But it is still a damn fine tool.
You just don't need to learn unless you really require it. And even if you do learn you will eventually forget if you don't use all the features.
Its not hard to see why people don't even bother.
If you have ever done a "git reset" (which implies --soft), then you should know what "hard" in this case means. I am not sure, I knew that it would most likely get rid of my uncommitted changes. I "git stash", then "git stash pop".
Do not run anything without knowing what it does, you should consult the manual page: "man git reset". Search for "--hard", and you get:
--hard
Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.
Slightly off-topic, but I love working with meld! If I do a "git rebase --onto [...]" I do not get "meld" open automatically, you gotta type "git mergetool" to resolve conflicts.
Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certainly one of the problems). Git is an incredibly user-hostile experience, and someone needs to fix or replace it. Can we just say it out loud and stop pretending that the problem is the literally thousands of users who have problems using it?
Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either.
In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.
If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows?
> 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.
SVN isn't distributed; it mostly tried to replace CVS, which it managed to do very successfully.
As for DVCS, the fact that system X became more popular than system Y doesn't mean that every aspect of X is better than Y. Many would say git succeeded despite its awful interface. As far as I can tell, the main feature of git was its speed; that made it usable for huge projects like Linux and Xorg, and this endorsement from high-profile projects gave git the edge for DVCS hosting sites like Gitorious. Then GitHub came along, and grew into such a behemoth that git became the de facto standard.
See also: WorseIsBetter
Because maybe mercurial's real problems wouldn't show up until people started using it at scale.
This is a classic problem that happens time and again.
Windows vs. Mac back in 2005:
"Windows having malware is a human problem"
"If it were a human problem, how could alternatives like Mac get consistent amounts of praise for their lack of malware?"
Turns out it's just because Mac didn't have a big enough market share. As soon as it did, Apple could no longer claim that Macs can't get malware because they can and do.
Similarly, if you scaled up the number of Mercurial users by several orders of magnitude so that it was now "mainstream", I'm sure some of its lesser known pain points and/or counter intuitive behaviors would start floating up to the top 10 HN stories. But since hardly anyone uses Mercurial vs. Git, that doesn't happen. Just because a minority of users praise something (<insert lesser known language>, <insert lesser known DB>, <insert lesser known VCS>, etc.) doesn't mean if you scaled up the userbase one or more magnitudes it would continue getting that level of praise from all users.
I actually tried both git and mercurial almost a decade ago having had only experience with subversion, and found git to be much easier to understand and use. I don't recall what those pain points were, and am sure I couldn't describe them correctly if I did remember, but because of that I do expect such things to start popping up if more people used it.
Typically Git was a bit faster for most operations on Linux. Mercurial was a bit faster for other operations. Especially on Windows. And both were much faster than the rest.
Bitbucket and GitHub started around the same time. GitHub just executed better.
That doesn't mean that Git couldn't have a much better UI for this problem than it does. And while I agree that Git seems to have mostly won over SVN and Hg, it doesn't follow that it's because of its UI. (For example, I think that a lot of Git's success actually comes from the UI of GitHub, not Git itself, but I don't have evidence to back it up.)
Take a look at the Research section at the bottom of https://gitless.com/ for work that's been done on how to accomplish the same operations with a simpler conceptual model.
Well, actually, a lot of people work in large repos, so this can be a pain.
Which of course brings up another failing of the git UI: the difficulty of removing old history from the repo. Last I checked, you pretty much have to use a 3rd party tool for this.
It helps a lot to set:
git config --global merge.conflictstyle diff3
then you can see the before as well as the 2 changes you are trying to resolve.
git mergetool
git checkout --ours/theirs && git add .`git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you use `git checkout -b new-branch-name`. Yes, a third separate use for git checkout.
Why not (e.g.) `git branch -c new-branch-name` with a config option to make `-c` the default if you want it?
If you rebase and push, it tells you to do a `git pull` to "fix" it, when in every workflow I've ever done, you want to add a `-f` and push away, just be aware that you are intentionally overwriting the remote branch.
git checkout -b test
git push
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 push, and I got the same error message.
git push origin HEAD
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!
You can fix this by doing `git config --global push.default current`.
I do agree with the second example. Pulling and merging with remote after a rebase makes a terrible mess!
It sounds like you are unaware of
git switch branch
git switch -c new-branch git switch --create new-branchHeh, and I'll do you one better: it's unstaged changes, so it won't put the file back to the HEAD version 100% of the time >:-)
But git saved me an immeasurable amount of hours in return. I was asked what I worked on some specific week back in may -- git saved me. I had to look up what performance my program had before a specific change -- git saved me. I had to try stuff out without messing up my codebase -- git saved me.
True, I invested quite a few hours and I still do, but I think the investment pays itself off. I'll never ever do a project without git.
Why is this tone deaf? It’s a development tool for programmers and the internal structure is conceptionally pretty straightforward. Understanding your tools is pretty much prerequisite. You don’t have to have written a compiler to use one, but you do have to have a model of what it does. Git is no different.
* in your opinion.
Mercurial has no staging area, and that can be inconvenient for some scenarios; but I think no-staging model is easier to grasp for beginners. I especially think many beginners would assume that modifying a file after it's been added to staging area would update staging area automatically too.
Mercurial has high-level, scenario-oriented distinct "undo" commands like "revert", "forget" and "backout" instead of overloading a single command ("reset") for everything.
I still like `git reflog` though.
The key thing seems to be the immutable repo editing is hidden by default, but viewable with --hidden flag if you need it.
On top of this, various git commands can delete things you've done in the working directory without any confirmation or warning (e.g. "git checkout [filename]"). And of course, so can various non-git commands (e.g. "rm [filename]"). If that happens, the work is permanently lost if there isn't another backup mechanism in place.
So they're not wrong, but the second sentence's implications are kind of glossed over. It's always confused me that git lets you lose work so easily, so a very long time ago I've always just made sure to put all of my programming projects in a Dropbox folder. I rarely mess anything up that badly with git, but for the few times I have, Dropbox version history has definitely saved me.
# Commit all changes and push to at least one remote so your changes are ""immutable""
rm -rf myrepo/
mkdir example && cd example
git init
# Repeat for each remote
git remote add remote1 https://origin.for/your/repo
git push remote1 --mirror --force
Which means git is failing to do its whole job: keep the history of my work safe. I'd argue that git actually makes data on your filesystem less safe, because it pointlessly write-protects files in the .git directory, which encourages a bad habit of using rm -rf.
It's useful even if I just refactor some code and change part of the refactor and then change my mind and want to go back to what I was initially trying. And it also helps if my hard drive dies or my laptop gets stolen, etc.
- Use a recent version of git. The error messages have improved a lot, have been localized (unless you do `LANG=C git …` to be able to search it on internet), the UI has improved, `git status` is more helpfull, …
- Create an alias for `git log --graph --decorate --oneline --all` or something fancier with `--format`. `--graph` should help you a lot to visualise stuff. - Don't use `git reflog` but `git log --graph --reflog`, it's much easier to visualize.
- Never use `git checkout`, but `git switch` and "git restore` that were introduced in git 2.15 IIRC. They are much less confusing and error prone.
- `--patches` (`-p` for short) can be used with `add`, `restore`, `reset`, `log`. It helps a lot with commit hygiene.
- Most complex rebase are easier to do with `--interactive` (`-i`).
- Activate `rerere` in your git config (it will reduce conflict merges during rebases).
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 the staging area.
I think to effectively use it you need to work with your brain squarely in that lower layer. Trying to think in terms of sequences of commands rather than a tree of commits and references is hopeless.
The fact that the UX concepts (commands, working copy, reflog staging area, …) and the underlying model (graph) are difficult to reconcile is git’s biggest weakness.
The difficulty with which is models some of the most common use cases (centralized, often including a few large binary files) is another.
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 games from a conflicts perspective, but I think it'd be worth it for any use case that involves long term maintenance of different releases of the same piece of software.)
A new repository starts with an empty branch.
A DAG gets layered on top.
I mentioned conflicts, but can you explain where race conditions would arise?
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?)
Why is this?
At least from my naive point of view I would expect these extremely user-hostile products to have been overtaken but more user-friendly alternatives. I know the best products don't always win, but when they don't there's often at least some theory about what is going on (network effects, business partnership, government regulation, etc.) that I don't have with these two products.
Fossil and Darcs sure look nice, but having to self-host my repositories or use a smaller company that could go under at any minute? Having to use barely-maintained plugins for my editor, CI, CD, etc.? And most importantly, having to explain a completely new set of tools to anyone who wants to work on my projects? In my opinion, it just isn't worth it.
Granted, I almost never use the Git command line and always favor a 3rd party GUI. For users who are a tad confused I think this is the right approach. And to me that's what makes Git a winner: the core software is powerful enough to do everything that needs to be done, and you can pick whatever UI you're comfortable with. No one is forcing you to use Git's built-in UI.
That said I think even the high-level Git concepts have naming that confuses new users. "Pull request" annoyed me for a long time. Yes I technically understood why they chose that term, but practically speaking it just seemed pointlessly misleading.
Now a couple of decades later, I just use Word or Pages.
- It's fast, which we all love. - It mostly does painless merges, again we love. - It's not actually that hard to 'get going' - and I think that a lot of people are totally overconfident in their skills. - It's free - It's open source - Linus Torvalds created the critical mass for Linux - GitHub - Lack of truly efficient alternatives - It technically 'works' i.e. does what it's supposed to do, relatively robustly. - It's designed for open source, which is a novel concept.
Personally, I'm scared of git from an organizational perspective, and I do not feel that we have reconciled the reality of how much pain it can cause to people, newer teams, the less familiar etc..
If people would pay for software I wonder if a great alternative could come to the fore because without it, we have to rely on volunteers and that's an ugly industry problem.
In my experience most beginners use a GUI like Atlassian Sourcetree or the Github desktop client. It's a lot harder to make mistakes using the GUI in my experience.
I still really like this idea though; eventually a subset of the beginners wants to learn the git cli and that sure seems scary at first.
I would like to see a GUI adopt these concepts. There's no reason why we should limit the commit graph display to only the current time, when we have enough information to scroll through its past states as well.
It's not as easy to use as SourceTree, but since there's no SourceTree for Linux, it works well enough.
A year later I had probably learned how to force push correctly and took hold of it again.
However I do think the GUI is great for git and that’s why I use GitHub Desktop. It’s super simple. Most other GUIs try to wrap git concepts too closely for comfort.
I think it would be possible to solve these with git, by doing something like automatically running a `git stash --include-untracked` before an operation that can clobber untracked files.
JetBrains IDEs also have the best UI I've come across for conflict merges.
When I help people get started with git, I tell them several times to commit as often as they can. If they committed it, I can probably save them when they think they lost something.
`git add -p`: prompt which hunks should be added to staging
`git checkout -p`: prompt which unstaged hunks should be thrown away
`git checkout HEAD^ -p`: prompt which hunks from HEAD should be discarded
`git reset -p`: prompt which currently-staged hunks should be unstaged
`git reset HEAD^ -p`: prompt which hunks from the HEAD commit should be unstaged
Nice thing is that you get interactive yes/no prompts with a preview of the change for each hunk, and you can also quit early if you realize it's not the command you want.
Doesn't fully address the potential for lost changes, but slows it down by adding an interactive roadblock for each change.
1. a large piece of something, especially food, cut or broken off a larger piece.
I am the CTO of Tower, a Git client for Mac and Windows.
Mine is as simple as:
- git pull -r (to pull & automatically rebase commits from the common branch)
- git checkout -b (to create my own feature/debug branch from the common branch)
- git add -A/commit -m/push (to add, commit and push… I usually let my IDE handle that part)
- git rebase (to rebase commits from the common branch)
- git reset (to squash all the "WIP" and "fix" commits on my feature/debug branch. I then do 1 or 2 clean commits and push -f)
- finally I do a merge request, or directly git cherry-pick the commits to the original branch if nobody else works on the project
I've been doing this for years and it just works.
- The interactive interface of `git undo` is probably too hard for beginners. Designing simple interfaces is hard, and you can't pplease everyone.
- It seems `git undo` simply does a `git reset--hard` toward a designed commit. The user probably expected to return to the state before the last git action. Instead `git undo` reverted the amend, but also reset the index and remove the local changes. At this point, the beginner could scream "Undo lost my changes! I just wanted a second commit instead of an amend."
Undoing could mean `git reset --hard {hash}`, but in many cases `--hard` would have unwanted effect and the default `--mixed` would be more suitable. But even in this case, it's not a full undo, since the index is not preserved: you don't end up in the same state as before the `commit --amend`.
It runs a `git checkout`, not a `git reset --hard`, so it will stop you if there are incompatible changes. Of course, if `git undo` can be made to lose your staged or unstaged work, then that's a bug.
Fortunately, you can undo the result of any `git undo` with another `git undo` that goes one more step back in time.
* the working copy
* the graph
And it gets better, if any file gets disconnected from the graph, it can be hard to locate. (Yes I know, it can be found in the reflog)
https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
The original idea was "current directory cache" and that still pops up in the syntax.
I always run "git diff --cached" as a last sanity check before a commit.
Empty directories do not contain files or information, it's entirely reasonable for a VCS to omit such a feature. Not sure which use case for git is hindered by the inability to check-in empty directories. I would even suggest such a use-case may be a case of DIW
For instance, it is nice to think about the repo holistically sometimes before I have say an actual unit test to put in the directory, it is nice to create that structure in the repo.
We could easily get into arguments over the specific uses of committing empty directories against the difference it ends up making in terms of stability and extensibility. Instead, consider that: 1) this behavior is very surprising, and 2) it offers no advantages to users, only disadvantages to some. Hence, it is unergonomic. My complaint was precisely that for extremely popular tools (such as git), it is worthwhile in general to sacrifice ease of implementation for ease of use, because the developper effort is amortized over the number of users.
But it's not really surprising that one can't commit empty directories, one can't commit directories at all. Git is a tool for version controlling the lines and bytes of source code under version control. It's a deliberate decision to focus solely on that.
Consider that what is one person's ease of use can be another's pain in the ass. I'm thankful that git has not chosen the path of trying to cater to everyone and their esoteric use cases. I've used other tools that do and it ends up creating a mess instead. Instead it does one thing and it does it well.
I think that if you dig you'll find that if there's something git doesn't do or doesn't do well, that's because a lot of smart people have already looked at that problem and come to the conclusion you shouldn't do things that way.
Tower for Mac supports Undo (and also Redo) for very much all Git operations starting with version 3 two years ago. This includes undoing all working tree actions like staging/unstaging/discarding individual chunks or complete files. Just hit CMD-Z.
This feature is coming to our Windows version soon as well.
If you're interested in technical details, you can read it here: https://www.git-tower.com/blog/how-we-built-undo/
The demo for Undo at https://www.git-tower.com/features/productive/Mac seems to be the wrong demo? It's showing a few lines being discarded, and no undo at all. (And the dialog says that discarding the lines can't be undone...)
From what I understand, some of them were more feasible to develop because they implemented their own plumbing (GitUpKit), instead of relying on the official git plumbing.
Nevertheless my main daily driver, along w/ the command line. It's undo capabilities, best-in-class visualization of the timeline, and ability to easily visually edit, reworder, and squash commits remain amazing.
(I was disappointed to see newer git clients like Submlime Merge did not take inspiration from GitUp.)
Ultimately I think the future of VC will be something patch-based (pijul?) w/ a UI along the lines of GitUp.
But yes, I wasn't really worth actively maintaining it as it was feature complete and I didn't intend to build a business out of it.
100% vs 80% is of course going to be subjective, but the missing 20% in my opinion is built-in merging and a built-in repo browser. When I've tried to advocate GitUp to my coworkers, those are the two things that keep them going back to SourceTree or Fork.
(Also, on our (admittedly, pretty large) repos, it's not quite rock-solid; staging can be unusably slow (requiring fallback to the command line), switching to the commit view from the map view can be slow, and making lots of changes to the working tree will crash GitUp.)
Still, a brilliant piece of software, and I am suprised that (1) it didn't find a larger audience and (2) that it wasn't more influential on clients that came after, like Sublime Merge.
Unlimited undo / redo is achieved by taking a snapshot of the entire repo before and after any operation (e.g. checking out the repo or creating a branch etc...). The inspiration I had at the time was that is it is trivially cheap to take such snapshots: essentially all you need is a list of all the refs.
Then when you need to undo, you have 3 things: 1 - current state of all the refs in the repo 2 - state of all the refs from the before snapshot 3 - state of all the refs from the after snapshot Compute the delta between 3 -> 2 and apply on top of 1.
The same technique allows to do the Time Machine feature.
But I'm not on Mac, does anyone know of a tool that has a similar design idea behind it that works on Windows or Linux?
I'm a very visual person so I tend to use Git Graph on VSCode. But I still get in trouble. Especially things like Cherry Picking, or reverting.
Another thing that is not so easy is switching branches without having to do a commit. Stashing, yeah, but then figuring out whether stashes have been applied or not, diffing between branches, picking some changes from a diff.
In the end I stick to some basic commands that don't get me in trouble so that I don't lose half a day to recover my work via Dropbox.
is `git reflog` not enough for your use case ?
Edit to add: the downside is that it only works in the current terminal session. To workaround that for myself, I have a fish shell post exec function that records the last command run, plus a bunch of metadata, to a log file.
You can also try `lazygit` it's a TUI written in Go
# fshow - git commit browser
fshow() {
git log --graph --color=always HEAD \
--format="%C(auto)%h%d %s %C(blue)(%aN) %C(black)%C(bold)%cr" "$@" |
fzf --ansi --no-sort --reverse --tiebreak=index --bind=ctrl-s:toggle-sort \
--bind "j:down,k:up,q:abort,ctrl-m:execute:
(grep -o '[a-f0-9]\{7\}' | head -1 |
xargs -I % sh -c 'git show --color=always % | less -R') << 'FZF-EOF'
{}
FZF-EOF"
}If I use github desktop I can roll back a commit whenever I like with a simple menu command.
What am I missing here. I feel like I don't understand what the tool is doing.
Short answer, recreating this tool's features in vanilla git requires using the reflog, which isn't user-friendly:
> Why not git reflog?
> git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository.
None of them works. At some point you will be told to fix the problem by hand.
The tools that do work are ones that add a simple extra function (git absorb is really cool, for example), or GUIs that help you visualise the repository and give you buttons that have the same names as the command lines that they replicate. Tools that try to make things "easier" are just confusing for people who know git, and prevent you ever learning git for real. When I first tried it, github desktop was firmly in this category.
We need to get git itself to adopt some changes - git switch is a good start, replacing checkout's branch switching features. I think that every time I do git checkout branch I should get a reminder to use git switch instead.
Agreed. When I was learning to climb the instructor told me I would never reach my full potential until after the first fall. You cannot work at your limit until you trust the rope.
However, I think this is still avoiding the rope. Git is really simple and when you understand it it's hard to go wrong. I really think what git is missing is a better user interface. Magit is the only one I'm aware of.
The hard part is understanding how to get a reference to the thing you want to get back, how to restore it to its proper place in the history, or at least to a reasonable place, and how, if it's been pushed to a shared repo, for other developers to get their local clone properly sync'd up without their local work getting shoved off into some hard-to-reach reference.
I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.
It doesn't have too many features, but the main thing it aims for - a better repo browser, it does really well in my opinion.
But nobody's going to solve the major problems of Git any time soon, because you can eventually get Git to work. This is a persistent problem I see all over the tech landscape. We live with crappy solutions because trying to make a better one is way more work than just dealing with the bad one. Progress isn't impossible, it's just tedious.
Still, the UX sugar of undo sounds quite nice. I only worry about introducing something heavyweight into the thing. If I use branchless will it force others to use branchless too?
My company has an equivalent to 'git undo' that basically undoes anything you just did to your local repo.
It's just so freeing. Sometimes you need that Ctrl+Z so you can undo and redo things correctly. It gets your mind back to whatever you were doing before without needing to debug wtf just happened.
> How is it so easy to “lose” your data in a system that’s supposed to never lose your data?
I think the author is mistaken; git isn't "a system that’s supposed to never lose your data". One of its features is the ability to "lose" data in a controlled way; i.e., to rewrite history. If you want a version control that is supposed to never lose data, use Fossil.
It’s extremely difficult to lose anything in Git once it’s been committed. You’d have to do something pathological or intentional.
1. Has three competing ways available to complete the 'undo'
2. Every way has a scary caveat that the user must be aware of
It would be awesome to simplify the process for new users.
The undo described here is much more powerful and much closer to what people expect from the word "undo" from its functionality in other tools.
Or how about after pushing to a remote?
Push: sadly, no.
Not that I would include this in my own shell. To the authors two example uses: 1) Undoing an amended commit. But if you're comfortable amending a commit, can't you just amend your amended commit? 2) Accidentally commiting an incorrectly resolved merge conflict. Revert the change if you want to be non-destructive. Reset HEAD~1 otherwise.
2. Yeah, but I think the UX improvement of a single command to say “Go back to where I was” is reasonable.
I haven't tried it, but have been meaning to look into it. Would be curious to hear experiences of anyone who's tried it, and how it compares to the OP.
`git reflog` `git reset --hard <SHA of commit you want >`
Or if you just want to move back 1 commit
`git reset HEAD@{1}`
Once I did that, everything else is just regular git commands. Check out a "commit." Revert to a "commit."
I always forget how to set up networking, because I don't do it often enough.
As a general rule of thumb, command line tools often ignore decades of UX best practice that have grown up. One of those is that operations (particularly destructive ones) should be easily reversible. It recognizes that human error is common.
And having "undo" specifically recognizes that human error puts the user in an emotional state where restoring things via complex operations is inviting risk. A typo to `git undo` is unlikely to be another command. A typo in the SHA (or an @{2} instead of an @{1}) for `git reset` will compound the error.
... that having been said, I'm going to go add `git undo` as an alias for `git reset HEAD@{1}` right now.
When recovering from a bad merge conflict, you have a bunch of commits in your reflog which have the same name, and you need to decide which one you want. It's hard to look at the exact diff data and decide which one is appropriate.
It's not listed in the article, but it also enables a workflow where you check out parent commits many times along your branch of development and start new offshoots, and possibly amend commits with many descendants. It becomes nigh impossible to manage the reflog when there are so many commits with the same message but different content. The reflog itself also doesn't make it easy to recover lost descendant commits, only the given root commit.
Other scenarios: the reflog will not help recover where a deleted branch pointed to, and it won't help update multiple branches that pointed to the different positions in the same rebased stack of commits (the reflog for HEAD, anyways).
Not that I'd trade git for subversion mind you, in the hands of a trained individual git is a godsend, but the training part can be arduous.
Even among DVCSs I'd argue that mercurial for instance is vastly easier to pick up.
If it's a matter of understanding the flow of the tool, then I will have to concede that mercurial probably is easier to understand for the beginner.
Wait, how do I remove it from staging? It seems there should be some symmetric operation, `git remove <file>` or something. Maybe git rm `<file>`, whoa don't do that.
No, it is `git reset HEAD -- <file>`. There is no mental symmetry.
Or why use add at all? What am I adding it to? It is so generic, why not `git stage file` and `git unstage file`?
I agree that you need to read and learn tools, but there is a lack of consistency and symmetry in many of the commands which make it harder.
(use "git restore --staged <file>..." to unstage)Also, it looks like "restore" was not added until august 2019. And I have not used it, but will in the future!
But this does not exactly help the conceptual issues, because now we have `git revert`, `git reset`, and `git restore`.
From an english concept perspective those words are all very similar in meaning.
Breaks down in uproarious laughter.
One of the worst offenses git is its use of multiple different jargon terms for the same concept; indeed, it's the only VCS I've used where reading help leaves me less sure than when I started if it does what I want it to do.
If I accidentally leave my system in a weird state (say, I'm in the middle of a git rebase and I forgot to git rebase --continue), and I start doing some regular git commits, the resulting mistakes are, while possible to recover from, difficult to do so unless you know git's internals. I have to use the "what's that git command to list the commits I just dropped on the floor by accident?" with surprising frequency.
Perhaps you have a different workflow than me, but I don't find myself rebasing all that often to begin with. I generally don't rewrite history unless I truly fucked up. And since I'm in "I fucked up" mode, I take extra care with commands I type.
I don't wanna be like Apple and say "You're holding the phone wrong," but maybe you shouldn't be doing frivolous rebasing.
https://github.com/git/git/blob/master/contrib/completion/gi...
You mean Mercurial :)
Here's something that happens when people are encouraged to make more mistakes: they make more mistakes.
The piece where people are encouraged to learn from these mistakes is missing from the author's equation. Without that, this tool becomes a crutch at best, and a disaster waiting to happen at worst.
Can we do better?
*Edit*: Let me answer my own question. We can do better - for example - simply by adding the Git commands this program would run, aside from the human readable explanation. Not sure what people replying to this comment were aiming for, since they clearly did not offer up a single suggestion.
Let me go a bit further and add that self-righteous soapboxes are NOT a good thing, and as it stands none of the replies to this comment were relevant. I was hoping to spark a discussion of what else could be done to improve the experience, but I could have worded my comment better.
On the other hand, you can do better.
Trying to learn from mistakes that can be solved by an undo on local repository are mostly in the realm of "be more careful", which is an impossible requirement to achieve in general.
An analogy in my mind is a "hardcore"(where your in-game character permanently dies if you die once) mode in a game. On the surface, even it's name suggests that a really die hard power gamer is going to want to try this mode, the phrase beckons truly a true epic gamer experience that will test the players skill to the utmost. But, you don't get that. You get people getting level 2 by killing only level 1 critters for 10 hours straight (or equivalent), you get a boring, sterile, slow progressing gameplay that is exactly opposite of what one might imagine going into it.
Well, yes and no.
Try combining it with a speedrun. You'll find you have to take calculated risks, and this can indeed add another level to the game.
I wasn't meaning to be dismissive of those that enjoy or make use of these types of game modes, but really just invoking how hardcore mode ends up on average with the average user for analogy only.
Or for an entirely different example, are you also opposed to FPGAs? Should people be forced to not simulate circuits before sending them off to be fabricated, in the hopes that by making the mistake more painful they won't make as many?
Besides its not like people need more examples in their lives of situations where a mistake is not easily recoverable from.
So to answer your question; I certainly can't, I am a mistake based learner. If you can do better then please, please, do.
The underlying assumption here is that undo features make people bad at thinking. I suspect that might be true in a lot of cases, but I think we should give users the benefit of the doubt and start by believing that they're undoing something that they tried to reason about and made a mistake with rather than thinking they're just whacking in random commands hoping to hit the right one. The outcome might be the same but one is a little more kind.
However, a reasonable counter argument to that whole idea is that without an escape hatch giving users a sense of safety they'll never even try to use any features that they perceive as 'dangerous'. Not having the ability to roll back something they've tried means they won't try, and that keeps most git users from becoming experts. An undo feature is an immensely useful learning tool (so long as it always works as expected), which is exactly what you want if you think that people should be encouraged to learn.