Re: git fetch documentation
Nicolas Richard wrote: > - A '*' can be used both in src and dest, and it matches any name, > including subdirectories, but not partial names (i.e. refs/heads/foo* > is invalid). > - multiple fetch lines can be given in .git/config, each of them will be > obeyed > > These are probably obvious for most users, but I think documenting them > would be good for newcomers. (I tried to come up with a patch but I > can't find a precise yet concise way to explain the role of '*' in > english.) Good. Yes, we don't even have examples showing that a rewrite like refs/heads/nr/*:refs/heads/* can be done. The documentation is definitely lacking. However, I'd urge you to get started by submitting an initial draft: we will review it and help you learn and contribute. Some pointers: - What you are attempting to document is called a refspec. Look at 'struct refspec' in remote.h, and attempt to understand what its fields mean by looking at how it is used in remote.c. - Notice that there is a push refspec corresponding to the fetch refspec. This feature is even more obscure and undocumented. - See remote.c:get_ref_match(); specifically, match_name_with_pattern() is doing the pattern matching. As you can see, match_name_with_pattern() hard-codes a '*' and tries to match just that: there is no support for anything else. Try to skim through the code once. - Read Documentation/SubmittingPatches and submit a first version quickly. It doesn't have to be perfect at all. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git fetch documentation
Hello, Regarding the git-fetch man page (IIUC, in pull-fetch-param.txt), in particular the explanation, I feel that two facts are missing: - A '*' can be used both in src and dest, and it matches any name, including subdirectories, but not partial names (i.e. refs/heads/foo* is invalid). - multiple fetch lines can be given in .git/config, each of them will be obeyed These are probably obvious for most users, but I think documenting them would be good for newcomers. (I tried to come up with a patch but I can't find a precise yet concise way to explain the role of '*' in english.) -- Nico. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
Drew Northup writes: > On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> I personally do not think the downside of breaking backward >> compatibility is too bad. If we do this only when we already are >> configured to keep remote tracking branch for branch $branch from >> remote $from (it has to be given as a nickname, not URL that happens >> to have an entry in the configuration), then a promiscuous fetch >> that grabs from a URL (or a nickname that is configured not to keep >> tracking branches) will not change any behaviour, and when you want >> to keep your remote tracking branch intact while doing one-shot >> fetch for whatever reason, you can say "git fetch $from $branch:" to >> explicitly decline copying. > > How are we supposed to remember those are different? > > "git fetch $from $branch..." > VS > "git fetch $from $branch:" I do not know what you meant by the three dots, but you are supposed to know what you meant by $branch... whatever it is. It is what you wrote, not I did ;-) Let me clarify what is in the message you are responding to. git fetch $from $branch (no colon in $branch part anywhere) traditionally meant a short-hand of saying git fetch $from $branch: I.e. "fetch $branch and store in FETCH_HEAD but not anywhere else". The hypothesized change is to make it a short-hand of saying git fetch $from $branch:refs/remotes/$from/$branch when "git fetch $from" is already configured to store the result there. Without [remote "$from"] fetch = refs/heads/*:refs/remotes/$from/* configured, it will still mean "git fetch $from $branch:". And for the record, I am *not* enthused about such a change. I am only saying that, seeing that many new people seem to wish the command behaved that way, such a change would not hurt existing users too much. Switching the meaning of shorthand (i.e. a piece of refspec that does not have any colon) from "just fetch but do not store" from "fetch and store in the remote tracking ref if it is configured to do so without command override" is still a backward incompatible change. > I strongly prefer EXPLICITLY setting tracking than expecting some > extreme syntactic nuance to quietly do it for me now and confuse the > heck out of me later. This is not about your preference. This is about what happens when you say something on the command line to override your explicit setting you have in $GIT_DIR/config [remote "$from"] fetch = ... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> In other words, you can do this from the command line if you want >> to do the update. >> >> $ git fetch origin master:refs/remotes/origin/master > > Now having said all that, we should probably revisit this and > possibly other issues and for the ones we can reach concensus, start > coding after 1.8.0 final. > * "git fetch $from $branch..." to update tracking branches > >This is the topic in this thread. > > I personally do not think the downside of breaking backward > compatibility is too bad. If we do this only when we already are > configured to keep remote tracking branch for branch $branch from > remote $from (it has to be given as a nickname, not URL that happens > to have an entry in the configuration), then a promiscuous fetch > that grabs from a URL (or a nickname that is configured not to keep > tracking branches) will not change any behaviour, and when you want > to keep your remote tracking branch intact while doing one-shot > fetch for whatever reason, you can say "git fetch $from $branch:" to > explicitly decline copying. How are we supposed to remember those are different? "git fetch $from $branch..." VS "git fetch $from $branch:" I strongly prefer EXPLICITLY setting tracking than expecting some extreme syntactic nuance to quietly do it for me now and confuse the heck out of me later. -- -Drew Northup -- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano wrote: > * Unify pathspec semantics > >This has happened and commands that used to take only path prefix >style pathspecs now take globs as well [ND] I've been thinking about it lately and will probably restart soon with a different approach. Still need to think about git-rm and git-mv as they also accept directories (i.e. not exactly pathspec by definition). -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
Junio C Hamano writes:
> In other words, you can do this from the command line if you want
> to do the update.
>
> $ git fetch origin master:refs/remotes/origin/master
Now having said all that, we should probably revisit this and
possibly other issues and for the ones we can reach concensus, start
coding after 1.8.0 final.
A good place to start may be $gmane/167149, where I listed (among
other things that turned out to be undesirable, which are omitted in
this copy):
* "git branch --set-upstream " should not be about setting the
upstream of to the current branch.
This has happened during 1.8.0 cycle [CMN].
* "git push" default semantics will be "upstream" (renamed from
"tracking"), not "matching".
1.8.0 has the first step toward this [MM].
* "git merge" without "what to merge" default to @{upstream}
This is not acceptable for the default, but the users can ask for
it with merge.defaultToUpstream since 1.7.5 era [JC]
* Unify pathspec semantics
This has happened and commands that used to take only path prefix
style pathspecs now take globs as well [ND]
* "git fetch $from $branch..." to update tracking branches
This is the topic in this thread.
I personally do not think the downside of breaking backward
compatibility is too bad. If we do this only when we already are
configured to keep remote tracking branch for branch $branch from
remote $from (it has to be given as a nickname, not URL that happens
to have an entry in the configuration), then a promiscuous fetch
that grabs from a URL (or a nickname that is configured not to keep
tracking branches) will not change any behaviour, and when you want
to keep your remote tracking branch intact while doing one-shot
fetch for whatever reason, you can say "git fetch $from $branch:" to
explicitly decline copying.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
Junio C Hamano writes: > Angelo Borsotti writes: > >> git fetch does not create the remote refs in >> the current (local) >> repository... >> However, if a git fetch origin is executed, the refs are properly created: > > Working as designed and documented. > > $ git fetch origin master > > is giving the refspec "master" from the command line which is a > short-hand for "refs/heads/master". > > When you run > > $ git fetch origin > > configured refspec is looked up from your config (because you didn't > give any from the command line). The default refspec in your config > is likely to be "refs/heads/*:refs/remotes/origin/*". > > The former, "refs/heads/master" refspec, tells Git not to update the > remote tracking branch. The latter has colon and right-hand-side of > the colon tells Git what to update with what was fetched. > > It would hlep to read up on refspec by running "git fetch --help" > and looking for a string "colon". Addendum. Your claim >> git fetch does not create the remote refs in >> the current (local) >> repository... is incorrect. The behaviour depends on what you give. In other words, you can do this from the command line if you want to do the update. $ git fetch origin master:refs/remotes/origin/master -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fetch documentation problem or bug
Angelo Borsotti writes: > git fetch does not create the remote refs in > the current (local) > repository... > However, if a git fetch origin is executed, the refs are properly created: Working as designed and documented. $ git fetch origin master is giving the refspec "master" from the command line which is a short-hand for "refs/heads/master". When you run $ git fetch origin configured refspec is looked up from your config (because you didn't give any from the command line). The default refspec in your config is likely to be "refs/heads/*:refs/remotes/origin/*". The former, "refs/heads/master" refspec, tells Git not to update the remote tracking branch. The latter has colon and right-hand-side of the colon tells Git what to update with what was fetched. It would hlep to read up on refspec by running "git fetch --help" and looking for a string "colon". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
