This test checks that git-cherry finds the expected number of patches
in two simple cases, and then tests the new limit arguments.
[jc: collapsed two patches into one and added sleep to make sure
the two commits would get different timestamps]
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows to use another commit than the merge base as a limit for
scanning patches.
[jc: part about t3500 test omitted.]
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tommi Virtanen expressed a wish on #git to be able to use short and elegant
git URLs by making git-daemon 'root' in a given directory. This patch
implements this, causing git-daemon to interpret all paths relative to
the given base path if any is given.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The main loop was prepared to take more than one revs, but the actual
naming logic wad not (it used pop_most_recent_commit while forgetting
that the commit marks stay after it's done).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a trailing slash to directory names in the output
when "--others --directory" option shows only untracked
directories and not their contents, to make them stand out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When both howto-index.sh and howto/make-dist.txt exist under
Documentation/ directory, dir_exists() mistakenly checked it
without the trailing slash to see if there was something under
Documentation/howto directory, and did not realize there was,
because '-' sorts earlier than '/' and cache_name_pos() finds
howto-index.sh, which is not under howto/ directory. This
caused --others --directory to show it which was incorrect.
Check the directory name with the trailing slash, because having
an entry that has such as a prefix is what we are looking for.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Darrin Thompson notes that git-ls-files -o reports all the unknown
files it finds in a work area. Subversion and probably other systems
"simply ignore all the files and directories inside an unknown
directory and just note the directory as unknown."
With --directory option, ls-files --others shows untracked directories
without descending into them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I added things to ls-remote so that Cogito can auto-follow tags
easily and correctly a while ago, but git-fetch did not use the
facility. Recently added git-describe command relies on
repository keeping up-to-date set of tags, which made it much
more attractive to automatically follow tags, so we do that as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I think it is probably a bug that "git non_existent_command"
returns its error message to stdout without an error, where
"git-non_existent_command" behaves differently and does return an
error.
Older versions of git did not implement "git describe" and
GIT-VERSION-GEN produces an empty version string if run on
a system with such a git installed. The consequence
is that "make rpm" fails.
This patch fixes GIT-VERSION-GEN so that it works in the
absence of a working "git describe"
Signed-off-by: John Ellson <ellson@research.att.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most other scm's understand it, most users expect it and it's an easy fix.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The -T and -t switches are swapped in the documentation and actual
code. I've made the documentation match the code.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I looked at svn-mirror to see how it did this, seems about right.
"It works for me" when using it against https://svn.musicpd.org
tested command-line: git-svnimport -C mpc -i -m -v \
-T mpc/trunk -b mpc/branches -t mpc/tags https://svn.musicpd.org
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the other end was prepared with older git and has tags that
do not follow the naming convention (see check-ref-format), do not
barf but simply reject to copy them.
Initial fix by Simon Richter, but done differently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition, also fixes a few synopses to be more consistent and a gitlink.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not every system (will not one microsoft windows system) have /var/tmp,
whereas using GIT_DIR for random temporary files is more or less established.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
and was successfully entered. Otherwise git-init-db will create it directly
in the working directory (t/) which can be dangerous.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not that the stat against open race would matter much in this context,
but that simplifies
the code a bit. Also some diagnostics added (why the open failed)
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It can happen if the temporary file already exists (i.e. after a panic
and reboot).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Stupid me.
If approxidate ends up with a month that is ahead of the current month, it
decrements the year to last year.
Which is correct, and means that "last december" does the right thing.
HOWEVER. It should only do so if the year is the same as the current year.
Without this fix, "5 days ago" ends up being in 2004, because it first
decrements five days, getting us to December 2005 (correct), but then it
also ends up decrementing the year once more to turn that December into
"last year" (incorrect, since it already _was_ last year).
Duh. Pass me a donut.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
AIX 5 has a /usr/include/regex.h containing this code:
#ifdef _NO_PROTO
extern char *regex();
extern char *regcmp();
#else /* _NO_PROTO */
extern char *regex(const char *, const char *, ...);
extern char *regcmp(const char *, ...);
#endif /* _NO_PROTO */
This means that repo-config.c is trying to redefine the `regex' symbol.
Here is a simple patch that just uses `regexp' as the symbol name instead.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Move git-rev-list --merge-order usage check for 'OpenSSL not linked' after
test 1; we cannot trigger this unless we try to actually use --merge-order
by giving some ref, and we do not have any ref until we run the first test
to create commits.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the protocol between git-send-pack/git-receive-pack
in a backward compatible way to allow failures at the receiving
end to be propagated back to the sender. Most notably, versions
of git-push before this could not notice if the update hook on
the receiving end refused to update the ref for its own policy
reasons.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Note: with this commit, the GIT maintainer workflow must change.
GIT-VERSION-GEN is now the file to munge when the default
version needs to be changed, not Makefile. The tag needs to be
pushed into the repository to build the official tarball and
binary package beforehand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Even though --all and --tags can be used to include non
annotated tags in the reference point candidates, prefer to use
annotated tags if there are more than one refs that name the
same commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With --tags, not just annontated tags, but also any ref under
refs/tags/ are used to name the revision.
The number of digits is configurable with the --abbrev=<n> option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Often there are references other than annotated tags under
refs/tags hierarchy that are used to "keep things just in case".
default to use annotated tags only, still leaving the option to
use any ref with --all flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It shows you the most recent tag that is reachable from a particular
commit is.
Maybe this is something that "git-name-rev" should be taught to do,
instead of having a separate command for it. Regardless, I find it useful.
What it does is to take any random commit, and "name" it by looking up the
most recent commit that is tagged and reachable from that commit. If the
match is exact, it will just print out that ref-name directly. Otherwise
it will print out the ref-name, followed by the 8-character "short SHA".
IOW, with something like Junios current tree, I get:
[torvalds@g5 git]$ git-describe parent
refs/tags/v1.0.4-g2414721b
ie the current head of my "parent" branch (ie Junio) is based on v1.0.4,
but since it has a few commits on top of that, it has added the git hash
of the thing to the end: "-g" + 8-char shorthand for the commit
2414721b194453f058079d897d13c4e377f92dc6.
Doing a "git-describe" on a tag-name will just show the full tag path:
[torvalds@g5 git]$ git-describe v1.0.4
refs/tags/v1.0.4
unless there are _other_ tags pointing to that commit, in which case it
will just choose one at random.
This is useful for two things:
- automatic version naming in Makefiles, for example. We could use it in
git itself: when doing "git --version", we could use this to give a
much more useful description of exactly what version was installed.
- for any random commit (say, you use "gitk <pathname>" or
"git-whatchanged" to look at what has changed in some file), you can
figure out what the last version of the repo was. Ie, say I find a bug
in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do:
[torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6
refs/tags/v2.6.14-rc4-g39ca371c
and I now know that it was _not_ in v2.6.14-rc4, but was presumably in
v2.6.14-rc5.
The latter is useful when you want to see what "version timeframe" a
commit happened in.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
