kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Shawn O. Pearce	ab865e6eec	Avoid printing unnecessary warnings during fetch and push If a transport doesn't support an option we already are telling the higher level application (fetch or push) that the option is not valid by sending back a >0 return value from transport_set_option so there's not a strong motivation to have the function perform the output itself. Instead we should let the higher level application do the output if it is necessary. This avoids always telling the user that depth isn't supported on HTTP urls even when they did not pass a --depth option to git-fetch. If the user passes an option and the option value is invalid we now properly die in git-fetch instead of just spitting out a message and running anyway. This mimics prior behavior better where incorrect/malformed options are not accepted by the process. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	85682c1903	Correct handling of branch.$name.merge in builtin-fetch My prior bug fix for git-push titled "Don't configure remote "." to fetch everything to itself" actually broke t5520 as we were unable to evaluate a branch configuration of: [branch "copy"] remote = . merge = refs/heads/master as remote "." did not have a "remote...fetch" configuration entry to offer up refs/heads/master as a possible candidate available to be fetched and merged. In shell script git-fetch and prior to the above mentioned commit this was hardcoded for a url of "." to be the set of local branches. Chasing down this bug led me to the conclusion that our prior behavior with regards to branch.$name.merge was incorrect. In the shell script based git-fetch implementation we only fetched and merged a branch if it appeared both in branch.$name.merge and in remote.$r.fetch, where $r = branch.$name.remote. In other words in the following config file: [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master [branch "pu"] remote = origin merge = refs/heads/pu Attempting to run `git pull` while on branch "pu" would always give the user "Already up-to-date" as git-fetch did not fetch pu and thus did not mark it for merge in .git/FETCH_HEAD. The configured merge would always be ignored and the user would be left scratching her confused head wondering why merge did not work on "pu" but worked fine on "master". If we are using the "default fetch" specification for the current branch and the current branch has a branch.$name.merge configured we now union it with the list of refs in remote.$r.fetch. This way the above configuration does what the user expects it to do, which is to fetch only "master" by default but when on "pu" to fetch both "master" and "pu". This uncovered some breakage in the test suite where old-style Cogito branches (.git/branches/$r) did not fetch the branches listed in .git/config for merging and thus did not actually merge them if the user tried to use `git pull` on that branch. Junio and I discussed it on list and felt that the union approach here makes more sense to DWIM for the end-user than silently ignoring their configured request so the test vectors for t5515 have been updated to include for-merge lines in .git/FETCH_HEAD where they have been configured for-merge in .git/config. Since we are now performing a union of the fetch specification and the merge specification and we cannot allow a branch to be listed twice (otherwise it comes out twice in .git/FETCH_HEAD) we need to perform a double loop here over all of the branch.$name.merge lines and try to set their merge flag if we have already schedule that branch for fetching by remote.$r.fetch. If no match is found then we must add new specifications to fetch the branch but not store it as no local tracking branch has been designated. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	f38395905b	Remove more debugging from builtin-fetch Older git-fetch.sh doesn't print "ref: X" when invoked as `git fetch $url X" so we shouldn't do that now in the new builtin version. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	b3abdd9d21	Allow builtin-fetch to work on a detached HEAD If we are running fetch in a repository that has a detached HEAD then there is no current_branch available. In such a case any ref that the fetch might update by definition cannot also be the current branch so we should always bypass the "don't update HEAD" test. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	e5f4e21463	Remove unnecessary 'fetch' argument from transport_get API We don't actually need to know at the time of transport_get if the caller wants to fetch, push, or do both on the returned object. It is easier to just delay the initialization of the HTTP walker until we know we will need it by providing a CURL specific fetch function in the curl_transport that makes sure the walker instance is initialized before use. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	e4022ed2c8	Always ensure the pack.keep file is removed by git-fetch If we are using a native transport and the transport chose to save the packfile it may have created a .keep file to protect the packfile from a concurrently running git-repack process. In such a case the git-fetch process should make sure it will unlink the .keep file even if it fails to update any refs as otherwise the newly downloaded packfile's diskspace will never be reclaimed if the objects are not actually referenced. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	1788c39cd0	Remove pack.keep after ref updates in git-fetch If we are using a native packfile to perform a git-fetch invocation and the received packfile contained more than the configured limits of fetch.unpackLimit/transfer.unpackLimit then index-pack will output a single line saying "keep\t$sha1\n" to stdout. This line needs to be captured and retained so we can delete the corresponding .keep file ("$GIT_DIR/objects/pack/pack-$sha1.keep") once all refs have been safely updated. This trick has long been in use with git-fetch.sh and its lower level helper git-fetch--tool as a way to allow index-pack to save the new packfile before the refs have been updated and yet avoid a race with any concurrently running git-repack process. It was unfortunately lost when git-fetch.sh was converted to pure C and fetch--tool was no longer being invoked. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	425b139313	Simplify fetch transport API to just one function Commit walkers need to know the SHA-1 name of any objects they have been asked to fetch while the native pack transport only wants to know the names of the remote refs as the remote side must do the name->SHA-1 translation. Since we only have three fetch implementations and one of them (bundle) doesn't even need the name information we can reduce the code required to perform a fetch by having just one function and passing of the filtered list of refs to be fetched. Each transport can then obtain the information it needs from that ref array to construct its own internal operation state. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Conflicts: transport.c Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	f1ae391e17	Remove unused unpacklimit variable from builtin-fetch Never referenced. This should actually be handled down inside of builtin-fetch-pack, not up here in the generic user frontend. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	133296f00c	Remove unnecessary debugging from builtin-fetch The older git-fetch client did not produce all of this debugging information to stdout. Most end-users and Porcelain (e.g. StGIT, git-gui, qgit) do not want to see these low-level details on the console so they should be removed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	4ad1eada97	Fix off by one bug in reflog messages written by builtin-fetch We are adding a space between each argument in the sprintf above so we must account for this as we update our position within the reflog message and append in any remaining arguments. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Shawn O. Pearce	1aad91f5a7	Correct builtin-fetch to handle + in refspecs If we are fetching to a local reference (the so called peer_ref) and the refspec that created this ref/peer_ref association had started with '+' we are supposed to allow a non-fast-forward update during fetch, even if --force was not supplied on the command line. The builtin-fetch implementation was not honoring this setting as it was copied from the wrong struct ref instance. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Daniel Barkalow	b888d61c83	Make fetch a builtin Thanks to Johannes Schindelin for review and fixes, and Julian Phillips for the original C translation. This changes a few small bits of behavior: branch.<name>.merge is parsed as if it were the lhs of a fetch refspec, and does not have to exactly match the actual lhs of a refspec, so long as it is a valid abbreviation for the same ref. branch.<name>.merge is no longer ignored if the remote is configured with a branches/* file. Neither behavior is useful, because there can only be one ref that gets fetched, but this is more consistant. Also, fetch prints different information to standard out. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago

1 2

71 Commits (fc71db39e0d75e8a403f36f3fecf4450886cd165)