ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Heath <doo...@brainfood.com>
Subject Re: move to git.
Date Thu, 23 Apr 2015 16:14:20 GMT

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.


Mime
View raw message