Re: Multi-head pulling series
Josef Weidendorfer <[EMAIL PROTECTED]> writes: > I think that both, default and non-default persistant > mappings, are only a handy convenience issue for less > typing. If GIT core is not doing this, some (most?) porcelains > will invent their own way for storing these mappings. Suppose I have something like this in $GIT_DIR/remotes/ko: URL: master.kernel.org:/pub/scm/git/git.git/ Pull: master:ko-master rc:ko-rc pu:ko-pu Push: master:master pu:pu rc:rc Default-Pull: master rc That is, "Pull/Push" describe only the default mappings, and "Default-Pull/Default-Push" names the refs pulled or pushed when only the shorthand (ko) is specified. I think that is what your proposal boils down to. Lack of "Default-Push" just means use the heads listed on "Push" line for the default. Am I reading you right so far? With that definition, what these would do would be intuitive and obvious: $ git push ko ;# my master, rc, and pu goes there, under # the same name. $ git fetch ko ;# their master comes to my ko-master, rc to my ko-rc # pu is not touched. But now, what should this do? $ git fetch ko master (1) does it use "Pull" mappings and use their "master" to fast forward my "ko-master"? or (2) does it obey "the command line overrides the configuration file" principle and fetch their "master" but not touch my local refs (remember, refspec "master" without colon is equivalent to "master:" in fetch, which means "get the objects to complete it, but do not store the ref locally")? If (1), then I would need to say "master:something" on the command line almost all the time, because the point of remotes/ configuration file is that I do not have to remember which remote head corresponds to my local head, and by definition I would not (and should not have to) know if "master" has the default mappings specified there and to which head, so even that "something" happens to be exactly what is in the remotes/ file, I would end up typing that explicitly. Which means that it defeats the point of having the configuration file to begin with. If (2), then I would again need to say master:ko-master if I wanted to mean "usually I pull from some heads (I do not remember which ones offhand, but my .git/remotes/ file would know), but this time I want to only pull from master and update ko-master". What this suggests to me is that making set of default refs to be pulled from and set of ref mappings orthgonal sounds like a good and clean way in theory, but would not be that much useful in practice. - 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
Re: Multi-head pulling series
Josef Weidendorfer <[EMAIL PROTECTED]> writes: > I think that both, default and non-default persistant > mappings, are only a handy convenience issue for less > typing. If GIT core is not doing this, some (most?) porcelains > will invent their own way for storing these mappings (like > Cogito is doing with branches/). I think it is better if this > is "standardized". I agree in principle, and it should not be hard to add support for optional "Default-pull" and "Default-push" keywords to remotes/ files (lack of which means to use LHS of refspecs on "Pull" or "Push" lines) to git-parse-remote-script. Patches welcome. > Currently missing here is automatic detection of the remote > repository for a given head to be pulled/pushed. But this is > no format issue. "git ls-remote " perhaps? - 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
Re: Multi-head pulling series
On Saturday 20 August 2005 20:54, Junio C Hamano wrote: > Josef Weidendorfer <[EMAIL PROTECTED]> writes: > >>$ cat $GIT_DIR/remotes/www > >>URL: http://www.kernel.org/pub/scm/git/git.git/ > >>Pull: master:ko-master pu:ko-pu > >>Push: master:master pu:pu foo:bar > > > > Isn't this mixing two kinds of information: > > 1) Some default/persistent mapping of local to remote heads > > 2) The default heads which are pulled/pushed when only giving the remote > > I am not convinced myself that default/persistent mapping makes > much sense, I think that both, default and non-default persistant mappings, are only a handy convenience issue for less typing. If GIT core is not doing this, some (most?) porcelains will invent their own way for storing these mappings (like Cogito is doing with branches/). I think it is better if this is "standardized". Currently missing here is automatic detection of the remote repository for a given head to be pulled/pushed. But this is no format issue. > and updating the stored mappings dynamically when > the user uses non-default mappings in push/pull as a one-shot > operation does not make any sense at all at least to me. Yes, you are right. Josef - 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
Re: Multi-head pulling series
Josef Weidendorfer <[EMAIL PROTECTED]> writes: >> $ cat $GIT_DIR/remotes/www >> URL: http://www.kernel.org/pub/scm/git/git.git/ >> Pull: master:ko-master pu:ko-pu >> Push: master:master pu:pu foo:bar > > Isn't this mixing two kinds of information: > 1) Some default/persistent mapping of local to remote heads > 2) The default heads which are pulled/pushed when only giving the remote I am not convinced myself that default/persistent mapping makes much sense, and updating the stored mappings dynamically when the user uses non-default mappings in push/pull as a one-shot operation does not make any sense at all at least to me. You should rather consider that the current specification does not deal with (1) at all. The set of default pull/push refs does not make much sense without mappings for them, so that is what the file records. - 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
Re: Multi-head pulling series
On Thursday 18 August 2005 09:24, Junio C Hamano wrote: > $ cat $GIT_DIR/remotes/www > URL: http://www.kernel.org/pub/scm/git/git.git/ > Pull: master:ko-master pu:ko-pu > Push: master:master pu:pu foo:bar Isn't this mixing two kinds of information: 1) Some default/persistent mapping of local to remote heads 2) The default heads which are pulled/pushed when only giving the remote, like in: > $ git push mko ;# push our master and pu to the same > # name, foo to .git/refs/heads/bar. I think it makes sense to be able to store mappings without adding the head to the default group of heads pulled. Can we put the default pull/push actions in separate lines, like $ cat $GIT_DIR/remotes/mko URL: master.kernel.org:/pub/scm/git/git.git/ Pull: master:ko-master pu:ko-pu mylocal:myremote Push: master:master pu:pu foo:bar Default-Pull: master pu Default-Push: master pu foo > $ git push mko pu:refs/heads/testing > # instead of pushing to the usual ref, > # push our pu to refs/heads/testing, > # this time only. With a command (push/fetch/pull) giving an explicit local/remote mapping, it would be cool to automatically add the given mapping to the remotes/ file if there is no push-mapping for pu yet, so that you can have the same later with only git push mko pu And finally, it would be nice to specify a default mapping for arbitrary heads $ cat $GIT_DIR/remotes/www URL: http://www.kernel.org/pub/scm/git/git.git/ Pull: www#*:* Such that git fetch www#pu will fetch head pu into local head .refs/heads/www#pu Josef PS: I know I should provide patches for my proposals. But let discuss them first. - 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
