Git Exercises • Hacker News Board

Re: Git Exercises

#21

Post by nlawalker » Wed, Jan 10, 2018, 3:02 PM UTC

westoncb wrote: post #16

da_chicken wrote: post #12

Earlier quoted context omitted.

That's an interesting paper. > More often than not, the choice of words makes sense in connection with the implementation of various git operations, but has no relation to the task you're attempting to accomplish. This seems like an extremely common problem in computing. I support several applications and a lot of the fields and functions in those applications seem to be placed arbitrarily until you know that those f…

> This seems like an extremely common problem in computing. I agree—I see it all over the place. It's what you get for a UI by default, if you don't take any extra measures to seek an effective design: you just expose program internals. I think the situation with git is slightly different from that all too common, naive pattern, though. The best comparison I can make is to graphics APIs like OpenGL (or even better, V…

>> But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it [...] I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead.

The beauty of being able to use an abstraction on top of git is that it doesn't need to cover everything you do. You can use a GUI or a couple simple aliases or scripts for daily driving and then move to the CLI for surgery; a good GUI will have a CLI pane or a button to open a CLI in the right directory.

Even for simply committing, it's nice to have the GUI visualization as an easy sanity check that you haven't accidentally added tons of files, or as an easy way to browse your changes before committing.

Stabilizing on git itself is good enough, there's no need for everyone to use the same abstraction on top of it. The only reason there's so much focus on the CLI is because it's the default, and because power users keep convincing newbies that you're not cool if you don't use it.

Re: Git Exercises

#22

Post by BeetleB » Wed, Jan 10, 2018, 6:36 PM UTC

yebyen wrote: post #18

BeetleB wrote: post #17

Earlier quoted context omitted.

Although I'm not a power user, I believe mercurial can do pretty much most things that git does - including editing history. They just make the easy stuff easy and make the advanced stuff harder - as opposed to git which puts them all on an equal footing. For history editing, people use the evolve extension in mercurial. It'll likely never become part of the default mercurial because there is a small chance of breaki…

Thanks for telling, I found the rebase extension on my own but I don't know what Mercurial users are using unless you tell me and I would not have found the evolve extension on my own :D I will probably check it out, to be fair it seems unlikely to "unseat the incumbent" git, but I've sampled my fair share of VCS including Git, SVN, CVS, RCS, Fossil, and have never really made it around to Mercurial. None of those ot…

>I will probably check it out, to be fair it seems unlikely to "unseat the incumbent" git

It will not, as they are more or less the same. People already on git have no good reason to switch. The only real benefit mercurial has is being friendlier. It may prove beneficial for new teams, but these days most people are already familiar with git and will put up with its pains (or rather, be oblivious to its pains).

Mostly an accident of history. If mercurial had initially gotten popular, I doubt anyone would be using git today.

Re: Git Exercises

#23

Post by da_chicken » Thu, Jan 11, 2018, 4:19 PM UTC

y4mi wrote: post #20

w0rd-driven wrote: post #14

Earlier quoted context omitted.

From SVN I cut my teeth on Hg/Mercurial, which had a much simpler barrier to entry and feels more user friendly. Mercurial and git solve the same basic underlying problem, distributed repositories, but in the "next gen vcs war" (if that was even a thing), git won out by a huge landslide largely due to a little site called Github. As I've dived into the nitty gritty of both, I find it seems you can get more out of git…

you clearly never had to support developers that need to work with a basic git-flow and get merge conflicts because they're unable to figure out why they shouldn't do the same change in separate branches. Or, if they do, how to resolve that conflict themselves.

To be fair, these are the same developers who moved files and renamed folders in SVN without using "svn mv".