Fwd: Current use of GitHub

[David Blevins <da...@gmail.com>]

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: <db...@visi.com>
> From: "Gav..." <ga...@16degrees.com.au>
> Date: April 2, 2011 11:45:10 PM PDT
> To: <in...@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...
> 
> 
> 

Fwd: Current use of GitHub

[David Jencks <da...@yahoo.com>]

Not sure if all the heavy git users are on infrastructure-dev...

david jencks

Begin forwarded message:

> From: David Blevins <da...@gmail.com>
> Date: April 3, 2011 10:17:01 PM PDT
> To: dev@geronimo.apache.org
> Subject: Fwd: Current use of GitHub
> Reply-To: dev@geronimo.apache.org
> 
> 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: <db...@visi.com>
>> From: "Gav..." <ga...@16degrees.com.au>
>> Date: April 2, 2011 11:45:10 PM PDT
>> To: <in...@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...
>> 
>> 
>> 
> 

Re: Current use of GitHub

[Steve Loughran <st...@apache.org>]

On 15/04/11 07:52, Guillaume Nodet wrote:
> Since the git mirrors are available at the ASF, I'm now exclusively
> using git-svn
> unless I need to do a release in which case
> I need to revert back to svn for maven to be able to do the release.
> For branches and patches, it's easy to add remote a git remote repository to
> your local repo pointing to a fork, so that you can cherry-pick or merge from a
> fork on github and then svn dcommit into the svn tree at the ASF.
> Git really consider the git-svn branch as a real branch, so there's no
> problem here.
>
> Also, in Karaf for example, we're maintaining bug fix branches.  Those
> are stored
> in svn as real branches, but also available in git-svn as git branches, so that
> cherry-picking and backporting fixes is way easier than using pure svn.
>
> However, not having a pure git master repository has some limitations,
> mostly the fact
> that we can't really use a branch-per-bug workflow such as the one described at
>      http://nvie.com/posts/a-successful-git-branching-model/
> Being able to support that would be a big win for us.

the MRUnit test tool -moved from Hadoop/contrib to incubation- are 
interested in using Git if it were hosted locally, as a precursor to 
seeing how well it works for Hadoop development in general, initially 
for code (and letting reviewers merge in branches published to github), 
playing with Gerrit as and when its possible.

Is there any experimental git "repository" in apache they could start with?

Re: Current use of GitHub

[Guillaume Nodet <gn...@gmail.com>]

Since the git mirrors are available at the ASF, I'm now exclusively
using git-svn
unless I need to do a release in which case
I need to revert back to svn for maven to be able to do the release.
For branches and patches, it's easy to add remote a git remote repository to
your local repo pointing to a fork, so that you can cherry-pick or merge from a
fork on github and then svn dcommit into the svn tree at the ASF.
Git really consider the git-svn branch as a real branch, so there's no
problem here.

Also, in Karaf for example, we're maintaining bug fix branches.  Those
are stored
in svn as real branches, but also available in git-svn as git branches, so that
cherry-picking and backporting fixes is way easier than using pure svn.

However, not having a pure git master repository has some limitations,
mostly the fact
that we can't really use a branch-per-bug workflow such as the one described at
    http://nvie.com/posts/a-successful-git-branching-model/
Being able to support that would be a big win for us.

On Mon, Apr 4, 2011 at 07:17, David Blevins <da...@gmail.com> 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: <db...@visi.com>
>> From: "Gav..." <ga...@16degrees.com.au>
>> Date: April 2, 2011 11:45:10 PM PDT
>> To: <in...@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...
>>
>>
>>
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

> git push -f github feature_name

I believe that syntax of pull+history overwrite. with pull, you need to use

git push github +feature_name:feature_name

And yes, it will make you heretic :)

-d


On Mon, Apr 4, 2011 at 2:17 PM, Paul Davis <pa...@gmail.com> wrote:
>> //do some work locally, committing to local git.
>>
>> git svn rebase // pull in other changes from apache
>> 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
>>
>> //do some more work locally, committing to local git.
>> //no one else changed the github branch AFAICT
>>
>> git svn rebase // pull in more apache changes, resolving merge conflicts
>>
>> 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???
>>
>
> David,
>
> Bottom line is that this is because when you rebase, you've changed
> the history of your branch. Since you did the first rebase before you
> pushed, this is fine, when you do the second rebase, it changes the
> commits you did locally before, which causes your local branch history
> to diverge from the branch at your GitHub remote.
>
> Think of the commit pattern like such:
>
> SN commit N from svn
> LNM local commit N, version M
>
> // do some work locally
>
> S0 -> L10 -> L20
>
> git svn rebase
>
> S0 -> S1 -> S2 -> L11 -> L21
>
> git push github feature_name
>
> # GitHub now has L31 as the head for branch feature_name
>
> // more local work
>
> S0 -> S1 -> S2 -> L11 -> L21 -> L30
>
> git svn rebase
>
> S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31
>
> // Now you can't push
>
> this is because your local branch has L31 as the head, and the GitHub
> branch is still L30. This is what's referred to a non fast forward
> push. You'll notice that both branches have commit S2 as the most
> recent commit in common.
>
> Now is the part where I write something that gets me branded as a heretic.
>
> To fix this, just do:
>
> $ git push -f github feature_name
>
> This will forcefully overwrite your remote branch so that it points at L31.
>
>
> Most people will tell you to never rebase something that has been
> pushed publicly. Generally that's true. For instance, you should never
> ever rebase your stable branches (master, version branches etc) that
> people might be using to develop against. On the other hand, if I have
> a public tracking branch of some wip, I'll rebase at will, treating it
> solely as a way for people to keep an eye on what I'm hacking on.
>
>
> I'll note that the alternative to this work flow is to svn rebase a
> local checkout of trunk, and then merge that into your feature branch.
> This will ensure that you'll always have fast forward updates when you
> push to GitHub. On the other hand, when you go to extract the work
> from your feature branch it can become much more difficult if you want
> to do anything more complicated than a single patch.
>

Re: Current use of GitHub

[Paul Davis <pa...@gmail.com>]

On Mon, Apr 4, 2011 at 5:50 PM, David Jencks <da...@yahoo.com> wrote:
> Hi Paul,
>
> IIUC your "heretical" suggestion is about the same as creating a new github branch every time I want to push my local branch, except the github branches all happen to have the same name so you can only see the most recent one?  I didn't know how to make them end up with the same name :-) ... this looks like my best option so far.
>

Roughly speaking. Just remember that the social aspect to keep
everyone informed that the branch will be changing and to not develop
code on it without close collaboration.

Re: Current use of GitHub

[Mark Struberg <st...@yahoo.de>]

I personally barely use dcommit, but frequently use git locally to create a patch which I attach to jira later. Git is just soooo much quicker at checkout + blame than svn that it easily pays off. Especially if you are not so deep into the code and need to grab through historical versions and commit messages of the code. 

I do not use git for projects I'm committer on though.
But I have seen a few people making use of git-clone for grabbing our projects.

LieGrue,
strub

--- On Tue, 4/5/11, Kristian Rosenvold <kr...@gmail.com> wrote:

> From: Kristian Rosenvold <kr...@gmail.com>
> Subject: Re: Current use of GitHub
> To: infrastructure-dev@apache.org
> Date: Tuesday, April 5, 2011, 9:19 AM
> ti., 05.04.2011 kl. 10.08 +0200,
> skrev Jukka Zitting:
> > Hi,
> > 
> > On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
> > <kr...@gmail.com>
> wrote:
> > > *All* git-svn based workflows involve rebasing
> (rewriting history). By
> > > standard git wisdom that makes your workflow
> single-user unless you have
> > > quite advanced git users.
> > 
> > I any case I would recommend git-svn users to use the
> svn repository
> > for collaboration. If you have a commit that can be
> shared, just do a
> > git svn dcommit and everyone is happy ..
> > 
> 
> As long as we're svn-backed, that should certainly be the
> official
> recommendation. This does not mean that's how things happen
> in real
> life ;)
> 
> I frequently use git/github to collaborate with myself at
> different
> computers, so I push/rebase/reset when I move from my
> laptop to my home
> office to my office. Sometimes code can be in shambles, not
> even
> compiling (I can switch dev computers in 30 seconds in this
> manner). Git
> users simply end up using their servers for far more
> use-cases than svn
> users, and I wouldn't dream of dcommitting anything that
> doesn't even
> compile.
> 
> And we already have several examples where asf committers
> choose to
> collaborate in git/github branches only to dcommit when
> done. I'm not
> sure it matters in this context, it just creates larger svn
> commits;
> there may be other concerns about this.
> 
> I understand the original query as requesting insight into
> the current
> usages of the mirrors, and there may be several reasons for
> that. From a
> technical perspective I think the current integration is
> reasonably
> state-of-the-art when it comes to git<->svn
> integration, which
> unfortunately says a lot about the orthogonality of these
> two SCM's
> (although I sometimes suspect there'd be ways to make
> git-svn better).
> There may be some provenance issues that could be addressed
> wrt the git
> forks; maybe something like crawling github looking for
> git-commits that
> are children of "official" apache sha1's (and persist it
> somewhere)
> could be an idea.
> 
> Even with all their limitations, the forks provide great
> value to git
> users. The biggest shame is that you really need to be a
> *good* git user
> to get a smooth experience, it's not much for git-beginners
> who really
> should start their learning with "proper" git.
> 
> Kristian
> 
> 
> 

Re: Current use of GitHub

[Kristian Rosenvold <kr...@gmail.com>]

ti., 05.04.2011 kl. 10.08 +0200, skrev Jukka Zitting:
> Hi,
> 
> On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
> > *All* git-svn based workflows involve rebasing (rewriting history). By
> > standard git wisdom that makes your workflow single-user unless you have
> > quite advanced git users.
> 
> I any case I would recommend git-svn users to use the svn repository
> for collaboration. If you have a commit that can be shared, just do a
> git svn dcommit and everyone is happy ..
> 

As long as we're svn-backed, that should certainly be the official
recommendation. This does not mean that's how things happen in real
life ;)

I frequently use git/github to collaborate with myself at different
computers, so I push/rebase/reset when I move from my laptop to my home
office to my office. Sometimes code can be in shambles, not even
compiling (I can switch dev computers in 30 seconds in this manner). Git
users simply end up using their servers for far more use-cases than svn
users, and I wouldn't dream of dcommitting anything that doesn't even
compile.

And we already have several examples where asf committers choose to
collaborate in git/github branches only to dcommit when done. I'm not
sure it matters in this context, it just creates larger svn commits;
there may be other concerns about this.

I understand the original query as requesting insight into the current
usages of the mirrors, and there may be several reasons for that. From a
technical perspective I think the current integration is reasonably
state-of-the-art when it comes to git<->svn integration, which
unfortunately says a lot about the orthogonality of these two SCM's
(although I sometimes suspect there'd be ways to make git-svn better).
There may be some provenance issues that could be addressed wrt the git
forks; maybe something like crawling github looking for git-commits that
are children of "official" apache sha1's (and persist it somewhere)
could be an idea.

Even with all their limitations, the forks provide great value to git
users. The biggest shame is that you really need to be a *good* git user
to get a smooth experience, it's not much for git-beginners who really
should start their learning with "proper" git.

Kristian

Re: Current use of GitHub

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> *All* git-svn based workflows involve rebasing (rewriting history). By
> standard git wisdom that makes your workflow single-user unless you have
> quite advanced git users.

I any case I would recommend git-svn users to use the svn repository
for collaboration. If you have a commit that can be shared, just do a
git svn dcommit and everyone is happy.

BR,

Jukka Zitting

Re: Current use of GitHub

[Kristian Rosenvold <kr...@gmail.com>]

*All* git-svn based workflows involve rebasing (rewriting history). By
standard git wisdom that makes your workflow single-user unless you have
quite advanced git users.

There are several strategies for collaboration even in this scenario,
but all of them only caters for "known" collaborators; in a small
group of people you can decide to work git-only on a branch that
*stays* anchored at a specific svn version for the scope of the
collaboration. Or you can have one person in the group run git rerere 
and have her do all the update-merges from svn trunk (but still stay on
a separate branch for the scope of the collaboration). This person
(and only her!) should be able to do a rebase & squash at the end of the
collaboration effort and commit back to svn. 

Most people are aware that git creates SHA1 hashes for each commit.
But git also creates SHA1 hashes of the *diff content* used in diff
based operations such as rebase, which means that you can actually
safely move an unmodified diff around in history and expect other users
to be able to recover from it (at least strong git users;). This is the
reason squashing is even more frowned upon, when you squash you also
change the SHA1 of the diff, meaning it becomes much harder
(impossible?) to follow rebases. But still, we squash when committing 
to svn.

But given the way we tag our svn commits with jira references, 
it's generally possible for an informed git-svn user to understand
the rebases/squashes going on. But it's definitely not for the
git beginners and IMO it's a bit of a half-perverted git workflow that
makes git look bad.

But these are the constraints of working with svn-backed git and I have
no indication they will go away. The only real "solution" to this 
problem is ditching svn as backing store, something I truely hope
will be done in due time, but I suppose that's a different discussion.
Github does a good git-backed svn ;)

Kristian

Re: Current use of GitHub

[David Jencks <da...@yahoo.com>]

Hi Paul,

IIUC your "heretical" suggestion is about the same as creating a new github branch every time I want to push my local branch, except the github branches all happen to have the same name so you can only see the most recent one?  I didn't know how to make them end up with the same name :-) ... this looks like my best option so far.

many thanks!
david jencks

On Apr 4, 2011, at 2:17 PM, Paul Davis wrote:

>> //do some work locally, committing to local git.
>> 
>> git svn rebase // pull in other changes from apache
>> 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
>> 
>> //do some more work locally, committing to local git.
>> //no one else changed the github branch AFAICT
>> 
>> git svn rebase // pull in more apache changes, resolving merge conflicts
>> 
>> 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???
>> 
> 
> David,
> 
> Bottom line is that this is because when you rebase, you've changed
> the history of your branch. Since you did the first rebase before you
> pushed, this is fine, when you do the second rebase, it changes the
> commits you did locally before, which causes your local branch history
> to diverge from the branch at your GitHub remote.
> 
> Think of the commit pattern like such:
> 
> SN commit N from svn
> LNM local commit N, version M
> 
> // do some work locally
> 
> S0 -> L10 -> L20
> 
> git svn rebase
> 
> S0 -> S1 -> S2 -> L11 -> L21
> 
> git push github feature_name
> 
> # GitHub now has L31 as the head for branch feature_name
> 
> // more local work
> 
> S0 -> S1 -> S2 -> L11 -> L21 -> L30
> 
> git svn rebase
> 
> S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31
> 
> // Now you can't push
> 
> this is because your local branch has L31 as the head, and the GitHub
> branch is still L30. This is what's referred to a non fast forward
> push. You'll notice that both branches have commit S2 as the most
> recent commit in common.
> 
> Now is the part where I write something that gets me branded as a heretic.
> 
> To fix this, just do:
> 
> $ git push -f github feature_name
> 
> This will forcefully overwrite your remote branch so that it points at L31.
> 
> 
> Most people will tell you to never rebase something that has been
> pushed publicly. Generally that's true. For instance, you should never
> ever rebase your stable branches (master, version branches etc) that
> people might be using to develop against. On the other hand, if I have
> a public tracking branch of some wip, I'll rebase at will, treating it
> solely as a way for people to keep an eye on what I'm hacking on.
> 
> 
> I'll note that the alternative to this work flow is to svn rebase a
> local checkout of trunk, and then merge that into your feature branch.
> This will ensure that you'll always have fast forward updates when you
> push to GitHub. On the other hand, when you go to extract the work
> from your feature branch it can become much more difficult if you want
> to do anything more complicated than a single patch.

Re: Current use of GitHub

[Paul Davis <pa...@gmail.com>]

> //do some work locally, committing to local git.
>
> git svn rebase // pull in other changes from apache
> 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
>
> //do some more work locally, committing to local git.
> //no one else changed the github branch AFAICT
>
> git svn rebase // pull in more apache changes, resolving merge conflicts
>
> 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???
>

David,

Bottom line is that this is because when you rebase, you've changed
the history of your branch. Since you did the first rebase before you
pushed, this is fine, when you do the second rebase, it changes the
commits you did locally before, which causes your local branch history
to diverge from the branch at your GitHub remote.

Think of the commit pattern like such:

SN commit N from svn
LNM local commit N, version M

// do some work locally

S0 -> L10 -> L20

git svn rebase

S0 -> S1 -> S2 -> L11 -> L21

git push github feature_name

# GitHub now has L31 as the head for branch feature_name

// more local work

S0 -> S1 -> S2 -> L11 -> L21 -> L30

git svn rebase

S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31

// Now you can't push

this is because your local branch has L31 as the head, and the GitHub
branch is still L30. This is what's referred to a non fast forward
push. You'll notice that both branches have commit S2 as the most
recent commit in common.

Now is the part where I write something that gets me branded as a heretic.

To fix this, just do:

$ git push -f github feature_name

This will forcefully overwrite your remote branch so that it points at L31.


Most people will tell you to never rebase something that has been
pushed publicly. Generally that's true. For instance, you should never
ever rebase your stable branches (master, version branches etc) that
people might be using to develop against. On the other hand, if I have
a public tracking branch of some wip, I'll rebase at will, treating it
solely as a way for people to keep an eye on what I'm hacking on.


I'll note that the alternative to this work flow is to svn rebase a
local checkout of trunk, and then merge that into your feature branch.
This will ensure that you'll always have fast forward updates when you
push to GitHub. On the other hand, when you go to extract the work
from your feature branch it can become much more difficult if you want
to do anything more complicated than a single patch.

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

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 <dl...@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 <dl...@gmail.com> wrote:
>> On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <da...@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: <db...@visi.com>
>>>>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>>>> To: <in...@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...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

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 <dl...@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <da...@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: <db...@visi.com>
>>>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>>> To: <in...@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...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <da...@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: <db...@visi.com>
>>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>> To: <in...@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...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: Current use of GitHub

[David Jencks <da...@yahoo.com>]

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.

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: <db...@visi.com>
>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>> To: <in...@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...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

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: <db...@visi.com>
>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>> To: <in...@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...
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

Re: Current use of GitHub

[David Jencks <da...@yahoo.com>]

On Apr 4, 2011, at 10:15 AM, Dmitriy Lyubimov wrote:

>> At the moment I have given up on providing a publicly accessible look into  what I'm doing until I commit to svn.  AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch.  If I'm missing something I'd love to know how to make this work.
>> 
> 
> Yes you can do it
> 
> just add github remote.
> 
> say you are on a trunk and your 'origin' points to apache git.
> then
> 
> git remote add github git@github.com:<your-user>/<your-github-repo>
> 
> and then you can push your branches to github e.g.
> git push github trunk:trunk
> 
> What i usually do is i create issues branches locally and set them
> track the branch in github (since i never can push them into ASF) such
> as
> 
> git checkout -b MAHOUT-555  (creates local brunch based on current
> branch, such as trunk)
> git push -u github MAHOUT-555:MAHOUT-555
> 
> now the issue branch is set up to track github's brunch
> so you've done something there (or somebody done something there) then
> assuming you want to commit it by merging -- you can merge directly to
> github branch by
> 
> git fetch github (fetch latest github branch snapshots)
> git checkout trunk (-- make sure we are on local trunk)
> git svn rebase (-- rewind trunk to latest in svn)
> 
> git merge --squash github/MAHOUT-555 (-- merge github branch changes
> but don't commit and squash history so it looks like a single commit )
> 
> //... resolve conflicts if necessary
> git commit -m "MAHOUT-555" (--format squashed history as single commit)
> 
> git svn dcommit (-- push into svn) .
> 
> ...
> now you have squashed issue commited to your local trunk

Hi Dmitriy,

I'm not sure how this relates to what I have been trying.  I'm definitely a git newbie so might be missing a lot....

here's what I think I tried, from a local git repo that matches apache svn and a github branch:

git remote add github git@github.com....
git branch feature1
git checkout feature1

//do some work locally, committing to local git.

git svn rebase // pull in other changes from apache
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

//do some more work locally, committing to local git.
//no one else changed the github branch AFAICT

git svn rebase // pull in more apache changes, resolving merge conflicts

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???

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: <db...@visi.com>
>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>> To: <in...@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...
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

> At the moment I have given up on providing a publicly accessible look into  what I'm doing until I commit to svn.  AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch.  If I'm missing something I'd love to know how to make this work.
>

Yes you can do it

just add github remote.

say you are on a trunk and your 'origin' points to apache git.
then

git remote add github git@github.com:<your-user>/<your-github-repo>

and then you can push your branches to github e.g.
git push github trunk:trunk

What i usually do is i create issues branches locally and set them
track the branch in github (since i never can push them into ASF) such
as

git checkout -b MAHOUT-555  (creates local brunch based on current
branch, such as trunk)
git push -u github MAHOUT-555:MAHOUT-555

now the issue branch is set up to track github's brunch
so you've done something there (or somebody done something there) then
assuming you want to commit it by merging -- you can merge directly to
github branch by

git fetch github (fetch latest github branch snapshots)
git checkout trunk (-- make sure we are on local trunk)
git svn rebase (-- rewind trunk to latest in svn)

git merge --squash github/MAHOUT-555 (-- merge github branch changes
but don't commit and squash history so it looks like a single commit )

//... resolve conflicts if necessary
git commit -m "MAHOUT-555" (--format squashed history as single commit)

git svn dcommit (-- push into svn) .

...
now you have squashed issue commited to your local trunk


>
> -----
>
> 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: <db...@visi.com>
>>> From: "Gav..." <ga...@16degrees.com.au>
>>> Date: April 2, 2011 11:45:10 PM PDT
>>> To: <in...@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...
>>>
>>>
>>>
>>
>
>

Re: Current use of GitHub

[Dmitriy Lyubimov <dl...@gmail.com>]

Also, if you keep resolving same conflicts during svn rebase, i think
something isn't right. I so far did not incur that so much . But my
github use is fairly recent (no more than several months). Although i
have been using git in general (and git-svn in particular) for several
years now.

On Mon, Apr 4, 2011 at 10:01 AM, David Jencks <da...@yahoo.com> wrote:
> I've been using git for all my non-trivial apache work for several months now.  I've only used it for projects I'm a committer on.
>
> At the moment I have given up on providing a publicly accessible look into  what I'm doing until I commit to svn.  AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch.  If I'm missing something I'd love to know how to make this work.
>
> so..
>
> I start by cloning the apache git mirror (following the instructions at http://wiki.apache.org/general/GitAtApache)
>
> I keep one or more branches locally for the different bits of the project I'm working on.
>
> Periodically I do git svn rebase to pull in svn commits
>
> If there are enough changes that I'm worried about "my house burned down" I do git bundle ** and put the result on people.apache.org
>
> When I'm ready I do git svn dcommit
>
> -----
>
> 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: <db...@visi.com>
>>> From: "Gav..." <ga...@16degrees.com.au>
>>> Date: April 2, 2011 11:45:10 PM PDT
>>> To: <in...@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...
>>>
>>>
>>>
>>
>
>

Re: Current use of GitHub

[David Jencks <da...@yahoo.com>]

I've been using git for all my non-trivial apache work for several months now.  I've only used it for projects I'm a committer on.

At the moment I have given up on providing a publicly accessible look into  what I'm doing until I commit to svn.  AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch.  If I'm missing something I'd love to know how to make this work.

so..

I start by cloning the apache git mirror (following the instructions at http://wiki.apache.org/general/GitAtApache)

I keep one or more branches locally for the different bits of the project I'm working on.

Periodically I do git svn rebase to pull in svn commits

If there are enough changes that I'm worried about "my house burned down" I do git bundle ** and put the result on people.apache.org

When I'm ready I do git svn dcommit

-----

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: <db...@visi.com>
>> From: "Gav..." <ga...@16degrees.com.au>
>> Date: April 2, 2011 11:45:10 PM PDT
>> To: <in...@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...
>> 
>> 
>> 
>