After seeing Jeff's guide, I changed my mind about the
big-rename transition plan. Even if Porcelains are kept up to
date, those web documents that describes older world order would
live longer and people will stumble across them via google
searches. And who knows how many mirrored copies there are.
The backward compatible symbolic links *will* be removed before
1.0. But that will not happen in 0.99.8.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a careful version of the script stuff that currently just
blindly writes HEAD with a new value.
You can use
git-update-ref HEAD <newhead>
or
git-update-ref HEAD <newhead> <oldhead>
where the latter version verifies that the old value of HEAD matches
oldhead.
It basically allows a "ref" file to be a symbolic pointer to another ref
file by starting with the four-byte header sequence of "ref:".
More importantly, it allows the update of a ref file to follow these
symbolic pointers, whether they are symlinks or these "regular file
symbolic refs".
NOTE! It follows _real_ symlinks only if they start with "refs/":
otherwise it will just try to read them and update them as a regular file
(ie it will allow the filesystem to follow them, but will overwrite such a
symlink to somewhere else with a regular filename).
In general, using
git-update-ref HEAD "$head"
should be a _lot_ safer than doing
echo "$head" > "$GIT_DIR/HEAD"
both from a symlink following standpoint _and_ an error checking
standpoint. The "refs/" rule for symlinks means that symlinks that point
to "outside" the tree are safe: they'll be followed for reading but not
for writing (so we'll never write through a ref symlink to some other
tree, if you have copied a whole archive by creating a symlink tree).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we conditionally compile things in compat/, so we should remove
object files there. Python execution can leave *.pyc and *.pyo, which
need to be cleaned as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also cmd-renames.sh can now be used to remove the backward compatible
symlinks -- this is not used by default in any way.
As discussed on the list with Pasky, git-ssh-push and git-ssh-pull will
keep calling each other for a while longer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pasky taught me how he does his versioning for ELinks. This will sort
after 0.99.7 and interim fixes 0.99.7a, and before 0.99.8.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Taking the make command line Peter Eriksen uses, give defaults
to SHELL_PATH, TAR, CURLDIR, NO_STRCASESTR, and INSTALL.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Support systems that do not install curl headers and libraries
in /usr/{include,lib}.
Signed-off-by: Patrick Mauritz <oxygene@studentenbude.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Including the current branch in the list of heads being merged
was not a good idea, so drop it. And shorten the message by
grouping branches and tags together to form a single line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The textual diff generation with built-in '-p' in diff-* brothers has
proven to be useful enough that git-diff-helper outlived its usefulness.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some old scripts might still use git-rev-tree, but it really is
clearly inferior in every way to git-rev-list that such scripts should
be fixed anyway. Fixing them should be pretty easy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-export was done as a concept example on how easy it is to export
the git data to something else. It's much less powerful than any
number of trivial one-liner scripts now, and real exporters would not
ever use git-export.
It's obviously much less powerful than "git-whatchanged", or just
about any combination of git-rev-list + git-diff-tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is my ARM assembly SHA1 implementation for GIT. It is approximately
50% faster than the generic C version. On an XScale processor running at
400MHz:
generic C version: 9.8 MB/s
my version: 14.5 MB/s
It's not that I expect a lot of big GIT users on ARM, but I stillknow
about one important ARM user that might benefit from it, and writing
that code was fun.
I also reworked the makefile a bit so any optimized SHA1 implementations
is used regardless of whether NO_OPENSSL is defined or not.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some C libraries lack strcasestr(); add a stupid replacement
to help folks with such.
[jc: original Linus posting, updated with his "also need <ctype.h>",
updated further with a fix from Joachim B Haga <cjhaga@fys.uio.no>"]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Jason Riedy suggests that we should be able to use getdomainname
if we properly specify which libraries to link.
Signed-off-by: Junio C Hamano <junkio@cox.net>
HPA reminded me that these programs knows about the name of the
counterpart on the other end and simply symlinking the old name to
new name locally would not be enough.
Signed-off-by: Junio C Hamano <junkio@cox.net>
... in order to please Solaris 'install'. GNU install is not harmed
with this.
[jc: Documentation/Makefile also fixed.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise we would regret when Fredrik comes up with another merge
algorithm with different pros-and-cons with the current one.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Very convenient shorthand for
git-ls-files [file-patterns] | xargs grep <pattern>
which I tend to do all the time.
Yes, it's trivial, but it's really nice. I can do
git grep '\<some_variable\>' arch/i386 include/asm-i386
and it does exactly what you'd think it does. And since it just uses the
normal git-ls-files file patterns, you can do things like
git grep something 'include/*.h'
and it will search all header files under the include/ subdirectory.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>'.
- They take input of this form:
<common1> <common2> ... '--' <head> <remote1> <remote2>...
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'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have deprecated the old environment variable names for quite a
while and now it's time to remove them. Gone are:
SHA1_FILE_DIRECTORIES AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME
COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
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.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now the rebase is rewritten to use git cherry-pick, there is no user
for that ancient script. I've checked Cogito and StGIT to make sure
they do not use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reverse patch application using "git apply" sometimes is too
rigid. Since the user would get used to resolving conflicting merges
by hand during the normal merge experience, using the same machinery
would be more helpful rather than just giving up.
Cherry-picking and reverting are essentially the same operation.
You pick one commit, and apply the difference that commit introduces
to its own commit ancestry chain to the current tree. Revert applies
the diff in reverse while cherry-pick applies it forward. They share
the same logic, just different messages and merge direction.
Rewrite "git rebase" using "git cherry-pick".
Signed-off-by: Junio C Hamano <junkio@cox.net>
You can define WITH_SEND_EMAIL to include the send-email command as
part of the installation. Since Debian, unlike RPM/Fedora, has the
two necessary Perl modules available as part of the mainline
distribution, there is no reason for us to shy away from shipping
send-email.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script uses the list of heads and their origin multi-head "git
fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
merge on top of the current HEAD using them.
The implementation tries to be strict for the sake of safety. It
insists that your working tree is clean (no local changes) and matches
the HEAD, and when any of the merged heads does not automerge, the
whole process is aborted and tries to rewind your working tree is to
the original state.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update git-pull to match updated git-fetch and allow pull to
fetch from multiple remote references. There is no support for
resolving more than two heads, which will be done with "git
octopus".
Update "git ls-remote" to use git-parse-remote-script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When showing only one branch a lot of default output becomes redundant,
so clean it up a bit, and document what is shown. Retire the earlier
implementation "git-show-branches-script".
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'git show-branches' command turns out to be reasonably useful,
but painfully slow. So rewrite it in C, using ideas from merge-base
while enhancing it a bit more.
- Unlike show-branches, it can take --heads (show me all my
heads), --tags (show me all my tags), or --all (both).
- It can take --more=<number> to show beyond the merge-base.
- It shows the short name for each commit in the extended SHA1
syntax.
- It can find merge-base for more than two heads.
Examples:
$ git show-branch --more=6 HEAD
is almost the same as "git log --pretty=oneline --max-count=6".
$ git show-branch --merge-base master mhf misc
finds the merge base of the three given heads.
$ git show-branch master mhf misc
shows logs from the top of these three branch heads, up to their
common ancestor commit is shown.
$ git show-branch --all --more=10
is poor-man's gitk, showing all the tags and heads, and
going back 10 commits beyond the merge base of those refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We always show the diff as an absolute path, but pathnames to diff are
taken relative to the current working directory (and if no pathnames are
given, the default ends up being all of the current working directory).
Note that "../xyz" also works, so you can do
cd linux/drivers/char
git diff ../block
and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Often I find myself wanting to do quick branches check when I am
not in the windowing environment and cannot run gitk.
This stupid script shows commits leading to the heads of
interesting branches with indication which ones belong to which
branches, so that fork point is somewhat discernible without
using gitk.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tools directory being separate is just a historical
coincidence. Build and install together with the main
directory, just like the clean target does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use <tab> instead of two spaces uniformly in the Makefile, even in the
ifdefs. Gives it a nice consistent look.
[jc: At the same time I indented the nested ifdefs to make them
slightly easier to read.]
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$DESTDIR is more usual during the build than $dest and is what
is usually used in the makefiles, so let's use it too.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch renames COPTS to CFLAGS, because it's COPTS that was user
overridable. Also, -Wall is moved there because it's optional. What
was CFLAGS is now ALL_CFLAGS, which users should not override.
Defines are added to DEFINES. Since ALL_CFLAGS is recursively expanded,
it uses the final value of DEFINES.
Implicit rules are made explicit since the implicit rules use CFLAGS
rather than ALL_CFLAGS. I believe that serious projects should not rely
on implicit rules anyway. Percent rules are used because they are used
already and because they don't need the .SUFFIXES target.
[jc: in addition to updating the patch for 0.99.4, I fixed up a
glitch in Pavel's original patch which compiled sha1.o out of
mozilla-sha1/sha1.c, where it should have left the resulting
object file in mozilla-sha1 directory for later "ar".]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merges commit
c35a7b8d806317dc1762e36561cbd31c2530dd9c
from master into our head commit
edee414c3e5a546aae3dd1529f397df949713305
Sincerely,
jit-merge command.
Given one existing commit, revert the change the patch
introduces, and record a new commit that records it. This
requires your working tree to be clean (no modifications from
the HEAD commit).
This is based on what Linus posted to the list, with
enhancements he suggested, including the use of -M to attempt
reverting renames.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merges commit
f10e0e0b18c8e2e69535e7380fb3c1f9b097cfda
from master into our head commit
c3958a7926ab20b90fe0767580b466698477f5b6
Sincerely,
jit-merge command.
RPM folks have problem installing the package otherwise. Since
its usefulness does have much to do with GIT, downgrade it to
"contrib" status for now. We may want to move it to contrib/
subdirectory after auditing other programs when we reorganize
the source tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merges commit
3c4e8a636f4de3668b24d0020df731cdc78ae6e9
from master into our head commit
80f45687f44b6258b0eacae6b1ae15e3ad4a6552
Sincerely,
jit-merge command.
Run install-tools target to install the tools to accept e-mail
patches. Also clean up the main Makefile a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is my first attempt to adjust Debian and RPM to pass
prefix, to prepare the 0.99.4 release.
It updates debian/rules and git-core.spec.in to properly pass
prefix when building binary packages. It also updates
debian/changelog to make the resulting binary package name
0.99.4; this is not needed on the RPM side (it takes the version
number from the main Makefile).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Per discussion with people interested in binary packaging,
change the default template location from /etc/git-core to
/usr/share/git-core hierarchy. If a user wants to run git
before installing for whatever reason, in addition to adding
$src to the PATH environment variable, git-init-db can be run
with --template=$src/templates/blt/ parameter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody envies rev-parse, who is the only one that can grok
the extended sha1 format. Move the get_extended_sha1() out of
rev-parse, rename it to get_sha1() and make it available to
everybody else.
The one I posted earlier to the list had one bug where it did
not handle a name that ends with a digit correctly (it
incorrectly tried the "Nth parent" path). This commit fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The king penguin said:
It has no point any more, all the tools check the file
status on their own, and yes, the thing should probably be
removed.
and the faithful servant makes it so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A template mechanism to populate newly initialized repository
with default set of files is introduced. Use it to ship example
hooks that can be used for update and post update checks, as
Josef Weidendorfer suggests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
all the nice things a good subsystem maintainer does when forwarding a patch or
50 upstream:
All the prior handlers of the patch, as determined by the
Signed-off-by: lines, and/or the author of the commit, are cc:ed on the
email.
All emails are sent as a reply to the previous email, making it easy to
skip a collection of emails that are uninteresting.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Things have slowly but surely started to settle down, and the
http transport finally can natively grok packed repositories.
To give Pasky a good anchor point, hoping that he can start
split off the core part from Cogito, here is the 0.99.3, which
will be accompanied with its own tag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just before updating a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha1
is called if executable. The hook can decline the ref to be
updated by exiting with a non-zero status, or allow it to be
updated by exiting with a zero status. The mechanism also
allows e.g sending of a mail with pushed commits on the remote
repository.
Documentation update with an example hook is included.
jc: The credits of the basic idea and initial implementation go
to Josef, but I ended up rewriting major parts of his patch, so
bugs are all mine. Also I changed the semantics for the hook
from his original version (which were post-update hook) so that
the hook can optionally decline to update the ref, and also can
be used to implement the overall cleanups. The latter was
primarily to implement a suggestion from Linus that calling
update-server-info should be made optional.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This counts the number of unpacked object files and disk space
consumed by them, to help you decide when it is a good time to
repack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Implement fetching from a packed repository over http/https
using the dumb server support files.
I consider some parts of the logic should be in a separate C
program, but it appears to work with my simple tests. I have
backburnered it for a bit too long for my liking, so let's throw
it out in the open and see what happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch implements Linus' idea that if you are not interested in
pulling by HTTP, you can now say
NO_CURL=1 make
to compile everything except git-http-pull (thus not needing curl at all).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a new "git bisect" command.
- "git bisect start"
start bisection search.
- "git bisect bad <rev>"
mark some version known-bad (if no arguments, then current HEAD)
- "git bisect good <revs>..."
mark some versions known-good (if no arguments, then current HEAD)
- "git bisect reset <branch>"
done with bisection search and go back to your work (if
no arguments, then "master").
The way you use it is:
git bisect start
git bisect bad # Current version is bad
git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
# tested that was good
When you give at least one bad and one good versions, it will
bisect the revision tree and say something like:
Bisecting: 675 revisions left to test after this
and check out the state in the middle. Now, compile that kernel, and boot
it. Now, let's say that this booted kernel works fine, then just do
git bisect good # this one is good
which will now say
Bisecting: 337 revisions left to test after this
and you continue along, compiling that one, testing it, and depending on
whether it is good or bad, you say "git bisect good" or "git bisect bad",
and ask for the next bisection.
Until you have no more left, and you'll have been left with the first bad
kernel rev in "refs/bisect/bad".
Oh, and then after you want to reset to the original head, do a
git bisect reset
to get back to the master branch, instead of being in one of the bisection
branches ("git bisect start" will do that for you too, actually: it will
reset the bisection state, and before it does that it checks that you're
not using some old bisection branch).
Not really any harder than doing series of "quilt push" and "quilt pop",
now is it?
[jc: This patch is a rework based on what Linus posted to the
list. The changes are:
- The original introduced four separate commands, which was
three too many, so I merged them into one with subcommands.
- Since the next thing you would want to do after telling it
"bad" and "good" is always to bisect, this version does it
automatically for you.
- I think the termination condition was wrong. The original
version checked if the set of revisions reachable from next
bisection but not rechable from any of the known good ones
is empty, but if the current bisection was a bad one, this
would not terminate, so I changed it to terminate it when
the set becomes a singleton or empty.
- Removed the use of shell array variable.
]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Separate the process of building the commands to compilation and
linkage. This makes it more consistent with the library objects, is the
traditional thing to do, and significantly speeds up the subsequent
rebuilds, especially for us the people who develop git on 300MHz
notebooks.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Support for completely OpenSSL-less builds. FSF considers distributing GPL
binaries with OpenSSL linked in as a legal problem so this is trouble
e.g. for Debian, or some people might not want to install OpenSSL
anyway. If you
make NO_OPENSSL=1
you get completely OpenSSL-less build, disabling --merge-order and using
Mozilla's SHA1 implementation.
Ported from Cogito.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The Makefile rules were massively reordered so that they are actually
logically grouped now. Captions were added to separate the sections. No
rule contents was touched during the process.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
