Re: Git workflow discussion

[Jacques Le Roux <ja...@les7arts.com>]

One think I did, but it's not possible with apache.org's own git as it's currently organised, is to copy the .svn directory inside the git repository. 
Then you have best of both world, quite convenient, I found not drawbacks so far.

Jacques

Le 27/06/2014 01:26, Adam Heath a écrit :
> That's the problem, using git for just this one problem.
>
> If you do things thru git, then eventually multiple people will have committed code into this new feature branch.  After some amount of time, the 
> branch will be done, and it'll be time to add it back to subversion.
>
> When this occurs, the author field in git will be thrown away, and whoever is doing the git-svn dcoommit will become the author; this is bad in 
> apache land, as now the CLA comes into play.  Aka, who authored the code?
>
> It will not be possible to do a git merge of the branch into a git-svn tracking branch, as then there will be a merge commit, and that will make 
> git-svn barf.
>
> If the merged branch itself has merge commits(which it probably will), then the previous item is even more difficult.
>
> It's possible to squash the entire new branch, when adding it to the git-svn tracking branch, but that will also loose any authorship on the changes.
>
> ps: This has nothing to do with github, apache.org's own git, or any place else that hosts git repositories.  It's a fundamental problem with the 
> way git and svn manage changesets.
>
> pps: I just recently found this: If you cherry pick, your branch model is wrong <http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html>
>
> On 06/26/2014 03:32 PM, Jacques Le Roux wrote:
>> I was only suggesting for the problem at hand...
>>
>> Jacques
>
>

--