It printed the header "encoding " instead of just showing
the encoding, as all other items do.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are two breakages in the %P/%p interpolation. It appended
an excess SP at the end of the list, and it gave uninitialized
contents of a buffer on the stack for root commits.
This fixes it, while updating the t6006 test which expected the
wrong output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Please see http://bugs.debian.org/409887
http-fetch expected the URL given at the command line to have a trailing
slash anyway, and then added '/objects...' when requesting objects files
from the http server.
Now it doesn't require the trailing slash in <url> anymore, and strips
trailing slashes if given nonetheless.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These could stand to be a little more complex, but it should
at least catch obvious problems (like the recently fixed %ct
bug).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Right now, we don't close the read end of the pipe when git-upload-pack
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.
Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.
This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A pointer arithmetic error in fill_person caused random data
from the commit object to be included with the timestamp,
which looked something like:
$ git-rev-list --pretty=format:%ct origin/next | head
commit 98453bdb3db10db26099749bc4f2dc029bed9aa9
1174977948 -0700
Merge branch 'master' into next
* master:
Bisect: Use
commit c0ce981f5e
1174889646 -0700
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At least in Linux glibc, "getaddrinfo()" has a very irritating feature (or
bug, who knows..).
Namely if you pass it in an empty string for the service name, it will
happily and quietly consider it identical to a NULL port pointer, and
return port number zero and no errors. Which obviously will not work.
Maybe that's what it's really expected to do, although the man-page for
getaddrinfo() certainly implies that it's a bug.
So when somebody passes me a "please pull" request pointing to something
like the following
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
(note the extraneous colon at the end of the host name), git would happily
try to connect to port 0, which would generally just cause the remote to
not even answer, and the "connect()" will take a long time to time out.
So to work around the glibc feature/bug, just notice this empty port case
automatically. Also, add the port information to the error information
when it fails to look up (maybe it's the host-name that fails, maybe it's
the port-name - we should print out both).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While running 'make test', the test-chmtime program is created, and should
be cleaned up on 'make clean'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use git-log --pretty=oneline to print a short description of the
current HEAD (and merge heads if any) in the buffer header.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We may be able to "run" with only one good revision given
and then verify that the result of the first run is bad.
And perhaps also the other way around.
But for now let's check that we have at least one bad and
one good revision before we start to run.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I stumbled across this in the context of the fchmod 0444 patch.
At first, I was going to unlink and call error like the two subsequent
tests do, but a failed write (above) provokes a "die", so I made
this do the same. This is testing for a write failure, after all.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given this set of commands:
$ echo "newly added file" >new
$ git add new
$ git rm new
the file "new" was previously removed from the working
directory and the index. Because it was not in HEAD, it is
available only by searching for unreachable objects.
Instead, we now err on the safe side and refuse to remove
a file which is not referenced by HEAD.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add simple example of config file (turning on and allowing override of
a few %features). Also example config file and script to generate list
of projects in a format that can be used as GITWEB_LIST / $projects_list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should fix fetching for people who did not use
"git svn --minimize" or cannot connect to the repository root
due to the lack of permissions.
I'm not sure what I was on when I made the change to the
rel_path() function in 4e9f6cc78e
that made it die() when we weren't connected to the repository
root :x
Thanks to Sven Verdoolaege for reporting this bug.
Signed-off-by: Junio C Hamano <junkio@cox.net>
They give a good starting point to new people who want to get
involved. This owes suggestions by Martin Langhoff and Steven
Grimm.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
user-manual: introduce "branch" and "branch head" differently
glossary: clean up cross-references
glossary: stop generating automatically
user-manual: Use def_ instead of ref_ for glossary references.
user-manual.txt: fix a tiny typo.
user-manual: run xsltproc without --nonet option
* maint:
gitweb: Add some installation notes in gitweb/INSTALL
gitweb: Fix not marking signoff lines in "log" view
gitweb: Don't escape attributes in CGI.pm HTML methods
gitweb: Change to use explicitly function call cgi->escapHTML()
This simplifies the shell code, reduces its memory footprint, and
speeds things up. The performance improvements should be noticable
when git-rebase works on big commits.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When some operations are interrupted (or "die()'d" or crashed) then the
partial object/pack/index file may remain around. Make it more obvious
in their name that those files are temporary stuff and can be cleaned up
if no operation is in progress.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The update hook's only job is to decide is a particular update
is allowed or not. It was not the right place to send out
update notification e-mails from to begin with, as the final
stage of updating refs can fail after this hook runs.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When converting from the shell script, based on a misreading of the
sed invocation, the builtin included the abbreviated commit name,
and did _not_ include the quotes around the oneline message.
This fixes it.
[jc: with a fix for the typo/thinko spotted by Linus, and also
removing the unwanted abbrev at the beginning.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a path-limited bisection, when the $bad commit is not
changing the limited path, and the number of suspects is 1, the
code miscounted and returned $bad from find_bisection(), which
is not marked with TREECHANGE. This is of course filtered by
the output routine, resulting in an empty output, in turn
causing git-bisect driver to say "$bad was both good and bad".
Illustration. Suppose you have these four commits, and only C
changes path P. You know D is bad and A is good.
A---B---C*--D
git-bisect driver runs this to find a bisection point:
$ git rev-list --bisect A..D -- P
which calls find_bisection() with B, C and D. The set of
commits that is given to this function is the same set of
commits as rev-list without --bisect option and pathspec
returns. Among them, only C is marked with TREECHANGE. Let's
call the set of commits given to find_bisection() that are
marked with TREECHANGE (or all of them if no path limiter is in
effect) "the bisect set". In the above example, the size of the
bisect set is 1 (contains only "C").
For each commit in its input, find_bisection() computes the
number of commits it can reach in the bisect set. For a commit
in the bisect set, this number includes itself, so the number is
1 or more. This number is called "depth", and computed by
count_distance() function.
When you have a bisect set of N commits, and a commit has depth
D, how good is your bisection if you returned that commit? How
good this bisection is can be measured by how many commits are
effectively tested "together" by testing one commit.
Currently you have (N-1) untested commits (the tip of the bisect
set, although it is included in the bisect set, is already known
to be bad). If the commit with depth D turns out to be bad,
then your next bisect set will have D commits and you will have
(D-1) untested commits left, which means you tested (N-1)-(D-1)
= (N-D) commits with this bisection. If it turns out to be good, then
your next bisect set will have (N-D) commits, and you will have
(N-D-1) untested commits left, which means you tested
(N-1)-(N-D-1) = D commits with this bisection.
Therefore, the goodness of this bisection is is min(N-D, D), and
find_bisection() function tries to find a commit that maximizes
this, by initializing "closest" variable to 0 and whenever a
commit with the goodness that is larger than the current
"closest" is found, that commit and its goodness are remembered
by updating "closest" variable. The "the commit with the best
goodness so far" is kept in "best" variable, and is initialized
to a commit that happens to be at the beginning of the list of
commits given to this function (which may or may not be in the
bisect set when path-limit is in use).
However, when N is 1, then the sole tree-changing commit has
depth of 1, and min(N-D, D) evaluates to 0. This is not larger
than the initial value of "closest", and the "so far the best
one" commit is never replaced in the loop.
When path-limit is not in use, this is not a problem, as any
commit in the input set is tree-changing. But when path-limit
is in use, and when the starting "bad" commit does not change
the specified path, it is not correct to return it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The branch you are on while bisecting is always "bisect", and
checking for "refs/heads/bisect*" is wrong. Only check if it is
exactly "refs/heads/bisect".
Signed-off-by: Junio C Hamano <junkio@cox.net>
After "git reset" moves the HEAD around, it reports which commit
you are on, which gives the user a warm fuzzy feeling of
assurance. Give the same assurance from git-checkout when
moving the detached HEAD around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This idea was suggested by Bill Lear
(Message-ID: <17920.38942.364466.642979@lisa.zopyra.com>)
and I think it is a very good one.
This patch adds a new test file for "git bisect run", but there
is currently only one basic test.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this the rev could be (e.g.) a tag and then the condition to end the
bisect might fail and you have to check the already known to be bad revision
once more.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Elias Pipping:
> I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes
> t4118 fail.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ack'd-by: Elias Pipping <pipping@macports.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we write out the result of patch application, we sometimes
need to munge the data (e.g. under core.autocrlf). After doing
so, what we should free is the temporary buffer that holds the
converted data returned from convert_to_working_tree(), not the
original one.
This patch also moves the call to open() up in the function, as
the caller expects us to fail cheaply if leading directories
need to be created (and then the caller creates them and calls
us again). For that calling pattern, attempting conversion
before opening the file adds unnecessary overhead.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The HEAD reflog is updated as well as the reflog for the branch pointed
to by HEAD whenever it is referenced with "HEAD".
There are some cases where a specific branch may be modified directly.
In those cases, the HEAD reflog should be updated as well if it is a
symref to that branch in order to be consistent.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was annoying to always have the first email from a project be from
the "Unnamed repository; edit this file to name it for gitweb project";
just because it's so easy to forget to set it.
This patch checks to see if the description file is still default (or
empty) and aborts if so - allowing you to fix the problem before sending
out silly looking emails to every developer.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-fetch <URL> && git-merge FETCH_HEAD produce the
same merge message as git-pull <URL>.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you want to amend the commit message of 3 commits before
the tip of the current branch, say 'master',
A--B--C--D--E(master)
it is sometimes handy to make your head detached at that commit
with:
$ git checkout HEAD~3 ;# check out B
$ git commit --amend ;# without modifying contents...
to create:
.B'(HEAD)
/
A--B--C--D--E(master)
and then rebase 'master' branch onto HEAD with this:
$ git rebase HEAD master
to result in:
.B'-C'-D'-E(master=HEAD)
/
A--B--C--D--E
However, the current code interprets HEAD after it switches to
the branch 'master', which means the rebase will not do
anything. You have to say something unwieldly like this
instead:
$ git rebase $(git rev-parse HEAD) master
This fixes it by expanding the $onto commit name before
switching to the target branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition to optimizing pathspecs that would never match,
which was done earlier, this optimizes pathspecs that would
always match (e.g. "arch/" while the traversal is already in
"arch/i386/" hierarchy).
This patch makes the worst case slightly more palatable, while
improving average case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we already know that some of the pathspecs can match later
entries in the tree we are looking at, we do not have to do more
expensive strncmp() upfront before comparing the length of the
match pattern and the path, as a path longer than the match
pattern will not match it, and a path shorter than the match
pattern will match only if the path is a directory-component
wise prefix of the match pattern.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are looking at a tree entry with pathspecs, if all the
pathspecs sort strictly earlier than the entry we are currently
looking at, there is no way later entries in the same tree would
match our pathspecs, because the entries are sorted.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the tree descriptor contain a "struct name_entry" as part of
it, and it gets filled in so that it always contains a valid entry. On
some benchmarks, it improves performance by up to 15%.
That makes tree entry "extract" trivial, and means that we only actually
need to decode each tree entry just once: we decode the first one when
we initialize the tree descriptor, and each subsequent one when doing
"update_tree_entry()". In particular, this means that we don't need to
do strlen() both at extract time _and_ at update time.
Finally, it also allows more sharing of code (entry_extract(), that
wanted a "struct name_entry", just got totally trivial, along with the
"tree_entry()" function).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes slightly more lines than it adds, but the real reason for
doing this is that future optimizations will require more setup of the
tree descriptor, and so we want to do it in one place.
Also renamed the "desc.buf" field to "desc.buffer" just to trigger
compiler errors for old-style manual initializations, making sure I
didn't miss anything.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we have the "tree_entry_len()" helper function these days, and
don't need to do a full strlen(), there's no point in saving the path
length - it's just redundant information.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Preferring git _space_ COMMAND over git _dash_ COMMAND allows the
user to have only git and gitk in their path. e.g. when git and gitk
are symbolic links in a personal bin directory to the real git and gitk.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The earlier round makes the function return "is it different"
and it does not return a value suitable for sorting anymore. Reverse
the logic to return "are they the same suspect" instead, and rename
it to "same_suspect()".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't try to remove the containing directory for every pruned object but
try only once after the directory has been scanned instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change the feedback message if doing 'git checkout foo' when already on
branch "foo".
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When creating a new object, we use "deflate(stream, Z_FINISH)" in a loop
until it no longer returns Z_OK, and then we do "deflateEnd()" to finish
up business.
That should all work, but the fact is, it's not how you're _supposed_ to
use the zlib return values properly:
- deflate() should never return Z_OK in the first place, except if we
need to increase the output buffer size (which we're not doing, and
should never need to do, since we pre-allocated a buffer that is
supposed to be able to hold the output in full). So the "while()" loop
was incorrect: Z_OK doesn't actually mean "ok, continue", it means "ok,
allocate more memory for me and continue"!
- if we got an error return, we would consider it to be end-of-stream,
but it could be some internal zlib error. In short, we should check
for Z_STREAM_END explicitly, since that's the only valid return value
anyway for the Z_FINISH case.
- we never checked deflateEnd() return codes at all.
Now, admittedly, none of these issues should ever happen, unless there is
some internal bug in zlib. So this patch should make zero difference, but
it seems to be the right thing to do.
We should probablybe anal and check the return value of "deflateInit()"
too!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Looking at the SHA1 validation code due to the corruption that Alexander
Litvinov is seeing under Cygwin, I notice that one of the most central
places where we read objects, we actually do end up verifying the SHA1 of
the result, but then we happily parse it anyway.
And using "printf" to write the error message means that it not only can
get lost, but will actually mess up stdout, and cause other strange and
hard-to-debug failures downstream.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When appending objects to a pack, make sure the appended data is really
what we expect instead of simply loading potentially corrupted objects
and legitimating them by computing a SHA1 of that corrupt data.
With this the sha1_object() can lose its test_for_collision parameter
which is now redundent.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use hash_sha1_file() instead of duplicating code to compute object SHA1.
While at it make it accept a const pointer.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Waaaaaaay back Git was considered to be secure as it never overwrote
an object it already had. This was ensured by always unpacking the
packfile received over the network (both in fetch and receive-pack)
and our already existing logic to not create a loose object for an
object we already have.
Lately however we keep "large-ish" packfiles on both fetch and push
by running them through index-pack instead of unpack-objects. This
would let an attacker perform a birthday attack.
How? Assume the attacker knows a SHA-1 that has two different
data streams. He knows the client is likely to have the "good"
one. So he sends the "evil" variant to the other end as part of
a "large-ish" packfile. The recipient keeps that packfile, and
indexes it. Now since this is a birthday attack there is a SHA-1
collision; two objects exist in the repository with the same SHA-1.
They have *very* different data streams. One of them is "evil".
Currently the poor recipient cannot tell the two objects apart,
short of by examining the timestamp of the packfiles. But lets
say the recipient repacks before he realizes he's been attacked.
We may wind up packing the "evil" version of the object, and deleting
the "good" one. This is made *even more likely* by Junio's recent
rearrange_packed_git patch (b867092f).
It is extremely unlikely for a SHA1 collisions to occur, but if it
ever happens with a remote (hence untrusted) object we simply must
not let the fetch succeed.
Normally received packs should not contain objects we already have.
But when they do we must ensure duplicated objects with the same SHA1
actually contain the same data.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The configured refspecs are printed almost verbatim, i.e. both the local
and the remote branch name separated by a colon are printed; only the
prefix 'refs/heads/' is removed, like this:
Local branch(es) pushed with 'git push'
master refs/tags/*:refs/tags/* next:next
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the single force (+) when fetched with fetch_per_ref.
Also use $LF as separator because IFS is $LF.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We already have -q in git clone. So for those who care to suppress
the noise during an http based clone, make -q actually do a quiet
http fetch.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: Fernando Herrera <fherrera@onirica.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The thing is, if the output buffer is empty, we should *still* actually
use the zlib routines to *unpack* that empty output buffer.
But we had a test that said "only unpack if we still expect more output".
So we wouldn't use up all the zlib stream, because we felt that we didn't
need it, because we already had all the bytes we wanted. And it was
"true": we did have all the output data. We just needed to also eat all
the input data!
We've had this bug before - thinking that we don't need to inflate()
anything because we already had it all..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple but powerful continuous integration build system
for Git. It works by receiving push events from repositories
through the post-receive hook, aggregates them on a per-branch
basis into a first-come-first-serve build queue, and lets a
background build daemon perform builds one at a time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There has not been any work on the shallow stuff lately, so it is hard
to find out what it does, and how. This document describes the ideas
as well as the current problems, and can serve as a starting point for
shallow people.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Setting up a git-daemon came up the other day on IRC, and it is slightly
non trivial for the uninitiated.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since in at least one use case, xdl_hash_record() takes over 15% of the
CPU time, it makes sense to even micro-optimize it. For many cases, no
whitespace special handling is needed, and in these cases we should not
even bother to check for whitespace in _every_ iteration of the loop.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commit structures are guaranteed their uniqueness by the object
layer, so we can check their address and see if they are the same
without going down to the object sha1 level.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This provides a smoother degradation in performance when the cache
gets trashed due to the delta_base_cache_limit being reached. Limited
testing with really small delta_base_cache_limit values appears to confirm
this.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently there are 3 different ways to deal with the cache size.
Let's stick to only one. The compiler is smart enough to produce the exact
same code in those cases anyway.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I think we can start to slow down, as we now have covered
everything I listed earlier in the short-term release plan.
The last release 1.5.0 took painfully too long.
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier conversion to run_command() from execlp() forgot that
run_command() takes an array that is terminated with NULL.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is mainly just a cleanup patch, and sets up for later changes where
the tree-diff.c "interesting()" function can return more than just a
yes/no value.
In particular, it should be quite possible to say "no subsequent entries
in this tree can possibly be interesting any more", and thus allow the
callers to short-circuit the tree entirely.
In fact, changing the callers to do so is trivial, and is really all this
patch really does, because changing "interesting()" itself to say that
nothing further is going to be interesting is definitely more complicated,
considering that we may have arbitrary pathspecs.
But in cleaning up the callers, this actually fixes a potential small
performance issue in diff_tree(): if the second tree has a lot of
uninterestign crud in it, we would keep on doing the "is it interesting?"
check on the first tree for each uninteresting entry in the second one.
The answer is obviously not going to change, so that was just not helping.
The new code is clearer and simpler and avoids this issue entirely.
I also renamed "interesting()" to "tree_entry_interesting()", because I
got frustrated by the fact that
- we actually had *another* function called "interesting()" in another
file, and I couldn't tell from the profiles which one was the one that
mattered more.
- when rewriting it to return a ternary value, you can't just do
if (interesting(...))
...
any more, but want to assign the return value to a local variable. The
name of choice for that variable would normally be "interesting", so
I just wanted to make the function name be more specific, and avoid
that whole issue (even though I then didn't choose that name for either
of the users, just to avoid confusion in the patch itself ;)
In other words, this doesn't really change anything, but I think it's a
good thing to do, and if somebody comes along and writes the logic for
"yeah, none of the pathspecs you have are interesting", we now support
that trivially.
It could easily be a meaningful optimization for things like "blame",
where there's just one pathspec, and stopping when you've seen it would
allow you to avoid about 50% of the tree traversals on average.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "track_tree_refs()" use the same "tree_entry()" function for
counting the entries as it does for actually traversing them a few lines
later.
Not a biggie, but the reason I care was that this was the only user of
"update_tree_entry()" that didn't actually *extract* the tree entry first.
It doesn't matter as things stand now, but it meant that a separate
test-patch I had that avoided a few more "strlen()" calls by just saving
the entry length in the entry descriptor and using it directly when
updating wouldn't work without this patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Run the pre-commit and post-commit hooks at appropriate places, and
display their output if any.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new configuration variable core.deltaBaseCacheLimit allows the
user to control how much memory they are willing to give to Git for
caching base objects of deltas. This is not normally meant to be
a user tweakable knob; the "out of the box" settings are meant to
be suitable for almost all workloads.
We default to 16 MiB under the assumption that the cache is not
meant to consume all of the user's available memory, and that the
cache's main purpose was to cache trees, for faster path limiters
during revision traversal. Since trees tend to be relatively small
objects, this relatively small limit should still allow a large
number of objects.
On the other hand we don't want the cache to start storing 200
different versions of a 200 MiB blob, as this could easily blow
the entire address space of a 32 bit process.
We evict OBJ_BLOB from the cache first (credit goes to Junio) as
we want to favor OBJ_TREE within the cache. These are the objects
that have the highest inflate() startup penalty, as they tend to
be small and thus don't have that much of a chance to ammortize
that penalty over the entire data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* sp/run-command:
Use run_command within send-pack
Use run_command within receive-pack to invoke index-pack
Use run_command within merge-index
Use run_command for proxy connections
Use RUN_GIT_CMD to run push backends
Correct new compiler warnings in builtin-revert
Replace fork_with_pipe in bundle with run_command
Teach run-command to redirect stdout to /dev/null
Teach run-command about stdout redirection
In the Linux kernel, for example, it's common to include Cc: lines
for cases when you want to remember to cc someone on a patch without
necessarily claiming they signed off on it. Make git-send-email
aware of these.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* ar/diff:
Add tests for --quiet option of diff programs
try-to-simplify-commit: use diff-tree --quiet machinery.
revision.c: explain what tree_difference does
Teach --quiet to diff backends.
diff --quiet
Remove unused diffcore_std_no_resolve
Allow git-diff exit with codes similar to diff(1)
This is a micro-optimization that grew out of the mailing list discussion
about "strlen()" showing up in profiles.
We used to pass regular C strings around to the low-level tree walking
routines, and while this worked fine, it meant that we needed to call
strlen() on strings that the caller always actually knew the size of
anyway.
So pass the length of the string down wih the string, and avoid
unnecessary calls to strlen(). Also, when extracting a pathname from a
tree entry, use "tree_entry_len()" instead of strlen(), since the length
of the pathname is directly calculable from the decoded tree entry itself
without having to actually do another strlen().
This shaves off another ~5-10% from some loads that are very tree
intensive (notably doing commit filtering by a pathspec).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>"
Signed-off-by: Junio C Hamano <junkio@cox.net>
A malloc() + memcpy() will always be faster than mmap() +
malloc() + inflate(). If the data is already there it is
certainly better to copy it straight away.
With this patch below I can do 'git log drivers/scsi/ >
/dev/null' about 7% faster. I bet it might be even more on
those platforms with bad mmap() support.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This trivial 256-entry delta_base cache improves performance for some
loads by a factor of 2.5 or so.
Instead of always re-generating the delta bases (possibly over and over
and over again), just cache the last few ones. They often can get re-used.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This doesn't change any code, it just creates a point for where we'd
actually do the caching of delta bases that have been generated.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Especially with the new index format to come, it is more appropriate
to encapsulate more into check_packed_git_idx() and assume less of the
index format in struct packed_git.
To that effect, the index_base is renamed to index_data with void * type
so it is not used directly but other pointers initialized with it. This
allows for a couple pointer cast removal, as well as providing a better
generic name to grep for when adding support for new index versions or
formats.
And index_data is declared const too while at it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure pack-objects with --delta-base-offset works fine, and that
it actually produces smaller packs as expected.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'use packed deltified objects' test was flawed as it failed to
remove the pack and index from the previous test, effectively preventing
the desired pack from being exercised as objects could be found in that
other pack instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier patch 87ab7992 broke applymbox by blindly copying piece
from git-am, causing a harmless but annoying series of error messages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We generally prefer xstrdup to just plain strdup.
Make it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If your development history does not have fast-forward merges,
i.e. the "first parent" of commits in your history are special
than other parents, this option gives a better overview of the
evolution of a particular branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses diff-tree --quiet machinery to terminate the internal
diff-tree between a commit and its parents via revs.pruning (not
revs.diffopt) as soon as we find enough about the tree change.
With respect to the optionally given pathspec, we are interested
if the tree of commit is identical to the parent's, only adds
new paths to the parent's, or there are other differences. As
soon as we find out that there is one such other kind of
difference, we do not have to compare the rest of the tree.
Because we do not call standard diff_addremove/diff_change, we
instruct the diff-tree machinery to stop early by setting
has_changes when we say we found the trees to be different.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This explains how tree_difference variable is used, and updates two
places where the code knows symbolic constant REV_TREE_SAME is 0.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches git-diff-files, git-diff-index and git-diff-tree
backends to exit early under --quiet option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the command line option 'quiet' to tell 'git diff-*'
that we are not interested in the actual diff contents but only
want to know if there is any change. This option automatically
turns --exit-code on, and turns off output formatting, as it
does not make much sense to show the first hit we happened to
have found.
The --quiet option is silently turned off (but --exit-code is
still in effect, so is silent output) if postprocessing filters
such as pickaxe and diff-filter are used. For all practical
purposes I do not think of a reason to want to use these filters
and not viewing the diff output.
The backends have not been taught about the option with this patch.
That is a topic for later rounds.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This introduces a new command-line option: --exit-code. The diff
programs will return 1 for differences, return 0 for equality, and
something else for errors.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously git-describe would output lines of the form
v1.1.1-gf509d56
The update hook found the dash and stripped it off using
sed 's/-g.*//'
The remainder was then used as the previous tag name.
However, git-describe has changed format. The output is now of the form
v1.1.1-23-gf509d56
The above sed fragment doesn't strip the middle "-23", and so the
previous tag name used would be "v1.1.1-23". This is incorrect.
Since the hook script was written, git-describe now gained support for
"--abbrev=0", which it uses as a special flag to tell it not to output
anything other than the nearest tag name. This patch fixes the problem,
and prevents any future recurrence by using this new flag rather than
sed to find the previous tag.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit: Also print the old revision similar to how cvs does it and
prepend a line stating the filename so that one can actually
understand what happened when commiting more than one file.
status: Fix the RCS filename displayed. The directory was
printed twice.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Submit some additional messages to the client on commit and update.
Inspired by the standard CVS server though a little more terse.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/fetch:
.gitignore: add git-fetch--tool
builtin-fetch--tool: fix reflog notes.
git-fetch: retire update-local-ref which is not used anymore.
builtin-fetch--tool: make sure not to overstep ls-remote-result buffer.
fetch--tool: fix uninitialized buffer when reading from stdin
builtin-fetch--tool: adjust to updated sha1_object_info().
git-fetch--tool takes flags before the subcommand.
Use stdin reflist passing in git-fetch.sh
Use stdin reflist passing in parse-remote
Allow fetch--tool to read from stdin
git-fetch: rewrite expand_ref_wildcard in C
git-fetch: rewrite another shell loop in C
git-fetch: move more code into C.
git-fetch--tool: start rewriting parts of git-fetch in C.
git-fetch: split fetch_main into fetch_dumb and fetch_native
If you use scanf or sscanf to parse integers, your code probably
accepts bogus inputs. For example, builtin-grep (aka git-grep) uses
sscanf(scan, "%u", &num) to parse the integer argument to -A, -B, -C.
Currently, "-C 1,000" and "-C 4294967297" are both treated just like
"-C 1":
$ git-grep -h -C 4294967297 juggle
out and you may find it easier to switch back and forth if you
juggle multiple lines of development simultaneously. Of
course, you will pay the price of more disk usage to hold
The obvious fix is to use strtoul instead. But using a bare strtoul is
too messy, at least when done properly, so I've added a wrapper function.
The new function in the patch below belongs elsewhere if it would be
useful in replacing any of the four remaining uses of sscanf.
One final note: With this change, I get a slightly different
diagnostic depending on the context size:
$ ./git-grep -h -C 4294967296 juggle
fatal: 4294967296: invalid context length argument
[Exit 128]
$ ./git-grep -h -C 4294967295 juggle
grep: 4294967295: invalid context length argument
[Exit 1]
A common convention that makes it easy to identify the source
of a diagnostic is to include the program name before the first ":".
Whether that should be "git" or "git-grep" is another question.
Using "grep" or "fatal" is misleading.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue as 8bef6204, which became an issue again
after 31d0399c.
Besides, it is not really helpful to print just "GEN " (_without_
"perl.mak").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I was trying to see who have been active recently to find GSoC
mentor candidates by running:
$ git shortlog -s -n --since=4.months | head -n 20
After waiting for about 20 seconds, I started getting worried,
thinking that the recent revision traversal updates might have
had an unintended side effect.
Not so. "git shortlog" acts as a filter when no revs are given,
unlike "git log" which defaults to HEAD. It was reading from
its standard input.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This avoids fetching new revisions remotely, and is usefuly
versus plain "git rebase" because the user does not have to
specify which remote head to rebase against.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-mergetool program can be used to automatically run an appropriate
merge resolution program to resolve merge conflicts. It will automatically
run one of kdiff3, tkdiff, meld, xxdiff, or emacs emerge programs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Maybe unnecessary as the merge-index utility may go away in the
future, but its currently here, its shorter to use run_command,
and probably will help the MinGW port out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we hand run_command RUN_GIT_CMD rather than 0 it will use
the execv_git_cmd path rather than execvp at the OS level.
This is typically the preferred way of running another Git
utility.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new builtin-revert code introduces a few new compiler errors
when I'm building with my stricter set of checks enabled in CFLAGS.
These all just stem from trying to store a constant string into
a non-const char*. Simple fix, make the variables const char*.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that the run_command family supports all of the redirection
modes needed by builtin-bundle, we can use those functions rather
than the underlying POSIX primitives. This should help to make the
bundle command slightly more portable to other systems, like Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some run-command callers may wish to just discard any data that
is sent to stdout from the child. This is a lot like our existing
no_stdin support, we just open /dev/null and duplicate the descriptor
into position.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some potential callers of the run_command family of functions need
to control not only the stdin redirection of the child, but also
the stdout redirection of the child. This can now be setup much
like the already existing stdin redirection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I have come across many emails that use long strings of '-'s as separators
for ideas. This patch below limits the separator to only 3 '-', with the
intent that long string of '-'s will stay in the commit msg and not in the
patch file.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I am working on a project that required parsing through regular
mboxes that didn't necessarily have patches embedded in them. I
started by creating my own modified copy of git-am and working
from there. Very quickly, I noticed git-mailinfo wasn't able to
handle a big chunk of my email.
After hacking up numerous solutions and running into more
limitations, I decided it was just easier to rewrite a big chunk
of it. The following patch has a bunch of fixes and features
that I needed in order for me do what I wanted.
Note: I'm didn't follow any email rfc papers but I don't think
any of the changes I did required much knowledge (besides the
boundary stuff).
List of major changes/fixes:
- can't create empty patch files fix
- empty patch files don't fail, this failure will come inside git-am
- multipart boundaries are now handled
- only output inbody headers if a patch exists otherwise assume those
headers are part of the reply and instead output the original headers
- decode and filter base64 patches correctly
- various other accidental fixes
I believe I didn't break any existing functionality or
compatibility (other than what I describe above, which is really
only the empty patch file).
I tested this through various mailing list archives and
everything seemed to parse correctly (a couple thousand emails).
[jc: squashed in another patch from Don's five patch series to
fix the test case, as this patch exposes the bug in the test.]
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
Remove unnecessary casts from fast-import
New fast-import test case for valid tree sorting
fast-import: grow tree storage more aggressively
POSIX says sed may add a trailing LF if there isn't already
one there. We shouldn't rely on it not adding that LF, as
some systems (Mac OS X for example) will add it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I started hacking on a change to add stdout redirection support to
the run_command family, but found I was using a lot of close calls
on two pipes in an array (such as for pipe). So I'm doing a tiny
bit of refactoring first to make the next set of changes clearer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Jeff King pointed out that these casts are quite unnecessary, as
the compiler should be doing them anyway, and may cause problems
in the future if the size of the argument for to_atom were to ever
be increased.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Git tree sorting convention is more complex than just the name,
it needs to include the mode too to make sure trees sort as though
their name ends with "/".
This is a simple test case that verifies fast-import keeps the tree
ordering correct after editing the same tree twice in a single
input stream. A recent proposed patch series (that has not yet
been applied) will cause this test to fail, due to a bug in the
way the series handles sorting within the trees.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
What the function wants to return is not if we saw any return
from pop_most_recent_commit(), but if we found what was asked
for.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I chose <F5> because it's also the key to reload the current
page in web browsers such as Konqueror and Firefox, so users
are more likely to be familiar with it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
A use case for git-bundle expected to be quite common is this:
$ git bundle create daily.bundle --since=10.days.ago --all
The expected outcome is _not_ to error out if only a couple of the
refs were not changed during the last 10 days.
This patch complains loudly about refs which are skipped due to the
pack not containing the corresponding objects, but dies only if
no objects would be in the pack _at all_.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Chain-reply-to is a personal perference, and is unlikely to change from
patchset to patchset. Similarly, bcc is likely to have the same values
every invocation is one likes to bcc oneself.
So, allow both to be set via configuration variables.
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/boundary:
git-bundle: prevent overwriting existing bundles
git-bundle: die if a given ref is not included in bundle
git-bundle: handle thin packs in subcommand "unbundle"
git-bundle: Make thin packs
git-bundle: avoid packing objects which are in the prerequisites
bundle: fix wrong check of read_header()'s return value & add tests
revision --boundary: fix uncounted case.
revision --boundary: fix stupid typo
git-bundle: make verify a bit more chatty.
revision traversal: SHOWN means shown
git-bundle: various fixups
revision traversal: retire BOUNDARY_SHOW
revision walker: Fix --boundary when limited
Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it
is possible for a single invocation of receive-pack to be given more
refs than the OS might allow us to pass as command line parameters
to a single hook invocation.
We don't want to break these up into multiple invocations (like
xargs might do) as that makes it impossible for the pre-receive
hook to verify multiple related ref updates occur at the same time,
and it makes it harder for post-receive to send out a single batch
notification.
Instead we pass the reference data on a pipe connected to the
hook's stdin, supplying one ref per line to the hook. This way a
single hook invocation can obtain an infinite amount of ref data,
without bumping into any operating system limits.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we have decided to change the calling conventions for the
pre-receive and post-receive hooks to take the ref data on stdin
rather than on the command line we cannot use the same logic to
invoke the update hook anymore.
So we take a small step backwards towards what we used to have,
and create a specialized function for executing just the update
hook.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm pulling the error handling used to decode the result of
run_command up into a new function so that I can reuse it.
No changes, just a simple code movement.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes callers trying to use run_command to execute a child
process will want to setup a pipe or file descriptor to redirect
into the child's stdin.
This idea is completely stolen from builtin-bundle's fork_with_pipe,
written by Johannes Schindelin. All credit (and blame) should lie
with Dscho. ;-)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the calling process wants to send data to stdin of a
child process it will need to arrange for a pipe and get
the child process running, feed data to it, then wait
for the child process to finish. So we split the run
function into two halves, allowing callers to first
start the child then later finish it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are a number of places where we do some variation of
fork()+exec() but we also need to setup redirection in the process,
much like what run_command does for us already with its option flags.
It would be nice to reuse more of the run_command logic, especially
as that non-fork API helps us to port to odd platforms like Win32.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't actually use these va_list based variants of run_command
anymore. I'm removing them before I make further improvements.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Another change by me is removing the va_list variants of run_command,
one of which is used by builtin-revert.c. To avoid compile errors
I'm refactoring builtin-revert to use the char** variant instead,
as that variant is staying.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using Update-existing leads to the client forgetting about the "locally
modified" status of the file which can lead to loss of local changes on
later updates.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
a try, but all I could get was a segfault. It was dereferencing a NULL
commit list. Fix below. With it, this example now works:
$ mkdir .j; cd .j; touch f
$ git-init; git-add f; git-commit -mc f; echo x >f; git-commit -md f
$ git-diff -p :/c :/d
diff --git a/f b/f
index e69de29..587be6b 100644
--- a/f
+++ b/f
@@ -0,0 +1 @@
+x
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When accessing objects, we first look for them in packs that
are linked together in the reverse order of discovery.
Since younger packs tend to contain more recent objects, which
are more likely to be accessed often, and local packs tend to
contain objects more relevant to our specific projects, sort the
list of packs before starting to access them. In addition,
favoring local packs over the ones borrowed from alternates can
be a win when alternates are mounted on network file systems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In order to track and build on top of a branch 'topic' you track from
your upstream repository, you often would end up doing this sequence:
git checkout -b mytopic origin/topic
git config --add branch.mytopic.remote origin
git config --add branch.mytopic.merge refs/heads/topic
This would first fork your own 'mytopic' branch from the 'topic'
branch you track from the 'origin' repository; then it would set up two
configuration variables so that 'git pull' without parameters does the
right thing while you are on your own 'mytopic' branch.
This commit adds a --track option to git-branch, so that "git
branch --track mytopic origin/topic" performs the latter two actions
when creating your 'mytopic' branch.
If the configuration variable branch.autosetupmerge is set to true, you
do not have to pass the --track option explicitly; further patches in
this series allow setting the variable with a "git remote add" option.
The configuration variable is off by default, and there is a --no-track
option to countermand it even if the variable is set.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/diff-ni:
Get rid of the dependency to GNU diff in the tests
diff --no-index: support /dev/null as filename
diff-ni: fix the diff with standard input
diff: support reading a file from stdin via "-"
* sp/make:
Allow "make -w" generate its usual output
Support of "make -s": do not output anything of the build itself
More build output cleaning up
Make 'make' quiet by default
Make 'make' quieter while building git
* maint:
git.el: Retrieve commit log information from .dotest directory.
git.el: Avoid appending a signoff line that is already present.
setup_git_directory_gently: fix off-by-one error
user-manual: install user manual stylesheet with other web documents
user-manual: fix rendering of history diagrams
user-manual: fix missing colon in git-show example
user-manual: fix inconsistent use of pull and merge
user-manual: fix inconsistent example
glossary: fix overoptimistic automatic linking of defined terms
Documentation: s/seperator/separator/
Adjust reflog filemode in shared repository
This adds the 'core.excludesfile' configuration variable. This variable can
hold a path to a file containing patterns of file names to exclude from
git-add, like $GIT_DIR/info/exclude. Patterns in the excludes file are used
in addition to those in info/exclude.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The --interactive option behaves like "git commit", except that
"git add --interactive" is executed before committing. It is
incompatible with -a and -i.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not only does it prevent accidentally losing older bundles, but it
also fixes a subtle bug: when writing into an existing bundle,
git-pack-objects would not truncate the bundle. Therefore,
fetching from the bundle would trigger an error in unpack-objects:
"fatal: pack has junk at the end".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier patch tried to be nice by just warning, but it seems
more likely that the user wants to adjust the parameters.
Also, it prevents a bundle containing _all_ revisions in the case
when the user only gave one ref, but also rev-list options which
excluded the ref.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The patch to make the packs in a bundle thin forgot the receiving side.
D'oh.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
Allow fast-import frontends to reload the marks table
Use atomic updates to the fast-import mark file
Preallocate memory earlier in fast-import
Thin packs are way smaller, but they rely on the receiving end to have the
base objects. However, Git's pack protocol also uses thin packs by
default. So make the packs contained in bundles thin, since bundles are
just another transport.
The patch looks a bit bigger than intended, mainly because --thin
_implies_ that pack-objects should run its own rev-list. Therefore, this
patch removes all the stuff we used to roll rev-list ourselves.
This commit also changes behaviour slightly: since we now know early
enough if a specified ref is _not_ contained in the pack, we can avoid
putting that ref into the pack. So, we don't die() here, but warn()
instead, and skip that ref.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When saying something like "--since=1.day.ago" or "--max-count=5",
git-bundle finds the boundary commits which are recorded as
prerequisites. However, it failed to tell pack-objects _not_ to
pack the objects which are in these.
Fix that. And add a test for that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm giving fast-import a lesson on how to reload the marks table
using the same format it outputs with --export-marks. This way
a frontend can reload the marks table from a prior import, making
incremental imports less painful.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we allow fast-import frontends to reload a mark file from a
prior session we want to let them use the same file as they exported
the marks to. This makes it very simple for the frontend to save
state across incremental imports.
But we don't want to lose the old marks table if anything goes wrong
while writing our current marks table. So instead of truncating and
overwriting the path specified to --export-marks we use the standard
lockfile code to write the current marks out to a temporary file,
then rename it over the old marks table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Bill Lear pointed out that it is easy to send out notifications of
changes with the update hook, but successful execution of the update
hook does not necessarily mean that the ref was actually updated.
Lock contention on the ref or being unable to append to the reflog
may prevent the ref from being changed. Sending out notifications
prior to the ref actually changing is very misleading.
To help this situation I am introducing two new hooks to the
receive-pack flow: pre-receive and post-receive. These new hooks
are invoked only once per receive-pack execution and are passed
three arguments per ref (refname, old-sha1, new-sha1).
The new post-receive hook is ideal for sending out notifications,
as it has the complete list of all refnames that were successfully
updated as well as the old and new SHA-1 values. This allows more
interesting notifications to be sent. Multiple ref updates could
be easily summarized into one email, for example.
The new pre-receive hook is ideal for logging update attempts, as it
is run only once for the entire receive-pack operation. It can also
be used to verify multiple updates happen at once, e.g. an update
to the `maint` head must also be accompained by a new annotated tag.
Lots of documentation improvements for receive-pack are included
in this change, as we want to make sure the new hooks are clearly
explained.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I discovered we did not send an ng line in the report-status feedback
if the ref was not updated because the repository has the config
option receive.denyNonFastForwards enabled. I think the reason this
happened is that it is simply too easy to forget to set error_string
when returning back a failure from update()
We now return an ng line for a non-fastforward update, which in
turn will cause send-pack to exit with a non-zero exit status.
Hence the modified test.
This refactoring changes update to return a const char* describing
the error, which execute_commands always loads into error_string.
The result is what I think is cleaner code, and allows us to
initialize the error_string member to NULL when we read_head_info.
I want error_string to be NULL in all commands before we call
execute_commands, so that we can reuse the run_hook function to
execute a new pre-receive hook.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple refactoring of run_update_hook to allow the function
to be passed the name of the hook it runs and also to build the
argument list from a list of struct commands, rather than just one
struct command.
The refactoring is to support new pre-receive and post-receive
hooks that will be given the entire list of struct commands,
rather than just one struct command. These new hooks will follow
in another patch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is little point in executing the post-update hook if all refs
had an error and were unable to be updated. In this case nothing
new is reachable within the repository, and there is no state change
for the post-update hook to be interested in.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As the post-update hook is meant to run after we have completed the
receipt of the pushed changes, and it might actually try to kick off
a `repack -a -d`, we should delay on invoking it until after we have
removed the *.keep file on the uploaded pack (if we kept the pack).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm about to teach fast-import how to reload the marks file created
by a prior session. The general approach that I want to use is to
immediately parse the marks file when the specific argument is found
in argv, thereby allowing the caller to supply multiple marks files,
as the mark space can be sparsely populated.
To make that work out we need to allocate our object tables before
we parse the command line options. Since none of these tables
depend on the command line options, we can easily relocate them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4.
This implies that we are able to access and work on files whose
maximum length is around 2^63-1 bytes, but we can only malloc or
mmap somewhat less than 2^32-1 bytes of memory.
On such a system an implicit conversion of off_t to size_t can cause
the size_t to wrap, resulting in unexpected and exciting behavior.
Right now we are working around all gcc warnings generated by the
-Wshorten-64-to-32 option by passing the off_t through xsize_t().
In the future we should make xsize_t on such problematic platforms
detect the wrapping and die if such a file is accessed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Always use an off_t value in pack-objects anytime we are dealing
with an offset to some data within a packfile.
Also fixed a minor uintmax_t that was incorrectly defined before.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not all platforms have declared 'unsigned long' to be a 64 bit value,
but we want to support a 64 bit packfile (or close enough anyway)
in the near future as some projects are getting large enough that
their packed size exceeds 4 GiB.
By using off_t, the POSIX type that is declared to mean an offset
within a file, we support whatever maximum file size the underlying
operating system will handle. For most modern systems this is up
around 2^60 or higher.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As we technically try to support up to a maximum of 2**32-1 objects
in a single packfile we should act like it and use unsigned 32 bit
integers for all of our object counts and progress output.
This change does not modify everything in pack-objects that probably
needs to change to fully support the maximum of 2**32-1 objects.
I'm intentionally breaking the improvements into slightly smaller
commits to make them easier to follow.
No logic change should be occuring here, with the exception that
some comparsions will now work properly when the number of objects
exceeds 2**31-1.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As we permit up to 2^32-1 objects in a single packfile we cannot
use a signed int to represent the object offset within a packfile,
after 2^31-1 objects we will start seeing negative indexes and
error out or compute bad addresses within the mmap'd index.
This is a minor cleanup that does not introduce any significant
logic changes. It is roach free.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We shouldn't attempt to assign constant strings into char*, as the
string is not writable at runtime. Likewise we should always be
treating unsigned values as unsigned values, not as signed values.
Most of these are very straightforward. The only exception is the
(unnecessary) xstrdup/free in builtin-branch.c for the detached
head case. Since this is a user-level interactive type program
and that particular code path is executed no more than once, I feel
that the extra xstrdup call is well worth the easy elimination of
this warning.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If an index is corrupt, or is simply too new for us to understand,
we were leaking the mmap that held the entire content of the index.
This could be a considerable size on large projects, given that
the index is at least 24 bytes * nr_objects.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we are currently cheating and never supplying the delta base
for an OBJ_OFS_DELTA we get a random SHA-1 in the delta base field.
Instead lets clear the hash out so its at least all 0's. This is
somewhat more obvious that something fishy is going on, like we
don't actually have the SHA-1 of the base handy. :)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support to archimport for remapping the branch
names to match those used in git more closely. This is useful
for projects that migrate to git (as opposed to users that want
to use git on Arch-based projects). For example, one can choose
an Arch branch name and call it "master".
The new command-line syntax works even if there is a colon in
a branch name, since only the part after the last colon is taken
to be the git name (git does not allow colons in branch names).
The new feature is implemented so that archives rotated every
year can also be remapped into a single git archive.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
They test the behaviour with just a URL in the command line.
Signed-off-by: Santi B,Ai(Bjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If read_header() fails, it returns <0, not 0. Further, an open(/dev/null)
was not checked for errors.
Also, this adds two tests to make sure that the bundle file looks
correct, by checking if it has the header has the expected form, and that
the pack contains the right amount of objects.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is no need to escape HTML tag's attributes in CGI.pm
HTML methods (like CGI::a()), because CGI.pm does attribute
escaping automatically.
$cgi->a({ ... -attribute => atribute_value }, tag_contents)
is translated to
<a ... attribute="attribute_value">tag_contents</a>
The rules for escaping attribute values (which are string contents) are
different. For example you have to take care about escaping embedded '"'
and "'" characters; CGI::a() does that for us automatically.
CGI::a() does not HTML escape tag_contents; we would need to write
<a href="URL">some <b>bold</b> text</a>
for example. So we use esc_html (or esc_path) to escape tag_contents
as needed.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- print output file name for .c files
- suppress output of the names of subdirectories when make changes into them
- use GEN prefix for makefile generation in perl/
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the list is truly limited and get_revision_1() returned NULL,
the code incorrectly returned it without switching to boundary emiting
mode. Silly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change to use explicitly function call cgi->escapHTML().
This fix the problem on some systems that escapeHTML() is not
functioning, as default CGI is not setting 'escape' parameter.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the code to set SHOWN on the commit from get_revision_1()
back to get_revision(), so that the bit means what it originally
meant: this commit has been given back to the caller.
Also it fixes the --reverse breakage Dscho pointed out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
verify_bundle() returned with an error early only when all
prerequisite commits were missing. It should error out much
earlier when some are missing.
When the rev-list is limited in ways other than revision range
(e.g. --max-count or --max-age), create_bundle() listed all
positive refs given from the command line as if they are
available, but resulting pack may not have some of them. Add a
logic to make sure all of them are included, and error out
otherwise.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes the flag internally used by revision traversal to
decide which commits are indeed boundaries and renames it to
CHILD_SHOWN. builtin-bundle uses the symbol for its
verification, but I think the logic it uses it is wrong. The
flag is still useful but it is local to the git-bundle, so it is
renamed to PREREQ_MARK.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Per Junio's suggestion we are setting 'make' to be quiet by default,
with `make V=1` available to force GNU make back to its default
behavior of showing each command it is running.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I find it difficult to see compiler warnings amongst the massive
spewing produced by GNU make as it works through our productions.
This is especially true if CFLAGS winds up being rather long, due
to a large number of -W options being enabled and due to a number
of -D options being configured/required by my platform.
By defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during
compilation users will get a less verbose output, such as:
...
CC builtin-grep.c
builtin-grep.c:187: warning: 'external_grep' defined but not used
CC builtin-init-db.c
CC builtin-log.c
CC builtin-ls-files.c
CC builtin-ls-tree.c
...
The verbose (normal make) output is still the default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-gui: Make 'make' quieter by default
git-gui: Remove unnecessary /dev/null redirection.
git-gui: Don't create empty (same tree as parent) commits.
git-gui: Add Reset to the Branch menu.
git-gui: Relocate the menu/transport menu code.
The handcrafted built-in rev-list lookalike forgot to mark the trees
and blobs contained in the boundary commits uninteresting, resulting
in unnecessary objects in the pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somewhere along the line (in abd6970a) git-revert.sh learned to
omit the private object name from the new commit message *unless*
-x was supplied on the command line by the user.
The way this was implemented is really non-obvious in the original
script. Setting replay=t (the default) means we don't include the
the private object name, while setting reply='' (the -x flag) means
we should include the private object name. These two settings now
relate to the replay=1 and replay=0 cases in the C version, so we
need to negate replay to test it is 0.
I also noticed the C version was adding an extra LF in the -x case,
where the older git-revert.sh was not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master-for-junio' of git://repo.or.cz/git/fastimport:
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
* maint:
Fix diff-options references in git-diff and git-format-patch
Add definition of <commit-ish> to the main git man page.
Begin SubmittingPatches with a check list
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
* maint:
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
[sp: Minor evil merge to deal with type_names array moving
to be private in 'master'.]
git-fsck always exited with status 0, which was a bit sloppy.
This makes it exit with a non-zero status when errors are
found. The error code is an OR'ed result of:
1 if corrupted objects are found.
2 if objects that are ought to be reachable are missing or corrupt.
For example, it would exit with 1 in a repository with an
unreachable corrupt object. If a tree object of the HEAD commit
is corrupt, you would get 3.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We did not detect broken loose object files, either when
underlying inflate() signalled the breakage, nor inflate()
finished and we had garbage trailing at the end. We do better
now.
We also make unpack_sha1_file() a static function to
sha1_file.c, since it is not used by anybody outside.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When "git fsck" without --full found a loose object missing
because it was broken, it mistakenly thought it was not parsed
because we found it in one of the packs. Back when this code
was written, we did not have a way to explicitly check if we
have the object in pack, but we do now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add git-blame as a candidate to the byte-compilation.
batch-byte-compile is the prefered way to byte-compile files in
batch mode. Use it instead of the interactive function.
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update the main git.html page to point at 1.5.0.3 documentation.
Update draft 1.5.1 release notes with what we have so far.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Panagiotis Issaris reports that some MUAs seem not to like
folded "content-type" and "content-disposition" headers, so this
makes format-patch --attach output to avoid them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The existing --attach option did not create a true "attachment"
but multipart/mixed with Content-Disposition: inline. It should
have been with Content-Disposition: attachment.
Introduce --inline to add multipart/mixed that is inlined, and
make --attach to create an attachement.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'js/fetch-progress' (early part):
Fixup no-progress for fetch & clone
fetch & clone: do not output progress when not on a tty
Conflicts:
git-fetch.sh
* js/symlink:
Tell multi-parent diff about core.symlinks.
Handle core.symlinks=false case in merge-recursive.
Add core.symlinks to mark filesystems that do not support symbolic links.
* maint:
GIT 1.5.0.3
glossary: Add definitions for dangling and unreachable objects
user-manual: more detailed merge discussion
user-manual: how to replace commits older than most recent
user-manual: insert earlier of mention content-addressable architecture
user-manual: ensure generated manual references stylesheet
user-manual: reset to ORIG_HEAD not HEAD to undo merge
Documentation: mention module option to git-cvsimport
When a cherry-pick failed, we used to recommend setting environment
variables to retain the authorship. It is much easier, though, to use
the "-c" flag of git-commit.
Print this message also when merge-recursive fails (the code used to
exit(1) in that case, never reaching the proper failure path).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that "git diff" handles stdin and relative paths outside the
working tree correctly, we can convert all instances of "diff -u"
to "git diff".
This commit is really the result of
$ perl -pi.bak -e 's/diff -u/git diff/' $(git grep -l "diff -u" t/)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from commit c699a40d68215c7e44a5b26117a35c8a56fbd387)
This allows us to create "new file" and "delete file" patches.
It also cleans up the code.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier commit to read from stdin was full of problems, and
this corrects them.
- The mode bits should have been set to satisify S_ISREG(); we
forgot to the S_IFREG bits and hardcoded 0644;
- We did not give escape hatch to name a path whose name is
really "-". Allow users to say "./-" for that;
- Use of xread() was not prepared to see short read (e.g. reading
from tty) nor handing read errors.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to say
echo Hello World | git diff x -
to compare the contents of file "x" with the line "Hello World".
This automatically switches to --no-index mode.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When run from a subdirectory of a repository, the command forgot
to adjust paths given to it with prefix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch documents the previously undocumented option --rename-section
and adds a new option to zap an entire section.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Unset NO_C99_FORMAT on Cygwin.
Fix a "pointer type missmatch" warning.
Fix some "comparison is always true/false" warnings.
Fix an "implicit function definition" warning.
Fix a "label defined but unreferenced" warning.
Document the config variable format.suffix
git-merge: fail correctly when we cannot fast forward.
builtin-archive: use RUN_SETUP
Fix git-gc usage note
When core.symlinks is false, and a merge of symbolic links had conflicts,
the merge result is left as a file in the working directory. A decision
must be made whether the file is treated as a regular file or as a
symbolic link. This patch treats the file as a symbolic link only if
all merge parents were also symbolic links.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the file system does not support symbolic links (core.symlinks=false),
merge-recursive must write the merged symbolic link text into a regular
file.
While we are here, fix a tiny memory leak in the if-branch that writes
real symbolic links.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some file systems that can host git repositories and their working copies
do not support symbolic links. But then if the repository contains a symbolic
link, it is impossible to check out the working copy.
This patch enables partial support of symbolic links so that it is possible
to check out a working copy on such a file system. A new flag
core.symlinks (which is true by default) can be set to false to indicate
that the filesystem does not support symbolic links. In this case, symbolic
links that exist in the trees are checked out as small plain files, and
checking in modifications of these files preserve the symlink property in
the database (as long as an entry exists in the index).
Of course, this does not magically make symbolic links work on such defective
file systems; hence, this solution does not help if the working copy relies
on that an entry is a real symbolic link.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add the new --no-abbrev option to the man page for the git-branch command.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-branch has an --abbrev= command line option, but it does
no checking of the input. Take the argument parsing code from
setup_revisions in revisions.c, and also the code for parsing
the --no-abbrev option.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When providing a negative indent, it means that -indent columns were
already printed. Fix a bug where the function ate the first character
if already the first word did not fit into the first line.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of using antiquated "git-rev-parse | git-rev-list"
pipeline, it is easier to use "git-rev-list" or "git-log" these
days, as Linus points out.
While we are at it, fix the typo on variable name $newref that
should be $newrev.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Another memory overrun in http-push.c
fetch.o depends on the headers, too.
Documentation: Correct minor typo in git-add documentation.
Documentation/git-send-email.txt: Fix labeled list formatting
Documentation/git-quiltimport.txt: Fix labeled list formatting
Documentation/build-docdep.perl: Fix dependencies for included asciidoc files
Fix some formatting problems:
- Some list labels were missing their "::" characters.
- Some of continuation paragraphs in labeled lists were incorrectly
formatted as literal paragraphs.
- In one case "[verse]" was missing before the config key list.
- The "Basic Examples" section was incorrectly nested inside the
"Config File-Only Options" section.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also the verbose output had unnecessary SHA1 and not-for-merge markers
leaked because append_fetch_head() cheated
Signed-off-by: Junio C Hamano <junkio@cox.net>
When specifying an absolute path, or a relative path pointing outside
the working tree, do not fail, but roll your own diffopt parsing,
and execute a --no-index diff.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing Release Notes for 1.5.0.3
Documentation: git-remote add [-t <branch>] [-m <branch>] [-f] name url
Include config.mak in doc/Makefile
git.el: Set the default commit coding system from the repository config.
git-archimport: support empty summaries, put summary on a single line.
http-push.c::lock_remote(): validate all remote refs.
git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
* np/types:
Cleanup check_valid in commit-tree.
make sure enum object_type is signed
get rid of lookup_object_type()
convert object type handling from a string to a number
formalize typename(), and add its reverse type_from_string()
sha1_file.c: don't ignore an error condition in sha1_loose_object_info()
sha1_file.c: cleanup "offset" usage
sha1_file.c: cleanup hdr usage
* 'js/diff-ni' (early part):
diff --no-index: also imitate the exit status of diff(1)
Fix typo: do not show name1 when name2 fails
Teach git-diff-files the new option `--no-index`
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
* maint:
builtin-fmt-merge-msg: fix bugs in --file option
index-pack: Loop over pread until data loading is complete.
blameview: Fix the browse behavior in blameview
Fix minor typos/grammar in user-manual.txt
Correct ordering in git-cvsimport's option documentation
git-show: Reject native ref
Fix git-show man page formatting in the EXAMPLES section
This routine should be using the object_type enum rather than a
string comparsion, as the expected type is always supplied and is
known at compile time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows for keeping the common idiom which consists of using
negative values to signal error conditions by ensuring that the enum
will be a signed type.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, show_date() can print three different kinds of dates: normal,
relative and short (%Y-%m-%s) dates.
To achieve this, the "int relative" was changed to "enum date_mode
mode", which has three states: DATE_NORMAL, DATE_RELATIVE and
DATE_SHORT.
Since existing users of show_date() only call it with relative_date
being either 0 or 1, and DATE_NORMAL and DATE_RELATIVE having these
values, no behaviour is changed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, it returns the current column, does not add a newline, and you can
pass a negative indent, to indicate that the indent was already printed.
With this, you can actually continue in the middle of a paragraph, not
having to print everything into a buffer first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The config option gitcvs.allbinary may be set to force all entries to
get the -kb flag.
In the future the gitattributes system will probably be a more
appropriate way of doing this, but that will easily slot in as the
entries lines sent to the CVS client now have their kopts set via the
function kopts_from_path().
In the interim it might be better to not just have a all-or-nothing
approach, but rather detect based on file extension (or file contents?).
That would slot in easily here as well. However, I personally prefer
everything to be binary-safe, so I just switch the switch.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commithash for updating the ref is obtained from a call to
git-commit-tree. However, it was returned (and stored) with the
trailing newline. This meant that the later call to git-update-ref that
was trying to update to $commithash was including the newline in the
parameter - obviously that hash would never exist, and so git-update-ref
would always fail.
The solution is to chomp() the commithash as soon as it is returned by
git-commit-tree.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "ci" codepath lockless by following the usual
"remember the tip, do your thing, then compare and swap at the
end" update pattern using update-ref. Incidentally, by updating
the code that reads where the tip of the head is to use
show-ref, it makes it safe to use in a repository whose refs are
pack-pruned.
I noticed that other parts of the program are not yet pack-refs
safe, but tried to keep the changes to the minimum.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/types: (253 commits)
get rid of lookup_object_type()
convert object type handling from a string to a number
formalize typename(), and add its reverse type_from_string()
sha1_file.c: don't ignore an error condition in sha1_loose_object_info()
sha1_file.c: cleanup "offset" usage
sha1_file.c: cleanup hdr usage
git-apply: do not fix whitespaces on context lines.
diff --cc: integer overflow given a 2GB-or-larger file
mailinfo: do not get confused with logical lines that are too long.
Documentation: link in 1.5.0.2 material to the top documentation page.
Documentation: document remote.<name>.tagopt
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
merge-recursive: fix longstanding bug in merging symlinks
merge-index: fix longstanding bug in merging symlinks
diff --cached: give more sensible error message when HEAD is yet to be created.
Update tests to use test-chmtime
Add test-chmtime: a utility to change mtime on files
...
This function is called only once in the whole source tree. Let's move
its code inline instead, which is also in the spirit of removing as much
object type char arrays as possible (not that this patch does anything for
that but at least it is now a local matter).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We currently have two parallel notation for dealing with object types
in the code: a string and a numerical value. One of them is obviously
redundent, and the most used one requires more stack space and a bunch
of strcmp() all over the place.
This is an initial step for the removal of the version using a char array
found in object reading code paths. The patch is unfortunately large but
there is no sane way to split it in smaller parts without breaking the
system.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometime typename() is used, sometimes type_names[] is accessed directly.
Let's enforce typename() all the time which allows for validating the
type.
Also let's add a function to go from a name to a type and use it instead
of manual memcpy() when appropriate.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
First there are too many offsets there and it is getting confusing.
So 'offset' is now 'curpos' to distinguish from other offsets like
'obj_offset'.
Then structures like x = foo(x, &y) are now done as y = foo(&x).
It looks more natural that the result y be returned directly and
x be passed as reference to be updated in place. This has the effect
of reducing some line length and removing a few, needing a bit less
stack space, and it even reduces the compiled code size.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's have hdr be a simple char pointer/array when possible, and let's
reduce its storage to 32 bytes. Especially for sha1_loose_object_info()
where 128 bytes is way excessive and wastes extra CPU cycles inflating.
The object type is already restricted to 10 bytes in parse_sha1_header()
and the size, even if it is 64 bits, will fit in 20 decimal numbers. So
32 bytes is plenty.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-apply: do not fix whitespaces on context lines.
diff --cc: integer overflow given a 2GB-or-larger file
mailinfo: do not get confused with logical lines that are too long.
diff sets the exit status to 0 when no changes were found, to 1
when changes were found, and 2 means error.
We imitate this to be able to use "git diff" in the test scripts.
(Actually, keeping in line with the rest of git, -1 is returned
on error, which corresponds to an exit status 255).
To find out if the diff is not empty, a member called
"found_changes" was introduced in struct diff_options, which is
set in builtin_diff() and fn_out_consume().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (201 commits)
Documentation: link in 1.5.0.2 material to the top documentation page.
Documentation: document remote.<name>.tagopt
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
merge-recursive: fix longstanding bug in merging symlinks
merge-index: fix longstanding bug in merging symlinks
diff --cached: give more sensible error message when HEAD is yet to be created.
Update tests to use test-chmtime
Add test-chmtime: a utility to change mtime on files
Add Release Notes to prepare for 1.5.0.2
Allow arbitrary number of arguments to git-pack-objects
rerere: do not deal with symlinks.
rerere: do not skip two conflicted paths next to each other.
Don't modify CREDITS-FILE if it hasn't changed.
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
...
Update config.txt with info regarding tagopt option
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
It is not like the user said 'diff --cached HEAD', so complaining about
HEAD not being a valid commit, while technically might be correct, is
not very helpful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
test-lib:
Make sure test-chmtime has been built before starting.
t4200-rerere:
Removed non-portable date dependency and avoid touch
Avoid "test -a" which isn't portable, either
lib-git-svn:
Use test-chmtime instead of Perl one-liner to poke
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended to be a portable replacement for our usage
of date(1), touch(1), and Perl one-liners in tests.
Usage: test-chtime (+|=|-|=+|=-)<seconds> <file>..."
'+' increments the mtime on the files by <seconds>
'-' decrements the mtime on the files by <seconds>
'=' sets the mtime on the file to exactly <seconds>
'=+' and '=-' sets the mtime on the file to <seconds> after or
before the current time.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Add Release Notes to prepare for 1.5.0.2
Allow arbitrary number of arguments to git-pack-objects
rerere: do not deal with symlinks.
rerere: do not skip two conflicted paths next to each other.
Don't modify CREDITS-FILE if it hasn't changed.
* 'jc/status' (early part):
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
This is to resolve semantic conflict (which is not textual) that
changes the calling convention of run_diff_files() early.
To name a commit, you can now say
$ git rev-parse ':/Initial revision of "git"'
and it will return the hash of the youngest commit whose
commit message (the oneline) begins with the given prefix.
For future extension, a leading exclamation mark is treated
specially: if you want to match a commit message starting with
a '!', just repeat the exclamation mark. So, to match a commit
which starts with '!Hello World', use
$ git show ':/!!Hello World'
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
git-show-ref --verify: Fail if called without a reference
Conflicts:
builtin-show-ref.c
diff.c
The intent of the commit 'fetch & clone: do not output progress when
not on a tty' was to make fetching and cloning less chatty when
output was not redirected (such as in a cron job).
However, there was a serious thinko in that commit. It assumed that
the client _and_ the server got this update at the same time. But
this is obviously not the case, and therefore upload-pack died on
seeing the option "--no-progress".
This patch fixes that issue by making it a protocol option. So, until
your server is updated, you still see the progress, but once the
server has this patch, it will be quiet.
A minor issue was also fixed: when cloning, the checkout did not
heed no_progress.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using do_switch:
We only need to ensure the index is clean and set to that of the
parent tree) we rely on being able to reconstruct full files
with deltas transferred over the network.
When using do_update:
We may safely unlink the index if we are fetching an entire
new tree with do_update. Having an old index (from a
previously deleted/abandoned directory) around can cause
irrelevant files to be mistakenly kept.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Clearing the pool of the previous SVN::Ra connection we have
seems to to fix mysterious connection dropping errors when
reconnecting to different paths of svn:// repositories hosted by
rubyforge.org.
Note: I'm not sure *why* this fixes things things,
but it does for me.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs caused this to fail:
* GIT_DIR was set incorrectly after entering the target directory
* Avoid double chdir-ing when clone is called with an explicit path
* create target subdirectory *before* running git-init when using
the multi-init path
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, it turns out that SVN::Ra doesn't attempt to deal with
authentication or pass the username to ssh when doing svn+ssh://
URLs
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If we are run inside a subdirectory of a working tree, we'll
chdir to the top first before touching anything. This also
prevents the accidental creation of .git directories inside
subdirectories since they need metadata.
Noticed by maio on #git
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows the user to run git-svn show-ignore on there
current HEAD without needing to remember which branch/ref they
branched from with -i. Also, find_by_url should correctly
handle cases where the URL passed to it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since the options that affect the way metadata is handled in
git-svn, should be consistently set/unset throughout history
imported by git-svn; it makes sense to allow the user to set
certain options from the command-line that will write to the
config file when initially creating the repository.
Also, fix some formatting issues while we're updating
documentation.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This documents the 'clone' and 'rebase' commands
of git-svn. Additionaly, examples are updated
to use them instead of the lower-level 'init' and
'fetch' commands.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These tests are very similar as the ones I used for useSvmProps
and expect the same results because both dumps were generated
from the same original repo.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svm:mirror is not useful at all for us. Parts of the old unit
test were broken and based on my misunderstanding of the
svm:mirror property.
When we read svm:source; make sure we correctly handle the '!'
in it: it is used to separate the path of the repository root
from the virtual path within the repository. We don't need
to make that distinction, honestly!
We also ensure that subdirectories are also mirrored with the
correct URL if we're using useSvmProps.
We have a new test that uses dumped repo that was really
created using SVN::Mirror to avoid ambiguities and
mis-understandings about the svm: properties.
Note: trailing whitespace in the svm.dump file is unfortunately
a reality and required by SVN; so please ignore it when applying
this patch.
Also, ensure that the -R/--remote/--svn-remote flag is always
in effect if explicitly passed via the command-line. This
allows us to track logically different mirrors sharing the
same URL (probably common with SVN::Mirror/SVK users).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to useSvmProps, but far simpler in
implementation because svnsync retains a 1:1
between revision numbers and relative paths within
the repository
Config keys: svn.useSvnsyncProps
svn-remote.<repo>.useSvnsyncProps
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This feature allows users to create repositories from alternate
URLs. For example, an administrator could run git-svn on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
Config key: svn-remote.<remote>.rewriteRoot
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having it named as 'config' prevents us from tracking a
ref named 'config', which is a huge mistake.
On the non-technical side, the word 'config' implies that
a user can freely modify it; but that's not the case
here.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Fixed logic for renaming old .rev_db -> .rev_db.$uuid
* correctly handle manual migrations for those who decide to
start use globbing to handle branches/tags over individual
'fetch' keys
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This works similarly to 'svn update' or 'git pull' except that
it preserves linear history with 'git rebase' instead of 'git
merge' for ease of dcommit-ing with git-svn.
While we're at it, put the working_head_info() logic
into its own function and allow --fetch-all/--all for
dcommit and rebase (which will fetch all refs in the
current [svn-remote] instead of just the working one).
Note that the '-a' switch (short for --fetch-all/--all) has been
removed as it conflicts with the non-svn 'git fetch'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
On newly-created repositories, 'refs/heads/master' does not
point to anything. This can be confusing to new users; so we
update 'master' to point to the last imported ref after fetching
is done.
Once 'master' is valid; we assume HEAD points to it; and if
the repository is not bare, then checkout the files if the
working tree is clean and unused.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force the showing of the --minimize flag as an option in the
'migrate' help.
Also, fix the usage function to correctly filter out
the deprecated aliases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows users to use SVM (SVN::Mirror) to mirror a remote
repository to use dcommit to commit to the repository that SVM
was mirroring. When dcommit is used in this manner, the automatic
fetch + rebase/reset does not happen; in which case the user will
have to manually invoke svm/svk, run 'git svn fetch', and finally
'git rebase'.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The newer default value should should lower memory usage for
large fetches and also help with fetching from less reliable
servers. Previously the value was 1000 and memory usage
got a bit high on some repositories and fetching became
less reliable in some cases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, some changes to avoid creating dead dirs under
.git/svn/. We now create all directories as late as
possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* avoid skipping modification-only changes in fetch
* correctly fetch when we only have branches and tags
to glob from (no fetch keys defined)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init is now just an alias that requires -T/-t/-b;
all options that 'init' can now accept.
This will hopefully simplify usage and reduce typing.
Also, allow the --shared option in 'init' to take an optional
argument now that 'git-init --shared' supports an optional
argument.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-fetch is deprecated, "fetch -a" is easier to type
By default, fetch will fetch everything from its default
[svn-remote]; if fetch [--all|-a] is specified, then it will
fetch from all svn remotes. Refspecs on the command-line
(like git-fetch) are not supported.
Also, enable -r/--revision arguments for fetch so
users can shoot themselves in the foot^W^W^W^W^W
skip some history and do the equivalent of a shallow
clone/fetch they're not interested in.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Some of the repo-config => config renaming missed the git-svn
tests; so I'm just renaming them to be consisten with the
rest of the modern git.
Also, some of the newer tests didn't have 'poke' in them
to workaround race conditions on fast machines. This adds
places where they can _possibly_ occur; but I don't have
fast enough hardware to trigger them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Similar in spirit to the recent dcommit change, we now
look at 'HEAD' by default to look for a GIT_SVN_ID
so the user won't have to pass -i <GIT_SVN_ID> argument.
We are also more tolerant of of people passing bare remote names
as a result (just $GIT_SVN_ID without the -i)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Merge commits can be created when following certain parents,
(most notably 'R' cases) and we definitely don't want to exclude
them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* dcommit no longer requires the correct -i/GIT_SVN_ID option
passed to it. Since you're committing from HEAD (or another
commit that is a parent of HEAD), you'll be able to find
a commit with metadata information containing the SVN URL
that your HEAD was descended from anyways.
* I don't think dcommit ever worked for people using the
noMetadata option; so I don't think relying on metadata
is an issue.
* useSvmProps users shouldn't commit to SVN::Mirror created
repositories anyways, right?
* Users of globbing should automatically be able to commit
to paths that are not explicitly set in .git/config
Signed-off-by: Eric Wong <normalperson@yhbt.net>
A manual test that sets up a repository that looks like an SVK depot,
and then imports it to check that it looks like we mirrored the
'original' source.
There is also a minor modification to the git-svn test library shell
file which sets a variable for the subversion repository's filesystem
path.
[ew: made some of the tests stricter and more thorough]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init did not write a svn-remote.<remote>.url config
entry without a --trunk argument.
Also, The svm:mirror property is used by SVN::Mirror to track
the path of the repository that we are mirroring. We need to
append that to the source (which is (presumably) just the URL of
the repository root).
Lastly, we now look harder for svm:(source|mirror|uuid) properties
in sub and parent directories. Since our relative path could
be tweaked.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Even if nothing touched paths we care about in a fetch;
increment the maxRev like we do with rev_db since
we don't like having to run get_log on revisions we've
seen before.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We need a separate .rev_db file for each repository we're
tracking. This allows us to track the same logical path off
multiple mirrors. We preserve a symlink to the old .rev_db
(no-UUID) if we're (auto-)migrating from an old version to
preserve backwards compatibility.
Also, get rid of the uuid() wrapper since we cache UUID in our
private config, and the SVN::Ra::get_uuid() function memoizes
the return value per-connection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Make sure we flush our userspace buffers and and fsync(2)
.rev_db information to disk if we use these options because
we really don't want to lose this information.
Also, disallow --use-svm-props and --no-metadata from the
command-line because history will be inconsistent if they're
only used occasionally. If a user wants to use these options,
they must be set in the config so they're always on.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Available options are currently:
svn-remote.<remote>.{noMetadata,useSvmProps,followParent}
These boolean switches will override options set globally in
[svn], and even override options set on the command-line (this
should probably change in the future, however).
Note that the noMetadata and useSvmProps options conflict. It's
both technically and logically impossible to use them together.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Pass --use-svm-props or set the svn.usesvmprops key with git-config
to enable using properties set by SVN::Mirror when it mirrored the
upstream URL.
This is heavily based on work from Sam Vilain:
> From: Sam Vilain <sam@vilain.net>
> Date: Sun, 11 Feb 2007 12:34:45 +1300
> Subject: [PATCH] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
>
> If an SVN revision has a property, "svm:headrev", it is likely that
> the revision was created by SVN::Mirror (a part of SVK). The property
> contains a repository UUID and a revision. We want to make it look
> like we are mirroring the original URL, so introduce a helper function
> that returns the original identity URL and UUID, and use it when
> generating commit messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I may resurrect it for dcommit at some point, but nobody really
uses set-tree anymore and I don't feel like introducing more
complexity into the code at this point.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs were found and fixed while getting this to work:
* Remember the 'R'(eplace) case of actions and treat it like we
would an 'A'(dd) case.
* Fix a small case of follow-parent missing a parent if a
subdirectory was modified in the revision where the parent was
copied.
* dirents returned by get_dir sometimes expire if the data
structure is too big and the pool is destroyed, so we
cache get_dir (along with check_path and get_revprops)
temporarily along with its pool.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I incorrectly used $path/? and $path/* to strip off leading
directories, but places where $path = 'branches/0.17' would
incorrectly strip changes to 'branches/0.17.1' as well.
For globs, we require that our '*' is its own path component
(surrounded by '/' or nothing). Enforce this when --prefix= is
passed to us, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--no-follow-parent disables and reverts it back to the old
default behavior of not following parents (if you don't care for
full history).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We don't need them anymore, all the rough points of
the --follow-parent implementation have been worked out.
The only improvement in the future will probably be
--follow-parent-harder, which will track subdirectories and
follow individual file history (so annotate/blame can be
complete); but that is still a ways off.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These checks were needed before git-svn got smarter about
match_paths() and using path information returned by get_log().
We also have extra checking against fetching revisions
out-of-order these days; so we don't have to worry about that as
much. We also check for tree deletions in match_paths() and
skip those as well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We can have a branch that was deleted, then re-added under the
same name but copied from another path, in which case we'll have
multiple parents (we don't want to break the original ref, nor
lose copypath info).
Add a test for this, too, of course.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to the way git proper handles refs, except we
use the keys 'branches' and 'tags' to distinguish when we want
to use wildcards.
The left-hand side of the ':' contains the remote path, and must
have one asterisk ('*') in it for the branch name. The asterisk
may be in any component of the path as long as is it on its own
directory level.
The right-hand side contains the refname and must have the
asterisk as the last path component.
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is an optimization that should conserve network
bandwidth on certain repositories and configurations.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It can be confusing and redundant, since historically the
default remote ref (not remote itself) has been "git-svn", too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since fetch_loop_common starts from the lowest revision number
in a group of Git::SVN objects; we want to avoid refetching
get_log for current users for things we've already cut it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This was originally needed before we used the delta fetcher and
had a less-clean follow-parent implementation that could leave
holes in the history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It looks better (like [remote "origin"]) instead of whatever
refname came up first in our directory traversal. Of course
--remote= overrides this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having 'fetch' entries in the config file created from
--follow-parent is wasteful because it can cause *future* of
invocations to follow revisions we were never interested in
in the first place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using buffered IO for reading 40-41 bytes at a time isn't very
efficient. Buffering writes for a short duration is alright
since we close() right away and buffers will be flushed.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Prefill .rev_db to the maximum revision we tried to fetch;
and take advantage of that so we can avoid using get_log()
on ranges we've already seen (and have deemed uninteresting).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Defer any signals that cause termination while they are
updating; and put the update-ref call as close to the rename()
as possible. Also, make things extra-safe (but slower) for
people using --no-metadata since they can't rely on .rev_db
being rebuilt if it's clobbered (well, I'm calling update-ref
with the -m flag for reflogs, we don't yet have a way to rebuild
.rev_db from reflogs.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Passing very large strings as arguments is bad for memory usage
as it never seems to get freed in Perl. The .rev_db format is
already not optimized for projects with sparse history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
get_log with explicit paths is the safest way to get revisions
that change a particular path we're interested in.
Unfortunately that means we still have to run get_log multiple
times for each path we're interested in, and even more if
a path gets deleted.
The first argument of get_log() is an array reference, but we
shouldn't use more than one element in that array ref because
the non-existence of _one_ of those paths for a particular range
would cause an error for all paths in that range, so yes, we
need multiple get_log calls to be on the safe side...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--svn-remote allows the default remote name to be overridden (useful
for tracking multiple SVN repositories).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We no longer delete the top-level directory even if it got
deleted from the upstream repository. In gs_do_update; we
double-check that the path we're tracking exists at both
endpoints before proceeding. We have also added additional
protection against fetching revisions out-of-order.
To simplify our internal interfaces, I've disabled passing the
'recursive' flag to the gs_do_{switch,update} wrapper functions
since we always want it in git-svn. We also pass the
entire Git::SVN object rather than just the path because it
helped me debug.
When printing progress, the refname is printed out to make
it less confusing when multi-fetch is running.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since refs/remotes/* are not automatically cloned, we expect the
user to be capable of copying those references themselves
anyways.
Also removed the documentation for --ignore-nodate while we're
at it; it has also been made automatic.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We were still skipping path information from get_log if we are
tracking /r9270/drunk/subversion/bindings/..., but got something
like this in the log:
A /r9270/drunk (from /r9270/trunk:14)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I can't seem to figure out what I or the SVN libraries are doing
wrong, but it appears to be related to reparent and probably
some global structure that gets reset if multiple SVN
connections are being used.
So now, in order to use do_switch; we'll open a new connection
to the repository with the complete URL; but we can't seem to
ever use an existing Ra object after another one has been
created...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We don't need our own error handler for other operations. Also
add a message about the successfully do_switch or do_update in
follow-parent for debugging do_switch failures with svn:// and
svn+ssh:// connections.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Historically, git-svn did not always use Digest::MD5 because
it did not use the SVN::Delta::Editor interfaces. Nowadays
it does, and the requires make strace more noisy.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using path names as refnames breaks horribly if a user is
tracking one large, toplevel directory, and a lower-level
directory is followed from another project is a parent
of another ref, as it will cause refnames such as:
'refs/remotes/trunk/path/to/stuff', which will conflict
with a refname of 'refs/remotes/trunk'.
Now we just append @$revno to the end of it the current
refname. And if we have followed back to a grandparent, then
we'll strip any existing '@$parent_revno' strings before
appending our own '@$revno' string to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The do_update or do_switch functions in SVN only allow for a
single path component; so 'path/to/deep/dir' would be
interpreted as 'path'.
SVN 1.4.x has a reparent function that can let us change the
session to use a higher-level root of the repository, so we can
use that for do_switch (which still doesn't seem to work in SVN
1.4.3 (a fix was attempted, but they missed the rest of the
typemap changes needed in trunk...)).
On the do_update side, we can use set_path on higher level
directories and set them to a newer revision so they don't get
updated. We can't do this with do_switch, either, because the
relative path we're tracking can change (directory moving into
a child of itself).
Because of these changes, we need to double check that our Fetch
editor is correctly performing stripping on any prefixed paths
from update, otherwise we'll just die() because that would be
a bug.
Added a test case which helped me notice and fix problems with
do_switch, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, this should allow for the tracking of new, but empty
directories where we would want to see the log message.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since single fetching is a special case of multi-fetch,
share code with it and the fetch loop into Git::SVN::Ra
since it uses a single Ra connection and multiple
Git::SVN objects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Before, we needed a separate svn_ra instance to run
our check_path calls once the editor was active; but
we can avoid that by running all the check_path calls
before our editor is active.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I broke this part with the URL minimization; since
git-svn will now try to connect to the root of
the repository and will end up writing files
there if it can...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn_log_changed_path_t structs were being used out of scope
outside of svn_ra_get_log (because I wanted to eventually be
able to use git-svn with only a single connection to the
repository). So now we dup them into a hash.
This was fixed while making --follow-parent fetches more
efficient. I've moved parsing of the command-line --revision
argument outside of the Git::SVN module so Git::SVN::fetch() can
be used in more places (such as find_parent_branch).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn has never been able to handle deleted branches very well
because svn_ra_get_log() is all-or-nothing, meaning that if the
max revision passed to it does not contain the path we're
tracking, we miss all the revisions in the repository.
Branches fetched using --follow-parent still do this
sub-optimally (will be fixed soon). --follow-parent will soon
become the default, so we will assume that when using get_log();
We will also avoid tracking revprops for revisions with no
path-related changes since otherwise we just end up pulling
logs to paths we don't care about.
Also added a test for this to t9104-git-svn-follow-parent.sh and
correctly commit the log message in the preceeding test (which
conflicted with a filename).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
They simply aren't interesting to track, and this will allow
us to avoid get_log().
Since r0 is covered by this, we need to update the tests to not
rely on r0 (which is always empty).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Introducing Git::IndexInfo. This module will probably be useful
outside of git-svn, so I'm not putting it in the Git::SVN
namespace.
This will allow me to more easily avoid the use of get_log() in
the future and simply run do_update in incrementing ranges.
get_log() should be avoided because there are cases where
moved/deleted directories do not track correctly (until
--follow-parent is run on a new branch).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This means that tracking the path of:
/another-larger/trunk/thunk/bump/thud inside a repository
would follow:
/larger-parent/trunk/thunk/bump/thud
even if the svn log output looks like this:
--------------------------------------------
Changed paths:
A /another-larger (from /larger-parent:5)
--------------------------------------------
Note: the usage of get_log() in git-svn still makes a
an assumption that shouldn't be made with regard to
revisions existing for a particular path.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows connections to be used more efficiently and not require
users to run 'git-svn migrate --minimize' for new repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tests always ran 'git init' before we ran so that repo-config
would always have something to read. However that does not work
in real-world situations where the user expects 'git svn init'
to work without running 'git init' first.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It's not really useful anymore now that we have a better
--follow-parent for the valid cases. Any other use
of it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having multiple fetch refspecs pointing to the same local ref
would be a very bad thing. Start avoiding the use of fatal() or
exit() inside the modules so we can libify more easily.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Bugs fixed:
* We didn't allow manually (not using git-svn) init-ed
remotes/fetch refspecs to be used before. It works now
because that's what I did in this test. git-svn init should
offer more control in the future.
* correctly strip paths in the delta editor when using
do_switch().
* Make the -i / GIT_SVN_ID option work correctly when doing
fetch on a multi-ref svn-remote
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--minimize will update the git-svn configuration to attempt to
connect to the repository root (instead of directly to the
path(s) we are tracking) in order to allow more efficient reuse
of connections (for multi-fetch and follow-parent).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Note: this can cause problems with Perl's reference counting GC,
so I'm disabling Git::SVN::Ra::DESTROY. If we notice more
problems down the line, we can disable this enhancement.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Of course, we handle metadata migrations from previous versions
and we have added unit tests.
The new .git/config remotes resemble non-SVN remotes. Below
is an example with comments:
[svn-remote "git-svn"]
; like non-svn remotes, we have one URL per-remote
url = http://foo.bar.org/svn
; 'fetch' keys are done in the same way as non-svn
; remotes, too. With the left-hand-side of the ':'
; being the remote (SVN) repository path relative to the
; above 'url' key; and the right-hand-side being a
; remote ref in git (refs/remotes/*).
; An empty left-hand-side means that it will fetch
; the entire contents of the 'url' key.
; old-style (migrated from previous versions of git-svn)
; are like this:
fetch = :refs/remotes/git-svn
; this is created by a current version of git-svn
; using the multi-init command with an explicit
; url (specified above). This allows multi-init
; to reuse SVN::Ra connections.
fetch = trunk:refs/remotes/trunk
fetch = branches/a:refs/remotes/a
fetch = branches/b:refs/remotes/b
fetch = tags/0.1:refs/remotes/tags/0.1
fetch = tags/0.2:refs/remotes/tags/0.2
fetch = tags/0.3:refs/remotes/tags/0.3
[svn-remote "alt"]
; this is another old-style remote migrated over
; to the new config format
url = http://foo.bar.org/alt
fetch = :refs/remotes/alt
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It's becoming a maintenance burden. I've never found it
particularly useful myself, nor have I heard much feedback about
it; so I'm assuming it's just as useless to everyone else.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, convert all usage of 'log_msg' to 'log_entry' for
consistency's sake
SVN::Git::Editor::apply_diff now drives the rest of the
editor.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
More cleanup to separate out functionality and make things
nicer to hack on.
While we're at it, centralize loading of the authors into
one place and correctly handle '(no author)' cases in
when showing logs after-the-fact; and not just at commit
time.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If a user specified a seperate URL and --tags/--branches as
a sepearte URL, allow the Ra object (and therefore the connection)
to be reused.
We'll get rid of libsvn_ls_fullurl() since it was only used
in one place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I will be using functions from Git.pm in more modules, so I
want to avoid re-importing the long argument list everywhere
it's used.
Also removed an unused command-line switch
(--no-ignore-externals) and some variables.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force some svn_ra functions to use a temporary pool via wrapper
This cleans up the code a bit by removing explicit instances of
pool allocation and deallocation and providing wrapper functions
that make use of temporary pools.
I've also added an explicit pool usage when creating the commit
editor for commit-diff where get_commit_editor can be called
multiple times with the same pool previously.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We can use the revision walker easily for checking if the
prerequisites are met, instead of fork()ing off a rev-list,
which would list only the first unmet prerequisite.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch fixes issues mentioned by Junio, Nico and Simon:
- I forgot to convert the usage string when removing the "--" from
the subcommands,
- a style fix in the bundle_header,
- use xread() instead of read(),
- use write_or_die() instead of write(),
- make the bundle header extensible,
- fail if the whitespace after a sha1 of a reference is missing,
- close() the fds passed to a subprocess,
- in verify_bundle(), do not use "rev-list --stdin", but rather
pass the revs directly (avoiding a fork()),
- fix a corrupted comment in show_object(), and
- fix the size check in index_pack.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was done by setting $HOME to somewhere bogus. A better method is
to reuse $GIT_CONFIG, which was invented for ignoring the global
config file explicitely.
Technically, setting GIT_CONFIG=.git/config could be wrong, but it
passes all the tests, and we can keep the tests that way.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lt/crlf:
Teach core.autocrlf to 'git apply'
t0020: add test for auto-crlf
Make AutoCRLF ternary variable.
Lazy man's auto-CRLF
* jc/apply-config:
t4119: test autocomputing -p<n> for traditional diff input.
git-apply: guess correct -p<n> value for non-git patches.
git-apply: notice "diff --git" patch again
Fix botched "leak fix"
t4119: add test for traditional patch and different p_value
apply: fix memory leak in prefix_one()
git-apply: require -p<n> when working in a subdirectory.
git-apply: do not lose cwd when run from a subdirectory.
Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository
Teach 'git apply' to look at $GIT_DIR/config
* maint:
git-diff: fix combined diff
Fix 'git commit -a' in a newly initialized repository
Include git-gui credits file in dist.
Document the new core.bare configuration option.
With this patch,
$ git show -s \
--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'
shows something like
Ze komit 04c5c88 woss
dunn buy ze great Junio C Hamano
The supported placeholders are:
'%H': commit hash
'%h': abbreviated commit hash
'%T': tree hash
'%t': abbreviated tree hash
'%P': parent hashes
'%p': abbreviated parent hashes
'%an': author name
'%ae': author email
'%ad': author date
'%aD': author date, RFC2822 style
'%ar': author date, relative
'%at': author date, UNIX timestamp
'%cn': committer name
'%ce': committer email
'%cd': committer date
'%cD': committer date, RFC2822 style
'%cr': committer date, relative
'%ct': committer date, UNIX timestamp
'%e': encoding
'%s': subject
'%b': body
'%Cred': switch color to red
'%Cgreen': switch color to green
'%Cblue': switch color to blue
'%Creset': reset color
'%n': newline
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this flag and given two paths, git-diff-files behaves as a GNU diff
lookalike (plus the git goodies like --check, colour, etc.). This flag
is also available in git-diff. It also works outside of a git repository.
In addition, if git-diff{,-files} is called without revision or stage
parameter, and with exactly two paths at least one of which is not tracked,
the default is --no-index.
So, you can now say
git diff /etc/inittab /etc/fstab
and it actually works!
This also unifies the duplicated argument parsing between cmd_diff_files()
and builtin_diff_files().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a patch fails, I automatically add '-v' to the command line
to see what fails.
This patch makes -v a synonym to --verbose, and actually tells
the user which text was not found.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This delays the error exit from hold_lock_file_for_update() in
update-index, so that "update-index --refresh" in a read-only
repository can still report what paths are stat-dirty before
exiting.
Also it makes -q to squelch the error message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-status work semi-decently in a read-only
repository. Earlier, the command simply died with "cannot lock
the index file" before giving any useful information to the
user.
Because index won't be updated in a read-only repository,
stat-dirty paths appear in the "Changed but not updated" list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances the third point in the previous commit. When
applying a non-git patch that begins like this:
--- 2.6.orig/mm/slab.c
+++ 2.6/mm/slab.c
@@ -N,M +L,K @@@
...
and if you are in 'mm' subdirectory, we notice that -p2 is the
right option to use to apply the patch in file slab.c in the
current directory (i.e. mm/slab.c)
The guess function also knows about this pattern, where you
would need to use -p0 if applying from the top-level:
--- mm/slab.c
+++ mm/slab.c
@@ -N,M +L,K @@@
...
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier one that tried to be too consistent with GNU patch by
not stripping the leading path when we _know_ we are in a
subdirectory and the patch is relative to the toplevel was a
mistake. This fixes it.
- No change to behaviour when it is run from the toplevel of
the repository.
- When run from a subdirectory to apply a git-generated patch,
it uses the right -p<n> value automatically, with or without
--index nor --cached option.
- When run from a subdirectory to apply a randomly generated
patch, it wants the right -p<n> value to be given by the
user.
The second one is a pure improvement to correct inconsistency
between --index and non --index case, compared with 1.5.0. The
third point could be further improved to guess what the right
value for -p<n> should be by looking at the patch, but should be
a topic of a separate patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Use gunzip -c over gzcat in import-tars example.
git-gui: Don't crash in citool mode on initial commit.
git-gui: Remove TODO list.
git-gui: Include browser in our usage message.
git-gui: Change summary of git-gui.
git-gui: Display all authors of git-gui.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Correct crash when saving options in blame mode.
git-gui: Expose the browser as a subcommand.
git-gui: Create new branches from a tag.
git-gui: Prefer version file over git-describe.
git-gui: Print version on the console.
git-gui: More consistently display the application name.
git-gui: Permit merging tags into the current branch.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Refactor 'exec git subcmd' idiom.
When (new_name == old_name), the previous one prefixed old_name
alone, leaving new_name untouched, and worse yet, left it
dangling pointing at an already freed memory location.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: the original from Pavel was limiting the variable names to only
fetch and url, but I loosened it to take valid variable names.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Matthias Lederhofer noticed that `diff -B` did not pick up on diff
colournig.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In response to a feature request from Shawn Pearce, this patch allows
a user to update a named group of remotes by using "git remote update
<group>", where the group is defined in the config file by
remotes.<group>. The default if the named group is not specified is
now fetched group remotes.default, instead of remote.fetch, which is
what had been previously used.
In addition, if remotes.default is not defined, all remotes defined in
the config file will be used, as before, but there is now also
possible to request that a particular repository to be skipped by
default by using the boolean configuration parameter
remote.<name>.skipDefaultUpdate.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is necessary if using CVS in an asymmetric fashion, i.e. when the
CVSROOT you are checking out from differs from the CVSROOT you have to
commit to.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Glibc uses the same size for int and off_t by default.
In order to support large pack sizes (>2GB) we force Glibc to a 64bit off_t.
Signed-off-by: Martin Waitz <tali@admingilde.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There were instances of strncmp() that were formatted improperly
(e.g. whitespace around parameter before closing parenthesis)
that caused the earlier mechanical conversion step to miss
them. This step cleans them up.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previous step converted use of strncmp() with literal string
mechanically even when the result is only used as a boolean:
if (!strncmp("foo", arg, 3)) ==> if (!(-prefixcmp(arg, "foo")))
This step manually cleans them up to read:
if (!prefixcmp(arg, "foo"))
Signed-off-by: Junio C Hamano <junkio@cox.net>
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
The settings in /etc/gitconfig can be overridden in ~/.gitconfig,
which in turn can be overridden in .git/config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the option "--no-progress" to fetch-pack and upload-pack,
and makes fetch and clone pass this option when stdout is not a tty.
While at documenting that option, also document --strict and --timeout
options for upload-pack.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, when saying --max-age=<timestamp>, or --max-count=<n>, together
with --boundary, rev-list prints the boundary commits, i.e. the
commits which are _just_ not shown without --boundary, i.e. their
children are, but they aren't.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When naming by a tag, we used to add "^0" even if this was not really
necessary. For example, `git name-rev de6f0def` now outputs
de6f0def tags/v1.5.0.1~9
instead of
de6f0def tags/v1.5.0.1^0~9
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply running inside a subdirectory, with or without --index,
used to always assume that the patch is formatted in such a way
to apply with -p1 from the toplevel, but it is more useful and
consistent with the use of "GNU patch -p1" if it defaulted to
assume that its input is meant to apply at the level it is
invoked in.
This changes the behaviour. It used to be that the patch
generated this way would apply without any trick:
edit Documentation/Makefile
git diff >patch.file
cd Documentation
git apply ../patch.file
You need to give an explicit -p2 to git-apply now. On the other
hand, if you got a patch from somebody else who did not follow
"patch is to apply from the top with -p1" convention, the input
patch would start with:
diff -u Makefile.old Makefile
--- Makefile.old
+++ Makefile
and in such a case, you can apply it with:
git apply -p0 patch.file
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a patch modifies (not deletes) the last file in a
directory, because we treat a modification just as deletion
followed by creation, and deleting the last file in a directory
automatically rmdir(2)'s that directory, we ended up removing
the directory, which can potentially be the cwd, and then
recreating the same directory to create the patch result.
Avoid the rmdir step when remove_file() is called only because
we are replacing it with the result by later calling
create_file().
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows users to use the command "git remote update" to update all
remotes that are being tracked in the repository.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On a Solaris machine I have access to libc contains the symbol
"iconv" but, when compiling with gcc and including iconv.h we get
iconv.h from GNU libiconv. This header file define (among other
things) "iconv" to "libiconv" and so on.
In order to link with GNU libiconv we need -liconv. Currently we
test if the symbol "iconv" is in libc (which is true), then we get
a undefined reference error because we don't have libiconv_open.
The solution this patch implements is to compile and link a
small test program, instead of just checking if the libraries
(libc and libiconv) contains the symbol "iconv".
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Update draft release notes for 1.5.0.1
Convert update-index references in docs to add.
Attempt to improve git-rebase lead-in description.
Do not take mode bits from index after type change.
git-blame: prevent argument parsing segfault
Make gitk save and restore window pane position on Linux and Cygwin.
Make gitk save and restore the user set window position.
[PATCH] gitk: Use show-ref instead of ls-remote
[PATCH] Make gitk work reasonably well on Cygwin.
[PATCH] gitk - remove trailing whitespace from a few lines.
Change git repo-config to git config
This teaches git-apply that the data read from and written to
the filesystem might need to get converted to adjust for local
line-ending convention.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When neither --index nor --cached was used, git-apply did not
try calling setup_git_directory(), which means it did not look
at configuration files at all. This fixes it to call the setup
function but still allow the command to be run in a directory
not controlled by git.
The bug probably meant that 'git apply', not moving up to the
toplevel, did not apply properly formatted diffs from the
toplevel when you are inside a subdirectory, even though 'git
apply --index' would. As a side effect, this patch fixes it as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of (or, in addition to) --tags, to use only tags for naming,
you can now use --refs=<pattern> to specify a shell glob pattern
which the refs must match to be used for naming.
Example:
$ git name-rev --refs=*v1* 33db5f4d33db5f4d tags/v1.0rc1^0~1593
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With a configuration entry like this:
[remote "alt-git"]
url = git://repo.or.cz/alt.git/git/
fetch = +refs/heads/*:refs/remotes/alt-git/*
tagopt = --no-tags
you do not have to say "git pull --no-tags alt-git". Just
saying "git pull alt-git" would suffice.
Obviously, if you want to get the tag from such an alternate
remote in a separate namespace, you could also do something like:
[remote "alt-git"]
url = git://repo.or.cz/alt.git/git/
fetch = +refs/heads/*:refs/remotes/alt-git/*
fetch = +refs/tags/*:refs/remote-tags/alt-git/*
tagopt = --no-tags
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT-VERSION-FILE: check ./version first.
sha1_file.c: Round the mmap offset to half the window size.
Make sure packedgitwindowsize is multiple of (pagesize * 2)
Add RelNotes 1.5.0.1
Still updating 1.5.0 release notes.
git-daemon: Avoid leaking the listening sockets into child processes.
Clarify two backward incompatible repository options.
This tests lowlevel of update/checkout codepaths and some patch
application. Currently, variants of "git apply" that look at
the working tree files does not work, so it does not test the
patch application without parameter and with --index parameter
when autocrlf is set to produce CRLF files.
We should add test for diff generation too.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to do:
[core]
AutoCRLF = input
and it should do only the CRLF->LF translation (ie it simplifies CRLF only
when reading working tree files, but when checking out files, it leaves
the LF alone, and doesn't turn it into a CRLF).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.
Anyway, BY DEFAULT it is off regardless, because it requires a
[core]
AutoCRLF = true
in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).
But you can actually enable it on UNIX, and it will cause:
- "git update-index" will write blobs without CRLF
- "git diff" will diff working tree files without CRLF
- "git checkout" will write files to the working tree _with_ CRLF
and things work fine.
Funnily, it actually shows an odd file in git itself:
git clone -n git test-crlf
cd test-crlf
git config core.autocrlf true
git checkout
git diff
shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.
Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).
I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.
NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.
The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
44478d99ee introduced a filter using "git-rev-parse --not --all" to the
log display to prevent the display of revisions already in the
repository. However, the table of contents generation didn't get that
same update.
This patch fixes that. The table of contents before the log and the log
now both display the same list of revisions.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver is analogous to git-receive-pack; a checking from a cvs
client to a central server is like a git-push from a working repository.
Therefore it's nice to use the same access control (and email sending)
that a receive-pack would perform.
This patch tests for an executable update hook; if it is it is run with
the ref being updated and the old and new hashes as normal. If the
update hook returns an error code the update is aborted and the ref is
never updated. The cvsserver returns "error 1" to the client to signal
there was an EPERM error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of running around listing the changes near the release,
let's keep things nicely organized by summarizing the changes as
we merge things to the 'master' branch.
I haven't decided how well this will go with people's patch
submission procedure yet --- we'll play it by the ear and see
what happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Makefile: update check-docs target
cmd-list: add git-remote
Documentation: Drop full-stop from git-fast-import title.
Minor corrections to release notes
Use the new stdin reflist passing mechanism for the call to
fetch--tool parse-reflist, allowing passing of more than ~128K
of reflist data.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the new stdin reflist passing mechanism for the call to
fetch--tool expand-refs-wildcard, allowing passing of more
than ~128K of reflist data.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the reflist is "-" then read the reflist data from stdin instead,
this will allow the passing of more than 128K of reflist data - which
won't fit in the environment passed by execve.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This does not seem to make measurable improvement when dealing
with 1000 unpacked refs, but we would need something like it
if we were to do a full rewrite in C somedaoy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Move another shell loop that canonicalizes the list of refs for
underlying git-fetch-pack and fetch-native-store into C.
This seems to shave the runtime for the same 1000 branch
repository from 30 seconds down to 15 seconds (it used to be 2
and half minutes with the original version).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "native-store" subcommand to git-fetch--tool to
move a huge loop implemented in shell into C. This shaves about
70% of the runtime to fetch and update 1000 tracking branches
with a single fetch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
`git diff --ignore-space-at-eol` will ignore whitespace at the
line ends.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you were issuing emails for two branches, and one merged the other,
you would get the same log messages appearing in two separate emails.
e.g. A working repository, where the last push to central was done at
the revision marked "B", after which two branches were developed
further.
* -- B -- 1 -- 1 -- M (branch1)
\ /
2 -- 2 -- 2 (branch2)
Now imagine that branch2 is pushed to the email-generating repository;
an email containing all the "2" revisions would be sent. Now, let's say
branch1 is pushed, the old update hook would run
git-rev-list $newrev ^$baserev
Where $newrev would be "M" and $baserev would be "B". This list
includes all the "2" revisions as well as all the "1" revisions.
This patch addresses this problem by using
git-rev-parse --not --all | git-rev-list --stdin $newrev ^$baserev
To inhibit the display of all revisions that are already in the
repository.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The option --reverse reverses the order of the commits.
[jc: with comments on rev_info.reverse from Simon 'corecode' Schubert.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The internal function in_merge_bases(A, B) is used to make sure
that commit A is an ancestor of commit B. This changes the
signature of it to take an array of B's and updates its current
callers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somebody was wondering on #git channel why a git generated diff
does not apply with GNU patch when the filename contains a SP.
It is because GNU patch expects to find TAB (and trailing timestamp)
on ---/+++ (old_name and new_name) lines after the filenames.
The "diff --git" output format was carefully designed to be
compatible with GNU patch where it can, but whitespace
characters were always a pain.
This adds an extra TAB (but not trailing timestamp) to old_name
and new_name lines of git-diff output when the filename has a SP
in it. An earlier patch updated git-apply to prepare for this.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 21:27:51 -08:00
348 changed files with 15698 additions and 6109 deletions
/* if symlinks don't work, assume symlink if all parents
* are symlinks
*/
is_file=has_symlinks;
for(i=0;!is_file&&i<num_parent;i++)
is_file=!S_ISLNK(elem->parent[i].mode);
if(!is_file)
elem->mode=canon_mode(S_IFLNK);
result_size=len;
result=xmalloc(len+1);
while(sz<len){
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
