191–200 of 390 posts
I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it? Convention over configuration?
It could just be misspelled. I've accidentally created quite a few misspelled branches in my time. E.g.: "bug-fix" vs "bug_fix" vs "bugfix".
I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it? Convention over configuration?
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 don't think those commands are remotely sufficient to work with git. You're forgetting about merging, traversing history, branch creation, remotes, grokking the staging area, etc. I'm sure I'm missing a lot as well, because those of us who have worked with git for a long time take these things for granted. And it does frustrate me that it's so complex, because Mercurial shows us it doesn't have to be this way. Unfo…
They are certainly not enough to work with Git for your whole career :)
Earlier quoted context omitted.
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…
Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it.
I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it? Convention over configuration?
Yeah but then there's the issue of simple misspellings. Perhaps switching and creating should be separate commands.
Earlier quoted context omitted.
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…
"Distributed" means something other than what you think it does. Dropbox is not a distributed system. In fact it is a good example of a centralised system.
"Decentralized" is associated with systems without a central point of failure or control.
Git qualifies as both, and Dropbox only qualifies as distributed.
Earlier quoted context omitted.
I don't think those commands are remotely sufficient to work with git. You're forgetting about merging, traversing history, branch creation, remotes, grokking the staging area, etc. I'm sure I'm missing a lot as well, because those of us who have worked with git for a long time take these things for granted. And it does frustrate me that it's so complex, because Mercurial shows us it doesn't have to be this way. Unfo…
The commands are enough to get through the first month of using git for your own project. They are certainly not enough to work with Git for your whole career :)
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…
git checkout // throw away all changes since the last commit (one file)
git reset --hard // throw away all changes since the last commit (all files)
[NOTE: these two commands actually don't do quite the same thing, which is part of the problem.]
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'm quite comfortable with git now but I also remember what a pain it was to learn. This included making mistakes and diving deep into git's internals to recover. The question is whether we should make things easier for new versus experienced developers? If switching to gitless became a thing I'd have to learn something new, but if it made things significantly easier for beginners, maybe my personal inconvenience isn…
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.
Or pijul. https://pijul.org/