Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
MIME-Version: 1.0
In-Reply-To: <BANLkTiksMeEb+AxrY_pUgYWOcAD0rP961w@mail.gmail.com>
References: <02f801cbf1ca$ad4b9290$07e2b7b0$@16degrees.com.au>
	<BANLkTiksMeEb+AxrY_pUgYWOcAD0rP961w@mail.gmail.com>
Date: Sun, 3 Apr 2011 01:01:36 -0700
Message-ID: <BANLkTim_A37zMKV=vAa-f9KQDf=d5VD_wg@mail.gmail.com>
Subject: Re: Current use of GitHub
From: Dmitriy Lyubimov <dlyubimov@apache.org>
To: infrastructure-dev@apache.org
Cc: "Gav..." <gavin@16degrees.com.au>
Content-Type: text/plain; charset=ISO-8859-1

ps -- so obviously it would help if ASF git mirrors had the same
history trees as git-svn trees. Then anything derived from ASF git
would be directly mergeable for commit. I am not sure why current ASF
git commit hashes do not match what i get in git-svn but it would have
been great if they did (or perhaps i have a wrong version of git-svn?)

On Sun, Apr 3, 2011 at 12:51 AM, Dmitriy Lyubimov <dlyubimov@apache.org> wrote:
> I am using github.
>
> But there are different scenarious here.
>
> Scenario #1: you fork ASF git (or github mirror) and create private
> branches to work. Then you create a patch and apply as usuall (using
> patch -p1) to your git-svn branch. from there you could then use
> git-svn dcommit.
>
> The problem with that approach is that you can't merge into git-svn
> branch as it happens that git-svn actually creates different hashes in
> commit tree than apache's git mirror. So those histories cannot be
> 3-way merged and commits can't be squashed as it would naturally occur
> . In addition, since there's a delay between git mirror and actual
> snapshot, there's always a danger that somebody commits and git
> doesn't see it and your patch would go stale until you can merge it
> properly when new commit finally goes thru git replica.
>
> So it's unnatural. so i switched to
> Scenario 2:
> instead of forking apache git, i push my git-svn branch directly into
> github and then follow everything i said in scenario #2 except i can
> now merge-squash directly into git-svn branch after work is done and i
> can rebase my git-svn snapshot at any moment. I still have to publish
> git diff to jira so others can review it though.
>
> If several people need to work on the same issue then they can do pull
> requests to my issues and then i would be able to incorporate their
> work into final squash-merge and git-svn dcommit. Although to tell you
> the truth I never collaborated on the same patch with anyone yet. Our
> project is fairly too sparsely populated for that so far.
>
> -dmitriy
>
> On Sat, Apr 2, 2011 at 11:45 PM, Gav... <gavin@16degrees.com.au> wrote:
>> 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...
>>
>>
>>
>