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

Oh shit, git (2016)

ohshitgit.com

Post reply on HN
Print view View original

101–110 of 280 posts

Re: Oh shit, git (2016)

#101

Post by rcxdude »

mehrdadn wrote: post #91
dagw wrote: post #84

Earlier quoted context omitted.

First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense) Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool for the job. Sure if you're already well versed in git go ahead and…

> First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense) Yes that's why I said "every use of git [...] (2) is a hack". > Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool f…

SVN is often better suited for such files because

a) they can grow quite large and the diffs do not compress well so downloading the entire history is quite expensive. SVN supports only downloading part of the tree and history which is useful

b) SVN supports file locking which can help prevent conflicts between editing the same file which is important because of the next point:

c) These files generally do not have diff and merge tools so branching is generally not useful and so are most of git's advantages over SVN.

That said, I am now generally using git for such files because a) I use git for code anyway and b) gitlab (especially which CI is still useful).

Re: Oh shit, git (2016)

#102

Post by mehrdadn »

rcxdude wrote: post #101
mehrdadn wrote: post #91

Earlier quoted context omitted.

> First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense) Yes that's why I said "every use of git [...] (2) is a hack". > Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool f…

SVN is often better suited for such files because a) they can grow quite large and the diffs do not compress well so downloading the entire history is quite expensive. SVN supports only downloading part of the tree and history which is useful b) SVN supports file locking which can help prevent conflicts between editing the same file which is important because of the next point: c) These files generally do not have di…

SVN? They should force themselves to need access to a server (or learn to run one) even if they're working by themselves locally?

Re: Oh shit, git (2016)

#103

Post by rusk »

masklinn wrote: post #68
teekert wrote: post #53

Earlier quoted context omitted.

Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I find this with many programming concepts.

Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.

Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.

Re: Oh shit, git (2016)

#104

Post by rusk »

dwaltrip wrote: post #41

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the int…

The Git support in the Jetbrains IDEs is very good. I'll often fire up IntelliJ if I'm too tired to try and figure out how to figure out what's going on.

Re: Oh shit, git (2016)

#105

Post by avar »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> Mercurial feels like it should be the winner. The commands are more uniform and predictable.

Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/

I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its repository format limitations inherently weren't fixable.

> Mercurial has a concept of commit stages to make history rewriting safer.

Yeah that's a really neat feature. For what it's worth some people at Google seem to be working on trying to get an equivalent feature into Git.

> For example, what Facebook did[...]

Much of what drove Facebook to Mercurial has since been addressed, e.g. "status" times being slow due to lack of inotify-like integration. That's now a feature of core git. Some of the rest is being worked on and actively upstreamed, e.g. from the GVFS effort: https://vfsforgit.org

Re: Oh shit, git (2016)

#106

Post by falsedan »

IshKebab wrote: post #83
jayd16 wrote: post #49

Earlier quoted context omitted.

>and super smooth conflict resolution? Because the hardest part of conflicts is already the conflicting changes themselves and not the source control.

Sure but I've never found a GUI or editor that lets me resolve conflicts in the way I want. For example say I change one line of code in a big function. I rebase and that function has moved. Conflict! I want a tool that says "here's what you changed, and here's the current state of the source". None of them do that though - they all just show the conflicts that git writes to disk - the code after you changed it, and…

I spent some time with `git mergetool` to help resolve conflicts. It's hideous but it's better than staring at inline conflict markers

Re: Oh shit, git (2016)

#107

Post by rusk »

mehrdadn wrote: post #63
_pmf_ wrote: post #34

I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.

> I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch. I can lose something for you in 2 seconds in git. Have fun e.g. recovering from this: $ git init $ mkdir -p widget && echo…

What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ...

Re: Oh shit, git (2016)

#108

Post by falsedan »

mehrdadn wrote: post #67
fulafel wrote: post #65

Earlier quoted context omitted.

The "own" branch is also public here and maybe collaboratively worked on

So then anyone building on it would rebase the same way you just did? Which was the same way they would have done so if you had just pushed a new commit?

yeah exactly, all the FUD about rebase and shared branches is baffling to me. are people regularly getting stuck on 'git pull --rebase' and slamming into merge conflicts?

Re: Oh shit, git (2016)

#109

Post by gbersac »

batisteo wrote: post #80
dwaltrip wrote: post #41

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the int…

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…

Exactly the kind of program which will benefit from being wrote in rust.

Re: Oh shit, git (2016)

#110

Post by mleonard »

bicolao wrote: post #97
noname120 wrote: post #94

Earlier quoted context omitted.

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. […

Hi. Interesting to know thanks!

Would you mind giving the current commands to achieve the three things you just listed?

That way I learn the future restore command along with the current approach and you description. T

Post reply on HN