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.

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.

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.

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.

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.

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.

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)?

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

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.

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.

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.

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

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

You might enjoy using Magit.

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.