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

Git undo: We can do better

blog.waleedkhan.name

Post reply on HN
Print view View original

231–240 of 490 posts

Re: Git undo: We can do better

#231

Post by nicoburns »

stormbrew wrote: post #169
fierro wrote: post #146

Earlier quoted context omitted.

can you explain the `git pull origin master` thing one more time here?

like why it's different? `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 tha…

I tend to default to `git pull --rebase`.

Re: Git undo: We can do better

#232

Post by cerved »

woah wrote: post #190
pizza234 wrote: post #37

Earlier quoted context omitted.

Are you using Git via GUI(s)? 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.

Sorry, I'm trying to get work done, not memorize an obscure set of incantations like some kind of D&D wizard. If the repo gets messed up, I delete it and reclone.

It's a handful of commands, very well documented with tons of SO questions that is one search away if you can figure it out yourself.

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

Re: Git undo: We can do better

#233

Post by lanstin »

zibzab wrote: post #50
sebmellen wrote: post #28

Earlier quoted context omitted.

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know

This also shows that quality of the technology matters. Like the discussion on the business value of Amazon's "use APIs always," using git is using a superior source code technology, designed from the ground up for distributed development by a master of distributed development; good things are enabled automatically. Linus' naming and UX choices and inconsistencies aside, the tool is awesome. That's why it wins in distributed development environments - the bazaar not the cathedral and not the bespoke engineering team hidden away in the corporation.

Re: Git undo: We can do better

#234

Post by lanstin »

matheusmoreira wrote: post #182
grogenaut wrote: post #58

Earlier quoted context omitted.

Personally I think it just needs a 3.0 where they completely rename all the commands so that they're really unified. I know there was pushback on this in the past

That would be nice but will probably never happen due to backwards compatibility. Breaking changes in git would be even worse than the slow switch to Python 3.

Just call the consistent one "ggit" and the inconsistent one "git."

Re: Git undo: We can do better

#235

Post by RvdV »

rjmunro wrote: post #201
thewebcount wrote: post #128

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI? 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 certa…

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `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 u…

New commands 'git switch' (git switch -c for new branch) and ' git restore' address exactly that issue and are available on newer git versions, so it's being worked on!

I do agree with the second example. Pulling and merging with remote after a rebase makes a terrible mess!

Re: Git undo: We can do better

#236

Post by lanstin »

carlosf wrote: post #41
SkyPuncher wrote: post #30

Earlier quoted context omitted.

> The truth is, while we use git every day, most people really don't understand how it works. 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.

Yeah that's my issue as well. I generally forget anything I don't use often and git is full of important stuff that you need infrequently.

It's very simple, it's a graph, and you can reason what changes you want to make to the graph, and then google for the commands. Re-writing history is really only reserved for binary checkins, and that task should be assigned to whomever checked them in, so you should never need to do a destructive change. Even credentials checked in should be rotated so they aren't valid, not re-written.

Re: Git undo: We can do better

#237

Post by skeeter2020 »

handrous wrote: post #32
eric4smith wrote: post #12

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? 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 implica…

I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…

YES! you learn the happy-path commands you use all the time and the handful of "sadder-path" approaches you try when things go south, but there is a dramatic fall-off in knowledge and understanding from there that leaves otherwise clever and confident people feeling stupid and frustrated. This is not a silver-bullet for productivity but still a very worthy problem to address that could have meaningful impact for a lot of people.

Re: Git undo: We can do better

#238

Post by cerved »

sebmellen wrote: post #28
eric4smith wrote: post #12

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? 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 implica…

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

The UX philosophy is radically different. One presupposes that you understand a lot more of the underlying system. The other tries to focus on what it is what you want to do, as opposed to how.

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.

Re: Git undo: We can do better

#239

Post by [deleted] »

oblio wrote: post #88
an_opabinia wrote: post #75

Earlier quoted context omitted.

Not a single person I’ve met using git in the last decade has thrived using a UI for it.

That's a failing of Git. TortoiseSVN brought source control to millions of people. A good tool should be fully embeddable in a UI, 15 years after its launch.

[deleted]

Re: Git undo: We can do better

#240

Post by stevenhuang »

dec0dedab0de wrote: post #45
pizza234 wrote: post #37

Earlier quoted context omitted.

Are you using Git via GUI(s)? 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.

I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. 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.

What's wrong with 'git diff'?

Then there's 'git add -i' to easily choose which files to add

Post reply on HN