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

41–50 of 390 posts

Re: Gitless: a version control system

#41

Post by dom0 »

tiborsaas wrote: post #21
chvid wrote: post #7

To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If…

The progress displays for pushing and fetching are a bit verbose in my opinion, but otherwise I mostly agree.

Re: Gitless: a version control system

#42

Post by bluejekyll »

rplst8 wrote: post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous.

UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands.

Quick examples:

'git reset' vs. 'git revert' and sometime 'git checkout'

'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick'

'git rebase' vs. 'git merge' vs. 'git merge --squash'

Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo?

I commend this project for trying to apply some sanity to the entire thing.

Re: Gitless: a version control system

#43

Post by m3kw9 »

whack wrote: post #30

Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is…

Just use the normal git fallback command

Re: Gitless: a version control system

#44

Post by drivingmenuts »

tiborsaas wrote: post #21
chvid wrote: post #7

To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If…

FFMPEG is a case of a tool trying to do too much, although, trying to break it out into separate tools would probably be worse.

Re: Gitless: a version control system

#45

Post by loup-vaillant »

cm3 wrote: post #29
masklinn wrote: post #22

Earlier quoted context omitted.

That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.

git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge w…

> You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul.

Darcs patches and git commits are markedly different. A git commit is a snapshot. A Darcs patch is a set of changes (that is, the difference between two snapshot). Any similarity necessarily comes from the ability to recover a snapshot from sets of changes, or deduce a set of changes from two snapshots.

As far as I know, subversion only deals with a linear history. Its way of doing branching and merging is necessarily a kludge on top of this: branching and tagging actually perform a copy. Which explains the original difficulties with merging: a mere copy makes it harder to recover the most recent common ancestor required for a 3-way merge.

Re: Gitless: a version control system

#46

Post by iagooar »

whack wrote: post #30

Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is…

> Both of the solutions above are really cumbersome and prevent easy context switching.

Too frequent context switching might actually be perjudicial for your productivity and health, while increasing stress levels. So git not making it trivial might not be a bad thing, in my opinion.

Re: Gitless: a version control system

#47

Post by zajd »

Certhas wrote: post #36
rplst8 wrote: post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it…

It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool.

Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.

Re: Gitless: a version control system

#48

Post by [deleted] »

chvid wrote: post #7

To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

[deleted]

Re: Gitless: a version control system

#49

Post by zajd »

bluejekyll wrote: post #42
rplst8 wrote: post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous. UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands. Quick examples: 'git reset' vs. 'git revert' and sometime 'git checkout' 'git checkout' vs.…

> What does it say when resolving these problems the easiest thing is to just reclone the remote repo?

It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work.

Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts.

There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool.

> It's crap experience, and all I want to do is code.

- every engineer when first experiencing version control

Re: Gitless: a version control system

#50

Post by achikin »

I don't see any improvement over git. Just another set of commands you'll need to learn from scratch. Some ideas seem not very good, like committing all changed files by default. If you find git commands too verbose - try 'tig' - the ncurses git client, it saves a lot of time and efforts being simple and straightforward at the same time.
Post reply on HN