Linus, I like the solution you are suggesting, but I suspect it will create more problems that it will solve, and while the coolness factor is drawing me in.... we ain't gonna need it, as the xp people say.
More below... On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > Git won't care, so it will work, but things like clone/pull etc also won't > actually ever look there, so it will only work for that one repo. Storing things there _works_ in the sense that it will be ignored, and that is fine with me. So I could just be lazy and have it strictly tied to the repo. In practice, if you are tracking an external Arch repo, you really have it scripted, and use a dedicated git repo for that. Not using a dedicated repo is quite... messy. If you do other things in that particular repo, the import script may find it dirty, and mess things up on import. And after the import, you'll probably run git-push-script --all because it's bringing a dynamically growing forest of heads from the arch repo. That's another reason why your private branches should be elsewhere. OTOH, storing the metadata in a branch will allow us to run the import in alternating repositories. But as Junio points out, unless I can guarantee that the metadata and the tree are in sync, I cannot trivially resume the import cycle from a new repo. > The git solution to this (which nobody has ever _used_, but which > technically is wonderful) is to have a "side branch" that does not share > any commits (or files, for that matter) in common with the "real branch", > and which is used to track any metadata. In fact, you can obviously have > any number of side branches. A couple of days ago, playing with the import, I realised that the git repo can hold unrelated projects, too, if you just commit orphan trees as new heads. I mean - it was a bug in my script but I thought it was cool. ;) > The way to maintain a metadata branch is to have not only a different > branch name (obviously), but also use a totally different index file, so > that you can index both branches in parallell, and you don't actually need > to check out one or the other. Hmmm. Now that's voodoo magic! I was thinking of reading the file by asking directly for the object by its sha, or doing a checkout in a tmpdir. Interesting. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
