summaryrefslogtreecommitdiff
path: root/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2015-02-24Merge branch 'jk/blame-commit-label' into maintLibravatar Junio C Hamano1-2/+2
"git blame HEAD -- missing" failed to correctly say "HEAD" when it tried to say "No such path 'missing' in HEAD". * jk/blame-commit-label: blame.c: fix garbled error message use xstrdup_or_null to replace ternary conditionals builtin/commit.c: use xstrdup_or_null instead of envdup builtin/apply.c: use xstrdup_or_null instead of null_strdup git-compat-util: add xstrdup_or_null helper
2015-01-13use xstrdup_or_null to replace ternary conditionalsLibravatar Jeff King1-2/+2
This replaces "x ? xstrdup(x) : NULL" with xstrdup_or_null(x). The change is fairly mechanical, with the exception of resolve_refdup, which can eliminate a temporary variable. There are still a few hits grepping for "?.*xstrdup", but these are of slightly different forms and cannot be converted (e.g., "x ? xstrdup(x->foo) : NULL"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07Merge branch 'jc/checkout-local-track-report'Libravatar Junio C Hamano1-11/+23
The report from "git checkout" on a branch that builds on another local branch by setting its branch.*.merge to branch name (not a full refname) incorrectly said that the upstream is gone. * jc/checkout-local-track-report: checkout: report upstream correctly even with loosely defined branch.*.merge
2014-11-25sort_string_list(): rename to string_list_sort()Libravatar Michael Haggerty1-3/+3
The new name is more consistent with the names of other string_list-related functions. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15refs.c: change resolve_ref_unsafe reading argument to be a flags fieldLibravatar Ronnie Sahlberg1-4/+7
resolve_ref_unsafe takes a boolean argument for reading (a nonexistent ref resolves successfully for writing but not for reading). Change this to be a flags field instead, and pass the new constant RESOLVE_REF_READING when we want this behaviour. While at it, swap two of the arguments in the function to put output arguments at the end. As a nice side effect, this ensures that we can catch callers that were unaware of the new API so they can be audited. Give the wrapper functions resolve_refdup and read_ref_full the same treatment for consistency. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-14checkout: report upstream correctly even with loosely defined branch.*.mergeLibravatar Junio C Hamano1-11/+23
When checking out a branch that is set to build on top of another branch (often, a remote-tracking branch), "git checkout" reports how your work relates to the other branch, e.g. Your branch is behind 'origin/master', and can be fast-forwarded. Back when this feature was introduced, this was only done for branches that build on remote-tracking branches, but 5e6e2b48 (Make local branches behave like remote branches when --tracked, 2009-04-01) added support to give the same report for branches that build on other local branches (i.e. branches whose branch.*.remote variables are set to '.'). Unlike the support for the branches building on remote-tracking branches, however, this did not take into account the fact that branch.*.merge configuration is allowed to record a shortened branch name. When branch.*.merge is set to 'master' (not 'refs/heads/master'), i.e. "my branch builds on the local 'master' branch", this caused "git checkout" to report: Your branch is based on 'master', but the upstream is gone. The upstream is our repository and is definitely not gone, so this output is nonsense. The fix is fairly obvious; just like the branch name is DWIMed when "git pull" merges from the 'master' branch without complaint on such a branch, the name of the branch the current branch builds upon needs to be DWIMed the same way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-22remote: simplify match_name_with_pattern() using strbufLibravatar René Scharfe1-12/+5
Make the code simpler and shorter by avoiding repetitive use of string length variables and leaving memory allocation to strbuf functions. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-09Merge branch 'sb/prepare-revision-walk-error-check'Libravatar Junio C Hamano1-1/+2
* sb/prepare-revision-walk-error-check: prepare_revision_walk(): check for return value in all places
2014-09-09Merge branch 'sb/plug-leaks'Libravatar Junio C Hamano1-3/+3
* sb/plug-leaks: clone.c: don't leak memory in cmd_clone remote.c: don't leak the base branch name in format_tracking_info
2014-08-12prepare_revision_walk(): check for return value in all placesLibravatar Stefan Beller1-1/+2
Even the documentation tells us: You should check if it returns any error (non-zero return code) and if it does not, you can start using get_revision() to do the iteration. In preparation for this commit, I grepped all occurrences of prepare_revision_walk and added error messages, when there were none. Signed-off-by: Stefan Beller <stefanbeller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-10remote.c: don't leak the base branch name in format_tracking_infoLibravatar Stefan Beller1-3/+3
Found by scan.coverity.com (Id: 1127809) Signed-off-by: Stefan Beller <stefanbeller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-30use a hashmap to make remotes fasterLibravatar Patrick Reynolds1-17/+46
Remotes are stored as an array, so looking one up or adding one without duplication is an O(n) operation. Reading an entire config file full of remotes is O(n^2) in the number of remotes. For a repository with tens of thousands of remotes, the running time can hit multiple minutes. Hash tables are way faster. So we add a hashmap from remote name to struct remote and use it for all lookups. The time to add a new remote to a repo that already has 50,000 remotes drops from ~2 minutes to < 1 second. We retain the old array of remotes so iterators proceed in config-file order. Signed-off-by: Patrick Reynolds <patrick.reynolds@github.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-09Merge branch 'jk/xstrfmt'Libravatar Junio C Hamano1-5/+1
* jk/xstrfmt: setup_git_env(): introduce git_path_from_env() helper unique_path: fix unlikely heap overflow walker_fetch: fix minor memory leak merge: use argv_array when spawning merge strategy sequencer: use argv_array_pushf setup_git_env: use git_pathdup instead of xmalloc + sprintf use xstrfmt to replace xmalloc + strcpy/strcat use xstrfmt to replace xmalloc + sprintf use xstrdup instead of xmalloc + strcpy use xstrfmt in favor of manual size calculations strbuf: add xstrfmt helper
2014-07-09Merge branch 'jk/skip-prefix'Libravatar Junio C Hamano1-3/+2
* jk/skip-prefix: http-push: refactor parsing of remote object names imap-send: use skip_prefix instead of using magic numbers use skip_prefix to avoid repeated calculations git: avoid magic number with skip_prefix fetch-pack: refactor parsing in get_ack fast-import: refactor parsing of spaces stat_opt: check extra strlen call daemon: use skip_prefix to avoid magic numbers fast-import: use skip_prefix for parsing input use skip_prefix to avoid repeating strings use skip_prefix to avoid magic numbers transport-helper: avoid reading past end-of-string fast-import: fix read of uninitialized argv memory apply: use skip_prefix instead of raw addition refactor skip_prefix to return a boolean avoid using skip_prefix as a boolean daemon: mark some strings as const parse_diff_color_slot: drop ofs parameter
2014-06-20Merge branch 'rs/more-starts-with'Libravatar Junio C Hamano1-1/+1
* rs/more-starts-with: Use starts_with() for C strings instead of memcmp()
2014-06-20use skip_prefix to avoid repeating stringsLibravatar Jeff King1-3/+2
It's a common idiom to match a prefix and then skip past it with strlen, like: if (starts_with(foo, "bar")) foo += strlen("bar"); This avoids magic numbers, but means we have to repeat the string (and there is no compiler check that we didn't make a typo in one of the strings). We can use skip_prefix to handle this case without repeating ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19use xstrfmt in favor of manual size calculationsLibravatar Jeff King1-5/+1
In many parts of the code, we do an ugly and error-prone malloc like: const char *fmt = "something %s"; buf = xmalloc(strlen(foo) + 10 + 1); sprintf(buf, fmt, foo); This makes the code brittle, and if we ever get the allocation wrong, is a potential heap overflow. Let's instead favor xstrfmt, which handles the allocation automatically, and makes the code shorter and more readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-09Use starts_with() for C strings instead of memcmp()Libravatar René Scharfe1-1/+1
Convert three cases of checking for a constant prefix using memcmp() to starts_with(). This way there is no need for magic string length constants and we avoid running over the end of the string should it be shorter than the prefix. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27remote.c: rearrange xcalloc argumentsLibravatar Brian Gesiak1-1/+1
xcalloc() takes two arguments: the number of elements and their size. parse_refspec_internal passes the arguments in reverse order, passing the size of a refspec, followed by the number to allocate. Rearrange them so they are in the correct order. Signed-off-by: Brian Gesiak <modocache@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano1-1/+1
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-04-03Merge branch 'cn/fetch-prune-overlapping-destination'Libravatar Junio C Hamano1-6/+44
Protect refs in a hierarchy that can come from more than one remote hierarcies from incorrect removal by "git fetch --prune". * cn/fetch-prune-overlapping-destination: fetch: handle overlaping refspecs on --prune fetch: add a failing test for prunning with overlapping refspecs
2014-03-31comments: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-26fetch: handle overlaping refspecs on --pruneLibravatar Carlos Martín Nieto1-6/+44
We need to consider that a remote-tracking branch may match more than one rhs of a fetch refspec. In such a case, it is not enough to stop at the first match but look at all of the matches in order to determine whether a head is stale. To this goal, introduce a variant of query_refspecs which returns all of the matching refspecs and loop over those answers to check for staleness. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18Merge branch 'jk/remote-pushremote-config-reading' into maintLibravatar Junio C Hamano1-1/+6
"git push" did not pay attention to branch.*.pushremote if it is defined earlier than remote.pushdefault; the order of these two variables in the configuration file should not matter, but it did by mistake. * jk/remote-pushremote-config-reading: remote: handle pushremote config in any order
2014-03-18Merge branch 'jk/detect-push-typo-early'Libravatar Junio C Hamano1-29/+75
Catch "git push $there no-such-branch" early. * jk/detect-push-typo-early: push: detect local refspec errors early match_explicit_lhs: allow a "verify only" mode match_explicit: hoist refspec lhs checks into their own function
2014-03-14Merge branch 'jk/remote-pushremote-config-reading'Libravatar Junio C Hamano1-1/+6
"git push" did not pay attention to branch.*.pushremote if it is defined earlier than remote.pushdefault; the order of these two variables in the configuration file should not matter, but it did by mistake. * jk/remote-pushremote-config-reading: remote: handle pushremote config in any order
2014-03-05push: detect local refspec errors earlyLibravatar Jeff King1-0/+25
When pushing, we do not even look at our push refspecs until after we have made contact with the remote receive-pack and gotten its list of refs. This means that we may go to some work, including asking the user to log in, before realizing we have simple errors like "git push origin matser". We cannot catch all refspec problems, since fully evaluating the refspecs requires knowing what the remote side has. But we can do a quick sanity check of the local side and catch a few simple error cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-05match_explicit_lhs: allow a "verify only" modeLibravatar Jeff King1-14/+24
The match_explicit_lhs function has all of the logic necessary to verify the refspecs without actually doing any work. This patch lets callers pass a NULL "match" pointer to indicate they want a "verify only" operation. For the most part, we just need to avoid writing to the NULL pointer. However, we also have to refactor the try_explicit_object_name sub-function; it indicates success by allocating and returning a new ref. Instead, we give it an "out" parameter for the match and return a numeric status. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-05match_explicit: hoist refspec lhs checks into their own functionLibravatar Jeff King1-19/+30
In preparation for being able to check the left-hand side of our push refspecs separately, this pulls the examination of them out into its own function. There should be no behavior change. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24remote: handle pushremote config in any orderLibravatar Jeff King1-1/+6
The remote we push can be defined either by remote.pushdefault or by branch.*.pushremote for the current branch. The order in which they appear in the config file should not matter to precedence (which should be to prefer the branch-specific config). The current code parses the config linearly and uses a single string to store both values, overwriting any previous value. Thus, config like: [branch "master"] pushremote = foo [remote] pushdefault = bar erroneously ends up pushing to "bar" from the master branch. We can fix this by storing both values and resolving the correct value after all config is read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27Merge branch 'mh/retire-ref-fetch-rules'Libravatar Junio C Hamano1-4/+4
Code simplification. * mh/retire-ref-fetch-rules: refname_match(): always use the rules in ref_rev_parse_rules
2014-01-14refname_match(): always use the rules in ref_rev_parse_rulesLibravatar Michael Haggerty1-4/+4
We used to use two separate rules for the normal ref resolution dwimming and dwimming done to decide which remote ref to grab. The third parameter to refname_match() selected which rules to use. When these two rules were harmonized in 2011-11-04 dd621df9cd refs DWIMmery: use the same rule for both "git fetch" and others , ref_fetch_rules was #defined to avoid potential breakages for in-flight topics. It is now safe to remove the backwards-compatibility code, so remove refname_match()'s third parameter, make ref_rev_parse_rules private to refs.c, and remove ref_fetch_rules entirely. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-27Merge branch 'jc/push-refmap'Libravatar Junio C Hamano1-4/+4
Make "git push origin master" update the same ref that would be updated by our 'master' when "git push origin" (no refspecs) is run while the 'master' branch is checked out, which makes "git push" more symmetric to "git fetch" and more usable for the triangular workflow. * jc/push-refmap: push: also use "upstream" mapping when pushing a single ref push: use remote.$name.push as a refmap builtin/push.c: use strbuf instead of manual allocation
2013-12-17Merge branch 'cc/starts-n-ends-with'Libravatar Junio C Hamano1-23/+23
Remove a few duplicate implementations of prefix/suffix comparison functions, and rename them to starts_with and ends_with. * cc/starts-n-ends-with: replace {pre,suf}fixcmp() with {starts,ends}_with() strbuf: introduce starts_with() and ends_with() builtin/remote: remove postfixcmp() and use suffixcmp() instead environment: normalize use of prefixcmp() by removing " != 0"
2013-12-12Merge branch 'mh/fetch-tags-in-addition-to-normal-refs'Libravatar Junio C Hamano1-28/+66
The "--tags" option to "git fetch" used to be literally a synonym to a "refs/tags/*:refs/tags/*" refspec, which meant that (1) as an explicit refspec given from the command line, it silenced the lazy "git fetch" default that is configured, and (2) also as an explicit refspec given from the command line, it interacted with "--prune" to remove any tag that the remote we are fetching from does not have. This demotes it to an option; with it, we fetch all tags in addition to what would be fetched without the option, and it does not interact with the decision "--prune" makes to see what remote-tracking refs the local has are missing the remote counterpart. * mh/fetch-tags-in-addition-to-normal-refs: (23 commits) fetch: improve the error messages emitted for conflicting refspecs handle_duplicate(): mark error message for translation ref_remote_duplicates(): extract a function handle_duplicate() ref_remove_duplicates(): simplify loop logic t5536: new test of refspec conflicts when fetching ref_remove_duplicates(): avoid redundant bisection git-fetch.txt: improve description of tag auto-following fetch-options.txt: simplify ifdef/ifndef/endif usage fetch, remote: properly convey --no-prune options to subprocesses builtin/remote.c:update(): use struct argv_array builtin/remote.c: reorder function definitions query_refspecs(): move some constants out of the loop fetch --prune: prune only based on explicit refspecs fetch --tags: fetch tags *in addition to* other stuff fetch: only opportunistically update references based on command line get_expanded_map(): avoid memory leak get_expanded_map(): add docstring builtin/fetch.c: reorder function definitions get_ref_map(): rename local variables api-remote.txt: correct section "struct refspec" ...
2013-12-05replace {pre,suf}fixcmp() with {starts,ends}_with()Libravatar Christian Couder1-23/+23
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04push: use remote.$name.push as a refmapLibravatar Junio C Hamano1-4/+4
Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch: improve the error messages emitted for conflicting refspecsLibravatar Michael Haggerty1-3/+22
If we find two refspecs that want to update the same local reference, emit an error message that is more informative based on whether one of the conflicting refspecs is an opportunistic update during a fetch with explicit command-line refspecs. And especially, do not die if an opportunistic reference update conflicts with an express wish of the user; rather, just emit a warning and skip the opportunistic reference update. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30handle_duplicate(): mark error message for translationLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30ref_remote_duplicates(): extract a function handle_duplicate()Libravatar Michael Haggerty1-8/+10
It will become more complex in a moment. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30ref_remove_duplicates(): simplify loop logicLibravatar Michael Haggerty1-21/+31
Change the loop body into the more straightforward * remove item from the front of the old list * if necessary, add it to the tail of the new list and return a pointer to the new list (even though it is currently always the same as the input argument, because the first element in the list is currently never deleted). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30ref_remove_duplicates(): avoid redundant bisectionLibravatar Michael Haggerty1-6/+6
The old code called string_list_lookup(), and if that failed called string_list_insert(), thus doing the bisection search through the string list twice in the latter code path. Instead, just call string_list_insert() right away. If an entry for that peer reference name already existed, then its util pointer is always non-NULL. Of course this doesn't change the fact that the repeated string_list_insert() calls make the function scale like O(N^2) if the input reference list is not already approximately sorted. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30query_refspecs(): move some constants out of the loopLibravatar Michael Haggerty1-2/+2
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30get_expanded_map(): avoid memory leakLibravatar Michael Haggerty1-3/+3
The old code could leak *expn_name if match_name_with_pattern() succeeded but ignore_symref_update() returned true. So make sure that *expn_name is freed in any case. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30get_expanded_map(): add docstringLibravatar Michael Haggerty1-0/+7
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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