www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Lyubimov <dlie...@gmail.com>
Subject Re: Current use of GitHub
Date Tue, 05 Apr 2011 16:24:46 GMT
Just posted somewhat hasty write-up on my approach:
http://weatheringthrutechdays.blogspot.com/2011/04/git-github-and-committing-to-asf-svn.html

seems to work so far.

On Mon, Apr 4, 2011 at 3:04 PM, Dmitriy Lyubimov <dlieu.7@gmail.com> wrote:
> PS since you use 3-way git merge from svn trunk branch onto feature1,
> git should memorize the merges you already resolved and your base for
> 3base merge should be updated as a result so should not continuously
> resolve conflicts you've already done.
>
> The only nasty thing that may pop up continuously in my experience in
> git is renaming/moving conflicts, i did not quite get a good handle on
> those one. Since git does not 'memorize' the fact of moving, but only
> 'detects'  them, sometimes they just keep popping up but that doesn't
> have anything to do with svn integration.:(
>
> -d
>
> On Mon, Apr 4, 2011 at 2:56 PM, Dmitriy Lyubimov <dlieu.7@gmail.com> wrote:
>> On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <david_jencks@yahoo.com> wrote:
>>> Hi Dmitriy,
>>>
>>> Everything you say makes sense, but IIUC the workflow you propose does not allow
me to bring the svn changes at apache into my local feature1 branch.  IIUC the svn changes
are only pulled into my local master and I'll have to resolve all the merge conflicts at once
right before I dcommit to svn.  Unfortunately this doesn't work for me for large-scale refactorings
where I need to keep current with svn changes over the several weeks I'm working.
>>
>>
>> David, that's easy: keep your svn trunk up-to-date by running 'git svn
>> rebase' on it. Since you presumably haven't committed any changes onto
>> trunk that you haven't pushed to svn, there should be no conflicts.
>>
>> Once you sync'd up your local trunk branch with svn , just merge it
>> into feature 1 using your regular git merge and then push it up to
>> github.
>>
>> I.e. on trunk
>> git checkout trunk
>> git svn rebase
>>
>> on feature 1:
>> git checkout feature1
>> git pull  (-- make sure you are in sync with remote github if needed)
>>
>> git merge trunk (-- now your svn commit history is locally on feature1)
>> git push (-- fast-forward remote github feature1 history to include
>> svn commits now)
>>
>> The merging and collaboration is really no specific to svn
>> integration. The only thing that specific  to svn integration is how
>> you set up your trunk for svn rebases and how you squash feature1
>> commit history onto it before pushing into svn (but even that is just
>> a git feature).
>>
>>
>>
>>
>>>
>>> I think that between your and Paul's responses my theory about why I can't keep
my github branch up to date (due to git svn rebase) is correct :-)
>>>
>>> many thanks!
>>> david jencks
>>>
>>> On Apr 4, 2011, at 2:19 PM, Dmitriy Lyubimov wrote:
>>>
>>>> the idea is to work with 2 branches: your svn trunk branch and the
>>>> issue branch.
>>>>
>>>> You only apply changes and commit to issue branch (in your case it
>>>> seems to be feature1). You enable github collaboration by
>>>> syncing it up with remote github branch (and set your local branch to
>>>> track it for convenience. Assuming you've been on your svn trunk
>>>> branch when
>>>> you started your sequence, you've done it here just that :
>>>>
>>>>>
>>>>> git remote add github git@github.com....
>>>>> git branch feature1
>>>>> git checkout feature1
>>>>
>>>> Now you can collaborate on feature1 branch in github with other people
>>>> via fork/pull requests as usual.
>>>>
>>>>
>>>>>
>>>>> //do some work locally, committing to local git.
>>>>>
>>>>> git svn rebase // pull in other changes from apache
>>>>
>>>> are you still on feature1 branch? if yes, you don't want to do svn
>>>> rebases to it. You should only do it to your svn trunk branch (which
>>>> you presumably haven't even pushed to github -- but you may if you
>>>> want.)
>>>> That's the problem, i think svn rebase will override your job.
>>>>
>>>>> git push -u github //I don't remember the exact command I used, but it
did get my local changes to a github branch named feature1
>>>>
>>>>
>>>>
>>>> here is the sequence i am proposing:
>>>>
>>>> suppose you are on your svn branch that you instantiated via cloning
>>>> apache git and then running git svn init ... per that apache wiki you
>>>> mentioned.
>>>>
>>>> do this :
>>>>
>>>> git remote add github git@github...
>>>> git checkout -b feature1 // this is equivalent to git branch + git
>>>> checkout steps you did
>>>>
>>>> git push -u github  // push feature1 branch marker to gtihub.
>>>>
>>>> now you can collaborate on feature1.
>>>> E.g. try to change something locally . To propagate your change to github,
do
>>>>
>>>> git commit -a -m "my feature1 change"
>>>> git push (pushes commit to github. Since you already set the github
>>>> tracking for your local feature1 branch, you can use default form to
>>>> push without more params while on the branch).
>>>>
>>>> Now your trunk diverged from both local and github's copies of 'feature1'.
>>>>
>>>> Suppose you or someone else did a series of commits on feature1 in
>>>> github's vesion of feature1 and you now wish to commit it back to svn
>>>> .
>>>> so, what you want to do is this:
>>>>
>>>> git checkout feature1 (-- on local feature1)
>>>> git pull (-- make sure your local feature1 branch grabbed all the
>>>> changes in the github branch 'feature1'
>>>>
>>>> -- now merge to the local trunk branch squashing the feature1 commit
>>>> history into 1 commit:
>>>> git checkout trunk
>>>> git svn rebase (-- make sure local trunk branch is up to date, an
>>>> git-svn equivalent of 'git pull', sort of)
>>>>
>>>> -- this is important part
>>>> git merge feature1 --squash
>>>>
>>>> this will leave your local branch with all cumulative changs of
>>>> feature1 applied onto local tree but not comitting them.
>>>> It may optionally say you have conflicts, if so, run 'git mergetool'
>>>> to resolve manually.
>>>>
>>>> git commit -a -m "feature1 patch" -- this will create a single commit
>>>> in your local trunk branch and that's exactly what is going to be
>>>> pushed into svn.
>>>>
>>>> you can double-check the diff at this point to see exactly what you
>>>> have applied by running
>>>> git log -p -1
>>>>
>>>> to replicate that commit to svn, just run
>>>> git svn dcommit
>>>>
>>>> (they recommend to run 'git svn dcommit --no-rebase for european users
>>>> because of delay in replicating between svn hosts, and run rebase
>>>> separately several seconds after).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I now can't push my local changes to the same feature1 github branch.
 My theory about why is that I've reordered history on my local git compared to the existing
github branch.  I have no way to verify this :-).  I guess I could create a new github branch
every time I push???
>>>>
>>>> most likely because you've run some svn rebases, you history on
>>>> feature1 can't be fast-forwarded to the github's without rewriting it.
>>>> Don run git-svn on your feature 1 branch ever.
>>>>
>>>>
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> -----
>>>>>>>
>>>>>>> git svn rebase is a major pain.  I don't really understand why
but it looks to me like I have to keep resolving the same merge conflicts.  I'm also not
completely convinced that all my local work gets preserved through the merge conflict resolution.
>>>>>>>
>>>>>>> I used to use svn branches for ongoing work but with the svn
version that tracks merges I've given up on this because of the enormous volume of noise in
an svn merge commit.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Apr 3, 2011, at 10:17 PM, David Blevins wrote:
>>>>>>>
>>>>>>>> I know a few of us use Git for Apache work.  Feel encouraged
to lend some feedback to infra.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>>> Resent-From: <dblevins@visi.com>
>>>>>>>>> From: "Gav..." <gavin@16degrees.com.au>
>>>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>>>> To: <infrastructure-dev@apache.org>
>>>>>>>>> Subject: Current use of GitHub
>>>>>>>>> Reply-To: infrastructure-dev@apache.org
>>>>>>>>>
>>>>>>>>> I'm trying to understand the _current_ workflows of those
ASF committers
>>>>>>>>> using Git and how the ASF GitHub mirrors tie into that
- if at all.
>>>>>>>>>
>>>>>>>>> A fair few projects requested ASF git mirrors and also
requested mirrors of
>>>>>>>>> that on GitHub (that 2nd request is now standard with
the 1st)
>>>>>>>>>
>>>>>>>>> So far , from projects I've browsed on GitHub, I see
a few forks here and
>>>>>>>>> there and a few Pull requests here and there.
>>>>>>>>> That is where it gets fuzzy for me. Obviously, no-one
can actually pull in
>>>>>>>>> those pull requests into the Apache/$project repo mirror,
so
>>>>>>>>> how are committers applying those pull requests? Are
they pulling them into
>>>>>>>>> their own copies of the mirror, converting them into
a patch
>>>>>>>>> that svn understands and then applying, if so, how? If
not, how else?
>>>>>>>>>
>>>>>>>>> Also, apart from Github, how else are Git only users
providing patches to
>>>>>>>>> projects, which patch programs are in use, and of those
which
>>>>>>>>> are most used by those projects/committers that need
to apply them.
>>>>>>>>>
>>>>>>>>> For those of you that are committers and have direct
access to svn, but are
>>>>>>>>> preferring to use Git before then committing your work
to svn,
>>>>>>>>> what is your workflow and tools used (whether or not
it involves GitHub)
>>>>>>>>>
>>>>>>>>> No deviating into what could happen or what would be
a good idea please yet,
>>>>>>>>> this is just a survey on what people are currently actually
>>>>>>>>> doing to incorporate Git into their workflows and how
we then get those
>>>>>>>>> applied.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Gav...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>

Mime
View raw message