On 04/23/2015 04:22 AM, Scott Gray wrote:
I'm just saying my current project has been using it for 18 months and it's
been a long time now since we've "lost" any changes. This is 15-30 devs
that were all new to git.
In my experience most issues come from:
- Reverting merge commits and picking the wrong mainline
Yeah, I've had issues here too. I generally don't do git reset HEAD^
when it's a merge, instead I do "git branch save-current; git checkout
save-current; git branch -F master $HASH; git checkout master". If all
went well, then I can delete that save-current branch, and continue on.
- Pushing to the wrong remote branch
If caught before anyone else pulls, git push +local-ref:remote-ref can fix.
- Incorrectly handling conflicts
This single item was a cause for much head-ache, at least for me. Merge
conflicts, and rebase conflicts, are given different markup as well,
which doesn't help the situation.
Conflicts happen with both git and svn based workflows. If you attempt
to commit with svn, and someone else modified the files first, svn says
no. So then you pull in the upstream changes, and attempt to fix
locally. It's still possible to pick the wrong code. The issue now is
that when you commit back to svn, it's not recorded as a merge, there is
no special text saying which files had conflict, so you are left to
assume the developer meant to change the code.
- Trying to force pushes
Also related, is pushing to a remote repo, that is also checked out(aka,
has a $working_directory), and the remote branch being pushed to is what
is checked out.
The most important thing is to stop when you mess something up and seek
help. Trying to fix things on the remote repo without understanding what
has gone wrong can make a bigger mess.
When I had problems earlier on, I got very frustrated. After a bit, I
realized I could abuse the garbage-collection nature of git, and create
a temporary branch against HEAD, before I changed anything. Git would
ensure that the content referenced by that branch would stay around,
while I made mistakes.
Eventually, I started to make use of reflog directly, and no longer need
that temporary branch.
On second thought I'm almost hesitant to say git would be a good idea for
OFBiz because we have so many committers that would have access to the
master branch without an adequate level of git experience. I can imagine
the mess someone might make trying to rewrite history on the remote repo.
The linux-kernel does not have all developers world-wide pushing to the
single repo that is responsible for producing the tarballs hosted at
kernel.org. Only one guy does that, Linus Torvalds.
Implicit in a svn->git switch, would be finding someone willing to be
that person. Which, is a whole other thread of discussion.
Regardless, I highly recommend git-svn for basic local development
or forking the git mirror if you want to go deeper.
I've been saying that for years.
