[PATCH] Make 'git checkout' a bit more forgiving when switching branches.
If you make a commit on a path, and then make the path
cache-dirty afterwards without changing its contents, 'git
checkout' to switch to another branch is prevented because
switching the branches done with 'read-tree -m -u $current
$next' detects that the path is cache-dirty, but it does not
bother noticing that the contents of the path has not been
actualy changed.
Since switching branches would involve checking out paths
different in the two branches, hence it is reasonably expensive
operation, we can afford to run update-index before running
read-tree to reduce this kind of false change from triggering
the check needlessly.
[PATCH] Omit patches that have already been merged from format-patch output.
This switches the logic to pick which commits to include in the output
from git-rev-list to git-cherry; as a side effect, 'format-patch ^up mine'
would stop working although up..mine would continue to work.
[PATCH] There are several undocumented dependencies
There are several undocumented dependencies in the .spec and in the
INSTALL files. The following is from Fedora, perhaps other RPM
distributions call the packages differently.
Also, the manpages aren't always installed gzipped.
Updates to git-core.spec.in file:
- Some git scripts use Perl
- gitk needs wish, which is part of TCL/Tk.
- curl is used all over
- Need the ssh program from openssh-clients
Updates to INSTALL:
- Mention wish
- Mention ssh
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
This allows any arbitrary flags to "grep", and knows about the few
special grep flags that take an argument too.
It also allows some flags for git-ls-files, although their usefulness
is questionable.
With this, something line
git grep -w -1 pattern
works, without the script enumerating every possible flag.
[jc: this is the version Linus sent out after I showed him a
barf-o-meter test version that avoids shell arrays. He must
have typed this version blindly, since he said:
I'm not barfing, but that's probably because my brain just shut
down and is desperately trying to gouge my eyes out with a spoon.
I slightly fixed it to catch the remaining arguments meant to be
given git-ls-files.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This should work around the compilation problem Johannes Schindelin
and others had on Mac OS/X.
Quoting Linus:
Any operating system where socklen_t is anything else than "int" is
terminally broken. The people who introduced that typedef were confused,
and I actually had to argue with them that it was fundamentally wrong:
there is no other valid type than "int" that makes sense for it.
When the git diff status 'N' was changed to 'A', diff-helper.c was
not updated accordingly. This means that it no longer shows the
diff for newly added files.
This patch makes that change in diff-helper.c.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Junio C Hamano <junkio@cox.net>
Switched from backwards hard-coded tmp directory creation to using
File::Temp::tempdir() to create the directory inside $TMP_PATH or
what the user has provided via the -t parameter.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Updated the usage/help message to match asciidoc documentation. The perldoc
documentation now includes the first paragraph from the asciidoc documentation
and points users to the manpage.
Updated TODO section.
Removed some redundant options from the getopt() invocation.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
AsciiDoc replace '--' with em-dash (—) by default. em-dash
looks a lot like a single long dash and it's very confusing when
we are talking about command options.
Section 21.2.8 'Replacements' of AsciiDoc's User Guide says that a
backslash in front of double dash prevent the replacement. This
patch does just that.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
I really wanted to try this out, instead of asking for an adjustment
to the 'git merge' driver and waiting. For now the new strategy is
called 'fredrik' and not in the list of default strategies to be tried.
The script wants Python 2.4 so this commit also adjusts Debian and RPM
build procecure files.
The new command 'git merge' takes the current head and one or more
remote heads, with the commit log message for the automated case.
If the heads being merged are simple fast-forwards, it acts the
same way as the current 'git resolve'. Otherwise, it tries
different merge strategies and takes the result from the one that
succeeded auto-merging, if there is any.
If no merge strategy succeeds auto-merging, their results are
evaluated for number of paths needed for hand resolving, and the
one with the least number of such paths is left in the working
tree. The user is asked to resolve them by hand and make a
commit manually.
The calling convention from the 'git merge' driver to merge
strategy programs is very simple:
- A strategy program is to be called 'git-merge-<strategy>'.
That is, one or more the common ancestors, double dash, the
current head, and one or more remote heads being merged into
the current branch.
- Before a strategy program is called, the working tree is
matched to the current <head>.
- The strategy program exits with status code 0 when it
successfully auto-merges the given heads. It should do
update-cache for all the merged paths when it does so -- the
index file will be used to record the merge result as a
commit by the driver.
- The strategy program exits with status code 1 when it leaves
conflicts behind. It should do update-cache for all the
merged paths that it successfully auto-merged, and leave the
cache entry in the index file as the same as <head> for paths
it could not auto-merge, and leave its best-effort result
with conflict markers in the working tree when it does so.
- The strategy program exists with status code other than 0 or
1 if it does not handle the given merge at all.
As examples, this commit comes with merge strategies based on
'git resolve' and 'git octopus'.
[PATCH] Add debugging help for case #16 to read-tree.c
This will help us detect if real-world example merges have multiple
merge-base candidates and one of them matches one head while another
matches the other head.
Keep bisection log so that it can be replayed later.
The 'git bisect' command was very unforgiving in that once you made a
mistake telling it good/bad it was very hard to take it back. Keep a
log of what you told it in an earlier session, so that it can be
replayed after removing everything after what you botched last time.
When (A,B) ==> (B,C) rename-copy was detected, we incorrectly said
that C was created by copying B. This is because we only check if the
path of rename/copy source still exists in the resulting tree to see
if the file is renamed out of existence. In this case, the new B is
created by copying or renaming A, so the original B is lost and we
should say C is a rename of B not a copy of B.
We now keep track of the patches merged in each branch since they have
diverged, using the records that the Arch "logs" provide. Merge parents
for a commit are defined if we are merging a series of patches that starts
from the mergebase.
If patches from a related branch are merged out-of-order, we keep track of
how much has been merged sequentially -- the tip of that sequential merge
is our new parent from that branch.
This mechanism works very well for branches that merge in dovetail and/or
flying fish patterns, probably less well for others.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
The --list option is what 'git branch' without parameter should
have been; it shows the one-line commit message for each branch
name. The --independent option is used to filter out commits
that can be reachable from other commits, to make detection of
fast forward condition in multi-head merge easier.
[PATCH] remove duplicate git-send-email-script.perl target in Makefile
Remove duplicate git-send-email-perl target in Makefile.
When WITH_SEND_EMAIL was defined, as in the Debian 'deb' target,
git-send-email-perl was added twice to SCRIPT_PERL, leading to a
duplicate definition in the Makefile. Creating a ".deb" then failed.
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl> Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we renamed git-foo.sh to git-foo while installing, which
was mostly done by inertia than anything else. This however
made writing tests to use scripts harder.
This patch builds the scripts the same way as we build binaries
from their sources. As a side effect, you can now specify
non-standard paths you have your Perl binary is in when running
the make.
git-daemon using inetd. does not work properly. inetd routes stderr onto the
network line just like stdout, which was apparently not expected to be so.
As the result of this, the stream is closed by the receiver, because some
"Packing %d objects\n" originating from pack_objects is first reported over
the line instead of the expected pack_header, and so the SIGNATURE test
fails. Here is a workaround.
[PATCH] Do not create bogus branch from flag to git branch
If you run `git branch --help', you will unexpectedly have created a new
branch named "--help". This simple patch adds logic and a usage
statement to catch this and similar problems, and adds a testcase for it.
Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* getdomainname unavailable there.
* needs -lsocket for linkage.
* needs __EXTENSIONS__ at the beginning of convert-objects.c
[JC: I've done this slightly differently from what Patrick originally
sent to the list and dropped the bit that deals with installations
that has curl header and library at non-default location. I am
resisting the slipperly slope called autoconf.]
As promised, this is the "big tool rename" patch. The primary differences
since 0.99.6 are:
(1) git-*-script are no more. The commands installed do not
have any such suffix so users do not have to remember if
something is implemented as a shell script or not.
(2) Many command names with 'cache' in them are renamed with
'index' if that is what they mean.
There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support is expected to be removed in the near
future.
parse-remote and rev-parse gets full documentation. Add skeleton for
archimport. Link them from the main git(7) page. Also move git-daemon
and git-request-pull out of 'undocumented' section.
Flatten tools/ directory to make build procedure simpler.
Also make platform specific part more isolated. Currently we only
have Darwin defined, but I've taken a look at SunOS specific patch
(which I dropped on the floor for now) as well. Doing things this way
would make adding it easier.
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
[PATCH] Make git-apply understand incomplete lines in non-C locales
The message "\ No newline at end of file" used by diff(1) to mark
an incomplete line is locale dependent. We can't assume more than
that it begins with "\ ".
For example, given two files, "foo" and "bar", with appropriate
contents, 'diff -u foo bar' will produce the following output on
my system:
--- foo 2005-09-04 18:59:38.000000000 +0200
+++ bar 2005-09-04 18:59:16.000000000 +0200
@@ -1 +1 @@
-foobar
+foo
\ Ingen nyrad vid filslut
[jc: the check for the marker still uses the line length being no less
than 12 bytes for a sanity check, but I think it is safe to assume
that in other locales. I haven't checked the .po files from diff, tho'.]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] archimport: avoid committing on an Arch tag
Arch tags are full commits (without any changed files) as well. Trust Arch
to have put an unchanged tree in place (which seems to do reliably), and
just add a tag & new branch. Speeds up Arch imports significantly, and leaves
history in a much saner state.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] NUL terminate the object data in patch_delta()
At least pretty_print_commit() expects to get NUL-terminated commit data to
work properly. unpack_sha1_rest(), which reads objects from separate files,
and unpack_non_delta_entry(), which reads non-delta-compressed objects from
pack files, already add the NUL byte after the object data, but patch_delta()
did not do it, which caused problems with, e.g., git-rev-list --pretty when
there are delta-compressed commit objects.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] Doc: replace read-cache with git-read-tree.
Replace references to "read-cache" with references to git-read-tree in the
documentation. I chose that because reference say "see read-cache about
stages", and stages are explained in git-read-tree.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net>
Mention post-update when we first talk about publishing a repository.
There is more detailed instruction for `project lead` later in
the tutorial to talk about the same, but at this point in the
flow of tutorial, the first time reader has no way of knowing it.
Double-equal is accepted by bash built-in '[' and bash(1) suggests
using '=' for strict POSIX compliance (test(1) from coreutils does not
mention '=='). Eradicate their uses everywhere.
[jc: Somebody with a pseudonym kindly sent a message to let
me know about the problem privately; I do not have access to a NetBSD
box.]
The rewrite done while adding the shorthand support made the remote
refname recorded in the commit message too long for human consumption,
while losing information by using the shorthand not the real URL to
name the remote repository there. They were both bad changes done
without enough thinking.
[PATCH] Explain what went wrong on update-cache of new file
If somebody tries to run `git update-cache foo', where foo is a new
file, git dies with a rather cryptic error message:
fatal: Unable to add foo to database
This trivial patch makes git explain what probably went wrong. It is
not a perfect diagnosis of all error paths, but for 90% of the cases it
should provide the user with the clue they need.
[jc: I ended up wording slightly differently, and fixed another
confusing error message I noticed while reviewing the code.]
Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
It used 'die' without including git-sh-setup-script; since everything
it uses are subdirectory-aware, instead of including the script to
force it to be run from the top, use echo & exit.