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 Mon, 04 Apr 2011 21:56:18 GMT
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