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

Legit. Git for humans

git-legit.org

Post reply on HN
Print view View original

21–30 of 136 posts

Re: Legit. Git for humans

#21

Post by regularfry »

eaurouge wrote: post #18
batista wrote: post #6

Earlier quoted context omitted.

I take offense to the "just" and the "sugar". You making sound like something bad for your health. An alternative syntax can make: 1) usage simpler 2) multiple step processes turn to one step 3) commands easier to remember 4) less error prone (or the opposite, depending on the specifics of the new syntax). So, no, this is not " just syntactic sugar " this is "new syntax", that is: an alternative command line user int…

Looks like it's just aliases. You might as well just use 'git alias'. There's no need for a new universal set of commands - it defeats the idea of configuring your very own Git.

I disagree. A lingua franca is important. If these are indeed common operations, then it's important that everyone talking about, say, `git sprout` means exactly the same thing.

Re: Legit. Git for humans

#22

Post by raganwald »

eaurouge wrote: post #10

I understand that Git is a fairly complex utility. But you can accomplish a lot just memorizing about 5 Git commands and what they do. Besides, if you decide to use an abstraction such as this one without understanding the plumbing, what do you do when 'git sync' fails due to conflicts?

The same thing I do when my hardware misbehaves and I don't understand how it works and why it failed.

:-)

Just kidding. Argument by Reuction Ad Absudum is fun, but in this case, you make a good point. There is a difference between a utility designed to make someting you understand easy and a utility designed to put an easy-to-understand facade in front of something you don't understand.

Re: Legit. Git for humans

#23

Post by MatthewPhillips »

alexchamberlain wrote: post #19
MatthewPhillips wrote: post #16

Earlier quoted context omitted.

But Git commands map to what is going on in the code, which isn't necessary. I think an effort to make a true CLI for git should be encouraged. For example: git push Pushes everything, in every branch. git pull Whoops, won't let me do that without providing a branch.

Erm... push behaviour can be changed using config and will be changed in the next release to only push the current branch. My git pull pulls the current branch...

> Erm... push behaviour can be changed using config

Right, and isn't that what legit is providing here? Sane defaults. I'm in favor.

Re: Legit. Git for humans

#24

Post by Jach »

arthurbrown wrote: post #12
orblivion wrote: post #7

I hope the developer thought very carefully about how to handle doing operations starting from unusual states. "# Switches to branch. Stashes and restores unstaged changes." I guess I can't think of anything in particular, but I feel like something unexpected could go wrong here. (I didn't know you could pop a the last stash that was made on a given branch?)

It seems like the use case he's optimizing for here is if you're accidentally on the wrong branch, and need to move your working changes over to the correct branch. Personally, I almost always use stash if I'm not quite ready to commit, but need to quickly fix a bug that takes precedence over whatever I'm currently working on. I stash what I'm doing, fix it, and them come back. Some of these operations seem at odds w…

I've used that workflow too. What disturbs me about the `git switch` proposed here is the unstashing. I think the intended optimization is more general: when you're trying to switch to another branch for any reason but git doesn't let you because of unsaved changes. But your use case of being on the wrong branch seems like the actual optimization for a fairly (at least for me) uncommon workflow. More frequently I, like you, stash and switch, then possibly do something (or not) like immediate bug-fixing, then switch back and unstash only then.

Re: Legit. Git for humans

#25

Post by alexk7 »

MatthewPhillips wrote: post #16
alexchamberlain wrote: post #9

Earlier quoted context omitted.

I'd have to agree. Git is very Unix - simple commands do one simple thing - it doesn't need complicating by opaque commands that do lots of things at once.

But Git commands map to what is going on in the code, which isn't necessary. I think an effort to make a true CLI for git should be encouraged. For example: git push Pushes everything, in every branch. git pull Whoops, won't let me do that without providing a branch.

There are discussions about changing the push default behavior.

http://lwn.net/Articles/487131/

Re: Legit. Git for humans

#26

Post by eaurouge »

regularfry wrote: post #21
eaurouge wrote: post #18

Earlier quoted context omitted.

Looks like it's just aliases. You might as well just use 'git alias'. There's no need for a new universal set of commands - it defeats the idea of configuring your very own Git.

I disagree. A lingua franca is important. If these are indeed common operations, then it's important that everyone talking about, say, `git sprout` means exactly the same thing.

"A lingua franca is important"

Exactly! And that lingua franca already exists. This is only useful if you would like a new syntax for personal use and you're too lazy to or don't want to use 'git alias'.

Re: Legit. Git for humans

#27

Post by kellishaver »

Switch, synch, publish, unpublish - those all made sense, but when they started adding things like 'sprout' and 'graft' it just passed into the realm of trying to be too cute with the branching metaphor for my tastes.

Personally, I'd pick git-flow over this. It seems more useful and makes, syntactically, more sense (though it can get a bit verbose at times `git flow feature start some-feature`). Starting and finishing features, hotfixes, releases, etc. handles all of the necessary branching, merging, and checkouts for you while adding structure and basically documenting the lifecycle of the code in your commit logs.

Maybe it's not as 'human friendly' as sprouting a branch, but starting and then finishing a feature sounds pretty straightforward.

https://github.com/nvie/gitflow

Re: Legit. Git for humans

#28

Post by ryanbigg »

I strongly disagree with the purpose of this. It still has precisely the same problem that regular git has: you need to understand the language behind it.

Just learn regular Git rather than re-inventing the language.

Re: Legit. Git for humans

#29

Post by untog »

knowtheory wrote: post #20
karamazov wrote: post #11

Earlier quoted context omitted.

The phrasing is intentional - a new syntax needs to be substantially better (as opposed to slightly better) than the old one to justify adding an additional standard.

Incremental and clarifying progress is always beneficial. I am on the fence as to whether this is clarifying or not. Git's problem is not just that the command structure is... esoteric, it's that once you're off the golden path, finding your way back onto the path is extraordinarily difficult. I am unclear as to what extent legit mitigates the second (thornier) problem.

Incremental and clarifying progress is always beneficial.

Only if everyone increments with it. If you have half a team using one set of terminology and half the other then it's going to end in an unholy mess.

Post reply on HN