A/very/long/path/to/.git that becomes exactly PATH_MAX bytes long
after suffixed with /objects/??/??38-hex??, would have overflown
the on-stack pathname[] buffer.
Noticed-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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"
...
"git diff -- ':(icase)makefile'" were rejected unnecessarily.
This needs to be merged to 'maint' later.
* nd/magic-pathspec:
diff: restrict pathspec limitations to diff b/f case only
Add a few formatting directives to "git for-each-ref --format=...",
to paint them in color, etc.
* rr/for-each-ref-decoration:
for-each-ref: avoid color leakage
for-each-ref: introduce %(color:...) for color
for-each-ref: introduce %(upstream:track[short])
for-each-ref: introduce %(HEAD) asterisk marker
t6300 (for-each-ref): don't hardcode SHA-1 hexes
t6300 (for-each-ref): clearly demarcate setup
People often wished a way to tell "git log --branches" (and "git
log --remotes --not --branches") to exclude some local branches
from the expansion of "--branches" (similarly for "--tags", "--all"
and "--glob=<pattern>"). Now they have one.
* jc/ref-excludes:
rev-parse: introduce --exclude=<glob> to tame wildcards
rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API
rev-list --exclude: tests
document --exclude option
revision: introduce --exclude=<glob> to tame wildcards
Enhance "rev-parse --parseopt" mode to help parsing options with
an optional parameter.
* nv/parseopt-opt-arg:
rev-parse --parseopt: add the --stuck-long mode
Use the word 'stuck' instead of 'sticked'
Code the logic in "pull --rebase" that figures out a fork point
from reflog entries in C.
* jc/merge-base-reflog:
merge-base: teach "--fork-point" mode
merge-base: use OPT_CMDMODE and clarify the command line parsing
* jk/robustify-parse-commit:
checkout: do not die when leaving broken detached HEAD
use parse_commit_or_die instead of custom message
use parse_commit_or_die instead of segfaulting
assume parse_commit checks for NULL commit
assume parse_commit checks commit->object.parsed
log_tree_diff: die when we fail to parse a commit
When the built-in "git tar-tree" command (a thin wrapper around "git
archive") was removed in 925ceccf (tar-tree: remove deprecated
command, 2013-11-10), the build continued to install a non-functioning
git-tar-tree command in gitexecdir by mistake:
$ PATH=$(git --exec-path):$PATH
$ git-tar-tree -h
fatal: cannot handle tar-tree internally
The list of links in gitexecdir is populated from BUILTIN_OBJS, which
includes builtin/tar-tree.o to implement "git get-tar-commit-id".
Rename the get-tar-commit-id source file to builtin/get-tar-commit-id.c
to reflect its purpose and fix 'make install'.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin_diff_b_f() needs a path, not pathspec. Other modes in diff
can deal with pathspec just fine. But because of the current
GUARD_PATHSPEC() location, other modes also reject :(glob) and
:(icase).
Move GUARD_PATHSPEC(), and the "path" assignment statement, which is
the reason of this GUARD_PATHSPEC(), inside builtin_diff_b_f().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To make sure that an invocation like the following doesn't leak color,
$ git for-each-ref --format='%(subject)%(color:green)'
auto-reset at the end of the format string when the last color token
seen in the format string isn't a color-reset.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%(color:green)%(refname:short)%(color:reset)
where color names are described in color.branch.*.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%(refname:short)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend its format with
%(HEAD) for the same effect.
Now you can use the following format in for-each-ref:
%(HEAD) %(refname:short)
to display an asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit f2e0873 (branch: report invalid tracking branch as gone) removed
an early return from fill_tracking_info() in the path taken when 'git
branch -v' lists a branch in sync with its upstream. This resulted in an
unconditionally added space in front of the subject line:
$ git branch -v
* master f5eb3da commit pushed to upstream
topic f935eb6 unpublished topic
Instead, only add the trailing space if a decoration have been added.
To catch this kind of whitespace breakage in the tests, be a bit less
smart when filtering the output through sed.
Signed-off-by: Torstein Hegge <hegge@resisty.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the unset push.default warning message is displayed this may be
the first time many users encounter push.default.
Explain in the warning message in a compact manner what push.default
is and what the change means to the end-user to help the users decide.
Signed-off-by: Greg Jacobson <coder5000@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Helped-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git tar-tree" has been a thin wrapper around "git archive" since commit
fd88d9c (Remove upload-tar and make git-tar-tree a thin wrapper to
git-archive, 2006-09-24), which also made it print a message indicating
that git-tar-tree is deprecated.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The release notes for Git 1.5.4 say that "git repo-config" will be
removed in the next feature release. Since Git 2.0 is nearly here,
remove it.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach "rev-parse" the same "I'm going to glob, but omit the ones
that match these patterns" feature as "rev-list".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git reset -p HEAD" has codepath to special case it from resetting
to contents of other commits, but recent change broke it.
* jk/reset-p-current-head-fix:
reset: pass real rev name to add--interactive
add-interactive: handle unborn branch in patch mode
Moving a regular file in a repository with a .gitmodules file was
producing a warning 'Could not find section in .gitmodules where
path=<filename>'.
* jl/submodule-mv:
mv: Fix spurious warning when moving a file in presence of submodules
Add the --stuck-long option to output the options in their long form
if available, and with their arguments stuck.
Contrary to the default form (non stuck arguments and short options),
this can be parsed unambiguously when using options with optional
arguments :
- in the non stuck form, when an option is taking an optional argument
you cannot know if the next argument is its optional argument, or the
next option.
- the long options form allows to differentiate between an empty argument
'--option=' and an unset argument '--option', which is not possible
with short options.
Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
If --no-prune is passed to one of the following commands:
git fetch --all
git fetch --multiple
git fetch --recurse-submodules
git remote update
then it must also be passed to the "fetch" subprocesses that those
commands use to do their work. Otherwise there might be a fetch.prune
or remote.<name>.prune configuration setting that causes pruning to
occur, contrary to the user's express wish.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use struct argv_array for calling the "git fetch" subprocesses.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder function definitions to remove the need for forward
declarations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old behavior of "fetch --prune" was to prune whatever was being
fetched. In particular, "fetch --prune --tags" caused tags not only
to be fetched, but also to be pruned. This is inappropriate because
there is only one tags namespace that is shared among the local
repository and all remotes. Therefore, if the user defines a local
tag and then runs "git fetch --prune --tags", then the local tag is
deleted. Moreover, "--prune" and "--tags" can also be configured via
fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it
even less obvious that an invocation of "git fetch" could result in
tag lossage.
Since the command "git remote update" invokes "git fetch", it had the
same problem.
The command "git remote prune", on the other hand, disregarded the
setting of remote.<name>.tagopt, and so its behavior was inconsistent
with that of the other commands.
So the old behavior made it too easy to lose tags. To fix this
problem, change "fetch --prune" to prune references based only on
refspecs specified explicitly by the user, either on the command line
or via remote.<name>.fetch. Thus, tags are no longer made subject to
pruning by the --tags option or the remote.<name>.tagopt setting.
However, tags *are* still subject to pruning if they are fetched as
part of a refspec, and that is good. For example:
* On the command line,
git fetch --prune 'refs/tags/*:refs/tags/*'
causes tags, and only tags, to be fetched and pruned, and is
therefore a simple way for the user to get the equivalent of the old
behavior of "--prune --tag".
* For a remote that was configured with the "--mirror" option, the
configuration is set to include
[remote "name"]
fetch = +refs/*:refs/*
, which causes tags to be subject to pruning along with all other
references. This is the behavior that will typically be desired for
a mirror.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, fetch's "--tags" option was considered equivalent to
specifying the refspec "refs/tags/*:refs/tags/*" on the command line;
in particular, it caused the remote.<name>.refspec configuration to be
ignored.
But it is not very useful to fetch tags without also fetching other
references, whereas it *is* quite useful to be able to fetch tags *in
addition to* other references. So change the semantics of this option
to do the latter.
If a user wants to fetch *only* tags, then it is still possible to
specifying an explicit refspec:
git fetch <remote> 'refs/tags/*:refs/tags/*'
Please note that the documentation prior to 1.8.0.3 was ambiguous
about this aspect of "fetch --tags" behavior. Commit
f0cb2f137c 2012-12-14 fetch --tags: clarify documentation
made the documentation match the old behavior. This commit changes
the documentation to match the new behavior.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old code processed (tags == TAGS_SET) before adding the entries
used to opportunistically update references mentioned on the command
line. The result was that all tags were also considered candidates
for opportunistic updating.
This is harmless for two reasons: (a) because it would only add
entries if there is a configured refspec that covers tags *and* both
--tags and another refspec appear on the command-line; (b) because any
extra entries would be deleted later by the call to
ref_remove_duplicates() anyway.
But, to avoid extra work and extra memory usage, and to make the
implementation better match the intention, change the algorithm
slightly: compute the opportunistic refspecs based only on the
command-line arguments, storing the results into a separate temporary
list. Then add the tags (which have to come earlier in the list so
that they are not de-duped in favor of an opportunistic entry). Then
concatenate the temporary list onto the main list.
This change will also make later changes easier.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder function definitions to avoid the need for a forward
declaration of function find_non_local_tags().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git checkout topic", when there is not yet a local "topic" branch
but there is a unique remote-tracking branch for a remote "topic"
branch, pretended as if "git checkout -t -b topic remote/$r/topic"
(for that unique remote $r) was run. This hack however was not
implemented for "git checkout topic --".
* mm/checkout-auto-track-fix:
checkout: proper error message on 'git checkout foo bar --'
checkout: allow dwim for branch creation for "git checkout $branch --"
C coding style fixes.
* fc/styles:
block-sha1/sha1.c: have SP around arithmetic operators
base85.c: have SP around arithmetic operators
archive.c: have SP around arithmetic operators
alloc.c: have SP around arithmetic operators
abspath.c: have SP around arithmetic operators
alias: have SP around arithmetic operators
C: have space around && and || operators
If you ask for-each-ref to print each ref and its object,
like:
git for-each-ref --format='%(objectname) %(refname)'
this should involve little more work than looking at the ref
files (and packed-refs) themselves. However, for-each-ref
will actually load each object from disk just to print its
sha1. For most repositories, this isn't a big deal, but it
can be noticeable if you have a large number of refs to
print. Here are best-of-five timings for the command above
on a repo with ~10K refs:
[before]
real 0m0.112s
user 0m0.092s
sys 0m0.016s
[after]
real 0m0.014s
user 0m0.012s
sys 0m0.000s
This patch checks for %(objectname) and %(objectname:short)
before we actually parse the object (and the rest of the
code is smart enough to avoid parsing if we have filled all
of our placeholders).
Note that we can't simply move the objectname parsing code
into the early loop. If the "deref" form %(*objectname) is
used, then we do need to parse the object in order to peel
the tag. So instead of moving the code, we factor it out
into a separate function that can be called for both cases.
While we're at it, we add some basic tests for the
dereferenced placeholders, which were not tested at all
before. This helps ensure we didn't regress that case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example, if the history looked like this:
o---B1
/
---o---o---B2--o---o---o---Base
\
B3
\
Derived
where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".
Internally, we have get_merge_bases_many() that can compute this
with one-go. We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base". When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".
Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.
Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Normally parse_pathspec() is used on command line arguments where it
can do fancy thing like parsing magic on each argument or adding magic
for all pathspecs based on --*-pathspecs options.
There's another use of parse_pathspec(), where pathspec is needed, but
the input is known to be pure paths. In this case we usually don't
want --*-pathspecs to interfere. And we definitely do not want to
parse magic in these paths, regardless of --literal-pathspecs.
Add new flag PATHSPEC_LITERAL_PATH for this purpose. When it's set,
--*-pathspecs are ignored, no magic is parsed. And if the caller
allows PATHSPEC_LITERAL (i.e. the next calls can take literal magic),
then PATHSPEC_LITERAL will be set.
This fixes cases where git chokes when GIT_*_PATHSPECS are set because
parse_pathspec() indicates it won't take any magic. But
GIT_*_PATHSPECS add them anyway. These are
export GIT_LITERAL_PATHSPECS=1
git blame -- something
git log --follow something
git log --merge
"git ls-files --with-tree=path" (aka parse_pathspec() in
overlay_tree_on_cache()) is safe because the input is empty, and
producing one pathspec due to PATHSPEC_PREFER_CWD does not take any
magic into account.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The add--interactive --patch mode adjusts the UI based on
whether we are pulling changes from HEAD or elsewhere (in
the former case it asks to unstage the reverse hunk, rather
than apply the forward hunk).
Commit 166ec2e taught reset to work on an unborn branch, but
in doing so, switched to always providing add--interactive
with the sha1 rather than the symbolic name. This meant we
always used the "apply" interface, even for "git reset -p
HEAD".
We can fix this by passing the symbolic name to
add--interactive. Since it understands unborn branches
these days, we do not even have to cover this special case
ourselves; we can simply pass HEAD.
The tests in t7105 now check that the right interface is
used in each circumstance (and notice the regression from
166ec2e we are fixing). The test in t7106 checks that we
get this right for the unborn case, too (not a regression,
since it didn't work at all before, but a nice improvement).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we move away from a detached HEAD that has broken or
corrupted commits, we might die in two places:
1. Printing the "old HEAD was..." message.
2. Printing the list of orphaned commits.
In both cases, we ignore the return value of parse_commit
and feed the resulting commit to the pretty-print machinery,
which will die() upon failing to read the commit object
itself.
Since both cases are ancillary to the real operation being
performed, let's be more robust and keep going. This lets
users more easily checkout away from broken history.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
