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

Git koans

stevelosh.com

Post reply on HN
Print view View original

71–80 of 143 posts

Re: Git koans

#71

Post by etjossem »

Context

---

Master Git and a novice API developer stood together in a crowded office.

"I am trying to merge two massive XML files," explained the API developer, "and I am getting many tedious conflicts. You must have a strategy for making the lines match up in a human-readable manner. What is my best option?"

"Patience," said Master Git, turning away from the monitor.

"But I have been manually resolving for hours!" protested the API developer. "My mergetool ought to be able to imply context and match lines properly!"

Master Git sighed and left the room without a word. Hours later, he returned to find the office empty and silent. Only the API developer remained, his head bowed in defeat before the monitor.

"git merge --strategy-option=patience," whispered Master Git.

Upon hearing the same word in explicit context, the novice was enlightened.

Re: Git koans

#72

Post by wonderzombie »

stevelosh wrote: post #66
the_mitsuhiko wrote: post #61

Earlier quoted context omitted.

> 1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. > `git checkout -- somefile.py` does not have…

If your solution to "get the current branch" is "cat out this magic data file that happens to exist in the data directory" then we have completely incompatible definitions of "user interface" and are never going to agree on this.

The question was not how to just get the current branch, thought, right? As pointed out already, `git branch` does that.

The question was how to do it programmatically, and there are multiple ways to do it. You might still call that user interface, but it's that's a stretch; fancy shell magic like branch-in-prompt is typically write-once.

Re: Git koans

#73

Post by philwelch »

aidenn0 wrote: post #59
philwelch wrote: post #53

Earlier quoted context omitted.

Branches are just mutable pointers to commits. You're imposing a mental model onto Git that simply isn't present. Git is revolutionary, in part, because instead of asking "what's the mental model we want to emulate and then never mind if that matches the implementation", they gave developers credit that they can understand a handful of simple concepts and made the actual design and data model as simple as possible. P…

Maybe Linux kernel devs deserve that credit, but it's becoming increasingly clear that developers as a whole don't deserve that credit.

That's their problem. There are tools for fools. I'm glad I don't have to use them.

Re: Git koans

#74

Post by salgernon »

micampe wrote: post #64
the_mitsuhiko wrote: post #61

Earlier quoted context omitted.

> 1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. > `git checkout -- somefile.py` does not have…

> Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. You should understand what you are responding to before typing your answer. Say today I create an alias “boom = ” and next week git introduces a boom command. Now my alias is ignored, m…

>> Git gives some very stupid hints “branhc is not a git command, did you mean branch?” it should also warn me when I defined an invalid alias.

This is the thing that really infuriates me - having a message from my tool that tells me there's an error is one thing, but offering a (frequently incorrect) correction forces me stop and try to figure out why this suggestion was offered, since it frequently has NOTHING to do with what I actually (mis)typed.

Lets put it this way - if this autocorrection feature is so great, then it should prompt you Y/N after giving the error message. Would it then be a better feature? Or would it make more people want to stab it in the eyeballs? Or if this suggestion feature is so great, then it should just DWIM in the first place.

Someone needs to take gits levenshtein algorithm away.

Re: Git koans

#75

Post by aidenn0 »

the_mitsuhiko wrote: post #62
aidenn0 wrote: post #60

Earlier quoted context omitted.

More people use git; I'm becoming increasingly convinced that few of them actually know git.

> More people use git; I'm becoming increasingly convinced that few of them actually know git. And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.

Yeah, named branches in hg are just weird.

Re: Git koans

#76

Post by micampe »

the_mitsuhiko wrote: post #68
micampe wrote: post #64

Earlier quoted context omitted.

> Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. You should understand what you are responding to before typing your answer. Say today I create an alias “boom = ” and next week git introduces a boom command. Now my alias is ignored, m…

> Now my alias is ignored, my scripts are broken and I might destroy my working copy or kill my cat by using it without knowing it now means something else. Your scripts should not rely on aliases you have in your config. Scripts are intended to be used by different people.

I decide who is intended to use my scripts, thank you. I have many scripts where I am the only user.

Also, the issue of having an alias changing behavior without warning on my command line still exists.

Re: Git koans

#77

Post by pilgrim689 »

philwelch wrote: post #53
pilgrim689 wrote: post #22

Earlier quoted context omitted.

Although in implementation, a commit is not done on a branch, for the user, that is precisely what happens. You checkout a branch and you do a commit while on that branch. Thus, to the novice, it might be perfectly normal to expect Git to tell him what branches the commit was made on , even though that makes no sense from Git's point of view. I've never had that use case (knowing what branch a commit was made on ), b…

Branches are just mutable pointers to commits. You're imposing a mental model onto Git that simply isn't present. Git is revolutionary, in part, because instead of asking "what's the mental model we want to emulate and then never mind if that matches the implementation", they gave developers credit that they can understand a handful of simple concepts and made the actual design and data model as simple as possible. P…

You're making the same mistake as GP. I love Git, and I know that asking "what branch was this commit on" makes no sense. My point is that some users have different requirements as to what a DVCS should provide. If Git can't fulfill some of these requirements, then just say "Git can't do this" rather than beating around the bush.

Re: Git koans

#78

Post by w0utert »

bvdbijl wrote: post #35
the_mitsuhiko wrote: post #28

Earlier quoted context omitted.

I just find it unfair criticism because hg has just as many UI kinks or just lack of UI to begin with. `hg diff` or how it's randomly split into different commands with a `-p` flag is just one example.

Hg having kinks is not an excuse for git to have kinks too

And, in addition to that, I find it very hard to believe that anyone who used both can sincerely say Hg's CLI interface is 'just as bad' as git's. I've used both and switched to git eventually, because from a technical point of view it's simply the better tool. Git is faster, more flexible, easier to deploy. The things it is not: more intuitive, easier, more consistent.

I don't understand why many git apologists continue to try to paper over the atrocious CLI that comes with git by blaming the user for not knowing his tools well enough. The tool is supposed to serve the user, not the other way around. Personally I think everything about the git CLI sucks, plain and simple. The command structure and naming, the switches, the error messages, the documentation, all of it. Compared to git, the hg CLI is a thing of beauty. Yet I still prefer git over Hg. No need to sugarcoat it and pretend git is flawless though.

Re: Git koans

#79

Post by lelandbatey »

austintaylor wrote: post #10
ctdonath wrote: post #2

Short of me downing distressing amounts of coffee, could someone explain these please for those of us still trying to grok git?

I'm not sure what Silence is about. My git-config-fu fails me. One Thing Well demonstrates how one command (git checkout), while it does do 'one thing well' (changing your working directory to match something in the index), can handle a wide variety of seemingly unrelated use cases. Only the Gods demonstrates how history can mean different things: commit parentage, which is usually immutable, and branch history, whic…

Just to explain "Silence":

Apparently, git does not allow you to alias default git commands (like "pull", "push", "commit", etc) to something else. In the given situation, a user is trying to alias the default "pull" command to "pull --ff-only" so that pull will not automatically merge changes and will only fast-forward.

However, since git does not allow you to alias default commands, when the Git Master runs "git pull" it ignores the alias entirely and does a normal pull, and in so doing merges changes. The student is confused, but eventually figures it out.

Re: Git koans

#80

Post by syncsynchalt »

the_mitsuhiko wrote: post #26
syncsynchalt wrote: post #17

Earlier quoted context omitted.

I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).

> I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it). What about the index? Or the branching (bookmarks kinda work now I think), or the better remote management?

You're touting these as positives for git but in the context of training a large group to use a new VCS they are a negative.
Post reply on HN