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.
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.
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.
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.
The previous round caught the most trivial case well, but broke
down once index file is updated again. Smudge problematic
entries (they should be very few if any under normal interactive
workflow) before writing a new index file out.
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
format-patch: make sure header and body are separated.
Since log message in a commit object is defined to be binary
blob, it could be something without an empty line between the
title line and the body text. Be careful to format such into
a form suitable for e-mail submission. There must be an empty
line between the headers and the body.
When I show transcripts to explain how something works, I often
find myself hand-editing the diff-raw output to shorten various
object names in the output.
This adds --abbrev option to the diff family, which shortens
diff-raw output and diff-tree commit id headers.
xread/xwrite: do not worry about EINTR at calling sites.
We had errno==EINTR check after read(2)/write(2) sprinkled all
over the places, always doing continue. Consolidate them into
xread()/xwrite() wrapper routines.
Credits for suggestion goes to HPA -- bugs are mine.
We still advertise "git resolve" as a standalone command, but never
"git octopus", so nobody should be using it and it is safe to
retire it. The functionality is still available as a strategy
backend.
rev-list --objects: fix object list without commit.
Earlier, "rev-list --objects <sha1>" for an object chain that
does not have any commit failed with a usage message. This
fixes "send-pack remote $tag" where tag points at a non-commit
(e.g. a blob).
This changes "pretty_print_string_list()" to show the git commands
alphabetically in column order, which is the normal one.
Ie instead of doing
git commands available in '/home/torvalds/bin'
----------------------------------------------
add am ...
applypatch archimport ...
cat-file check-ref-format ...
...
it does
git commands available in '/home/torvalds/bin'
----------------------------------------------
add diff-tree ...
am fetch ...
apply fetch-pack ...
...
where each column is sorted.
This is how "ls" sorts things too, and since visually the columns are much
more distinct than the rows, so it _looks_ more sorted.
The "ls" command has a "-x" option that lists entries by lines (the way
git.c used to): if somebody wants to do that, the new print-out logic
could be easily accomodated to that too. Matter of taste and preference, I
guess.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently the git "show commands" function will react to the environment
variable COLUMNS, or just default to a width of 80 characters.
That's just soo eighties. Nobody sane sets COLUMNS any more, unless they
need to support some stone-age software from before the age of steam
engines, SIGWINCH and TIOCGWINSZ.
So get with the new century, and use TIOCGWINSZ to get the terminal size.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Split out the functions that deal with the socketpair after
finishing git protocol handshake to receive the packed data into
a separate file, and use it in fetch-pack to keep/explode the
received pack data. We earlier had something like that on
clone-pack side once, but the list discussion resulted in the
decision that it makes sense to always keep the pack for
clone-pack, so unpacking option is not enabled on the clone-pack
side, but we later still could do so easily if we wanted to with
this change.
This removes the misguided attempt to refuse processing a branch
name xyzzy and insist it to be given as either heads/xyzzy or
tags/xyzzy when a tag xyzzy exists. There was no reason to do
so --- the search order was predictable and well defined, so if
the user says xyzzy we should have taken the tag xyzzy in such a
case without complaining.
This incidentally fixes another subtle bug related to this. If
such a duplicate branch/tag name happened to be a unique valid
prefix of an existing commit object name (say, "beef"), we did
not take the tag "beef" but after complaining used the commit
object whose name started with beef.
Another problem this fixes while introducing some confusion is
that there is no longer a reason to forbid a branch name HEAD
anymore. In other words, now "git pull . ref1:HEAD" would work
as expected, once we revert "We do not like HEAD branch" patch.
It creates "HEAD" branch under ${GIT_DIR-.git}/refs/heads (or
fast-forwards if already exists) using the tip of ref1 branch
from the current repository, and merges it into the current
branch.
git-am --skip does not unpack the next patch and ends up reapplying the
old patch, believing that it is the new patch in the sequence.
If the old patch applied successfully it will commit it with the
supposedly skipped log message and ends up dropping the following patch.
If the patch did not apply the user is left with the conflict he tried
to skip and has to unpack the next patch in the sequence by hand to get
git-am back on track.
By clearing the resume variable whenever skips bumps the sequence
counter we correctly unpack the next patch. I also added another
resume= in the case a patch file is missing from the sequence to
avoid the same problem when a file in the sequence was removed.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
Morten Welinder says examples of resetting is really about
recovering from botched commit/pulls. I agree that pointers
from commands that cause a reset to be needed in the first place
would be very helpful.
Also reset examples did not mention "pull/merge" cases.
"git show-branch bugs/*" shows all branches whose name match the
specified pattern, but in the order readdir() happened to
returned. Sort them to make the output more predictable.
When .git/refs/heads/frotz and .git/refs/tags/frotz existed, and
the object name stored in .git/refs/heads/frotz were corrupt, we
ended up picking tags/frotz without complaining. Worse yet, if
the corrupt .git/refs/heads/frotz was more than 40 bytes and
began with hexadecimal characters, it silently overwritten the
initial part of the returned result.
This commit adds a couple of tests to demonstrate these cases,
with a fix.
Now we detect that the SVN repo does not have new commits for us and exit
cleanly, removing the lockfile. With this, svnimport supports being run
on a cronjob to maintain a SVN2GIT gateway.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
clone-pack: make it usable for partial branch cloning.
clone-pack had some logic to accept subset of remote refs from
the command line and clone from there. However, it was never
used in practice and its problems were not found out so far.
This commit changes the command to output the object names of
refs to the standard output instead of making a clone of the
remote repository when explicit <head> parameters are given; the
output format is the same as fetch-pack.
The traditional behaviour of cloning the whole repository by
giving no explicit <head> parameters stays the same.
Oh, I hate to do this but I ended up merging big usage string
cleanups from Fredrik, git-am enhancements that made a lot of
sense for non mbox users from HPA, and rebase changes (done
independently by me and Lukas) among other things, so git is
still in perpetual state of 1.0rc. 1.0 will probably be next
Wednesday, but who knows.
git rebase loses author name/email if given bad email address
If GIT_AUTHOR_EMAIL is of a certain form, `git rebase master' will blow
away the author name and email when fast-forward merging commits. I
have not tracked it down, but here is a testcase that demonstrates the
behavior.
Signed-off-by: Amos Waterland <apw@us.ibm.com> Acked-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix bugs in git-rebase wrt rebasing another branch than
the current HEAD, rebasing with a dirty working dir,
and rebasing a proper decendant of the target branch.
[jc: with a bit of hand-merging]
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
An isolated developer could have a local-only e-mail, which will
be stripped out by mailinfo because it lacks '@'. Define a
fallback parser to accomodate that.
At the same time, reject authorless patch in git-am.
rebase: do not get confused in fast-forward situation.
When switching to another branch and rebasing it in a one-go, it
failed to update the variable that holds the branch head, and
did not detect fast-forward situation correctly.
Recommend git over ssh direct to master.kernel.org, instead of
going over rsync to public machines, since this is meant to be a
procedure for kernel subsystem maintainers.
There were some problems with the usage message clean-up patch
series. I hadn't realised that subdirectory aware scripts can't source
git-sh-setup. I propose that we change this and let the scripts which
are subdirectory aware set a variable, SUBDIRECTORY_OK, before they
source git-sh-setup.
The scripts will also set USAGE and possibly LONG_USAGE before they
source git-sh-setup. If LONG_USAGE isn't set it defaults to USAGE.
If we go this way it's easy to catch --help in git-sh-setup, print the
(long) usage message to stdout and exit cleanly. git-sh-setup can
define a 'usage' shell function which can be called by the scripts to
print the short usage string to stderr and exit non-cleanly. It will
also be easy to change $0 to basename $0 or something else, if would
like to do that sometime in the future.
What follows is a patch to convert a couple of the commands to this
style. If it's ok with everyone to do it this way I will convert the
rest of the scripts too.
[jc: thrown in to proposed updates queue for comments.]
This allows git-am to accept single-message files as well as mboxes.
Unlike the previous version, this one doesn't need to be explicitly told
which one it is; rather, it looks to see if the first line is a From
line and uses it to select mbox mode or not.
I moved the logic to do all this into git-mailsplit, which got a new
user interface as result, although the old interface is still available
for backwards compatibility.
[jc: applied with two obvious fixes.]
Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git fetch --tags
* Use of "git push" as a one-man distributed development vehicle.
* Show example of remotes file for pulling and pushing.
* Annotate git-shell setup.
* Using Carl's update hook in a CVS-style shared repository.
Make git-send-pack exit with error when some refs couldn't be pushed out
In case some refs couldn't be pushed out due to an error (mostly the
not-a-proper-subset error), make git-send-pack exit with non-zero status
after the push is over (that is, it still tries to push out the rest
of the refs).
[jc: I adjusted a test for this change.]
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Although "git-merge" is advertised as the end-user level command
(instead of being a "git-pull" backend), it was not prepared to
take tag objects that point at commits and barfed when fed one.
Sanitize the input while we validate them, for which we already
have a loop.
git-clone: tell the user a bit more about clone-pack failure.
When clone-pack has trouble with the remote, it dies unfriendly
"EOF" error message. We cannot tell the reason why it failed
from the local end; it could be that the repository did not
exist, or configured not to serve over git-daemon, or a network
failure. At least, saying clone-pack failed makes it a bit more
meaningful.
I am not convinced yet that removing the newly created directory
is the right thing to do, so this commit leaves the new
directory behind.
The initial section of tutorial was too heavy on internal
workings for the first-time readers, so rewrite the introductory
section of git(7) to start with "not learning core git commands"
section and refer them to README to grasp the basic concepts,
then Everyday to give overview with task/role oriented examples
for minimum set of commands, and finally the tutorial.
Also add to existing note in the tutorial that many too
technical descriptions can be skipped by a casual reader.
I initially started to review the tutorial, with the objective
of ripping out the detailed technical information altogether,
but I found that the level of details in the initial couple of
sections that talk about refs and the object database in a
hands-on fashion was about rigth, and left all of them there. I
feel that reading about fsck-index and repack is too abstract
without being aware of these directories and files.