> Disappointing. We move stuff in and out of trunk all the time. I think I need to elaborate a bit more in depth about the possibilities.
There is no straight 'you cannot move with history' because this heavily depends on the situations. a.) you CAN retain history if you e.g. have a sandbox-repo which is a clone of the official upstream repo. If you just add new features in a new branch, then the tree-ish (the diff-objects forming a tree) has a parent with a root node sha1 of the upstream repository. Thus GIT can apply any merge from your sandbox repo to the canonical main repo and perfectly retain history. This will of course only work if the work you like to merge is rooted in the upstream repo somehow. It is NOT possible to just git-merge a nice feature from e.g. openwebbeans.git into openejb.git (or the other way around), because those 2 repos don't have a common ancestor! b.) GIT provides a porcelain (the little hardcore pieces which form the foundation layer for all the polished things on top) which allows to import with history. git porcelains are certainly able to modify the history, so I think it could work somehow. I'm not sure if git-fetch from such a repo into a new branch and then merging it will success, but it might be worth a try. After a bit searching I saw that Linus did something already: http://thread.gmane.org/gmane.comp.version-control.git/5126/ Good read also ;) LieGrue, strub ----- Original Message ----- > From: David Blevins <[email protected]> > To: [email protected] > Cc: > Sent: Sunday, November 27, 2011 8:57 PM > Subject: Re: [DISCUSS] - OpenEJB to use Git (Fwd: [PROPOSAL] Wicket to use > Git@ASF) > > > On Nov 27, 2011, at 4:35 AM, Mark Struberg wrote: > >> * tags and branches are always repository-global! It's not possible to > just tag a single subdirectory as you can do in SVN. You really need to know > upfront how you will going to release your stuff later (all the > modularisation > thingy), because that's exactly the way you need to separate your > repositories. >> >> * git does not support a real sparse checkout handling and git-submodules > handling still sucks. >> >> * you cannot move a directory with all his history from one git repo to > another one (e.g. sandbox to proper) if they don't have a common tree-ish > ancestor. > > Disappointing. We move stuff in and out of trunk all the time. And as you > point out on the Maven list, having a ton of tiny repos, some active some > not, > is really frustrating. Reorganizing has serious consequences -- dead repos, > lost history, etc. > > The "one big ASF repo" that SVN offers is really elegant. Git's > pension to force you to split things up into tiny islands between which code > cannot flow with history seems to eat away at some of the advantages Git > brings. > > Are there plans in the Git roadmap to improve this? > > Why are people not holding their feet to the fire and making them fix such > basic > things? > > > -David >
