prune: do not show error from pack-redundant when no packs are found.
When there is no pack yet, git-prune leaked an error message
from "git-pack-redundant --all" which complained that there is
no pack. Squelch the annoying message.
The official maintainer is keeping up-to-date quite well, and now
the older Debian is supported with backports.org, there is no reason
for me to keep debian/ directory around here.
I have not been building and publishing debs since 1.0.4 anyway.
"cvs add" support was already there, but the "unknown" status
returned when querying a file not yet known to cvs caused the
script to abort prematurely.
Make GIT-VERSION-GEN tolerate missing git describe command
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>
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.
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>
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>
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>
send-pack/receive-pack: allow errors to be reported back to pusher.
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.
Makefile: use git-describe to mark the git version.
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.
git-describe: still prefer annotated tag under --all and --tags
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.
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.
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:
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:
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:
Starting from this one I won't be touching debian/ directory
since the official maintainer seems to be reasonably quick to
package up things. The packaging procedure used there seems to
be quite different from what I have, so I'd like to avoid
potential confusion and reduce work by the official maintainer
and myself.
This patch converts a stat() to an lstat() call, thereby fixing the case
when the date of a symlink was not the same as the one recorded in the
index. The included test case demonstrates this.
This is for the case that the symlink points to a non-existing file. If
the file exists, worse things than just an error message happen.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes found that the test has 1/256 chance of falsely
producing an uncorrupted idx file, causing the check to detect
corruption fail. Now we have 1/2^160 chance of false failure
;-).
Avoid asking for zero bytes when that change simplifies overall
logic. Later we would change the wrapper to ask for 1 byte on
platforms that return NULL for zero byte request.
are set group writable (and g+s, since the git group may be not the primary
group of all users).
Since all files are written as lock files first, and then moved to
their destination, they do not have to be group writable. Indeed, if
this leads to problems you found a bug.
Note that -- as in my first attempt -- the config variable is set in the
function which checks the repository format. If this were done in
git_default_config instead, a lot of programs would need to be modified
to call git_config(git_default_config) first.
[jc: git variables should be in environment.c unless there is a
compelling reason to do otherwise.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
We did not distinguish the case the user asked not to make a
commit with --no-commit flag and the automerge failed. Tell
these cases apart and phrase dying message differently.
. It simplifies the logic to handle the case in which no
refs are given on the command line, and fixes the bug
when only "--heads" is specified. Earlier we showed
them twice.
. It avoids to add the same ref twice.
. It sorts the glob result (e.g. "git show-branch
'tags/v1.0*'") according to a more version friendly
sort order.
Adjust to ls-tree --full-name when run from a subdirectory.
A proposed change to show cwd relative paths by default from
ls-tree when run from a subdirectory means we would need to
give --full-name option to it.
ls-tree: chomp leading directories when run from a subdirectory
When run from a subdirectory, even though we filtered the output
based on where we were using pathspec, we wrote out the
repository relative paths, not subtree relative paths. This
changes things so that it shows only the current subdirectory
relative paths.
For example, in Documentation subdirectory of git itself, this
used to be the case:
$ git-ls-tree --name-only HEAD | grep how
Documentation/git-show-branch.txt
Documentation/git-show-index.txt
Documentation/howto-index.sh
Documentation/howto
But now it does this instead:
$ git-ls-tree --name-only HEAD | grep how
git-show-branch.txt
git-show-index.txt
howto-index.sh
howto
There are two things to keep in mind.
1. This shows nothing.
$ git-ls-tree --name-only HEAD ../ppc/
This is to make things consistent with ls-files, which
refuses relative path that goes uplevel.
2. These show things in full repository relative paths. In this
case, paths outside the current subdirectory are also shown.
$ git-ls-tree --name-only --full-name HEAD | grep how
Documentation/git-show-branch.txt
Documentation/git-show-index.txt
Documentation/howto-index.sh
Documentation/howto
$ git-ls-tree --name-only --full-name HEAD ../ppc/
ppc/sha1.c
ppc/sha1.h
ppc/sha1ppc.S
The flag --full-name gives the same behaviour as 1.0, so it
ought to be the default if we really care about the backward
compatibility, but in practice no Porcelain runs ls-tree from a
subdirectory yet, and without --full-name is more human
friendly, so hopefully the default being not --full-name would
be acceptable.
We could of course chdir to top and do the whole-tree checkout
in git-checkout, but the point is the operation does not make
sense on a partial tree. The whole tree is checked out.
The other form is to update the index file and working tree file
selectively:
git-checkout <treeish> <file>... ;# out of tree to index and file
git-checkout -- <file>... ;# out of index to file
This form _does_ make sense to run from subdirectory; and I
myself often wish we supported this.
sha1_to_hex() returns a pointer to a static buffer. Some of its users
modify that buffer by appending a newline character. Other users rely
on the fact that you can call
printf("%s", sha1_to_hex(sha1));
Just to be on the safe side, terminate the SHA1 in sha1_to_hex().
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
We want to record the version of the tools the patch was generated with.
While these tools could be rebuilt, git-format-patch stayed the same and
report the wrong version.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Wnen refusing to push a head, we said cryptic "remote 'branch'
object X does not exist on local" or "remote ref 'branch' is not
a strict subset of local ref 'branch'". That was gittish.
Since the most likely reason this happens is because the pushed
head was not up-to-date, clarify the error message to say that
straight, and suggest pulling first.
First noticed by Johannes and seconded by Andreas.
This changes the way the case two branches rename the same path
to different paths is handled. Earlier, the code removed the
original path and added both destinations to the index at
stage0. This commit changes it to leave the original path at
stage1, and two destination paths at stage2 and stage3,
respectively.
[jc: I am not really sure if this makes much difference in the
real life merge situations. What should happen when our branch
renames A to B and M to N, while their branch renames A to M?
That is, M remains in our tree as is.]
HPA suggests it is simply silly to imitate Linux versioning
scheme where the leading "2" does not mean anything anymore, and
I tend to agree.
The first feature release after 1.0.0 will be 1.1.0, and the
development path leading to 1.1.0 will carry 1.0.GIT as the
version number from now on. Similarly, the third maintenance
release that follows 1.0.0 will not be 1.0.0c as planned, but
will be called 1.0.3. The "maint" branch will merge in fixes
and immediately tagged, so there is no need for 1.0.2.GIT that
is in between 1.0.2 (aka 1.0.0b) and 1.0.3.
- Avoid misleading success message on error (Johannes)
- objects/info/packs: work around bug in http-fetch.c::fetch_indices()
- http-fetch.c: fix objects/info/pack parsing.
- An off-by-one bug found by valgrind (Pavel)
objects/info/packs: work around bug in http-fetch.c::fetch_indices()
The code to fetch pack index files in deployed clients have a
bug that causes it to ignore the pack file on the last line of
objects/info/packs file, so append an empty line to work it
around.