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

201–210 of 280 posts

Re: Oh shit, git (2016)

#201

Post by avar »

darkpuma wrote: post #69
jchw wrote: post #45

Earlier quoted context omitted.

Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.) Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it so…

> If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems. Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket. The world di…

If you care about distributed bug tracking you might be interested in, or want to contribute to git-bug: https://github.com/MichaelMure/git-bug

It's aiming to create a fossil-like distributed bugtracker on top of git, with bidirectional importing from e.g. github's and gitlab's APIs.

Re: Oh shit, git (2016)

#202

Post by JohnFen »

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…

> I'm sure there is something much better waiting to he invented.

I think that's fair to say. I think that's always fair to say.

Re: Oh shit, git (2016)

#203

Post by bunderbunder »

JohnFen wrote: post #197
bunderbunder wrote: post #191

Earlier quoted context omitted.

> git, ugly as it is, reflects the underlying data model. Once you understand that data model... This is, like, the very definition of bad/sloppy UX.

Perhaps, but speaking personally, that doesn't matter much to me. What matters to me is how much easier a tool makes my job, and of all the version control systems I've used, git is easily the winner.

And I don't want to say that Git isn't an improvement over many other version control systems.

But, IMO, the real sea change there is the shift to a DVCS, and not Git's interface. Within the set of DVCS that I've used, I find Git to be easily the most difficult to understand and work with, and the one where I have to spend the most time reading and grokking abstruse explanations of the tool's implementation details in order to figure out how to deal with some edge case.

I don't think that I'm the only one. My sense is that people whose only DVCS is git are much more likely to love it unconditionally than people who came to git after having first spent significant time on some other DVCS. For my part, as another concrete example, I have to spend a lot more time helping junior devs with source control snafus now that I'm at a Git shop than I did when I was at a Hg shop.

In summary, "Sure it's easy to use, you just have to read this lengthy explanation of its implementation details first," isn't really a compelling argument when you know that there are other competing products that are easy to use even if you didn't spend that much time on RTFM first.

Re: Oh shit, git (2016)

#204

Post by mehrdadn »

_pmf_ wrote: post #200
mehrdadn wrote: post #63

Earlier quoted context omitted.

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

Apparently I'm warned when I do this using SmartGit; if you are unable to safely use the CLI tool, maybe you should switch to a safer tool and leave the CLI tools to power users?

> if you are unable to safely use the CLI tool,

Way to suggest only incompetent people lose data like this.

But yes, GUIs do prevent this to a decent extent. Unfortunately git is not a tool for which switching to a GUI before you're comfortable with the CLI is a good idea. SVN is, but not git. I say this from personal experience as a TortoiseGit user. You really gotta learn the command-line first.

Re: Oh shit, git (2016)

#205

Post by phaemon »

thatoneuser wrote: post #24
scarejunba wrote: post #18

Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok. Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical master…

OK hot shot. Tell everyone here how you've never fucked up commands and had to blow out a repo and start over and how were all idiots for having done that. It's a tool. Any tool can be confusing if the person isn't taught how to use it. Git requires teaching so there's a lot of room for misunderstanding.

> never fucked up commands and had to blow out a repo and start over

You never have to do this, because it's virtually impossible to screw up a git repo with git commands, to the point it can't be easily fixed. And I'll tell you why and how.

As you no doubt know, all commits in git are hashed. This means that you can't change a commit in any way, only ever add a new one. Neither can you insert a commit into an existing chain: you have to rewrite the whole chain with new commits.

As a consequence, if your `master` branch, for example, is pointing to commit `aa33bf`, there will be a unique chain of commits leading back to the original commit which can't be altered.

It doesn't matter if you cherry-pick, merge, rebase or dance the fandango...if you point `master` back to `aa33bf` it will look exactly the same as it did before.

You can usually find what the branch was pointing before with `git reflog`. But you were going to clone it from github again, right? So, `origin/master` is pointing to the right commit, and you can just reset it back to that (remember to first commit any random stuff in your working dir that you want to keep):

  git checkout master
  git reset --hard origin/master
And, obviously, you can do exactly the same with any other branches that have been messed up.

There you go. Now you too are a "git hot shot" and can wow your friends with your amazing skills. ;)

Re: Oh shit, git (2016)

#206

Post by dllthomas »

fouronnes3 wrote: post #181
andrewla wrote: post #172

Earlier quoted context omitted.

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?

You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.

Re: Oh shit, git (2016)

#207

Post by dahart »

cesarb wrote: post #183
dahart wrote: post #175

Earlier quoted context omitted.

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own as…

> Aren’t git commits stored as patches? No, they aren't, git commits are stored as snapshots. Each git commit has one tree, which is a snapshot of the state after the commit; zero or more parent commits; a pair of authors with corresponding timestamps; a commit message; and nothing more. Any patch you see in git is an illusion, made by comparing the commit's tree with the parent commit's tree.

Thank you. Sheesh I feel like I should have known this about git. That would make diffing very far apart changes super fast.

So what's the advantage to explicit storage in patches over snapshots? Are diffs between snapshots not able to capture the same information that explicit patches have?

Re: Oh shit, git (2016)

#208

Post by Grangar »

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.

Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.

Re: Oh shit, git (2016)

#209

Post by jancsika »

> git diff --staged

The way it worked well was that the "--staged" flag would be implied if you had already staged some files to be committed.

But on this day I noticed that nothing bad happened from that behavior. So I time traveled back and whispered to the git devs that the interface should be made more pedantic to keep users from relying too much on git to do the right thing for them.

Now it's great because users suffer and I have plausible deniability from this now being on par with the rest of git's interface.

Re: Oh shit, git (2016)

#210

Post by js2 »

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…

I'm an early git contributor and long time user. At the time I picked it up, I was following and using hg as well.

I found git easier to learn and use. Git has just a few basic concepts underlying how it works. Once I learned blobs, trees, commits, the index, and references (branches, tags, reflog, etc), I understood the model. It wasn't hard to grok a local vs remote repo, how history was a dag, and so forth. From there, I realized all the crazy commands, the baroque UI, these were all just ways of manipulating those objects in various ways. I could always figure out how to make git do what I wanted. It never fought me or tried to tell me I couldn't do something.

hg, by contrast, I felt was always trying to hold my hand. Its model was harder to understand. It required me to adapt to its workflow, instead of allowing me to adapt it to mine. It was generally much less flexible.

I found everything about git more Unix-philosophy like.

I understand completely if you don't want to think about your VCS and just want it to record your changes and otherwise get out of your way, but I wanted a more flexible and powerful tool.

Post reply on HN