login
Search
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:Ahh. Ok, try the patch I just sent out, and see if it works for you. It _should_ allow you to do exactly that mkdir new-repo cd new-repo git init-db git pull <remote> <onehead> and now your "master" branch should be initialized to "onehead". Oh, except I just realized that I forgot to do a "git checkout" in my patch, so you'd need to add that (or do it by hand, but you really shouldn't need to, since the checkout is implied by the "pull"). The downside with this is that it does NOT populate your "remotes" information (like "git clone" would have done), so either we'd need to teach "git pull" to do that too, or you just have to do it by hand (so that you then can do the shorthand "git pull" to update in the future). Yeah, you're supposed to "init-db" and "push". Right now, that tends to unpack everything (which is bad), although that is hopefully getting fixed (ie the receiving end shouldn't unpack any more if it is recent. Junio?) "git push" uses send-pack internally, you shouldn't ever need to use it yourself. The creation of a new archive tends to need special rights (with _real_ ssh access and a shell you could do it, but "ssh+git" really means "git protocol over a connection that was opened with ssh, but doesn't necessarily have a real shell at the other end"). So for most protocols, you simply cannot (and shouldn't) do it. Think about services like the one that Pasky has set up, that allow you to set up a new git repo - the setup phase really _has_ to be separate (because you need to set up your keys etc). So I think the above syntax is actually not a good one, because it cannot work in the general case. It's much better to get used to setting up a repo first, and then pushing into it, and just accepting that it's a two-phase thing. Also, from a bandwidth standpoint, you can often (although obviously not always) make the setup start with something that is _closer_ to what you want to do. So, for example, you'd often do something like: (a) ssh to central repository (b) create the new repository by cloning it _locally_ at the central place from some other repository that is related (c) then, from your local (non-central) repository, do a "git push --force" to force your changes (which now only needs the _incremental_ thing). An example of this is again the "forking" thing that he repos at at http://git.or.cz/ already supports. Right. In fact, you should probably do website/master:refs/heads/master just to make it really explicit. A "fetch" by default won't actually generate a local branch unless you told it to. It just squirrels the end result into the magic FETCH_HEAD name, so that you can do # do the fetch git fetch git://git.sv.gnu.org/lilypond.git web/master # look at changes gitk ..FETCH_HEAD # If you're happy with them, merge them in git merge "merge new code" HEAD FETCH_HEAD and you never actually created a real local branch at all. If you want "git fetch" to fetch _into_ a branch, you need to tell it so, by using the full "src:dest" format. Otherwise it doesn't know what branch to fetch it into. (And, of course, you can define that branch relationship in your remote configuration, so you don't actually have to say it explicitly every time) Right. So you can either (a) do it that way to begin with (because you now told it to put the results in "master", so you never needed to do the second fetch in the first place) or (b) after you did the first fetch (into FETCH_HEAD), you could also have just decided to do git update-ref HEAD FETCH_HEAD "" (where that "" at the end is really not technically necessary, but it tells "update-ref" that you _only_ want to do this if the old HEAD was empty/undefined. Without it, "git update-ref" will just overwrite HEAD without caring what it contained before, so it can be a dangerous operation!) See? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
