"In the beginning, all you want are results. In the end, all you want is control."
Things I hate about Git (2012)
71–80 of 83 posts
Re: Things I hate about Git (2012)
#72Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand…
Any recommendations for resources on workflows for GIT?
I mostly write ML code as a single author and there's a lot of experimenting going on, so often I sit at the end of the day and write a commit message along the lines of "dicking around" or "updated some files" and feel like I might as well just sync my stuff with Dropbox and not have to worry about all the GIT commands.
Re: Things I hate about Git (2012)
#73Earlier quoted context omitted.
Is hg easier to use? Or any other DVCS not created by such a bad UX practitioner?
I've used both extensively and I think they're virtually identical. Mercurial is a bit nicer because it's written in Python, but git has github going for it. In my experience, once you get into more complicated commands like rebase, I had to read a lot of docs to get things to work in both systems, so I'd say hg is easier to get started with but they're on par overall in terms of complexity. As a sidenote, I think th…
As for Mercurial, I'd this RhodeCode is the company going for it, since we heavily invest in supporting Mercurial in our product.
Re: Things I hate about Git (2012)
#74Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand…
Any recommendations for resources on workflows for GIT? I mostly write ML code as a single author and there's a lot of experimenting going on, so often I sit at the end of the day and write a commit message along the lines of "dicking around" or "updated some files" and feel like I might as well just sync my stuff with Dropbox and not have to worry about all the GIT commands.
This is possible the best overview of a number of tried and tested workflows: https://about.gitlab.com/2014/09/29/gitlab-flow/
They're naturally recommending the GitLab Flow, but a good approach is to read through it and choose what might work for you. The important thing is to keep in mind that there are countless variables that will likely be different for each team -- team size, release schedule, build process, testing etc -- which mean that each team's flow will be somewhat specific.
And as for commit messages, I have developed a system which helps me write more meaningful messages with just a little bit of discipline: instead of summarising what I did, I try to figure how would I give instructions to someone to do the same. So I have things like "refactor MyBigFunction to individual methods" or "change SomeSetting to use float instead of int" or "implement NewClass".
Re: Things I hate about Git (2012)
#75I've been using git for 7 years now. Never used anything else for version control (besides visual source safe which I try to forget). Never felt the need or desire to try anything else.
Genuinely curious as to why I'm getting down voted without explanation for stating my opinion.
I'd not downvote your comment but I'd like to point out you have a biased perception. You clearly state you never used anything else and then you say you never felt the need to use anything else.
It's not unlike a programmer who only knows GWBASIC saying they feel no need for recursion because they never wrote any code that relied on it, or named functions, because subroutines can do that. Or a C programmer who thinks class-based inheritance is superfluous syntactic sugar.
I don't mean it as an offense, mind you, but your lack of experience in DVCSs makes your opinion suspect. Spend a month actually working with Bzr or Mercurial and then, having been exposed to different solutions to the same problem, your opinions will be much richer.
Re: Things I hate about Git (2012)
#76I'm working with a small team that uses CVS and I'm I'm in charge of recommending more modern version control software. I've been learning git since it seems to be the new standard, but after reading this, I don't think we have the time it will take to learn it. Is there another open source vcs that would be a more natural upgrade to CVS?
Specifically for the requirement "Is there another open source vcs that would be a more natural upgrade to CVS": the answer is hands down Subversion for that requirement. If you want distributed or "more modern" but not git, perhaps Mercurial or Bazaar, but they're less prevalent choices.
Thank you! Subversion does seem like a great fit. Mercurial seems like it might be easier to use (Facebook uses their own customized version [1]), but we don't need distributed at this time.
Re: Things I hate about Git (2012)
#77Earlier quoted context omitted.
Genuinely curious as to why I'm getting down voted without explanation for stating my opinion.
I'd not downvote your comment but I'd like to point out you have a biased perception. You clearly state you never used anything else and then you say you never felt the need to use anything else. It's not unlike a programmer who only knows GWBASIC saying they feel no need for recursion because they never wrote any code that relied on it, or named functions, because subroutines can do that. Or a C programmer who think…
My point wasn't that the others weren't good. It was that git has always met all my requirements and I never ran into any issues that made me want to try another solution.
Re: Things I hate about Git (2012)
#78The man pages are one almighty “fuck you”. And there are people I've wanted to strangle for telling me: RTFM. The examples in this article are the crowning example of why their painful death would be well-deserved. There's this thing about bedside manner that technically adept people need to cultivate, just as doctors do. Did I mention I despise cold, snotty doctors too? There's nothing worse than a condescending pri…
Hey there, in reading your comment I feel like you are trying to make some good points, but you're getting downvoted heavily because of the tone and language you're using. Your language feels really personal and negative, like you decided just to go off on a rant. That's generally discouraged on HN - but there are always exceptions, especially if it's a topic or moment in time when a rant is actually called for. The…
[deleted]
Re: Things I hate about Git (2012)
#79The primary goal of software development is to solve problems, not to perform elaborate rituals with version control systems or other tools (IDE's, Makefiles, etc.).
The primary function of a version control system is to recover earlier versions of the software in rare error situations where it is hard to figure out what has gone wrong. Backup to something that worked and identify the change that caused the problem.
For most software developers, a version control system should appear very simple so they can focus on solving the end user or customer or their own problem.
check-in o if the file is new for the project, the VCS should ask do you want to add this to the project? o check-in checks everything in the folder (directory) all at once. If the folder is new: do you want to add this folder to the project?
checkout [ ] o checkout checks out the most recent version of the file . o checkout checks out the most recent versions of the files in and its sub-folders o checkout checks out the most recent version of the entire project. The project can just be the specification of the top level folder! o is an easy, human readable/understandable specification of the earlier version, a file sequence number such as 1.43, a folder or module sequence number, or an overall project sequence number (all generated automatically by the VCS -- at least by default).
All sorts of pain and suffering is avoided by dividing the project into folders for different components and contributors and/or teams. These check-in/check-out their folder independently.
For a single developer or a team in the same office or building or for that matter office park with a fast network, that is all you need. For remote collaboration -- such as China and USA -- then you might need one or two command to push/pull the code to remote repositories; this too should be simple!
KISS (Keep It Simple Stupid)
Re: Things I hate about Git (2012)
#80Earlier quoted context omitted.
There are two categories of possible criticisms: the model, and the implementation. Fixing the implementation means changing code, improving APIs (e.g. local/remote branch delete). Fixing the model means finding an everything different system. Yes, a graph-based VCS more complicated than a linear one. But it also matches realities of collaborative software development. And reality is complicated. As you might guess,…
My problem is not the theory. That's easy to learn. My problem is implementation.
Ah, the easy one then.
Which DVCS implementation do you like the most?