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

91–100 of 390 posts

Re: Gitless: a version control system

#91

Post by kowdermeister »

nerdponx wrote: post #60
tiborsaas wrote: post #21

Earlier quoted context omitted.

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…

You don't think that the "git push" output includes a lot of verbose tehnical junk not meaningful to most users?

Not really, while I'm not sure what 50% of that means, it's just reassuring that after push I see that 5 lines and a percentage counter. I can also copy the commit hash and refer to it in a ticket.

Re: Gitless: a version control system

#92

Post by kazinator »

Git needs the parent pointer equivalent of NIL.

Whenever I start a blank new repo nowadays, I do a

  git commit --allow-empty -m "NIL"
See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two commits: it refers to the parent, but since the parent is the excluded delimiting endpoint you can think of that 1 as being the number of commits being rewritten.

If all you have is a single commit with no parent, you cannot rebase it.

If you have NIL there, it takes the HEAD^ reference; no problem.

Essentially, git is a list manipulation system whose use cases fail when operations span the entire list, oops. You can tell it was designed by someone who never took a Lisp or Scheme course (or forgot all of it). Imagine if (remove 3 '(1 2 3)) failed because the suffix (3) has no CDR, haha. "Sorry, you can't "rebase" your (1 2 3) to (1 2) because 3 is the "root commit"! Just scrap the whole thing and build (1 2) in its place."

Re: Gitless: a version control system

#93

Post by dahart »

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…

> With git, I'm forced to either make an extraneous commit...

You only need to commit or stash if there are conflicts, and many time there aren't, so you can first try to switch branches without stashing.

> The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch

I started a big ol thread on stash yesterday, but there are a bunch of safer alternatives to stash. You never have to clutter history, you can always move things around and still keep it clean. Problem with stash is it circumvents git's normal systems, so it's a little dangerous (which the stash man page mentions.)

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

If there are conflicts, you could do this instead:

  $ git checkout -b work
  $ git commit -am "WIP"
  $ git checkout another_branch
  $ git cherry-pick work
  $ git branch -D work
Exact same effect as stash with no clutter left over in the history, and much safer. The advantage here is your changes are put multiple places and referenced by git, so if anything ever goes wrong it's in the recent reflog. With stash, if you have problems, your only option is to use fsck.

Given that the whole point of gitless is to avoid super confusing and intimidating commands like fsck, especially for beginners, it makes sense to me they chose not to include stash.

Re: Gitless: a version control system

#94

Post by leshow »

wreft wrote: post #70
iagooar wrote: post #46

Earlier quoted context omitted.

> 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.

I don't think perjudicial is a word.

you are wrong

Re: Gitless: a version control system

#95

Post by wtetzner »

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 think part of the issue here is that the actions one wants to take isn't the same for everyone.

For example, I basically never want to commit and then immediately push to some server.

And for add, then commit, you can just do git commit -a.

But being able to add and commit changes separately can be very useful.

Re: Gitless: a version control system

#96

Post by __david__ »

arielb1 wrote: post #39
JohnKacz wrote: post #23

Earlier quoted context omitted.

It's not a quick answer but they cover this in the Gitless vs. Git section.[0] One main difference seems to be with branching "The main thing to understand is that in Gitless a branch is a completely independent line of development." [0] http://gitless.com/#vs

By that, AFAICT they mean "a branch, in addition to being a commit pointer, contains all the files in the working directory".

And also the current merge state (though I'm not sure why I'd ever want to context switch away from a merge conflict resolution).

Re: Gitless: a version control system

#97

Post by zajd »

philjohn wrote: post #86
jstimpfle wrote: post #13

Earlier quoted context omitted.

The CLI is indeed hard to learn. But the simplicity of git is not using it, it's its internal structures: http://eagain.net/articles/git-for-computer-scientists/ If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a"). What people complain about is often the CLI's inconsistency. For examp…

You shouldn't have to learn how the data structures of the tool work beneath the surface to successfully know how to use a tool.

You don't have to. The difference with git is that it's even possible.

Re: Gitless: a version control system

#98

Post by jstimpfle »

philjohn wrote: post #86
jstimpfle wrote: post #13

Earlier quoted context omitted.

The CLI is indeed hard to learn. But the simplicity of git is not using it, it's its internal structures: http://eagain.net/articles/git-for-computer-scientists/ If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a"). What people complain about is often the CLI's inconsistency. For examp…

You shouldn't have to learn how the data structures of the tool work beneath the surface to successfully know how to use a tool.

I think you should learn them, but ideally it should be obvious from using a tool what its internal data structures are. For persistent data structures simplicity, transparency and stability are very important.

Re: Gitless: a version control system

#99

Post by fail2fail2ban »

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…

Git works really well but I've had some exposure to Canonical's Bazaar (bzr) in the past and at a high level; I'd say it's easier to not shoot yourself in the foot with bzr while still accomplishing pretty much what Git does. I'm not knocking Git at all, just bringing some background on an alternative tool I'd say is in the same class.

Re: Gitless: a version control system

#100

Post by wtetzner »

sametmax wrote: post #54
tiborsaas wrote: post #21

Earlier quoted context omitted.

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…

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the opt…

The thing is, once you learn the UI, it's very productive. I'm not sure we should be optimizing for ease of learning. People are only beginners for a little while. They spend much more time as intermediate/advanced users.
Post reply on HN