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
