Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused.
Furthermore, --subdirectory-filter supplies its own '--', and if the user
provided one himself, such as in
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
an extra '--' was used as path filter in the call to git-rev-list that
determines the commits that shall be rewritten.
To keep the argument handling sane, we filter $@ to contain only the
non-revision arguments, and store all revisions in $ref_args. The
$ref_args are easy to handle since only the SHA1s are needed; the
actual branch names have already been stored in $tempdir/heads at this
point.
An extra separating -- is only required if the user did not provide
any non-revision arguments, as the latter disambiguate the
$filter_subdir following after them (or fail earlier because they are
ambiguous themselves).
Thanks to Johannes Sixt for suggesting this solution.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When saying the initial branch is equal to the currently active
remote branch, it is probably intended that the branch heads
point to the same commit. Maybe it would be more useful to a
new user to emphasize that the tree contents and history are the
same.
More important, probably, is that this new branch is set up so
that "git pull" merges changes from the corresponding remote
branch. The next paragraph addresses that directly. What the
reader needs to know to begin with is that (1) the initial branch
is your own; if you do not pull, it won't get updated, and that
(2) the initial branch starts out at the same commit as the
upstream.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aliases with newlines have been a problem since commit 56fc25f (Bash
completion support for remotes in .git/config., 2006-11-05). The chance
of the problem occurring has been slim at best, until commit 518ef8f
(completion: Replace config --list with --get-regexp, 2009-09-11)
removed the case statement introduced by commit 56fc25f. Before removing
the case statement, most aliases with newlines would work unless they
were specially crafted as follows
[alias]
foo = "log -1 --pretty='format:%s\nalias.error=broken'"
After removing the case statement, a more benign alias like
[alias]
whowhat = "log -1 --pretty='format:%an <%ae>\n%s'"
wont-complete = ...
would cause the completion to break badly.
For now, revert the removal of the case statement until someone comes up
with a better way to get keys from git-config.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After commit 511a3fc (wrap git's main usage string., 2009-09-12), the
bash completion for git commands includes COMMAND and [ARGS] when it
shouldn't. Fix this by grepping more strictly for a line with git
commands. It's doubtful whether git will ever have commands starting
with anything besides numbers and letters so this should be fine. At
least by being stricter we'll know when we break the completion earlier.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes an obvious syntax error that snuck in commit 7e787953:
syntax error at /home/ingmar/bin//git-import-tars line 143, near "/^$/ { "
syntax error at /home/ingmar/bin//git-import-tars line 145, near "} else"
syntax error at /home/ingmar/bin//git-import-tars line 152, near "}"
Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
Acked-and-Tested-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Idealists may want USE_NSEC to be the default on Linux some day.
Point to a patch to better explain the requirements on
filesystem code for that to happen.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not necessarily obvious to a git novice what it means for a
filesystem tree to be equal to the HEAD. Spell it out.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation seems to assume that the starting point for a new
branch is the tip of an existing (ordinary) branch, but that is not
the most common case. More often, "git branch" is used to begin
a branch from a remote-tracking branch, a tag, or an interesting
commit (e.g. origin/pu^2). Clarify the language so it can apply
to these cases. Thanks to Sean Estabrooks for the wording.
Also add a pointer to the user's manual for the bewildered.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the documentation for --merged and --no-merged to explain
the meaning of the optional parameter introduced in commit 049716b
(branch --merged/--no-merged: allow specifying arbitrary commit,
2008-07-08).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sounds better this way, at least to my ears. ("The syntax and
supported options of git merge" is a plural noun. "the same"
instead of "equal" sounds less technical and seems to convey
the meaning better here.)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fmt-merge-message builtin can be invoked as "git fmt-merge-msg" rather
than through the hard link in GIT_EXEC_PATH. Although this is unlikely to
confuse most script writers, it should not hurt to make the documentation
a little clearer anyway.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is excellent documentation for these options in
Documentation/Makefile, but some users may never find it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are several reasons a git-pull invocation might not
have anything marked for merge:
1. We're not on a branch, so there is no branch
configuration.
2. We're on a branch, but there is no configuration for
this branch.
3. We fetched from the configured remote, but the
configured branch to merge didn't get fetched (either
it doesn't exist, or wasn't part of the fetch refspec).
4. We fetched from the non-default remote, but didn't
specify a branch to merge. We can't use the configured
one because it applies to the default remote.
5. We fetched from a specified remote, and a refspec was
given, but it ended up not fetching anything (this is
actually hard to do; if the refspec points to a remote
branch and it doesn't exist, then fetch will fail and
we never make it to this code path. But if you provide
a wildcard refspec like
refs/bogus/*:refs/remotes/origin/*
then you can see this failure).
We have handled (1) and (2) for some time. Recently, commit
a6dbf88 added code to handle case (3).
This patch handles cases (4) and (5), which previously just
fell under other cases, producing a confusing message.
While we're at it, let's rewrap the text for case (3), which
looks terribly ugly as it is.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After doing a rebase, git-svn checks that the SVN URL
is what it expects. However, it does not account for
rewriteRoot, which is a legitimate way for the URL
to change. This produces a lot of spurious errors.
[ew: fixed line wrapping]
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When git is compiled with the MIPSpro 7.4.4m compiler, and NO_PTHREADS is
set, and NO_MMAP is _not_ set, then git segfaults when trying to access the
first entry in a reflog. If NO_PTHREADS is not set (which implies that the
pthread library is linked in), or NO_MMAP _is_ set, then the segfault is
not encountered. The conservative choice has been made to set NO_MMAP in
the Makefile to avoid this flaw. The GNU C compiler does not produce this
behavior.
The segfault happens in refs.c:read_ref_at(). The mmap succeeds, and the
loop is executed properly until rec is rewound into the first line (reflog
entry) of the file. The segfault is caught by test 28 of
t1400-update-ref.sh which fails when 'git rev-parse --verify "master@{May 25
2005}"' is called.
So, add a comment in the Makefile to describe why NO_MMAP is set and as a
hint to those who may be interested in unsetting it.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When ls-files was called with -i but no exclude pattern, it was
calling fprintf(stderr, "...", NULL) and then exiting. On Solaris,
passing NULL into fprintf was causing a segfault. On glibc systems,
it was simply producing incorrect output (eg: "(null)": ...). The
NULL pointer was a result of argv[0] not being preserved by the option
parser. Instead of requesting that the option parser preserve
argv[0], use die() with a constant string.
A trigger for this bug was: `git ls-files -i`
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit dcda3614 removed the use of a variable length array from
builtin-pack-objects.c, it is now safe to compile with the threaded delta
search feature enabled. Formerly, the MIPSpro 7.4.4m compiler warned that
variable length arrays should not be used with pthreads.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During an MSVC build on cygwin, the make program did not notice
when the compiler or linker exited with an error. This was caused
by the scripts exiting with the value returned by system() directly.
On POSIX-like systems, such as cygwin, the return value of system()
has the exit code of the executed command encoded in the first byte
(ie the value is shifted up by 8 bits). This allows the bottom
7 bits to contain the signal number of a terminated process, while
the eighth bit indicates whether a core-dump was produced. (A value
of -1 indicates that the command failed to execute.)
The make program, however, expects the exit code to be encoded in the
bottom byte. Futhermore, it apparently masks off and ignores anything
in the upper bytes.
However, these scripts are (naturally) intended to be used on the
windows platform, where we can not assume POSIX-like semantics from
a perl implementation (eg ActiveState). So, in general, we can not
assume that shifting the return value right by eight will get us
the exit code.
In order to improve portability, we assume that a zero return from
system() indicates success, whereas anything else indicates failure.
Since we don't need to know the exact exit code from the compiler
or linker, we simply exit with 0 (success) or 1 (failure).
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the MSVC section of the Makefile, BASIC_CFLAGS is set to a
value which contains the string "-DWIN32-D_CONSOLE". This results
in a (single) malformed -Define being passed to the compiler.
At least on my cygwin installation, the msvc compiler seems to
ignore this parameter, without issuing an error or warning, and
results in the WIN32 and _CONSOLE macros being undefined. This
breaks the build.
In order to fix the build, we simply insert a space between the
two -Define parameters, "-DWIN32" and "-D_CONSOLE", as originally
intended.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With --prefix=string that does not end with a slash, the top-level entries
are written out with the specified prefix as expected, but no paths in the
directories are added.
Fix this by adding the prefix in write_archive_entry() instead of letting
get_pathspec() and read_tree_recursive() pair; they are designed to only
handle prefixes that are path components.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git am learned --scissors, git commit learned --dry-run and git log
learned --decorate=long|short recently.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When reading the "raw format" timestamp from the input stream, make sure
that the timezone offset is a reasonable value by imitating 7122f82
(date.c: improve guess between timezone offset and year., 2006-06-08).
We _might_ want to also check if the timestamp itself is reasonable, but
that is left for a separate commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
2007-01-15) added this check, $? referred to the error status of reading
HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
2007-11-28) moved the command away from where the check is, and nobody
noticed the breakage. Ever since, $? has always been 0 (tr at the end of
the pipe to find merge_head never fails) and other case arms were never
reached.
These days, error_on_no_merge_candidates function is prepared to handle a
detached HEAD case, which was what the code this patch removes used to
handle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git show-branch" without any parameter in a repository that
has showbranch.default defined, we used to rely on the fact that our
handcrafted option parsing loop never looked at av[0].
The array of default strings had the first real command line argument in
default_arg[0], but the option parser wanted to look at the array starting
at av[1], so we assigned the address of -1th element to av to force the
loop start working from default_arg[0].
This no longer worked since 5734365 (show-branch: migrate to parse-options
API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in
its ctx->out and later in parse_options_end() it did memmove to ctx->out
(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.
I am not sure if this is a bug in parse_options(), or a bug in the caller,
and tonight I do not have enough concentration to figure out which. In
any case, this patch works the issue around.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes '--relative-date' so that it does not give '0
year, 12 months', for the interval 360 <= diff < 365.
Signed-off-by: Johan Sageryd <j416@1616.se>
Signed-off-by: Jeff King <peff@peff.net>
commit 51ea551 ("make sure byte swapping is optimal for git"
2009-08-18) introduced a "sane definition for ntohl()/htonl()"
for use on some GNU C platforms. Unfortunately, for some of
these platforms, this results in the introduction of a problem
which is essentially the reverse of a problem that commit 6e1c234
("Fix some warnings (on cygwin) to allow -Werror" 2008-07-3) was
intended to fix.
In particular, on platforms where the uint32_t type is defined
to be unsigned long, the return type of the new ntohl()/htonl()
is causing gcc to issue printf format warnings, such as:
warning: long unsigned int format, unsigned int arg (arg 3)
(nine such warnings, covering six different files). The earlier
commit (6e1c234) needed to suppress these same warnings, except
that the types were in the opposite direction; namely the format
specifier ("%u") was 'unsigned int' and the argument type (ie the
return type of ntohl()) was 'long unsigned int' (aka uint32_t).
In order to suppress these warnings, the earlier commit used the
(C99) PRIu32 format specifier, since the definition of this macro
is suitable for use with the uint32_t type on that platform.
This worked because the return type of the (original) platform
ntohl()/htonl() functions was uint32_t.
In order to suppress these warnings, we change the return type of
the new byte swapping functions in the compat/bswap.h header file
from 'unsigned int' to uint32_t.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Jeff King <peff@peff.net>
For example:
alias -group friends foo Foo Bar <foo@bar.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked(-and-tested)-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Jeff King <peff@peff.net>
Some compilers (including at least MSVC and ARM RVDS) supports
NORETURN on function declarations, but not on function pointers.
This patch makes it possible to define NORETURN for these compilers,
by splitting the NORETURN macro into two - one for function
declarations and one for function pointers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Some compilers (including at least MSVC) support NORETURN
on function declarations, but only before the function-name.
This patch makes it possible to define NORETURN to something
meaningful for those compilers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
