31–40 of 390 posts
I really wish Git came with some simplified version of dependency management, subrepo and subtree just don't cut it.
First time in a while zooming caused a web site to have its text overlap with itself.
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 is powerful. And also seems to have a powerfully elitist community around it, as evidenced from your comment.
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.
git commit -am "message".
Will add and commit. Pushing should be separate for a distributed vc.
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.
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…
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 has become ubiquitous and now we all have to live with it, programmers or not.
In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state.
And the design of the interface _is_ atrocious:
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…
Could just be my biases I guess.
Then, many clients have tried to hide git complexity under some friendly UI. They might be productive in some cases (e.g: to manage your stage area), but for others at some moment they will end up confused and not knowing what to do.
> Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. ... changes them how exactly? A big part of what I like about Git is that its underlying concepts are simple and clear and feel like the right building blocks for version control. So I'm curious to know how they believe they can improve on that.
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
Earlier quoted context omitted.
But why should each developer need to do that on each system they use? The whole point of this tool is to add a common set of things on top of git.
I don't see why each developer should. I'm perfectly fine with commands as they are by default. I'm just saying that if your problem is that you need to enter multiple commands instead of one, then instead of new VCS you may as well just put a config file in your home dir.
You can still use all git commands.