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

471–480 of 490 posts

Re: Git undo: We can do better

#471

Post by saiojd »

cerved wrote: post #409
saiojd wrote: post #363

Earlier quoted context omitted.

I'm going to be charitable in interpreting your answer, but, if I'm being honest, I find your tone very dismissive... (I would even say, reminiscent of StackOverflow, and not in a good way.) 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 surprisi…

I apologize, that wasn't my intention. 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 pa…

Oh, I definitely understand the mindset behind the decision, I just feel it's worthwhile to relax that kind of razor-sharp focus when millions of people are using your tool. Since you seem knowledgable about git, would you mind telling me how complicated implemented directories would be? (out of sheer curiosity, it's not like I care all that much about directories in git lol)

Re: Git undo: We can do better

#472

Post by cerved »

jcranmer wrote: post #54
zach_garwood wrote: post #19

This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?

> git is already the easiest to understand of any VCS that I've used 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 rebas…

This is the script that shows the current branch and things like an active REBASE in PS1

https://github.com/git/git/blob/master/contrib/completion/gi...

Re: Git undo: We can do better

#473

Post by foxyv »

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've noticed this. Every time I try to explain to people about hash maps, GIT blobs and commit trees their eyes glaze over. If you are ever curious though the documentation is kinda cool.

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Re: Git undo: We can do better

#474

Post by hbogert »

weaksauce wrote: post #365
ethbr0 wrote: post #199

Earlier quoted context omitted.

> levels of state 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 a…

i can't stress just how great magit is. it's worth trying out emacs for just that. something like spacemacs as a wrapper is useful too since it gives you some well configured defaults for file operations. emacs is a kinda trash text editor but an amazing text utility toolkit that enabled magit.

I'll stress with you. Even if you hate Emacs, magit alone is a valid single use-case to start up emacs.

Re: Git undo: We can do better

#475

Post by rileymat2 »

cerved wrote: post #423
rileymat2 wrote: post #133

Earlier quoted context omitted.

`git add ` Wait, how do I remove it from staging? It seems there should be some symmetric operation, `git remove ` or something. Maybe git rm ` `, whoa don't do that. No, it is `git reset HEAD -- `. 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 consiste…

It may not be the most mnemonic but it clearly says right in the CLI what you're supposed to do (use "git restore --staged ..." to unstage)

It looks like I get that message when I do a git status, not the git add.

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.

Re: Git undo: We can do better

#476

Post by chefandy »

atoav wrote: post #394
still_grokking wrote: post #354

Earlier quoted context omitted.

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

As someone who just learned a thousand electrical norms let me assure you of one thing: the way git handles "dangerous actions" that might delete things is NOT something you would find an equivalent for in the industrial machines, where you have mandatory warning signs, switches for operation with two hands (or even two people), mandatory inspections of these safety features etc. It is not a different league it is a…

Right. I've worked with many machines that can chop or rip off limbs and I can't think of a single instance in which the operator even had access to the manual. "Push these two buttons and this foot pedal to make it go. Don't wear loose clothing." If it was more complicated than a few button-presses to use and that risky, it would either be operated by a team or it wouldn't be used.

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.

Re: Git undo: We can do better

#477

Post by arthurcolle »

rjmunro wrote: post #440
29athrowaway wrote: post #205

There is a large graveyard of "simple git tools", many of them portray themselves as happy GUIs that prevent you from learning git... None of them works. At some point you will be told to fix the problem by hand.

This. 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 fir…

git absorb looks sick, thanks for sharing! Any other dark magic you want to share?

Re: Git undo: We can do better

#478

Post by lmm »

Ensorceled wrote: post #464
lmm wrote: post #442

Earlier quoted context omitted.

> 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? 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 framewor…

I have multiple branches, we use gitflow (well modified). This isn't about branching, it's about what happens in the edge cases and how difficult git is when things go wrong. The comment I'm replying to said "branch more" as if that would solve some kind of problem with edge case complexity.

That comment likely assumed merging between branches was the "edge case" you were hitting; the general principle - do whatever it is more often, so that the edge case becomes routine - is sound. I found gitflow horrendously overcomplicated so I can imagine it might introduce some edge cases, but I'm honestly struggling to think what they might be - in my experience as long as you never rebase/cherry-pick/squash, frequently have parallel branches, never rebase/cherry-pick/squash, and frequently merge, there aren't actually any edge cases in git - as long as you remember to never rebase/cherry-pick/squash.

Re: Git undo: We can do better

#479

Post by npteljes »

u801e wrote: post #462
npteljes wrote: post #410

Earlier quoted context omitted.

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

Have you tried running: git push origin HEAD In both Github and Github Enterprise, that command will create a branch with the same name on the remote.

Works like a charm, thanks!

Re: Git undo: We can do better

#480

Post by saagarjha »

stormbrew wrote: post #335
mikepurvis wrote: post #289

Earlier quoted context omitted.

What's wrong with `git push -f`? When I'm working on a branch that's been previously pushed with `-u`, it's pretty normal to force push it, particularly if you're amending or reordering commits in response to review feedback, or rebasing due to conflicts in preparation to merge.

changing `-f/--force` to act like `--force-with-lease` would have no effect on that flow whatsoever. What it would prevent is you accidentally overwriting something on the remote because you didn't know its current state, potentially silently backing out changes someone else (or perhaps you yourself on another machine) had pushed. All it does is add this simple check before actually pushing: if (remote_ref("blah") !=…

It’s important to also understand where this might fall down: many tools fetch automatically and this can cause issues with reliability here.
Post reply on HN