Well, I consider myself a git black-belt user as well (I even wrote parts of the german man pages).
But the problems I explained mostly happens to users which do not have that much GIT foo. It's just pretty easy to mess up a repo with git pull (especially when using --rebase or core.autorebase=true) Anyway, my main concern is how to effectively slice up the repos without having tons of unnecessary repos lying around at the end of the day. Because that is exactly what happened to a few projects I know! Let's just consider we will abandon some old plugin because we replaced it with a much better approach. In SVN you just create a branch for maintenance and delete the plugin from trunk. Nobody will see this obsolete plugin if he checks out the trunk. But in GIT you still have the repo around. And for knowing which ones are in use and which aren't anymore you would need to clone all of them. There are 2 use cases when maintaining plugins: 1.) a plugin specific fix 2.) a cross-cutting fix which concerns many plugins (upgrade of technologies, introducing a new pattern, etc) Especially for 2.) it would become _much_ harder to do this properly as you cannot easily make sure that you checked all plugins! LieGrue, strub ----- Original Message ----- > From: Kristian Rosenvold <kristian.rosenv...@gmail.com> > To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Wednesday, September 5, 2012 2:32 PM > Subject: Re: Git as the canonical SCM > > While I'm sure it's academically interesting, I'm not sure if this > discussion is all that relevant for practical purposes. We > adapt/optimize for the technologies we use, and in moving to git I'm > quite convinced anything other than 1 release unit = 1 repo is > suboptimal. All the chit-chat about sparse checkouts is basically how > to live with suboptimal repos, and there is really no good reason why > we should choose to do that. > > As for your considerations on mixed merge/rebase workflows, you're > describing some hard cases that are quite far from beginners workflow > that require decent understanding of how things work. I work daily > with multiple remotes (apache/github) merges and rebases and I hardly > even think about it. But then again I'm probably a black belt user. > I'm not going to scare off beginners about the wonders of rebasing > merge commits because it is a problem they shouldnt be running into. > > Kristian > > 2012/9/5 Mark Struberg <strub...@yahoo.de>: >>> No longer true, git has sparse checkout support (I believe since > 1.7.0). >> >> I hear this argument over and over again, and it is still wrong! >> >> >> The sparse checkout support is only fragmentaric at least! It's for > sure not comparable with the sparse checkout features of SVN. I'd rather > call it 'farce checkout' :) >> >> Try creating a sparse branch >> Try creating a sparse tag >> Try getting multiple sparse checkouts at the same time >> >> >> git is good, but it it's basic design decisions does not fit to all > project setups. >> E.g. GIT is still primarily intended for only pushing to your own repo. Try > to do a git merge and later rebase of a concurring merge conflict. You will > end > up with all commits duplicated in the history... >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Stanislav Ochotnicky <sochotni...@redhat.com> >>> To: Maven Developers List <dev@maven.apache.org> >>> Cc: >>> Sent: Wednesday, September 5, 2012 9:51 AM >>> Subject: Re: Git as the canonical SCM >>> >>> Quoting Olivier Lamy (2012-09-04 22:23:11) >>> ... >>>> Due to lack of support of sparse checkout in git, I (perso) > don't want >>>> we have to create a git repo per plugin etc... >>>> IMHO That will be a pain to manage. >>> >>> No longer true, git has sparse checkout support (I believe since > 1.7.0). >>> See http://git-scm.com/docs/git-read-tree.html (search for Sparse >>> checkout section). There are multiple examples spread through the >>> interwebs, one would be: >>> > http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/ >>> >>> And there's always shallow clones which are fine for sending >>> format-patch(es). >>> >>> That said, the code should IMHO be split into repositories depending on >>> their releases (i.e. code that gets releases simultaneously should be > in >>> one repo, code that has multiple parts which get their own release tags >>> should be in separate repos) >>> >>> -- >>> Stanislav Ochotnicky <sochotni...@redhat.com> >>> Software Engineer - Base Operating Systems Brno >>> >>> PGP: 7B087241 >>> Red Hat Inc. http://cz.redhat.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
