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

Things I wish everyone knew about Git (Part II)

blog.plover.com

Post reply on HN
Print view View original

141–148 of 148 posts

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

#141

Post by arxanas »

wdkrnls wrote: post #135
formerly_proven wrote: post #24

Earlier quoted context omitted.

reflog tells you when you created/changed a label and what ID it had, so you can recover them.

Has anyone written a tool to actually does this? I want to add that to my post-rewrite hook immediately so that I can gain peace of mind I will always be able to switch to a branch where I can study the previous reality after rebasing a new one.

My project https://github.com/arxanas/git-branchless does this. Use `git undo -i` to get a graphical view of where branches were at an arbitrary previous point in time.

It's worth noting that, in principle, there are cases where the reflog will have never observed a branch move. The reflog we usually look at is that of HEAD; if HEAD did not have the branch checked out when it moved, then that information will be lost. (For example, if you run `git branch -f my-branch abc123`, the branch will be forcibly reassigned without having been checked out.) See https://github.com/arxanas/git-branchless/wiki/Architecture#... for more details.

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

#142

Post by rjmunro »

everybodyknows wrote: post #118
cassianoleal wrote: post #80

Earlier quoted context omitted.

What's `git gui`? $ git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are ci gc grep init lg80 pull push

Alternative: git-log --graph --all --stat

That's more like gitk, not git gui.

On ubuntu it's a separate install from the main git, https://launchpad.net/ubuntu/bionic/+package/git-gui

Try `apt install git-gui`, or similar.

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

#143

Post by valenterry »

nedbat wrote: post #140
valenterry wrote: post #85

Earlier quoted context omitted.

git could also have just followed some standards. For instance, how am I supposed to know the syntax of "3 days ago" in general? They could have used time spans from ISO 8601 standard, so for instance simply "P3D". Or "P3Y6M4DT12H30M17S". git is powerful but it involves a higher amount of time investment than it could if it were not reinventing the wheel and taking shortcuts as much. It's easy to see that it is and w…

Are you really suggesting that more people know what "P3D" means than "3 days ago"?

I think more people know how to define "3 days ago" when you tell them "provide it as an ISO 8601 time span" vs. "provide it in gits own format".

When it comes to presenting it nicely, then sure, use 3 days ago. No problem with that.

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

#144

Post by js2 »

js2 wrote: post #113

> What if you can't find it? Funny enough, I just wrote "git-lost-and-found" last week because I'd added a new file (`git add`) but before I created a commit I did a `git reset --hard` which deleted the file. It wouldn't have been in the reflog since there was never a commit created. But I knew it would be under .git/objects until the next time a `git gc` runs, so the trick was to just take a look at a few recent blo…

I guess I could use `git fsck --lost-found` too.

https://git-scm.com/docs/git-fsck

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

#145

Post by mabbo »

js2 wrote: post #119
mabbo wrote: post #44

I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things. That's maybe not a good sign about the usability of git. That `@{'3 days ago'}` thing? That's incredible. Why didn't I know about that 8 years ago? Why wasn't it obvious, intuitive to me that this was possible? git is brilliant and I lov…

> I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things. If I can humbly offer a suggestion: read the man pages. A man page read once thoroughly is much more useful than the same man page skimmed 1000 times. The syntax in question is in the rev-parse man page (`git help rev-parse`). These ar…

I think rather than asking everyone to read the manual, the designers of software systems ought to all read Don Norman's "The Design of Everyday Things".

Apple products became what they are because no manual was needed. They were designed with patterns that were intuitive, affordances, and a deep understanding of human psychology.

What I am arguing is that git lacks those very things that make reading a manual not needed.

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

#146

Post by atom_arranger »

TheChaplain wrote: post #13
MBlume wrote: post #6

"It is really hard to lose stuff" It is really hard to lose stuff that you have ever committed. It is really hard to lose stuff as long as you commit early and often. Uncommitted work is pretty easy to lose with 'git reset'.

Depends. I use an IDE from Jetbrains, their "Local History" feature makes it fairly difficult to lose anything, even between changes on uncommitted files.

This has saved me many times. Memory is cheap these days, this should probably be a more common editor feature, on by default.

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

#147

Post by morberg »

roeles wrote: post #120
Tijdreiziger wrote: post #97

Earlier quoted context omitted.

And the corollary: since code is harder to read than write, steer clear of writing clever code where simple code would suffice, as the clever code will be much harder to read.

A second argument is that debugging is harder than writing.

AKA Kernighan's Law: https://www.laws-of-software.com/laws/kernighan/

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

#148

Post by stonemetal12 »

stu2b50 wrote: post #88
stonemetal12 wrote: post #87

Earlier quoted context omitted.

Git supports history rewriting so 1 isn't true. Git uses hashes for "unique ids" hashes aren't unique just low probability of collision, so 3 is also not true. Having run into issues that appear to be caused by 3 not being true, I don't see that as a theoretical issue.

1 is true. When git is “rewriting” history it’s actually creating a new commits and moving the branch pointer over. Until the gc reaps them, you can absolutely git checkout the hash of any of the rewritten history and it’s still there, same as you left it. You can even move the branch pointer back, undoing the history rewrite.

So when I do a pull I get their un-rewritten history? Just because they have a short undo buffer doesn't make modifiable history immutable.
Post reply on HN