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

91–100 of 280 posts

Re: Oh shit, git (2016)

#91

Post by mehrdadn »

dagw wrote: post #84
mehrdadn wrote: post #70

Earlier quoted context omitted.

Are you imagining every use of git is either (1) a Computer Scientist writing Code, or (2) a hack? You can't imagine anything in the spectrum in between? LaTeX papers by academics in various fields, scientific coders (MATLAB etc.), people writing stuff in Markdown, students who are still learning even CS, etc. are all doing the wrong thing by using git?

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 for the job. Sure if you're already well versed in git go ahead and use it and if you're collaborating with people using git you're probably going to have to learn it, but at least realize that using git for not-code is probably not the best tool for the job especially if you're at the same time trying to learn git from zero.

What do you see as the best tool for the job?

Re: Oh shit, git (2016)

#92

Post by mehrdadn »

johnsea wrote: post #85
fileeditview wrote: post #75

Earlier quoted context omitted.

Wow just tried this.. is this considered a bug or a feature and where can you read about this if it is intended behavior?

`git checkout --help` gives git checkout [ ] [--] ... Overwrite paths in the working tree by replacing with the contents in the index or in the (most often a commit). When a is given, the paths that match the are updated both in the index and in the working tree. As 'widget' is a path (and not a branchname as most often), local changes will be overwritten. Together with `git reset --hard` this is a bit a dangerous op…

Also note that 'widget' could've also easily been a typo for a branch (maybe they meant 'widgets' or something). Meaning that even if you only stick to uses of git checkout for branches, you're not safe (unless you're infallible).

Re: Oh shit, git (2016)

#93

Post by kurtisc »

louiskottmann wrote: post #73
kinkrtyavimoodh wrote: post #31

Earlier quoted context omitted.

Git being difficult has unfortunately become a meme, and like all memes, gets propagated irrespective of its truth value. Like I get it, we all enjoy making fun of vi but imagine every thread about vi only filled with people harping about ":wq". It gets tiring real soon.

I think many believe that "this should be easy, just add commits and get versioning, voilà!" and thus never invest the time (what, 2 days max?) to actually dig in, try a few common scenarios on a dummy repo, before actually using it on a live project. The truth is, it's not so easy a task to get versioning right and git does, people are not humble enough.

I agree. Usually if someone gives out a concrete change they'd make to improve git I can quickly point out a simple workflow it breaks because they have a mental model of a Github repo with a trunk and branches. Lots want to couple commit and push, but on this machine

  history|grep 'git commit'|wc -l
is 20 times larger than

  history|grep 'git push'|wc -l

Re: Oh shit, git (2016)

#94

Post by noname120 »

teekert wrote: post #53
_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.

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.

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.

Re: Oh shit, git (2016)

#95

Post by cozzyd »

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…

Have you tried a three-way-merge tool (e.g. vimdiff, meld, kdiff3, surely some emacs way of doing it)?

Re: Oh shit, git (2016)

#96

Post by reacweb »

ddtaylor wrote: post #21

Many of these problems can be avoided by using a pull-request style workflow.

Yes, there is a balance between preventing problem or fixing problem. It is useful be prevent problems, but it remains useful to be able to fix them easily.

Re: Oh shit, git (2016)

#97

Post by bicolao »

noname120 wrote: post #94
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.

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.

[1] https://github.com/git/git/blob/pu/Documentation/git-restore...

Re: Oh shit, git (2016)

#98

Post by bicolao »

mehrdadn wrote: post #77
fileeditview wrote: post #75

Earlier quoted context omitted.

Wow just tried this.. is this considered a bug or a feature and where can you read about this if it is intended behavior?

Probably a feature given how many gazillion meanings they've given to checkout intentionally, but I have no clue. Hopefully it got the point across though ;) and I'm pretty sure it's not the only way to lose info in git...

In a near future, hopefully we will have two new commands, git-switch and git-restore. The former is only about switching branches, the latter restoring files. Then you can stay away from the overloaded git-checkout.

See

https://github.com/git/git/blob/pu/Documentation/git-switch....

https://github.com/git/git/blob/pu/Documentation/git-restore...

Re: Oh shit, git (2016)

#99

Post by idoubtit »

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…

Even without plugin in a three-ways tool, Git's conflict can provide more information.

    [merge]
        # display 3 parts for each conflict,
        # including the common ancestor
        conflictstyle = diff3
There's also the option to use a semantic merge tool. AFAIK, there are only paying tools for this, and only a few languages are supported.

Re: Oh shit, git (2016)

#100

Post by mehrdadn »

bicolao wrote: post #98
mehrdadn wrote: post #77

Earlier quoted context omitted.

Probably a feature given how many gazillion meanings they've given to checkout intentionally, but I have no clue. Hopefully it got the point across though ;) and I'm pretty sure it's not the only way to lose info in git...

In a near future, hopefully we will have two new commands, git-switch and git-restore. The former is only about switching branches, the latter restoring files. Then you can stay away from the overloaded git-checkout. See https://github.com/git/git/blob/pu/Documentation/git-switch.... https://github.com/git/git/blob/pu/Documentation/git-restore...

That's awesome :) though this is just one way to lose files.
Post reply on HN