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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
2014-09-02 18:41 GMT+02:00 Mark Thomas : > 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)
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 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
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 : > 2014-09-02 18:41 GMT+02:00 Mark Thomas : > > > 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)
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 : > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: git (yet again)
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. The current svn setup is a single repo. 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 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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
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 : > >> 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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
>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)
On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat wrote: > 2014-09-02 18:41 GMT+02:00 Mark Thomas : > > > 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)
2014-09-02 20:41 GMT+04:00 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. 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 () 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
Re: git (yet again)
On 2 September 2014 20:25, Filip Hanik wrote: > On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat wrote: > >> 2014-09-02 18:41 GMT+02:00 Mark Thomas : >> >> > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
> 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)
Hi, 2014-09-02 22:15 GMT+03:00 Mark Thomas : > > ... > It is up to us. > > > The current svn setup is a single repo. > > > 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 : > > ... > 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)
2014-09-02 23:22 GMT+03:00 Violeta Georgieva : > > Hi, > > > 2014-09-02 22:15 GMT+03:00 Mark Thomas : > > > > ... > > > It is up to us. > > > > > > The current svn setup is a single repo. > > > > > > 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 : > > > > ... > > 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)
2014-09-02 22:49 GMT+02:00 Violeta Georgieva : > 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)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
On 3 September 2014 10:41, Rainer Jung 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
Hi all, On Sep 3, 2014 12:42 PM, "Rainer Jung" 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
Re: git (yet again)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: git (yet again)
On 3 September 2014 16:10, Martin Grigorov wrote: > On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig 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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git (yet again)
On Thu, Sep 4, 2014 at 12:46 AM, sebb wrote: > On 3 September 2014 16:10, Martin Grigorov wrote: > > On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig > 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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >