summaryrefslogtreecommitdiff
path: root/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2013-10-28Merge branch 'jk/remote-literal-string-leakfix'Libravatar Junio C Hamano1-1/+1
* jk/remote-literal-string-leakfix: remote: do not copy "origin" string literal
2013-10-15remote: do not copy "origin" string literalLibravatar Jeff King1-1/+1
Our default_remote_name starts at "origin", but may be overridden by the config file. In the former case, we allocate a new string, but in the latter case, we point to the remote name in an existing "struct branch". This gives the variable inconsistent free() semantics (we are sometimes responsible for freeing the string and sometimes pointing to somebody else's storage), and causes a small leak when the allocated string is overridden by config. We can fix both by simply dropping the extra copy and pointing to the string literal. Noticed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-20Merge branch 'jx/branch-vv-always-compare-with-upstream'Libravatar Junio C Hamano1-25/+47
"git branch -v -v" (and "git status") did not distinguish among a branch that does not build on any other branch, a branch that is in sync with the branch it builds on, and a branch that is configured to build on some other branch that no longer exists. * jx/branch-vv-always-compare-with-upstream: status: always show tracking branch even no change branch: report invalid tracking branch as gone
2013-09-09Merge branch 'jc/push-cas'Libravatar Junio C Hamano1-13/+162
Allow a safer "rewind of the remote tip" push than blind "--force", by requiring that the overwritten remote ref to be unchanged since the new history to replace it was prepared. The machinery is more or less ready. The "--force" option is again the big red button to override any safety, thanks to J6t's sanity (the original round allowed --lockref to defeat --force). The logic to choose the default implemented here is fragile (e.g. "git fetch" after seeing a failure will update the remote-tracking branch and will make the next "push" pass, defeating the safety pretty easily). It is suitable only for the simplest workflows, and it may hurt users more than it helps them. * jc/push-cas: push: teach --force-with-lease to smart-http transport send-pack: fix parsing of --force-with-lease option t5540/5541: smart-http does not support "--force-with-lease" t5533: test "push --force-with-lease" push --force-with-lease: tie it all together push --force-with-lease: implement logic to populate old_sha1_expect[] remote.c: add command line option parser for "--force-with-lease" builtin/push.c: use OPT_BOOL, not OPT_BOOLEAN cache.h: move remote/connect API out of it
2013-09-09Merge branch 'ms/fetch-prune-configuration'Libravatar Junio C Hamano1-0/+3
Allow fetch.prune and remote.*.prune configuration variables to be set, and "git fetch" to behave as if "--prune" is given. "git fetch" that honors remote.*.prune is fine, but I wonder if we should somehow make "git push" aware of it as well. Perhaps remote.*.prune should not be just a boolean, but a 4-way "none", "push", "fetch", "both"? * ms/fetch-prune-configuration: fetch: make --prune configurable
2013-08-26status: always show tracking branch even no changeLibravatar Jiang Xin1-3/+4
In order to see what the current branch is tracking, one way is using "git branch -v -v", but branches other than the current are also reported. Another way is using "git status", such as: $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. ... But this will not work if there is no change between the current branch and its upstream. Always report upstream tracking info even if there is no difference, so that "git status" is consistent for checking tracking info for current branch. E.g. $ git status # On branch feature1 # Your branch is up-to-date with 'github/feature1'. ... $ git status -bs ## feature1...github/feature1 ... $ git checkout feature1 Already on 'feature1' Your branch is up-to-date with 'github/feature1'. ... Also add some test cases in t6040. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-26branch: report invalid tracking branch as goneLibravatar Jiang Xin1-25/+46
Command "git branch -vv" will report tracking branches, but invalid tracking branches are also reported. This is because the function stat_tracking_info() can not distinguish invalid tracking branch from other cases which it would not like to report, such as there is no upstream settings at all, or nothing is changed between one branch and its upstream. Junio suggested missing upstream should be reported [1] like: $ git branch -v -v master e67ac84 initial * topic 3fc0f2a [topicbase: gone] topic $ git status # On branch topic # Your branch is based on 'topicbase', but the upstream is gone. # (use "git branch --unset-upstream" to fixup) ... $ git status -b -s ## topic...topicbase [gone] ... In order to do like that, we need to distinguish these three cases (i.e. no tracking, with configured but no longer valid tracking, and with tracking) in function stat_tracking_info(). So the refactored function stat_tracking_info() has three return values: -1 (with "gone" base), 0 (no base), and 1 (with base). If the caller does not like to report tracking info when nothing changed between the branch and its upstream, simply checks if num_theirs and num_ours are both 0. [1]: http://thread.gmane.org/gmane.comp.version-control.git/231830/focus=232288 Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22push --force-with-lease: tie it all togetherLibravatar Junio C Hamano1-13/+36
This teaches the deepest part of the callchain for "git push" (and "git send-pack") to enforce "the old value of the ref must be this, otherwise fail this push" (aka "compare-and-swap" / "--lockref"). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22push --force-with-lease: implement logic to populate old_sha1_expect[]Libravatar Junio C Hamano1-0/+61
This plugs the push_cas_option data collected by the command line option parser to the transport system with a new function apply_push_cas(), which is called after match_push_refs() has already been called. At this point, we know which remote we are talking to, and what remote refs we are going to update, so we can fill in the details that may have been missing from the command line, such as (1) what abbreviated refname the user gave us matches the actual refname at the remote; and (2) which remote-tracking branch in our local repository to read the value of the object to expect at the remote. to populate the old_sha1_expect[] field of each of the remote ref. As stated in the documentation, the use of remote-tracking branch as the default is a tentative one, and we may come up with a better logic as we gain experience. Still nobody uses this information, which is the topic of the next patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22remote.c: add command line option parser for "--force-with-lease"Libravatar Junio C Hamano1-0/+57
Update "git push" and "git send-pack" to parse this commnd line option. The intended sematics is: * "--force-with-lease" alone, without specifying the details, will protect _all_ remote refs that are going to be updated by requiring their current value to be the same as some reasonable default, unless otherwise specified; * "--force-with-lease=refname", without specifying the expected value, will protect that refname, if it is going to be updated, by requiring its current value to be the same as some reasonable default. * "--force-with-lease=refname:value" will protect that refname, if it is going to be updated, by requiring its current value to be the same as the specified value; and * "--no-force-with-lease" will cancel all the previous --force-with-lease on the command line. For now, "some reasonable default" is tentatively defined as "the value of the remote-tracking branch we have for the ref of the remote being updated", and it is an error if we do not have such a remote-tracking branch. But this is known to be fragile, its use is not yet recommended, and hopefully we will find more reasonable default as we gain experience with this feature. The manual marks the feature as experimental unless the expected value is specified explicitly for this reason. Because the command line options are parsed _before_ we know which remote we are pushing to, there needs further processing to the parsed data after we instantiate the transport object to: * expand "refname" given by the user to a full refname to be matched with the list of "struct ref" used in match_push_refs() and set_ref_status_for_push(); and * learning the actual local ref that is the remote-tracking branch for the specified remote ref. Further, some processing need to be deferred until we find the set of remote refs and match_push_refs() returns in order to find the ones that need to be checked after explicit ones have been processed for "--force-with-lease" (no specific details). These post-processing will be the topic of the next patch. This option was originally called "cas" (for "compare and swap"), the name which nobody liked because it was too technical. The second attempt called it "lockref" (because it is conceptually like pushing after taking a lock) but the word "lock" was hated because it implied that it may reject push by others, which is not the way this option works. This round calls it "force-with-lease". You assume you took the lease on the ref when you fetched to decide what the rebased history should be, and you can push back only if the lease has not been broken. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18fetch: make --prune configurableLibravatar Michael Schubert1-0/+3
Without "git fetch --prune", remote-tracking branches for a branch the other side already has removed will stay forever. Some people want to always run "git fetch --prune". To accommodate users who want to either prune always or when fetching from a particular remote, add two new configuration variables "fetch.prune" and "remote.<name>.prune": - "fetch.prune" allows to enable prune for all fetch operations. - "remote.<name>.prune" allows to change the behaviour per remote. The latter will naturally override the former, and the --[no-]prune option from the command line will override the configured default. Since --prune is a potentially destructive operation (Git doesn't keep reflogs for deleted references yet), we don't want to prune without users consent, so this configuration will not be on by default. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael Schubert <mschub@elegosoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18Merge branch 'bc/push-match-many-refs'Libravatar Junio C Hamano1-2/+25
Pushing to repositories with many refs employed O(m*n) algorithm where n is the number of refs on the receiving end. * bc/push-match-many-refs: remote.c: avoid O(m*n) behavior in match_push_refs
2013-07-08cache.h: move remote/connect API out of itLibravatar Junio C Hamano1-0/+8
The definition of "struct ref" in "cache.h", a header file so central to the system, always confused me. This structure is not about the local ref used by sha1-name API to name local objects. It is what refspecs are expanded into, after finding out what refs the other side has, to define what refs are updated after object transfer succeeds to what values. It belongs to "remote.h" together with "struct refspec". While we are at it, also move the types and functions related to the Git transport connection to a new header file connect.h Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-08remote.c: avoid O(m*n) behavior in match_push_refsLibravatar Brandon Casey1-2/+25
When pushing using a matching refspec or a pattern refspec, each ref in the local repository must be paired with a ref advertised by the remote server. This is accomplished by using the refspec to transform the name of the local ref into the name it should have in the remote repository, and then performing a linear search through the list of remote refs to see if the remote ref was advertised by the remote system. Each of these lookups has O(n) complexity and makes match_push_refs() be an O(m*n) operation, where m is the number of local refs and n is the number of remote refs. If there are many refs 100,000+, then this ref matching can take a significant amount of time. Let's prepare an index of the remote refs to allow searching in O(log n) time and reduce the complexity of match_push_refs() to O(m log n). We prepare the index lazily so that it is only created when necessary. So, there should be no impact when _not_ using a matching or pattern refspec, i.e. when pushing using only explicit refspecs. Dry-run push of a repository with 121,913 local and remote refs: before after real 1m40.582s 0m0.804s user 1m39.914s 0m0.515s sys 0m0.125s 0m0.106s The creation of the index has overhead. So, if there are very few local refs, then it could take longer to create the index than it would have taken to just perform n linear lookups into the remote ref space. Using the index should provide some improvement when the number of local refs is roughly greater than the log of the number of remote refs (i.e. m >= log n). The pathological case is when there is a single local ref and very many remote refs. Dry-run push of a repository with 121,913 remote refs and a single local ref: before after real 0m0.525s 0m0.566s user 0m0.243s 0m0.279s sys 0m0.075s 0m0.099s Using an index takes 41 ms longer, or roughly 7.8% longer. Jeff King measured a no-op push of a single ref into a remote repo with 370,000 refs: before after real 0m1.087s 0m1.156s user 0m1.344s 0m1.412s sys 0m0.288s 0m0.284s Using an index takes 69 ms longer, or roughly 6.3% longer. None of the measurements above required transferring any objects to the remote repository. If the push required transferring objects and updating the refs in the remote repository, the impact of preparing the search index would be even smaller. A similar operation is performed in the reverse direction when pruning using a matching or pattern refspec. Let's avoid O(m*n) behavior in the same way by lazily preparing an index on the local refs. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23remote: remove dead code in read_branches_file()Libravatar Ramkumar Ramachandra1-19/+4
The first line of the function checks that the remote-name contains a slash ('/'), and sets the "slash" variable accordingly. The only caller of read_branches_file() is remote_get_1(); the calling codepath is guarded by valid_remote_nick(), which checks that the remote does not contain a slash. Therefore, the "slash" variable can never be set: remove the dead code that assumes otherwise. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28remote: trivial style cleanupLibravatar Felipe Contreras1-2/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02remote.c: introduce branch.<name>.pushremoteLibravatar Ramkumar Ramachandra1-0/+4
This new configuration variable overrides `remote.pushdefault` and `branch.<name>.remote` for pushes. When you pull from one place (e.g. your upstream) and push to another place (e.g. your own publishing repository), you would want to set `remote.pushdefault` to specify the remote to push to for all branches, and use this option to override it for a specific branch. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02remote.c: introduce remote.pushdefaultLibravatar Ramkumar Ramachandra1-0/+7
This new configuration variable defines the default remote to push to, and overrides `branch.<name>.remote` for all branches. It is useful in the typical triangular-workflow setup, where the remote you're fetching from is different from the remote you're pushing to. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02remote.c: introduce a way to have different remotes for fetch/pushLibravatar Ramkumar Ramachandra1-4/+21
Currently, do_push() in push.c calls remote_get(), which gets the configured remote for fetching and pushing. Replace this call with a call to pushremote_get() instead, a new function that will return the remote configured specifically for pushing. This function tries to work with the string pushremote_name, before falling back to the codepath of remote_get(). This patch has no visible impact, but serves to enable future patches to introduce configuration variables to set pushremote_name. For example, you can now do the following in handle_config(): if (!strcmp(key, "remote.pushdefault")) git_config_string(&pushremote_name, key, value); Then, pushes will automatically go to the remote specified by remote.pushdefault. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02remote.c: simplify a bit of code using git_config_string()Libravatar Ramkumar Ramachandra1-3/+2
A small segment where handle_config() parses the branch.remote configuration variable can be simplified using git_config_string(). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'jc/nobody-sets-src-peer-ref'Libravatar Junio C Hamano1-3/+0
Dead code removal. * jc/nobody-sets-src-peer-ref: match_push_refs(): nobody sets src->peer_ref anymore
2013-03-25Merge branch 'jc/push-follow-tag'Libravatar Junio C Hamano1-0/+99
The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out. * jc/push-follow-tag: push: --follow-tags commit.c: use clear_commit_marks_many() in in_merge_bases_many() commit.c: add in_merge_bases_many() commit.c: add clear_commit_marks_many()
2013-03-21Merge branch 'jc/fetch-raw-sha1'Libravatar Junio C Hamano1-18/+23
Allows requests to fetch objects at any tip of refs (including hidden ones). It seems that there may be use cases even outside Gerrit (e.g. $gmane/215701). * jc/fetch-raw-sha1: fetch: fetch objects by their exact SHA-1 object names upload-pack: optionally allow fetching from the tips of hidden refs fetch: use struct ref to represent refs to be fetched parse_fetch_refspec(): clarify the codeflow a bit
2013-03-05push: --follow-tagsLibravatar Junio C Hamano1-0/+99
The new option "--follow-tags" tells "git push" to push annotated tags that are missing from the other side and that can be reached by the history that is otherwise pushed out. For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the commit at your current HEAD and nothing else. With this option, you would also push all annotated tags that can be reached from that commit to the other side. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-04match_push_refs(): nobody sets src->peer_ref anymoreLibravatar Junio C Hamano1-3/+0
In ancient times, we used to disallow the same source ref to be pushed to more than one places, e.g. "git push there master:master master:naster" was disallowed. We later lifted this restriction with db27ee63929f (send-pack: allow the same source to be pushed more than once., 2005-08-06) and there no longer is anybody that sets peer_ref for the source side of the ref list in the push codepath since then. Remove one leftover no-op in a loop that iterates over the source side of ref list (i.e. our local ref) to see if it can/should be sent to a matching destination ref while skipping ones that is marked with peer_ref (which will never exist, so we do not skip anything). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07fetch: fetch objects by their exact SHA-1 object namesLibravatar Junio C Hamano1-1/+11
Teach "git fetch" to accept an exact SHA-1 object name the user may obtain out of band on the LHS of a pathspec, and send it on a "want" message when the server side advertises the allow-tip-sha1-in-want capability. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07parse_fetch_refspec(): clarify the codeflow a bitLibravatar Junio C Hamano1-17/+12
Most parts of the cascaded if/else if/... checked an allowable condition but some checked forbidden conditions. This makes adding new allowable conditions unnecessarily inconvenient. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-04Merge branch 'jc/push-reject-reasons'Libravatar Junio C Hamano1-23/+19
Improve error and advice messages given locally when "git push" refuses when it cannot compute fast-forwardness by separating these cases from the normal "not a fast-forward; merge first and push again" case. * jc/push-reject-reasons: push: finishing touches to explain REJECT_ALREADY_EXISTS better push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection reason push: further clean up fields of "struct ref"
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCELibravatar Junio C Hamano1-3/+8
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24push: further simplify the logic to assign rejection reasonLibravatar Junio C Hamano1-16/+11
First compute the reason why this push would fail if done without "--force", and then fail it by assigning that reason when the push was not forced (or if there is no reason to require force, allow it to succeed). Record the fact that the push was forced in the forced_update field only when the push would have failed without the option. The code becomes shorter, less repetitive and easier to read this way, especially given that the set of rejection reasons will be extended in a later patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24push: further clean up fields of "struct ref"Libravatar Junio C Hamano1-10/+6
The "nonfastforward" and "update" fields are only used while deciding what value to assign to the "status" locally in a single function. Remove them from the "struct ref". The "requires_force" field is not used to decide if the proposed update requires a --force option to succeed, or to record such a decision made elsewhere. It is used by status reporting code that the particular update was "forced". Rename it to "forced_update", and move the code to assign to it around to further clarify how it is used and what it is used for. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23Merge branch 'cr/push-force-tag-update'Libravatar Junio C Hamano1-36/+7
Regression fix to stop "git push" complaining "target ref already exists", when it is not the real reason the command rejected the request (e.g. non-fast-forward). * cr/push-force-tag-update: push: fix "refs/tags/ hierarchy cannot be updated without --force"
2013-01-16push: fix "refs/tags/ hierarchy cannot be updated without --force"Libravatar Junio C Hamano1-36/+7
When pushing to update a branch with a commit that is not a descendant of the commit at the tip, a wrong message "already exists" was given, instead of the correct "non-fast-forward", if we do not have the object sitting in the destination repository at the tip of the ref we are updating. The primary cause of the bug is that the check in a new helper function is_forwardable() assumed both old and new objects are available and can be checked, which is not always the case. The way the caller uses the result of this function is also wrong. If the helper says "we do not want to let this push go through", the caller unconditionally translates it into "we blocked it because the destination already exists", which is not true at all in this case. Fix this by doing these three things: * Remove unnecessary not_forwardable from "struct ref"; it is only used inside set_ref_status_for_push(); * Make "refs/tags/" the only hierarchy that cannot be replaced without --force; * Remove the misguided attempt to force that everything that updates an existing ref has to be a commit outside "refs/tags/" hierarchy. The policy last one tried to implement may later be resurrected and extended to ensure fast-forwardness (defined as "not losing objects", extending from the traditional "not losing commits from the resulting history") when objects that are not commit are involved (e.g. an annotated tag in hierarchies outside refs/tags), but such a logic belongs to "is this a fast-forward?" check that is done by ref_newer(); is_forwardable(), which is now removed, was not the right place to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11Merge branch 'jc/fetch-ignore-symref' into maintLibravatar Junio C Hamano1-1/+12
"git fetch --mirror" and fetch that uses other forms of refspec with wildcard used to attempt to update a symbolic ref that match the wildcard on the receiving end, which made little sense (the real ref that is pointed at by the symbolic ref would be updated anyway). Symbolic refs no longer are affected by such a fetch. * jc/fetch-ignore-symref: fetch: ignore wildcarded refspecs that update local symbolic refs
2013-01-05Merge branch 'jc/fetch-ignore-symref'Libravatar Junio C Hamano1-1/+12
Avoid false error from an attempt to update local symbolic ref via fetch. * jc/fetch-ignore-symref: fetch: ignore wildcarded refspecs that update local symbolic refs
2013-01-05Merge branch 'cr/push-force-tag-update'Libravatar Junio C Hamano1-20/+63
Require "-f" for push to update a tag, even if it is a fast-forward. * cr/push-force-tag-update: push: allow already-exists advice to be disabled push: rename config variable for more general use push: cleanup push rules comment push: clarify rejection of update to non-commit-ish push: require force for annotated tags push: require force for refs under refs/tags/ push: flag updates that require force push: keep track of "update" state separately push: add advice for rejected tag reference push: return reject reasons as a bitset
2012-12-11fetch: ignore wildcarded refspecs that update local symbolic refsLibravatar Junio C Hamano1-1/+12
In a repository cloned from somewhere else, you typically have a symbolic ref refs/remotes/origin/HEAD pointing at the 'master' remote-tracking ref that is next to it. When fetching into such a repository with "git fetch --mirror" from another repository that was similarly cloned, the implied wildcard refspec refs/*:refs/* will end up asking to update refs/remotes/origin/HEAD with the object at refs/remotes/origin/HEAD at the remote side, while asking to update refs/remotes/origin/master the same way. Depending on the order the two updates happen, the latter one would find that the value of the ref before it is updated has changed from what the code expects. When the user asks to update the underlying ref via the symbolic ref explicitly without using a wildcard refspec, e.g. "git fetch $there refs/heads/master:refs/remotes/origin/HEAD", we should still let him do so, but when expanding wildcard refs, it will result in a more intuitive outcome if we simply ignore local symbolic refs. As the purpose of the symbolic ref refs/remotes/origin/HEAD is to follow the ref it points at (e.g. refs/remotes/origin/master), its value would change when the underlying ref is updated. Earlier commit da3efdb (receive-pack: detect aliased updates which can occur with symrefs, 2010-04-19) fixed a similar issue for "git push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03Merge branch 'mm/status-push-pull-advise'Libravatar Junio C Hamano1-6/+9
Finishing touch to allow the new advice message squelched with an advice.* configuration variable. * mm/status-push-pull-advise: status: respect advice.statusHints for ahead/behind advice
2012-12-03status: respect advice.statusHints for ahead/behind adviceLibravatar Jeff King1-6/+9
If the user has unset advice.statusHints, we already suppress the "use git reset to..." hints in each stanza. The new "use git push to publish..." hint is the same type of hint. Let's respect statusHints for it, rather than making the user set yet another advice flag. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03push: cleanup push rules commentLibravatar Chris Rorvick1-15/+17
Rewrite to remove inter-dependencies amongst the rules. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: clarify rejection of update to non-commit-ishLibravatar Chris Rorvick1-0/+5
Pushes must already (by default) update to a commit-ish due to the fast- forward check in set_ref_status_for_push(). But rejecting for not being a fast-forward suggests the situation can be resolved with a merge. Flag these updates (i.e., to a blob or a tree) as not forwardable so the user is presented with more appropriate advice. While updating *from* a tag object is potentially destructive, updating *to* a tag is not. Additionally, a push to the refs/tags/ hierarchy is already excluded from fast-forwarding, and refs/heads/ is protected from anything but commit objects by a check in write_ref_sha1(). Thus someone fast-forwarding to a tag is probably not doing so by accident. Since updating to a tag is benign and unlikely to cause confusion, allow it in case someone finds the behavior useful. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: require force for annotated tagsLibravatar Chris Rorvick1-2/+9
Do not allow fast-forwarding of references that point to a tag object. Updating from a tag is potentially destructive since it would likely leave the tag dangling. Disallowing updates to a tag also makes sense semantically and is consistent with the behavior of lightweight tags. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: require force for refs under refs/tags/Libravatar Chris Rorvick1-4/+14
References are allowed to update from one commit-ish to another if the former is an ancestor of the latter. This behavior is oriented to branches which are expected to move with commits. Tag references are expected to be static in a repository, though, thus an update to something under refs/tags/ should be rejected unless the update is forced. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: flag updates that require forceLibravatar Chris Rorvick1-3/+8
Add a flag for indicating an update to a reference requires force. Currently the `nonfastforward` flag is used for this when generating the status message. A separate flag insulates dependent logic from the details of set_ref_status_for_push(). Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: keep track of "update" state separatelyLibravatar Chris Rorvick1-7/+11
If the reference exists on the remote and it is not being removed, then mark as an update. This is in preparation for handling tags (lightweight and annotated) exceptionally. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: add advice for rejected tag referenceLibravatar Chris Rorvick1-0/+10
Advising the user to fetch and merge only makes sense if the rejected reference is a branch. If none of the rejections are for branches, just tell the user the reference already exists. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28Merge branch 'mm/status-push-pull-advise'Libravatar Junio C Hamano1-3/+10
* mm/status-push-pull-advise: status: add advice on how to push/pull to tracking branch
2012-11-16status: add advice on how to push/pull to tracking branchLibravatar Matthieu Moy1-3/+10
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-15Merge branch 'jc/maint-fetch-tighten-refname-check'Libravatar Junio C Hamano1-2/+2
For a fetch refspec (or the result of applying wildcard on one), we always want the RHS to map to something inside "refs/" hierarchy. This was split out from discarded jc/maint-push-refs-all topic. * jc/maint-fetch-tighten-refname-check: get_fetch_map(): tighten checks on dest refs
2012-10-19get_fetch_map(): tighten checks on dest refsLibravatar Junio C Hamano1-2/+2
The code to check the refname we store the fetched result locally did not bother checking the first 5 bytes of it, presumably assuming that it always begin with "refs/". For a fetch refspec (or the result of applying wildcard on one), we always want the RHS to map to something inside "refs/" hierarchy, so let's spell that rule out in a more explicit way. Signed-off-by: Junio C Hamano <gitster@pobox.com>