171–180 of 352 posts
The last addendum reminds me of this inexorably relevant xkcd entry: https://xkcd.com/1597/
I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…
I always use git on the command line. Regarding GUI tools I like to avoid them, for me is too much noise. People get lost most of the time because they don't know what the tool is doing. After all is just one more layer on top of git core tool per se (aka, what you have in command line).
Another option is to use Mercurial with hg-git to GitHub for network effects. I've been doing that for a while for dropbear ssh, it does hit occasional problems but is overall more pleasant than straight git.
If you're concerned about not knowing how to do certain things with git, and understanding at a deeper level how git works, I highly recommend reading Scott Chacon's "Pro Git" book: https://progit.org/
I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…
I think the reason you're disagreeing is that you're not looking at this from a beginner's point of view. Generally there are (roughly) three approaches depending on where you are in your journey from beginner to expert: As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, a…
> As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help.
That's one way to do it, but it's not preferable. I would rather sit the beginner down for at least an hour and go through the basic concepts with them.
I've taught Git to a few people (mostly fellow students or colleagues) and I found that they have a much easier time when they are introduced early on to the basic concepts of Git (the commit graph, and branches/tags as pointers into the graph), they have a much easier time grasping relevant tasks like merge and rebase.
For specific questions (mostly in these "I screw up" moments), a whiteboard is also really helpful to explain them how the two or three magic commands that I tell them are actually fixing things up.
Earlier quoted context omitted.
SVN is a glorified backup - which is basically what you're saying. The SVN UI is just horrid in other dimensions, mainly the "you can't do that at all" one.
sorry... you come across as a git-sheep. (getting down-voted for it, but someone has to say it)
I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…
If you're used to the commands from the keyboard, where you're likely already typing from your editor...can't imagine going back to the GUI.
Earlier quoted context omitted.
Can you justify git>subversion or are you just following the sheep? Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time. BTW: Mercurial still beats them all.
>subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups. For some values of "work". We're using SVN at my new job, with a single trunk branch. Not having the ability to commit locally, and mess around with local branches is a pain in the ass. I found a solution though. I cloned SVN repo using git-svn and now I can make local commits like a pro, and use my be…
(I used git in an cvs-to-svn migration, and stayed since.)
Another option is to use Mercurial with hg-git to GitHub for network effects. I've been doing that for a while for dropbear ssh, it does hit occasional problems but is overall more pleasant than straight git.
I've had problems with tags. What else have caused you problems?
Now you mention it my git tags are out of date...
Earlier quoted context omitted.
> ... that just happened to win the PR battle ... Chalk that up to the power of fashion. Otherwise, people would use an SCM that doesn't destroy their work in the blink of an eye and actually has an API that deserves the name.
The only way to lose work with git is either to (a) not commit it or (b) run a garbage collection.
And (c) lose the entire subtree the repo is in.