Live data from Hacker News

Git undo: We can do better

blog.waleedkhan.name

351–360 of 490 posts

Re: Git undo: We can do better

#351

I feel like an outcast after reading all the comments here. I've never really had issues using git. I didn't realize so many people had trouble with it.

That's what I was thinking. I barely understand how git works but I've never had issues neither. Could be because people don't have a good workflow.

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.

Re: Git undo: We can do better

#352
Git is just a horrible user interface, period. Linus named it "git" because it's clearly kind of stupid. But it works for many people. Other version control systems are much better for beginners (especially centralized ones). But mainly they are easier because they're designed to be user friendly.

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.

Re: Git undo: We can do better

#353
post #130

Earlier quoted context omitted.

I don't know what to tell you, commit more code? Branch more? Work in teams? 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…

That's nice, but most of us here are version control consumers, not version control professionals. We need something that has very few knobs to turn because our job is focused around delivering value through other tasks. 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 comma…

This is such a strange attitude to source control as a developer. It's literally the most important tool a developer will use second only to an editor.

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.

Re: Git undo: We can do better

#354
post #310

Earlier quoted context omitted.

use git stash instead to unstage changes not committed to the index and you'll never lose anything ever again

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a small mistake. 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.

Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse.

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.

Re: Git undo: We can do better

#355
post #130

Earlier quoted context omitted.

I don't know what to tell you, commit more code? Branch more? Work in teams? 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 was replying to this part of your comment: > 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 f…

This is just retarded.

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.

Re: Git undo: We can do better

#356
post #120

Earlier quoted context omitted.

I come across this attitude a lot. 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…

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

The problem with this is that eventually you need to branch, in that case, stash works well. But eventually you learn that branching is better and easier than stash almost 99 times out of 100.

Re: Git undo: We can do better

#357
post #324
post #116

Earlier quoted context omitted.

Git init inits a git repo. 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.

The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master. Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

So use svn?

Re: Git undo: We can do better

#359

Earlier quoted context omitted.

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. 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 hap…

> It's a human problem 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 mos…

Mercurial scaled better actually. It's 1 of the reasons Sun, Mozilla, and Facebook used it instead of Git.

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.

Re: Git undo: We can do better

#360
Git is hard to use mostly due to "clean commit history" cargo culting. The commands that cause the most trouble are the command that re-write history, and there really is never a good reason to use them beyond "I want my commit history to look like a line".
Post reply on HN