Hi all, On Sep 3, 2014 12:42 PM, "Rainer Jung" <rainer.j...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
