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

Things I wish everyone knew about Git (Part I)

blog.plover.com

Post reply on HN
Print view View original

181–190 of 200 posts

Re: Things I wish everyone knew about Git (Part I)

#181

Post by pdonis »

shikoba wrote: post #166
TacticalCoder wrote: post #113

Earlier quoted context omitted.

Yeah I much preferred Mercurial from that standpoint. And branches there were correctly named branch. But you kinda, sorta, can get "what should have been called branches but don't exist in Git" by using named tags when you "start a branch" (a real branch I mean, not a Git "branch"). > Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each c…

> branch that aren't branch at all What do you mean? Git branches are branches. What is a branch for you? And why git branches aren't?

Read the post of mine that TacticalCoder was responding to.

Re: Things I wish everyone knew about Git (Part I)

#182

Post by fiddlerwoaroof »

lmm wrote: post #153
fiddlerwoaroof wrote: post #146

Earlier quoted context omitted.

You can, I think, with `git stash push foo.js`

You can't; depending on the options that will either stash your staged changes to foo.js, stash your unstaged changes to foo.js, or stash both but flatten them so that when you apply them they're all staged (or all unstaged). There's no way to stash it so that you can unstash it and get it back how it is now.

Yeah, I’ve actually found WIP commits and a hook to block them from being pushed end up working better than stashes, so I haven’t spent a lot of time figuring out the complexities of stashes.

My workflow here would be something like:

    git checkout -b save
    git commit # save staged changes
    git add .
    git commit -m WIP # save unstaged changes 
    git checkout -

Re: Things I wish everyone knew about Git (Part I)

#183

Post by remram »

cryptonector wrote: post #175
remram wrote: post #173

Earlier quoted context omitted.

Which is what we're talking about.

Right, so stop typing that at all. Instead use `git checkout -f` to throw away extant changes. The `-f`/`--force` option is a lot clearer in intent than `--hard`.

The GP was talking about "moving the branch pointer", which checkout does not do. I am encouraging you (for the second time) to read the thread you are replying into...

git checkout can also nuke changes from both working copy and staging area. `git checkout ` will nuke working copy (and auto-completion is likely to give you a path when you were looking for a branch), `git checkout ` will nuke both. No --force required in either case, so let's not pretend that you can't lose changes without a scary-looking flag like --force or --hard.

Re: Things I wish everyone knew about Git (Part I)

#184

Post by shikoba »

pdonis wrote: post #181
shikoba wrote: post #166

Earlier quoted context omitted.

> branch that aren't branch at all What do you mean? Git branches are branches. What is a branch for you? And why git branches aren't?

Read the post of mine that TacticalCoder was responding to.

I already read it. It's not clear to me.

Re: Things I wish everyone knew about Git (Part I)

#185

Post by cryptonector »

remram wrote: post #183
cryptonector wrote: post #175

Earlier quoted context omitted.

Right, so stop typing that at all. Instead use `git checkout -f` to throw away extant changes. The `-f`/`--force` option is a lot clearer in intent than `--hard`.

The GP was talking about "moving the branch pointer", which checkout does not do. I am encouraging you (for the second time) to read the thread you are replying into... git checkout can also nuke changes from both working copy and staging area. `git checkout ` will nuke working copy (and auto-completion is likely to give you a path when you were looking for a branch), `git checkout ` will nuke both. No --force requir…

> The GP was talking about "moving the branch pointer",

Not explicitly.

`git checkout ref path` implies `--force`, since you're being specific.

I would prefer if Git could keep a GCed pile of saved workspace changes every time you force checkout/reset.

But for the love of all that is good, stop using `git checkout`/`git reset` in the few ways they hurt.

Re: Things I wish everyone knew about Git (Part I)

#186

Post by sagarm »

eropple wrote: post #63
dotancohen wrote: post #51

Earlier quoted context omitted.

How is that git's fault? I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key. I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.

I dunno - I can tell zsh to are-you-sure me about an `rm -rf *`, git seems like it should be able to do similarly. Or, as Mercurial does, back up overwritten files to .bak. These are pretty light asks.

The sole purpose of git checkout -- file is to overwrite the file you explicitly listed. There should not be a confirmation by default.

Re: Things I wish everyone knew about Git (Part I)

#187

Post by patal »

What I really want to do with Git, but haven't found a way to do, is to compare diffs. Often I have a merged a feature on some main develop, but need to backport these changes to some older release branch. The backport has some merge conflicts, indicating that much has changed on develop since. Now I want to see that the set of changes (the diff) on main develop is basically the same as the set of changes (the diff) on the old release branch. I want to diff their diffs. Anybody any ideas?

Re: Things I wish everyone knew about Git (Part I)

#188

Post by bsder »

shikoba wrote: post #165
bsder wrote: post #162

Earlier quoted context omitted.

> Am I the only one sad that Git beat out Mercurial as the industry standard? Quibble: Git didn't win. Github won. Git was simply the parasite on the Github host. However, I feel just like you. Mercurial is just so ridiculously easier to explain to people. I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.

> I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it. That's the problem. Git has a sane UX. The only issue is that a lot of people who doesn't understand it, write silly tutorials where they spread their misconception about it. The real issue is the poor quality of tutorials over the internet that mislead a lot of people.

So why is it that every other source control system seems to have such nice tutorials?

We can either posit that the people who made and use Git are substandard, or we can posit that there is something fundamental about Git that makes writing such tutorials difficult.

Re: Things I wish everyone knew about Git (Part I)

#189

Post by [deleted] »

cryptonector wrote: post #177
andrewjl wrote: post #147

Earlier quoted context omitted.

To use an example from TFA: how does Reset make any sense based on the Unix filesystem?

`git reset` is analogous to filesystem restore from backup. Next question. Note that the analogy to filesystems is not exact. The point is that you can understand higher-level operations in terms of lower level ones / gain insight into higher level operations from knowledge of the lower level concepts. As opposed to the cognitive burden of incomprehensible magic, where every time you get in trouble you've no idea wha…

[deleted]

Re: Things I wish everyone knew about Git (Part I)

#190

Post by woojoo666 »

mathstuf wrote: post #169
woojoo666 wrote: post #168

Earlier quoted context omitted.

I don't think the UX is that intuitive. If you want to tweak a commit that's not the branch head, you have to rebase the parent of that commit. From a technical standpoint this sort of makes sense, but for a casual user this is not intuitive at all

You rebase onto the parent of that commit. The parent doesn't change. Or am I misunderstanding what you're describing here?

But the average casual user just wants to modify the commit. There could easily be a higher level command for this, which internally finds the parent and performs the rebase, but instead Git (and even most GUI tools on top) forces you to go the manual route of selecting the parent and initiating a rebase. It's counterintuitive
Post reply on HN