I am doing a bit of research and I could really use some input. I would like to know more about the common mistakes that people make when using a version control system such as svn or git (and please do not say “they use foo” or “they do not rtfm”).
Have you ever made such a mistake? If so, what was it and how did you fix it?
Mistake nr 1. Commited a file/change which shouldn’t be in that special commit.
Mistake nr2. wrong commit message
Mistake nr3 commited to wrong branch
Mistake nr4 tagged wrong commit.
Everything fixable if you know it before publishing (in dvcs). For example using git-rebase -i, git-reset, git-cherry-pick.git-commit –amend
Almost every vcs I’ve used I’ve managed to destroy some valuable data using a vcs command. Usually it takes some experience and making few mistakes before you know which commands can bite you.
Anything else is recoverable.
Most common mistake ever: forgetting to ’svn add’ a file before committing code that depends on it.
Mistake I learned to avoid: using ’svn commit -m “message”‘ for short messages. Reason why this is a mistake: I run unit tests from a shell using some variation of ./test, and I do this a lot, so my fingers are used to pressing to repeat a test run. When you do that in the wrong terminal by accident, it’s too easy to accidentally commit, if the previous command was ’svn commit -m’. svn commit without the -m is easily abortable.
Announcing that they’ve fixed something but forgetting to actually push the changes to a public location..
Not sure that these are “common”, but..
Mistake: committing a huge file for whatever reason. At my last job someone committed a test database for a test case, and getting it out was pretty nightmarish because git hangs on to destroyed commits until you clear them from the reflog.
Mistake: once I accidentally committed an entire git repository to another git project. Git seemed to cope OK on my machine, but broke hard on an older version on the server. Similar to the above.
Mistake: git in particular has a lot of gotchas. I personally always get the argument order wrong when using git rebase. To rebase master onto origin/master is git checkout master; git rebase origin/master, but I always try things like git rebase master origin/master, git rebase master –onto origin/master. I often get git checkout REV confused with git rebase REV. Similarly with git submodules I confuse git submodule sync with git submodule update. When trying to update a version of submodules, I often add submodule/ instead of submodule, and inadvertently screwing up the state of the submodule. I often do “git stash” meaning to check the status of the stash but instead storing stuff into the stash.
Mistake: I often commit debugging output or temporary change-configuration-for-testing-purposes code.
Ethan
Using ‘git commit -a –amend’ instead of ‘git add’ during a git rebase after resolving a merge conflict.
Can be resolved by either ‘git rebase –abort’ if you find out about it during the rebase, or ‘git reset –hard ‘ if you find out too late. The “” can be found using the obscure but extremely useful command ‘git reflog’.
Cheers,
FJP
With svn and commit with emacs+vc
. emacs+vc did not support changesets until recently
http://svn.haxx.se/dev/archive-2007-10/0493.shtml
(emacs 23 release is 2009, emacs 22 probably probably do not have a fixed version)
. so emacs+vc commit is a single file instead of a changeset
Mistake: the mistake is vc (should not say it supports svn if it does not support changesets).
Solution: do not use emacs+vc, do not trust vc anymore.
Use svn commit with SVN_EDITOR=emacs instead.
Repair: additionnal commit or svn command to revert commit (svn merge or svnadmin).
@Marius Gedminas: I use screen, and only ever commit from window number 1, thus avoiding the bash history problem ;) (but then, sourceforge is so slow that you always have time to Control-C to abort…)
A “mistake” I did early on: I was mostly the only one working in this one directory, and whenever someone did a minor one-line change before I’d commited, I was so scared svn wouldn’t be able to deal with it, I’d rename my file, svn up, and manually merge… I should’ve just done the “stupid” thing and typed “svn up” – I almost never have a merge conflict anyway.
I can’t say I trust emacs-vc much either for committing, although it is _very_ handy to be able to do a vc-diff straight from emacs =D
On SVN do plan the repository layout before doing the initial svn import/commit. When the repo grows over time the branches/tags/trunk scheme inside a subfolder is really helpful.
The most common mistake is using git. Unfortunately it is so common nowadays.
Using the 1.5 svn client which supports the “depth” checkout / update feature, in combination with a 1.4 svn server, which does not, on a huge repository. This leads to an equally long checkout time as without the depth option, because the server will send everything, which the client then filters.
Fix: After waiting for 5 minutes and realizing the mistake, either break it off and do a more sensible checkout (smaller branch or folder), or just let it run and hope it will finish soon.
A common mistake I see a lot for Subversion is when people recursively copy a directory under revision control to a new directory in the project and then start editing that copy as if it’s actually a copy. It’s not. The .svn meta-data directory is included in the copy, so to Subversion, they’re both exactly the same directory. Then you do a commit, and all hell breaks loose.
Make two or more changes which are conceptually different (e.g. fix a bug you discover whilst working on something else) and commit them as a lump, rather than separately.
Forgetting half of the stuff that you actually commited in the commit message… Happened a few times to me.
Commit forgetting to add new files (git –amend helps with this, with subversion you’re stuck; occasionally, I realise after pushing, which is too late even for git).
Forget to tag a release, then it takes a bit to find out what was the right revision to tag.
Fixing minor bugs in a feature branch I’m working on instead of the mainline, then having to extract the fix only and move it back to the main line.
If I notice formatting issues in code, I tend to leave it there because I forget about them when it would be the right time to do a formatting-only commit.
As someone else said, lumping unrelated stuff into commits, which SVN and CVS greatly amplify by not allowing to separate committing and pushing. I really appreciate the Git index, even though it throws some people off at first. `git add -p` is simply great, and the ability to reorder commits with `git rebase -i` prior to publishing them encourages frequent, small commits, which can later be grouped in sensible ways.
Many other mistakes stem from people using Git, thinking it’s just another VCS, when in fact it’s more of a filesystem. That, and understanding what exactly is a commit (including the hash sum) is paramount in being able to use tools like `git rebase` correctly. And to be able to understand the consequences of pushing or otherwise publishing commits.
Committing a batch of files in git and missing one. Then pushing to a remote repo.
If it was before I pushed, I could commit the missed file and squash the commits. Once pushed, it’s a pain and not always possible especially if you’re collaborating.
About git:
Forgetting to set name and email thus committing as root or something else that is not correct. Correcting it requires rewriting the history.
Committing something at home, realizing when you get to work that you forgot to push it.
Someone on our team recently published and open-sourced our user credentials (Yes, I know. Sad, but nevertheless true.) while putting our code base on Launchpad.
Solution: Changing credentials, moving our credentials out of the core code and pushing the changes.
i like your titles; blogtitles, headings for texts, your nick. is it clever, or are you alpha male?
Forgetting a pattern in .gitignore. If there are multiple matches all over the place, it’s difficult to recover from.
As someone else said, losing track of what you’re doing, and committing a bug fix with new functionality.