Gitless: a version control system • Hacker News Board

Re: Gitless: a version control system

#351

Post by eriknstr » Mon, Oct 03, 2016, 1:57 PM UTC

marcandre wrote: post #344

eriknstr wrote: post #340

Earlier quoted context omitted.

After having used git for a few years, I identified what commands I use most frequently and have created two-letter aliases for these; alias st='git status' # STatus alias dp='git diff' # Diff Pending alias aa='git add .' # Add All alias di='git diff --cached' # DIff alias cm='git commit -m' # CoMmit alias pu='git push' # PUsh I've added comments above to show you what I think in my head when I type the two-letter al…

It's way superior to use git aliases instead of shell aliases. In this way autocompletion and autocorrection will work.

For the specific aliases I have, the only one that needs an argument is commit and you can't auto-complete a commit message anyway ;) For the aliases that I sometimes specify a file path for, bash is still able to tab-complete that. So for me, shell aliases are actually the best.

Re: Gitless: a version control system

#352

Post by anarcat » Mon, Oct 03, 2016, 1:57 PM UTC

I am also pleasently surprised by this initiative.

I consider myself an advanced git user so I am not sure I would use it myself, because my brain is hardwired to git's wicked commandline interface now. There is little that surprises me in git nowadays.

I am used to give out simple "the 10 git commands you will ever need" tutorials to people, but it's true that it is confusing for people, even with that. gitless takes out significant confusion out of the daily grind of using git, so much that I may end up recommending it instead of git itself, especialy since they are interoperable.

What I would love to see would be to have those commands percolate back into git itself. git's usability has improved significantly since it started, and while this project shows there's still a lot that can be improved, history has shown us that git can be improved. track, untrack, history, switch, resolve, publish, init's remote argument, all those could be added as commands into git and equivalent commands could be deprecated or just kept for the hardcores like me that don't want to be bothered learning a new simpler interface.

Unfortunately, given the reaction on the mailing list, I am thinking this will not/never happen and gitless will remain a friendly fork: http://marc.info/?l=git&m=147527432403442&w=2

Re: Gitless: a version control system

#353

Post by skoczymroczny » Mon, Oct 03, 2016, 2:20 PM UTC

bsder wrote: post #264

lbotos wrote: post #163

Earlier quoted context omitted.

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git,…

> Version control is arguably confusing for beginners NO IT IS NOT . That kind of thinking is broken. Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works. As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with som…

For me the problems are always merge conflicts. Don't know why, in SVN I wasn't afraid of merge conflicts, I just opened a GUI, clicked on some arrows, picked the parts I want and parts I don't want, save and done. In Git, even with gui tools, I often end up with a mess of .BASE, .LOCAL, .REMOTE files, then I can't merge it all properly, and even if I do it asks me to commit the changes again and it's a mess, so I just clone the repo again and copy the files (xkcd #1597).

Re: Gitless: a version control system

#354

Post by dahart » Mon, Oct 03, 2016, 2:45 PM UTC

lmm wrote: post #348

dahart wrote: post #313

Earlier quoted context omitted.

Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality. What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, st…

> $ git commit -am "config changes" > $ git checkout Y > $ git cherry-pick X Sure, but then I also have to do: $ git checkout - $ git reset --hard HEAD~1 $ git checkout - which is a bunch of faff compared to the stash approach. (side complaint: why doesn't "-" work for merge/cherry-pick/reset like it does for checkout?)

Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows.

> why doesn't "-" work for merge/cherry-pick/reset like it does for checkout?

I don't know what a single dash does for you. On my git, I get a command line error with a single dash. Maybe you were thinking double-dash?

A double-dash is used to separate flags to your git command from path arguments, just in case a file you put on the command line starts with a dash. (Pro-tip: don't name files that start with dashes.) Running "git checkout -- ." at the top level of your repo will do the same thing as "git reset --hard HEAD".

Merge, cherry-pick and reset all work on refs, not on paths, so when you add a -- to one of those commands you may get an error like this:

  fatal: Cannot do hard reset with paths

The -- is optional to checkout, if the path is unambiguous. You can reset unstaged changes from your repo root by using "git checkout ."

Re: Gitless: a version control system

#355

Post by influx » Mon, Oct 03, 2016, 2:52 PM UTC

slowmovintarget wrote: post #350

matt4077 wrote: post #339

Earlier quoted context omitted.

I never realized how much of a tool git users were before I knew there are 500 page books about it.... This whole thread is evidence of two opposing viewpoints: "git is too hard" and "git is powerful, professional tool and that requires some effort". I believe those making the latter point misunderstand the first group (to which I belong): I'm not opposed to putting in some time to learn a tool that's central to my c…

Git is a powerful, professional tool that requires some effort, primarily because the UI was accumulated, not designed.

It also was designed for a use case that almost no one actually does which is distributed version control.

Most people use it like a svn with better branching and merging.

Re: Gitless: a version control system

#356

Post by [deleted] » Mon, Oct 03, 2016, 3:17 PM UTC

marcandre wrote: post #344

eriknstr wrote: post #340

Earlier quoted context omitted.

After having used git for a few years, I identified what commands I use most frequently and have created two-letter aliases for these; alias st='git status' # STatus alias dp='git diff' # Diff Pending alias aa='git add .' # Add All alias di='git diff --cached' # DIff alias cm='git commit -m' # CoMmit alias pu='git push' # PUsh I've added comments above to show you what I think in my head when I type the two-letter al…

It's way superior to use git aliases instead of shell aliases. In this way autocompletion and autocorrection will work.

[deleted]

Re: Gitless: a version control system

#357

Post by massysett » Mon, Oct 03, 2016, 3:38 PM UTC

rficcaglia wrote: post #314

nine_k wrote: post #271

Earlier quoted context omitted.

Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.

yes. and that's why as new planes are being produced, both commercial and small planes, they are replacing the older cockpits with fully electronic modern cockpit controls (with non-electronic secondary controls for power failure use) many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings

Fully electronic "modern" solves nothing without training. Part of the reason Air France 447 crashed was because the crew did not react correctly to the instruments, even though it was an Airbus with all its gee-whiz electronic stuff. Boeing has been more conservative.

Re: Gitless: a version control system

#358

Post by [deleted] » Mon, Oct 03, 2016, 3:38 PM UTC

rficcaglia wrote: post #314

nine_k wrote: post #271

Earlier quoted context omitted.

Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.

yes. and that's why as new planes are being produced, both commercial and small planes, they are replacing the older cockpits with fully electronic modern cockpit controls (with non-electronic secondary controls for power failure use) many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings

[deleted]

Re: Gitless: a version control system

#359

Post by lisper » Mon, Oct 03, 2016, 3:45 PM UTC

stevenhuang wrote: post #325

lisper wrote: post #319

Earlier quoted context omitted.

> How so? Because he's the one who said that they do the same thing.

I don't follow--where does he say that?

https://news.ycombinator.com/item?id=12622746

Re: Gitless: a version control system

#360

Post by lmm » Mon, Oct 03, 2016, 3:51 PM UTC

dahart wrote: post #354

lmm wrote: post #348

Earlier quoted context omitted.

> $ git commit -am "config changes" > $ git checkout Y > $ git cherry-pick X Sure, but then I also have to do: $ git checkout - $ git reset --hard HEAD~1 $ git checkout - which is a bunch of faff compared to the stash approach. (side complaint: why doesn't "-" work for merge/cherry-pick/reset like it does for checkout?)

Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows. > why doesn't "-" work fo…

> Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows.

I accidentally made changes while on X when I wanted to make them on Y. I don't want to just "git checkout Y" in case that conflicts. If I do as you suggested and commit them (on X) and then cherry-pick that commit onto Y, I then have to go back to X to remove the commit I made, otherwise I have the changes on X as well.

> I don't know what a single dash does for you. On my git, I get a command line error with a single dash

"git checkout -" switches to the previous branch. Which is great, but it's frustrating that I can't do e.g. "git merge -" to merge the previous branch - logically that should be the same kind of thing.