You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2014/09/02 18:41:24 UTC
git (yet again)
I've been looking at this again (anything to get a break from writing
parsers for cookies) and chatting with some of the infra folks that look
after the ASF's git repos.
There are a couple of things we need to do:
a) decide how we want to organise development in git
b) decide if we want to move to git
Now the decision we make for a) might influence some folks to make a
different decision for b). On the other hand, there is no point debating
a) if we are never going to move.
So, how do folks want to approach this?
A: Vote to move to git and then figure out how best to use it? or
B: Agree our git workflows and then have a vote on moving to git with
those workflows?
I'm leaning towards A myself.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by sebb <se...@gmail.com>.
On 2 September 2014 20:25, Filip Hanik <fi...@hanik.com> wrote:
> On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat <re...@apache.org> wrote:
>
>> 2014-09-02 18:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>> > I'm leaning towards A myself.
>>
>
>
> The move to git clears a huge hurdle, and that is managing contributions.
> The patch system is very difficult, and impossible to maintain. A pull
> request stays alive
> and can be maintained through code changes
> . I believe we can get more contributions by moving to Git.
>
>
>
>> >
>>
>> Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
>> we should also move to it first, then think about how to use it later,
>> otherwise people will never vote in favor)
>>
>
> Let's skip Maven and move straight to Gradle, it has the benefit of not
> needing a build system installed on the developers machine, as it gets
> downloaded by the wrapper checked into the repo. This is yet one less
AIUI the wrapper is not source, it is binary.
Generally only source code is allowed in repos, so will this cause an issue?
> version that is required by the contributor.
> It's built on top of Ant, and should give us all the flexibility we need.
>
>
>>
>> :)
>>
>> Rémy
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Henri Gomez <he...@gmail.com>.
> Let's skip Maven and move straight to Gradle, it has the benefit of not
> needing a build system installed on the developers machine, as it gets
> downloaded by the wrapper checked into the repo. This is yet one less
> version that is required by the contributor.
> It's built on top of Ant, and should give us all the flexibility we need.
>
Maven is used by so many ASF projects and especially projects using Tomcat
like TomEE, it would be nice to share contents and expertises.
Also, Maven is way more used in companies than Gradle or Ant/Ivy.
It should help also for companies (or companies developpers) contribution.
Re: git (yet again)
Posted by Filip Hanik <fi...@hanik.com>.
On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat <re...@apache.org> wrote:
> 2014-09-02 18:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> > I'm leaning towards A myself.
>
The move to git clears a huge hurdle, and that is managing contributions.
The patch system is very difficult, and impossible to maintain. A pull
request stays alive
and can be maintained through code changes
. I believe we can get more contributions by moving to Git.
> >
>
> Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
> we should also move to it first, then think about how to use it later,
> otherwise people will never vote in favor)
>
Let's skip Maven and move straight to Gradle, it has the benefit of not
needing a build system installed on the developers machine, as it gets
downloaded by the wrapper checked into the repo. This is yet one less
version that is required by the contributor.
It's built on top of Ant, and should give us all the flexibility we need.
>
> :)
>
> Rémy
>
Re: git (yet again)
Posted by Henri Gomez <he...@gmail.com>.
Maven Strike back ?
That would be a very good new and our friend Olivier Lamy will be more than
happy :)
2014-09-02 18:52 GMT+02:00 Rémy Maucherat <re...@apache.org>:
> 2014-09-02 18:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> > I'm leaning towards A myself.
> >
>
> Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
> we should also move to it first, then think about how to use it later,
> otherwise people will never vote in favor)
>
> :)
>
> Rémy
>
Re: git (yet again)
Posted by Rémy Maucherat <re...@apache.org>.
2014-09-02 18:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I'm leaning towards A myself.
>
Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
we should also move to it first, then think about how to use it later,
otherwise people will never vote in favor)
:)
Rémy
Re: git (yet again)
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Sep 4, 2014 at 12:46 AM, sebb <se...@gmail.com> wrote:
> On 3 September 2014 16:10, Martin Grigorov <mg...@apache.org> wrote:
> > On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >
> >> On 2014-09-03, sebb wrote:
> >>
> >> > Maybe it's possible to configure the commit messages so that diffs are
> >> > shown; if not, then perhaps there needs to be a convention for how to
> >> > comment on commits.
> >>
> >> Might be something that can be configured per project, we do get diffs
> >> for commits in Ant-land: for example
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E
> >
> >
> > Diffs in mail notifications come for free in the ASF Git setup.
>
> OK, good.
>
> I was going by the infra puppet diffs on infrastructure-cvs which
> only have a compare URL.
>
> But it seems these are github commits.
>
I also noticed those commits.
I'll ask Tony (tonypc) how this works for them.
I know Joe (joes) was strongly against using non-ASF services for Apache
needs. Apparently this changed!
I see Apache Spark also makes a heavy use of GitHub but I don't know the
details again.
Joe (and the whole Infra team) was against using Atlassian Stash (
https://www.atlassian.com/software/stash) on ASF hardware. ASF already uses
several other Atlassian product like JIRA, Confluence, HipChat, FishEye.
Stash is the application behind bitbucket.org. I find it even better than
GitHub user experience.
>
> > Commenting on diffs in the email is not the important thing. Having an
> > email means that another committer (i.e. someone with more knowledge) did
> > something.
> > The new thing is being able to comment on "the patch" (the Pull Request)
> > provided by a contributor *before* it gets in the repo. Usually the
> > contributors don't have the whole picture.
>
> Yes, this would be useful.
>
> However, it is fairly common for Tomcat committers to comment on each
> other's commits, either as part of CTR or sometimes to provide
> feedback. etc.
> A quick scan of some recent commits shows 5-10% with comments.
>
> >
> >>
> >>
> >> Stefan
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: git (yet again)
Posted by sebb <se...@gmail.com>.
On 3 September 2014 16:10, Martin Grigorov <mg...@apache.org> wrote:
> On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2014-09-03, sebb wrote:
>>
>> > Maybe it's possible to configure the commit messages so that diffs are
>> > shown; if not, then perhaps there needs to be a convention for how to
>> > comment on commits.
>>
>> Might be something that can be configured per project, we do get diffs
>> for commits in Ant-land: for example
>>
>> http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E
>
>
> Diffs in mail notifications come for free in the ASF Git setup.
OK, good.
I was going by the infra puppet diffs on infrastructure-cvs which
only have a compare URL.
But it seems these are github commits.
> Commenting on diffs in the email is not the important thing. Having an
> email means that another committer (i.e. someone with more knowledge) did
> something.
> The new thing is being able to comment on "the patch" (the Pull Request)
> provided by a contributor *before* it gets in the repo. Usually the
> contributors don't have the whole picture.
Yes, this would be useful.
However, it is fairly common for Tomcat committers to comment on each
other's commits, either as part of CTR or sometimes to provide
feedback. etc.
A quick scan of some recent commits shows 5-10% with comments.
>
>>
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2014-09-03, sebb wrote:
>
> > Maybe it's possible to configure the commit messages so that diffs are
> > shown; if not, then perhaps there needs to be a convention for how to
> > comment on commits.
>
> Might be something that can be configured per project, we do get diffs
> for commits in Ant-land: for example
>
> http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E
Diffs in mail notifications come for free in the ASF Git setup.
Commenting on diffs in the email is not the important thing. Having an
email means that another committer (i.e. someone with more knowledge) did
something.
The new thing is being able to comment on "the patch" (the Pull Request)
provided by a contributor *before* it gets in the repo. Usually the
contributors don't have the whole picture.
>
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: git (yet again)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-09-03, sebb wrote:
> Maybe it's possible to configure the commit messages so that diffs are
> shown; if not, then perhaps there needs to be a convention for how to
> comment on commits.
Might be something that can be configured per project, we do get diffs
for commits in Ant-land: for example
http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 03/09/2014 12:17, sebb a écrit :
> Maybe it's possible to configure the commit messages so that diffs are
> shown; if not, then perhaps there needs to be a convention for how to
> comment on commits.
I confirm this is possible, here is for example a commit message for a
change on the tomcat8 package in Debian:
http://lists.alioth.debian.org/pipermail/pkg-java-commits/2014-July/032758.html
The commits are also threaded and grouped by push, see:
http://lists.alioth.debian.org/pipermail/pkg-java-commits/2014-July/thread.html
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by sebb <se...@gmail.com>.
On 3 September 2014 10:41, Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 02.09.2014 um 18:41 schrieb Mark Thomas:
>
>> I've been looking at this again (anything to get a break from writing
>> parsers for cookies) and chatting with some of the infra folks that look
>> after the ASF's git repos.
>>
>> There are a couple of things we need to do:
>> a) decide how we want to organise development in git
>> b) decide if we want to move to git
>>
>> Now the decision we make for a) might influence some folks to make a
>> different decision for b). On the other hand, there is no point debating
>> a) if we are never going to move.
>>
>> So, how do folks want to approach this?
>
>
>> A: Vote to move to git and then figure out how best to use it? or
>> B: Agree our git workflows and then have a vote on moving to git with
>> those workflows?
>>
There's one aspect of Git that does not seem to have been covered here:
the commit messages don't seem to include what was actually changed.
So in order to review a commit, it is necessary to click the link.
In turn, this makes it harder to comment on a change.
This is something that happens quite frequently with the SVN commit messages.
Maybe it's possible to configure the commit messages so that diffs are
shown; if not, then perhaps there needs to be a convention for how to
comment on commits.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Martin Grigorov <mg...@apache.org>.
Hi all,
On Sep 3, 2014 12:42 PM, "Rainer Jung" <ra...@kippdata.de> wrote:
>
>
> Am 02.09.2014 um 18:41 schrieb Mark Thomas:
>
>> I've been looking at this again (anything to get a break from writing
>> parsers for cookies) and chatting with some of the infra folks that look
>> after the ASF's git repos.
>>
>> There are a couple of things we need to do:
>> a) decide how we want to organise development in git
>> b) decide if we want to move to git
>>
>> Now the decision we make for a) might influence some folks to make a
>> different decision for b). On the other hand, there is no point debating
>> a) if we are never going to move.
>>
>> So, how do folks want to approach this?
>
>
>> A: Vote to move to git and then figure out how best to use it? or
>> B: Agree our git workflows and then have a vote on moving to git with
>> those workflows?
>>
>> I'm leaning towards A myself.
>
>
> It looks like the discussion in january and the answers on this thread
show a majority for a move to git (not necessarily a consensus). I'd prefer
if we knew more about the details before finally voting on it, so "B", and
I expect the time and work needed for that will not be wasted.
>
> I agree with others about items for a). Things that come into my mind:
>
> - one repos or multiple: Actually I dont't care about that question per
se, but more about the implications that will have (which I'm not sure
about). For instance, does it matter in git, that we would only have one
master (trunk), and the heads of the versions only as branches?
I am not sure how merging/cherry-pucking would work in separate repos.
As I said before I use git-new-workdir to have different local working
folders for branches of the same repo. This way I can have several branches
opened simultaneously in the IDE. Konstantin noted that this doesn't work
on Windows at the moment.
>
> - backport workflow
> I find "trunk first, then version branches" slightly better, but it
might depend on details unknown to me. Concerning "cherry-pick" this seems
to break the link between the original (e.g. master) commit and the commit
on the branch. Not a good thing IMHO.
Each cherry picked commit has the sha id of the original in its message
automatically. Additionally with "git cherry" you can check the branches a
commit has been picked.
>
> - use of temporary feature or backport branches: delete after merge?
Branching in Git is cheap. You can keep them if you want. Feature branches
are usually deleted after merge.
>
> - handling pull requests (tracking patch authors)
Apache committers don't have write access to GitHub mirrors. I have a Shell
script to merge Pull Requests and preserve the authorship.
The PR is automatically closed once the code is sync-ed as Mark already
said.
Commenting on code in a feature branch at GitHub UI doesn't notify the
author nor the team. Not ideal!
>
> - move tomcat-connectors as well, same repos? No preference here.
>
> - move old branches to simplify code archeology? I'd prefer so.
Most svn2git scripts support this.
>
> - sources for the web site remain in svn?
This is the case for Apache Wicket. I'd like to change it to Git too.
>
> - is there (in principle) a way back from git to svn, or is this a one
way street? No details needed, but if the project finds out the move was a
bad thing, are we confident, that we can get back?
>
> - Konstantin provided some reasons against git during the last three
discussions. Some of the might be mitigated by now (e.g. svn externals vs.
git submodules? Version diffs), some of them might not (Buildbot and
Jenkins integration, missing EU mirror).
We use BuildBot without problems.
For me US Git is much faster than EU SVN. I live in Bulgaria.
>
> I guess experienced git users (like Martin Grigorov) could answer most
questions easily, but I don't have the experience with git allowing me to
understand implications of decisions.
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: git (yet again)
Posted by Rainer Jung <ra...@kippdata.de>.
Am 02.09.2014 um 18:41 schrieb Mark Thomas:
> I've been looking at this again (anything to get a break from writing
> parsers for cookies) and chatting with some of the infra folks that look
> after the ASF's git repos.
>
> There are a couple of things we need to do:
> a) decide how we want to organise development in git
> b) decide if we want to move to git
>
> Now the decision we make for a) might influence some folks to make a
> different decision for b). On the other hand, there is no point debating
> a) if we are never going to move.
>
> So, how do folks want to approach this?
> A: Vote to move to git and then figure out how best to use it? or
> B: Agree our git workflows and then have a vote on moving to git with
> those workflows?
>
> I'm leaning towards A myself.
It looks like the discussion in january and the answers on this thread
show a majority for a move to git (not necessarily a consensus). I'd
prefer if we knew more about the details before finally voting on it, so
"B", and I expect the time and work needed for that will not be wasted.
I agree with others about items for a). Things that come into my mind:
- one repos or multiple: Actually I dont't care about that question per
se, but more about the implications that will have (which I'm not sure
about). For instance, does it matter in git, that we would only have one
master (trunk), and the heads of the versions only as branches?
- backport workflow
I find "trunk first, then version branches" slightly better, but it
might depend on details unknown to me. Concerning "cherry-pick" this
seems to break the link between the original (e.g. master) commit and
the commit on the branch. Not a good thing IMHO.
- use of temporary feature or backport branches: delete after merge?
- handling pull requests (tracking patch authors)
- move tomcat-connectors as well, same repos? No preference here.
- move old branches to simplify code archeology? I'd prefer so.
- sources for the web site remain in svn?
- is there (in principle) a way back from git to svn, or is this a one
way street? No details needed, but if the project finds out the move was
a bad thing, are we confident, that we can get back?
- Konstantin provided some reasons against git during the last three
discussions. Some of the might be mitigated by now (e.g. svn externals
vs. git submodules? Version diffs), some of them might not (Buildbot and
Jenkins integration, missing EU mirror).
I guess experienced git users (like Martin Grigorov) could answer most
questions easily, but I don't have the experience with git allowing me
to understand implications of decisions.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Mark Thomas <ma...@apache.org>.
On 02/09/2014 20:28, Konstantin Kolinko wrote:
> In July I successfully configured Git to operate on the same set of
> files as Subversion, on Windows.
Neat.
I use completely separate git and svn checkouts and swap between them as
the mood suits me. As I get more familiar with git then I am using git
more. Generally the only time when I have issues is when I try and take
a short cut and do git development directly on trunk and then realise
the issue is more complex and I really should be using a branch.
> Impressions etc.
> ========
> 1. Such workflow works. It is great for building up experience with the tool.
>
> It also allows us to discuss Mark's "a) decide how we want to organise
> development in git" point, without actually moving to Git.
>
> I think I can document it on a Wiki page, if others are interested.
My impression is that it is more complex to set up than [1] and might
make folks think git is more difficult to work with than it really is.
> 2. An annoying fact is that the Git repository at git.apache.org lags
> for up to one hour behind the Subversion one.
>
> The symptoms are as if the "git svn pull" is performed via some cron
> job, instead of a postcommit hook or svn-pub-sub. I wonder whether
> the Infra team can make it work better.
The sync from svn to the git.a.o is based on svn-pub-sub and is meant to
be close to real time. The replication it github is less frequent.
Obviously this would cease to be an issue if we moved to git (note there
is no git -> svn process to keep the old svn repo up to date).
> 3. I would like to commit my ".git/info/attributes" file as
> ".gitattributes" into Subversion.
Can you put that file somewhere where others can take a look at it first?
> 4. My impression is that Git works slower.
My impression has been the opposite. git-svn is a little slower than
just svn but that is expected since there is an extra layer. When I use
git at work (with github) things seem very quick.
> My points from the previous thread on this topic:
> http://markmail.org/message/m7ig5a7wunyewdy6
>
> Areas where we depend on Subversion and need to implement a fix before the move:
> 1). There is svn externals reference from Tomcat Native to Tomcat Trunk.
>
> (Does it mean that we have to migrate TC Native to Git at the same time?
> Can we remove this svn externals reference?)
We'd move Tomcat Native at the same time. There are equivalent features
we can use to continue to use something svn external like. [2]
> 2). svn revision numbers are used by the config difference form in the
> Migration guide.
> http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
>
> (Is it possible to replace it with links to similar Git tools, e.g. to
> "compare" pages on GitHub? Does HTML GUI at git.apache.org have
> similar history and compare pages?)
I'm sure we could come up with something.
> 3). The plan to create a Maven build (BZ 56397) relies on svn externals.
> (I think it is time to abandon the idea.)
I'm happy to leave this open for now. We could do this using one of the
ideas in [2].
> 6. Maybe move away modules/bayeux and modules/tomcat-lite ?
My expectation was that these would be left behind in svn.
[1] http://wiki.apache.org/general/GitAtApache
[2] http://stackoverflow.com/questions/571232/svnexternals-equivalent-in-git
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-09-02 20:41 GMT+04:00 Mark Thomas <ma...@apache.org>:
> I've been looking at this again (anything to get a break from writing
> parsers for cookies) and chatting with some of the infra folks that look
> after the ASF's git repos.
>
> There are a couple of things we need to do:
> a) decide how we want to organise development in git
> b) decide if we want to move to git
>
> Now the decision we make for a) might influence some folks to make a
> different decision for b). On the other hand, there is no point debating
> a) if we are never going to move.
>
> So, how do folks want to approach this?
> A: Vote to move to git and then figure out how best to use it? or
> B: Agree our git workflows and then have a vote on moving to git with
> those workflows?
>
> I'm leaning towards A myself.
We shall discuss the workflows and our expectations first.
In July I successfully configured Git to operate on the same set of
files as Subversion, on Windows.
That is: I have a sparse subversion workng copy that spans the whole
of site/trunk, tc6.0.x/trunk, tc7.0.x/trunk and trunk, and I have
".git" directories in each of the branches.
It works. If both Git and Subversion data are up-to-date, the "status"
command in both shows no changes (except an occasional uncommitted
bin/tcnative-1.dll that is used to run JUnit tests with APR).
As such, I use Git to prepare sets of changes and use Subversion
client to commit them when they are ready.
Technical bits:
========
1. I am using TortoiseGit (64-bit) and msysGit (32-bit).
2. I cloned the repositories from git://git.apache.org/
3. I have not initialized "git-svn" on this repository. I do not use it.
4. I have eol-conversion options turned off (the default) and I have
.git/info/attributes files in my local repositories that configure
Git to apply "text" attribute to the same set of files that are
treated as textual (<patternset id="text.files" >) in build.xml, the
same ones that have svn:eol-style=native in Subversion.
5. To pull fresh changes one has to update both subversion wc and
local git repository. Both "svn, git" and "git, svn" update sequences
do work successfully.
I prefer "svn, git", because it works a bit better and because git
repository lags behind subversion one.
6. To update the local trunk branch in Git according to master
repository the following works:
a) "Git Sync" command in TortoiseGit, using "Fetch and Rebase" operation there
b) In command line (Git Shell) it maps to the following sequence of commands:
git stash -u
git pull --rebase --verbose
git stash pop
Impressions etc.
========
1. Such workflow works. It is great for building up experience with the tool.
It also allows us to discuss Mark's "a) decide how we want to organise
development in git" point, without actually moving to Git.
I think I can document it on a Wiki page, if others are interested.
I used this workflow to prepare some patches when I had no network
access (traveling on a train across some sticks) and to commit them
when I had access.
2. An annoying fact is that the Git repository at git.apache.org lags
for up to one hour behind the Subversion one.
The symptoms are as if the "git svn pull" is performed via some cron
job, instead of a postcommit hook or svn-pub-sub. I wonder whether
the Infra team can make it work better.
3. I would like to commit my ".git/info/attributes" file as
".gitattributes" into Subversion.
My concerns before committing it:
a) If any of you are using Git on Windows, such commit probably means
that you have to "git checkout trunk" a fresh set of files so that
they get CRLF line ends applied from this setting.
b) I do not know whether this interoperates with git-svn, if any of
you are using it. We may give it a try and rollback later. In any
case, if there is anything wrong, a local ".git/info/attributes" file
can be used to overwrite the setting, as it has precedence over the
repository-provided ".gitattributes" one.
Documentation:
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
At the same time. I think it would be good to commit an svn:auto-props
property that applies svn:eol-style=native for the same set of files
for Subversion clients.
By the way Apache Subversion project configured a svn:auto-props
property for their project today,
http://svn.apache.org/r1621946
4. My impression is that Git works slower.
Maybe it is no so optimized, has less optimal database structure, or
does more work.
5. I think that now I will be able to continue working on Tomcat if we
migrate to Git,
but I am not yet convinced that it is worth moving,
and several issues listed below have to be fixed before the move.
My points from the previous thread on this topic:
http://markmail.org/message/m7ig5a7wunyewdy6
Areas where we depend on Subversion and need to implement a fix before the move:
1). There is svn externals reference from Tomcat Native to Tomcat Trunk.
(Does it mean that we have to migrate TC Native to Git at the same time?
Can we remove this svn externals reference?)
2). svn revision numbers are used by the config difference form in the
Migration guide.
http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
(Is it possible to replace it with links to similar Git tools, e.g. to
"compare" pages on GitHub? Does HTML GUI at git.apache.org have
similar history and compare pages?)
3). The plan to create a Maven build (BZ 56397) relies on svn externals.
(I think it is time to abandon the idea.)
6. Maybe move away modules/bayeux and modules/tomcat-lite ?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Henri Gomez <he...@gmail.com>.
>The git repo would be mirrored at github. Folks can open pull requests
>at gitbuh now and we can close them when we commit the changes. That
>won't change if we switch to git.
There is mecansims to merge pull-requests for GitHub in Git ASF ?
How is documented somewhere ?
> > Side note, did infra folks plans to use a new git hosting ?
> > Using Stash, Gitlab, Gitblit ? Or GitBucket (this implementation came
> from
> > an ASFer) ?
>
> No plans to change current arrangement.
Ok, no problems
Re: git (yet again)
Posted by Mark Thomas <ma...@apache.org>.
On 02/09/2014 19:31, Henri Gomez wrote:
> About git workflow.
>
> Github popularized fork/pull-request mode and it helped enrolled tons of
> new developpers in many Git projects, in Github but not only.
> Would it be something possible with current Git infra in ASF ?
The git repo would be mirrored at github. Folks can open pull requests
at gitbuh now and we can close them when we commit the changes. That
won't change if we switch to git.
> Side note, did infra folks plans to use a new git hosting ?
> Using Stash, Gitlab, Gitblit ? Or GitBucket (this implementation came from
> an ASFer) ?
No plans to change current arrangement.
Mark
>
>
>
> 2014-09-02 18:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> I've been looking at this again (anything to get a break from writing
>> parsers for cookies) and chatting with some of the infra folks that look
>> after the ASF's git repos.
>>
>> There are a couple of things we need to do:
>> a) decide how we want to organise development in git
>> b) decide if we want to move to git
>>
>> Now the decision we make for a) might influence some folks to make a
>> different decision for b). On the other hand, there is no point debating
>> a) if we are never going to move.
>>
>> So, how do folks want to approach this?
>> A: Vote to move to git and then figure out how best to use it? or
>> B: Agree our git workflows and then have a vote on moving to git with
>> those workflows?
>>
>> I'm leaning towards A myself.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Henri Gomez <he...@gmail.com>.
About git workflow.
Github popularized fork/pull-request mode and it helped enrolled tons of
new developpers in many Git projects, in Github but not only.
Would it be something possible with current Git infra in ASF ?
Side note, did infra folks plans to use a new git hosting ?
Using Stash, Gitlab, Gitblit ? Or GitBucket (this implementation came from
an ASFer) ?
2014-09-02 18:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I've been looking at this again (anything to get a break from writing
> parsers for cookies) and chatting with some of the infra folks that look
> after the ASF's git repos.
>
> There are a couple of things we need to do:
> a) decide how we want to organise development in git
> b) decide if we want to move to git
>
> Now the decision we make for a) might influence some folks to make a
> different decision for b). On the other hand, there is no point debating
> a) if we are never going to move.
>
> So, how do folks want to approach this?
> A: Vote to move to git and then figure out how best to use it? or
> B: Agree our git workflows and then have a vote on moving to git with
> those workflows?
>
> I'm leaning towards A myself.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: git (yet again)
Posted by Rémy Maucherat <re...@apache.org>.
2014-09-02 22:49 GMT+02:00 Violeta Georgieva <mi...@gmail.com>:
> One more thing - in github you can make inline comments for a given
> commit/pull request.
> This is very convenient for a review purposes.
>
Well, I guess since it is mirrored in github, you can comment there.
About the patching process, I would vote a) Make change in master and
cherry pick to backport.
For Maven, it was a joke, sorry for hijacking the thread. It should be
revisited later (or never). One last note: IMO Gradle sounds better, but
the point is to help integration so Maven is likely more useful.
Rémy
Re: git (yet again)
Posted by Violeta Georgieva <mi...@gmail.com>.
2014-09-02 23:22 GMT+03:00 Violeta Georgieva <mi...@gmail.com>:
>
> Hi,
>
>
> 2014-09-02 22:15 GMT+03:00 Mark Thomas <ma...@apache.org>:
> >
> > ...
>
> > It is up to us.
> >
> > <aside>
> > The current svn setup is a single repo.
> > </aside>
> >
> > My preference is for a single git repo with branches for 7.0.x and 6.0.x
>
> +1 one repo with many branches
> master is the latest development in our case 8.0.x at the moment
>
> >
> > > - how to backport modifications from one major version to another ?
is cherry-picking ok ?
> >
> > Again, it is up to us. I see two basic choices.
> >
> > a) Make change in master and cherry pick to backport
>
> +1 cherry pick from master to other branches
>
> > b) Make changes in earliest branch that needs the change and merge
> > forward until we reach trunk/master
> >
> > a) is closer to how we work now. b) is 'nicer'. a) is more flexible.
> >
> > I have a slight preference for a) but I'm happy with either.
> >
>
> 2014-09-02 22:28 GMT+03:00 Konstantin Kolinko <kn...@gmail.com>:
> >
> > ...
> > 2). svn revision numbers are used by the config difference form in the
> > Migration guide.
> > http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
> >
> > (Is it possible to replace it with links to similar Git tools, e.g. to
> > "compare" pages on GitHub? Does HTML GUI at git.apache.org have
> > similar history and compare pages?)
> >
>
> https://github.com/apache/tomcat/compare
One more thing - in github you can make inline comments for a given
commit/pull request.
This is very convenient for a review purposes.
>
>
> Regards,
> Violeta
Re: git (yet again)
Posted by Violeta Georgieva <mi...@gmail.com>.
Hi,
2014-09-02 22:15 GMT+03:00 Mark Thomas <ma...@apache.org>:
>
> ...
> It is up to us.
>
> <aside>
> The current svn setup is a single repo.
> </aside>
>
> My preference is for a single git repo with branches for 7.0.x and 6.0.x
+1 one repo with many branches
master is the latest development in our case 8.0.x at the moment
>
> > - how to backport modifications from one major version to another ? is
cherry-picking ok ?
>
> Again, it is up to us. I see two basic choices.
>
> a) Make change in master and cherry pick to backport
+1 cherry pick from master to other branches
> b) Make changes in earliest branch that needs the change and merge
> forward until we reach trunk/master
>
> a) is closer to how we work now. b) is 'nicer'. a) is more flexible.
>
> I have a slight preference for a) but I'm happy with either.
>
2014-09-02 22:28 GMT+03:00 Konstantin Kolinko <kn...@gmail.com>:
>
> ...
> 2). svn revision numbers are used by the config difference form in the
> Migration guide.
> http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
>
> (Is it possible to replace it with links to similar Git tools, e.g. to
> "compare" pages on GitHub? Does HTML GUI at git.apache.org have
> similar history and compare pages?)
>
https://github.com/apache/tomcat/compare
Regards,
Violeta
Re: git (yet again)
Posted by Mark Thomas <ma...@apache.org>.
On 02/09/2014 19:24, Sylvain Laurent wrote:
> Regarding question b), I vote yes, whatever the organization of the development
>
> Regarding a), for my part I rather see something between A and B. I think of the following questions that should be answered first :
> - will there be 1 repo per major version like the current SVN setup ? or only branches in a unique repo ?
It is up to us.
<aside>
The current svn setup is a single repo.
</aside>
My preference is for a single git repo with branches for 7.0.x and 6.0.x
> - how to backport modifications from one major version to another ? is cherry-picking ok ?
Again, it is up to us. I see two basic choices.
a) Make change in master and cherry pick to backport
b) Make changes in earliest branch that needs the change and merge
forward until we reach trunk/master
a) is closer to how we work now. b) is 'nicer'. a) is more flexible.
I have a slight preference for a) but I'm happy with either.
> - where will the main repo be (the one committers will push to)? ASF or github ? where should we open and treat pull requests, ASF or github ? (currently having the SVN repo at ASF and pull requests at github is not convenient)
The canonical location for the source for an ASF project is ALWAYS the
ASF. The repo will be mirrored at github. The github integration makes
working with github pull requests very easy - we are doing this already.
Mark
>
> Sylvain
>
> On 2 sept. 2014, at 18:41, Mark Thomas <ma...@apache.org> wrote:
>
>> I've been looking at this again (anything to get a break from writing
>> parsers for cookies) and chatting with some of the infra folks that look
>> after the ASF's git repos.
>>
>> There are a couple of things we need to do:
>> a) decide how we want to organise development in git
>> b) decide if we want to move to git
>>
>> Now the decision we make for a) might influence some folks to make a
>> different decision for b). On the other hand, there is no point debating
>> a) if we are never going to move.
>>
>> So, how do folks want to approach this?
>> A: Vote to move to git and then figure out how best to use it? or
>> B: Agree our git workflows and then have a vote on moving to git with
>> those workflows?
>>
>> I'm leaning towards A myself.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: git (yet again)
Posted by Sylvain Laurent <sl...@apache.org>.
Regarding question b), I vote yes, whatever the organization of the development
Regarding a), for my part I rather see something between A and B. I think of the following questions that should be answered first :
- will there be 1 repo per major version like the current SVN setup ? or only branches in a unique repo ?
- how to backport modifications from one major version to another ? is cherry-picking ok ?
- where will the main repo be (the one committers will push to)? ASF or github ? where should we open and treat pull requests, ASF or github ? (currently having the SVN repo at ASF and pull requests at github is not convenient)
Sylvain
On 2 sept. 2014, at 18:41, Mark Thomas <ma...@apache.org> wrote:
> I've been looking at this again (anything to get a break from writing
> parsers for cookies) and chatting with some of the infra folks that look
> after the ASF's git repos.
>
> There are a couple of things we need to do:
> a) decide how we want to organise development in git
> b) decide if we want to move to git
>
> Now the decision we make for a) might influence some folks to make a
> different decision for b). On the other hand, there is no point debating
> a) if we are never going to move.
>
> So, how do folks want to approach this?
> A: Vote to move to git and then figure out how best to use it? or
> B: Agree our git workflows and then have a vote on moving to git with
> those workflows?
>
> I'm leaning towards A myself.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org