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

131–140 of 390 posts

Re: Gitless: a version control system

#131

Post by moonmusick »

gcb0 wrote: post #78
achikin wrote: post #50

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.

wildly guessing from the clone to checkout name change, it probably started as a git for subversion users?

Removal of the staging area seems like a move in this direction too.

Re: Gitless: a version control system

#132

Post by Pxtl »

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.

My pet peeve is how many steps it is to resolve a merge conflict on a branch I've pushed when were using controlled merges into dev branch. Stash or commit my work on the new feature branch I've started, then switch to dev, then pull, then switch back to my old conflicty feature branch, then merge from dev and resolve the conflicts, then push, then go to the server and complete the merge, then switch back to my old stashed branch so I can get back to work.

Re: Gitless: a version control system

#133

Post by arielb1 »

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…

gitless gives each branch its own separate worktree (see `git worktree`), and saves/restores them when you switch branches.

Also, there's no harm in creating "temp" commits. If you are having multiple branches, you probably want to give your current state a name - which is what a "temp" commit is.

Re: Gitless: a version control system

#134

Post by twic »

chousuke wrote: post #75
sametmax wrote: post #54

Earlier quoted context omitted.

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…

Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users. The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice. EDIT: editing this to expand on why I think the index is essential: Being able to use the VCS tool to fashion a commit se…

> The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice.

I can't disagree more. The index is entirely unnecessary, as umpty thousands of happy Mercurial users can testify.

> Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to

... record states which never existed, and haven't been tested. It's an antipattern. If you are doing this a lot, you are doing development wrong. In the rare occasions where you do want to do it, Gitless and Mercurial, like every other source control tool, give you a way to fine-tune the set of files which go into the commit. They don't need an index to do it.

> Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece-by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc.

Again, you don't need the index for this, you need to track conflict state. As Mercurial does:

https://www.mercurial-scm.org/wiki/TutorialConflict

> I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed?

This is a very interesting perspective! It doesn't immediately sound immensely practical, though. Say i want to test a fraction of the current working tree's state; i commit, and then ... what? Create a fresh clone of that state somewhere so that i can run tests on it?

Re: Gitless: a version control system

#135

Post by Pxtl »

ms4720 wrote: post #58
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…

Or the original syntax for tar

Obligatorily: https://m.xkcd.com/1168/

Re: Gitless: a version control system

#136

Post by pmoriarty »

wtetzner wrote: post #100
sametmax wrote: post #54

Earlier quoted context omitted.

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.

This really depends on how frequently and how deeply you use git. If you're using many of its advanced features a lot, then yes, you'll probably learn it well just by doing that.

But many people don't use it very deeply most of the time, and only occasionally have need to do something out of the ordinary, at which point it can be a pain to discover the Right Way to do what they need, and easy to shoot themselves in the foot.

Re: Gitless: a version control system

#137

Post by qznc »

KKKKkkkk1 wrote: post #112
heisenbit wrote: post #65

Git is powerful. While the underlying architecture has beautifully simple aspects arguing that the complexity of the git tool-chain is simple is similar to arguing that TeX is simple as it is written in a simple language. Git is managing trees of file-sets in a distributed manner. It took many generations of configuration management systems to get there. Git is bottom up. Understand the inner workings and you know wh…

As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like git remote add mothership ssh://foo@bar.baz git push mothership in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where th…

Being distributed is essential for gits design. It explains why there are strange sha1 ids instead of incremental revision numbers like with svn, for example.

Re: Gitless: a version control system

#138

Post by kasey_junk »

musicnarcoman wrote: post #130
kasey_junk wrote: post #37

Earlier quoted context omitted.

When people suggest that git is great I lose a little faith in them as a programmer cause it indicates to me they don't have much breadth if experience with source control systems & they are too intellectually lazy to investigate alternatives. Could just be my biases I guess.

So, what alternatives are you suggesting? I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git. Granted, Git may not be great, but it is still my first choice.

Hg is a very similar model to git but doesn't have the cli problems it does.

Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does.

But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting and is GUI oriented which some people like.

Re: Gitless: a version control system

#139

Post by norswap »

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…

I think git's concepts are simple and worth learning (unlike what the gitless people said).

That being said, the command line interface is "meh" at best and full of byzantine options.

Re: Gitless: a version control system

#140

Post by buerkle »

Pxtl wrote: post #132
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.

My pet peeve is how many steps it is to resolve a merge conflict on a branch I've pushed when were using controlled merges into dev branch. Stash or commit my work on the new feature branch I've started, then switch to dev, then pull, then switch back to my old conflicty feature branch, then merge from dev and resolve the conflicts, then push, then go to the server and complete the merge, then switch back to my old s…

No need to switch to dev:

  git co feature_branch
  git fetch origin dev
  git merge FETCH_HEAD
Post reply on HN