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

Gitless: a version control system

gitless.com

Post reply on HN
Print view View original

341–350 of 390 posts

Re: Gitless: a version control system

#341

Post by ubernostrum »

Nursie wrote: post #334
ubernostrum wrote: post #291

Earlier quoted context omitted.

In this sense, trivially, every tool is a "professional" tool, since if you just rote-memorize every aspect of it you know how to do everything it can do. The problem with git is the lack of coherence in its default UI. Multiple ways to accomplish the same task, git commands which perform incredibly different functions depending on (invisible) context, inability to decide whether commands or flags should act as the h…

No, trivially, there can be tools that you know inside out which still present roadblocks to perfectly ordinary tasks and be a bad fit for the domain they operate in. Visual SourceSafe springs to mind here... Git, by comparison, is very flexible and allows you to do an awful lot, when you've learned it. You can learn SourceSafe inside out and still have it be a total pain in the arse.

Again: git as some sort of Platonic ideal of an implementation of a DAG I don't care to argue about. But git's default user interface I will argue about until I'm out of breath, then keep arguing about.

Nothing in that interface is designed to aid in learning. Nothing in it is designed so that mastering one task provides discoverability or intuitability of how to perform another task. It is a complex mess of inconsistencies, discontinuities and obscurities which point more to a lack of design or even of someone with authority to perform design than to anything else. It can only be "mastered" through rote memorization, and bears no necessary or useful relationship to the underlying data models and structures whatsoever.

Re: Gitless: a version control system

#344

Post by marcandre »

eriknstr wrote: post #340
k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

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.

Re: Gitless: a version control system

#345

Post by TuringTest »

njharman wrote: post #253
maker1138 wrote: post #230

I'm surprised at how many people are responding negatively to software that improves user experience. Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed. The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging…

"dumbed down" only improves the user experience of new users. It hurts power users and is rarely useful to anyone other than newbs. It can be net gain for infrequently used and rarely mastered tools. Source Control should the 2nd (after editor) most mastered tool of a developer. Many will assume this is "dumbed down" interface and thus overall bad for source control tool.

> "dumbed down" only improves the user experience of new users. It hurts power users and is rarely useful to anyone other than newbs.

That's only true if the power users perform a completely different group of tasks from the new users, or if the "new user" interface is made wholly incompatible with the "power user" interface.

If the power users still needs to perform the same basic tasks, the simplified and easier interface will likely make those tasks more efficient for the power user as well.

Re: Gitless: a version control system

#346

Post by TuringTest »

leshow wrote: post #343
twic wrote: post #128

Earlier quoted context omitted.

It seems to be a word in Spanish. It isn't a word in English.

prejudicial is absolutely a word in English. look it up

But "perjudicial" is a word in Spanish, meaning "harmful", "detrimental". I think that was the meaning intended.

Re: Gitless: a version control system

#347

Post by collinmanderson »

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

Merge Conflicts.

I think a lot of tutorials spend a lot of time teaching you the index/staging (a non-trivial concept that beginners don't need) but don't teach you how to survive merge conflicts and other common tricky situations which beginners are likely to run into if they're collaborating.

Your list is all you need...until you try to `git pull` and it says

> Cannot pull with rebase: You have unstaged changes.

You're only option with your list is commit your changes, but I think it's better to `git stash` then `git pull` then `git stash pop`

Though when you `git pull` you can get a merge conflict and there's two different ways to resolve it depending on if you used the `--rebase` flag or not.

Once you're done resolving those conflicts, you run `git stash pop` and could possibly get yet-another merge conflict that needs to get resolved.

Basically, I'd add `git stash` to your collaborative list. You can't `git pull` without it.

Re: Gitless: a version control system

#348

Post by lmm »

dahart wrote: post #313
projektir wrote: post #288

Earlier quoted context omitted.

> No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. I was talking about the non-rebase version. You didn't address the rest of my post: there are other cases. This will work for that particular case, but it's not a general-purpose solution. If I have branch X with config changes, and coworker wants me to switch to branch Y but I still want my config changes, wha…

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?)

Re: Gitless: a version control system

#349

Post by Nursie »

ubernostrum wrote: post #341
Nursie wrote: post #334

Earlier quoted context omitted.

No, trivially, there can be tools that you know inside out which still present roadblocks to perfectly ordinary tasks and be a bad fit for the domain they operate in. Visual SourceSafe springs to mind here... Git, by comparison, is very flexible and allows you to do an awful lot, when you've learned it. You can learn SourceSafe inside out and still have it be a total pain in the arse.

Again: git as some sort of Platonic ideal of an implementation of a DAG I don't care to argue about. But git's default user interface I will argue about until I'm out of breath, then keep arguing about. Nothing in that interface is designed to aid in learning. Nothing in it is designed so that mastering one task provides discoverability or intuitability of how to perform another task. It is a complex mess of inconsis…

Eh. Fair enough, my pedant mode just kicked in when you said any tool could be a 'professional' tool in the sense the parent poster said.

I have no particular view on how good or bad git's command line is - I have greatly enjoyed using SourceTree though, and the underlying DVCS seemed not to get in the way.

Re: Gitless: a version control system

#350

Post by slowmovintarget »

matt4077 wrote: post #339
globuous wrote: post #335

Earlier quoted context omitted.

No, but there's a book called "Pro Git" by Scott Chacon and Ben Straub that popped up on HN not too long ago. It does explain git on the lower level without going into the git source code. This book is over 500 pages, but chapters 1 to 3 will get you up and efficient within 2 hours. Especially chapter 3 (I skipped to it, I kinda knew the basic git commands from "experience"), which goes over branching and how it work…

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.
Post reply on HN