Mark Wooding noticed there was a type mismatch warning in git.c; this
patch does things slightly differently (mostly tightening const) and
was what I was holding onto, waiting for the setup-revisions change
to be merged into the master branch.
Documentation/Makefile: Some `git-*.txt' files aren't manpages.
In particular, git-tools.txt isn't a manpage, and my Asciidoc gets upset
by it. The simplest fix is to Remove articles from the list of manpages
the Makefile.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Add --temp and --stage=all options to checkout-index.
Sometimes it is convient for a Porcelain to be able to checkout all
unmerged files in all stages so that an external merge tool can be
executed by the Porcelain or the end-user. Using git-unpack-file
on each stage individually incurs a rather high penalty due to the
need to fork for each file version obtained. git-checkout-index -a
--stage=all will now do the same thing, but faster.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
When amending a commit only to update the commit log message, git-status
would rightly say "Nothing to commit." Do not let this prevent commit to
be made.
I am very sorry to do this, but without this funky octopus, "git
log --no-merges master..next" will show commits already merged
into "master" forever.
There are some commits on the next branch (which is never to be
rewound) that are reverts of other commits on the next branch.
They are to revert the finer grained delta experiments that
turned out to have undesirable performance effects. Also there
are some other commits that were first done as a merge into
"next" (a pull request based on next) and then cherry picked
into master. Since they are not going to be merged into
"master" ever, they will stay forever in "log master..next".
Yuck.
So this commit records the fact that the commits currently shown
by "git log --no-merges master..next" to be merged into "master"
are already in the master, either because they really are (in
the case of git-cvsserver bits, which needed cherry-picking into
"master"), or because they are fully reverted in "next" (in the
case of finer-grained delta bits).
This shows what git thinks are missing from master. It
shows chain of commits that are already merged and chain of
commits whose net effect should amount to a no-op.
Look at each commits and make sure they are either unwanted
or already merged by cherry-picking.
(2) Record the tip of branches that I do not want. In this
case, the following were unwanted:
* master:
AsciiDoc fix for tutorial
git.el: Added customize support for all parameters.
git.el: Added support for Signed-off-by.
git.el: Automatically update .gitignore status.
git.el: Set default directory before running the status mode setup hooks.
git.el: Portability fixes for XEmacs and Emacs CVS.
contrib/emacs: Add an Emacs VC backend.
Add a basic Emacs VC backend. It currently supports the following
commands: checkin, checkout, diff, log, revert, and annotate. There is
only limited support for working with revisions other than HEAD.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/diff:
diffcore-delta: make change counter to byte oriented again.
diffcore-break: similarity estimator fix.
count-delta: no need for this anymore.
diffcore-delta: make change counter to byte oriented again.
The textual line oriented change counter was fun but was not
very effective. It tended to overcount the changes. This one
changes it to a simple N-letter substring based implementation.
This is a companion patch to e29e1147e485654d90a0ea0fd5fb7151bb194265
which made diffcore similarity estimator independent from the packfile
deltifier. There is no reason for us to be counting the xdelta anymore.
* lt/rev-list:
setup_revisions(): handle -n<n> and -<n> internally.
git-log (internal): more options.
git-log (internal): add approxidate.
Rip out merge-order and make "git log <paths>..." work again.
Tie it all together: "git log"
Introduce trivial new pager.c helper infrastructure
git-rev-list libification: rev-list walking
Splitting rev-list into revisions lib, end of beginning.
rev-list split: minimum fixup.
First cut at libifying revlist generation
I just rebuilt my 'next' branch from scratch, based on master without
the delta topics that were there. This would rewind the head which is
a no-no. This merges the original 'next' back in, to finish the "reverting"
of these two topic branches.
nothing to commit
* lt/rev-list:
setup_revisions(): handle -n<n> and -<n> internally.
git-log (internal): more options.
git-log (internal): add approxidate.
Rip out merge-order and make "git log <paths>..." work again.
Tie it all together: "git log"
Introduce trivial new pager.c helper infrastructure
git-rev-list libification: rev-list walking
Splitting rev-list into revisions lib, end of beginning.
rev-list split: minimum fixup.
First cut at libifying revlist generation
(On some inetd implementations you may have to put the pserver parameter twice.)
Commits are blocked. Naively, git-cvsserver assumes non-malicious users. Please
review the code before setting this up on an internet-accessible server.
NOTE: the <nobody> user above will need write access to the .git directory
to maintain the sqlite database. Updating of the sqlite database should be
put in an update hook to avoid this problem, so that it is maintained by
users with write access.
cvsserver: nested directory creation fixups for Eclipse clients
To create nested directories without (or before) sending file entries
is rather tricky. Most clients just work. Eclipse, however, expects
a very specific sequence of events. With this patch, cvsserver meets
those expectations.
Note: we may want to reuse prepdir() in req_update -- should move it
outside of req_co. Right now prepdir() is tied to how req_co() works.
* tl/anno:
annotate should number lines starting with 1
contrib/git-svn: fix a copied-tree bug in an overzealous assertion
show-branch --topics: omit more uninteresting commits.
workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)
git-mv: fix moves into a subdir from outside
send-email: accept --no-signed-off-by-cc as the documentation states
contrib/git-svn: better documenting of CLI switches
contrib/git-svn: add --id/-i=$GIT_SVN_ID command-line switch
contrib/git-svn: avoid re-reading the repository uuid, it never changes
contrib/git-svn: create a more recent master if one does not exist
contrib/git-svn: cleanup option parsing
contrib/git-svn: allow --authors-file to be specified
contrib/git-svn: strip 'git-svn-id:' when commiting to SVN
contrib/git-svn: several small bug fixes and changes
contrib/git-svn: add -b/--branch switch for branch detection
Prevent --index-info from ignoring -z.
manpages: insert two missing [verse] markers for multi-line SYNOPSIS
gitview: pass the missing argument _show_clicked_cb.
Fix test case for some sed
git-branch: add -r switch to list refs/remotes/*
contrib/git-svn: fix a copied-tree bug in an overzealous assertion
I thought passing --stop-on-copy to svn would save us from all
the trouble svn-arch-mirror had with directory (project) copies.
I was wrong, there was one thing I overlooked.
If a tree was moved from /foo/trunk to /bar/foo/trunk with no
other changes in r10, but the last change was done in r5, the
Last Changed Rev (from svn info) in /bar/foo/trunk will still be
r5, even though the copy in the repository didn't exist until
r10.
Now, if we ever detect that the Last Changed Rev isn't what
we're expecting, we'll run svn diff and only croak if there are
differences between them.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
show-branch --topics: omit more uninteresting commits.
When inspecting contents of topic branches for yet-to-be-merged
commits, a commit that is in the release/master branch is
uninteresting. Previous round still showed them, especially,
the ones before a topic branch that was forked from the
release/master later than other topic branches.
git-mv needs to be run from the base directory so that
the check if a file is under revision also covers files
outside of a subdirectory. Previously, e.g. in the git repo,
cd Documentation; git-mv ../README .
produced the error
Error: '../README' not under version control
The test is extended for this case; it previously only tested
one direction.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: avoid re-reading the repository uuid, it never changes
If it does change, we're screwed anyways as SVN will refuse to
commit or update. We also never access more than one SVN
repository per-invocation, so we can store it as a global, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: create a more recent master if one does not exist
In a new repository, the initial fetch creates a master branch
if one does not exist so HEAD has something to point to.
It now creates a master at the end of the initial fetch run,
pointing to the latest revision. Previously it pointed to the
first revision imported, which is generally less useful.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: strip 'git-svn-id:' when commiting to SVN
We regenerate and use git-svn-id: whenever we fetch or otherwise
commit to remotes/git-svn. We don't actually know what revision
number we'll commit to SVN at commit time, so this is useless.
It won't throw off things like 'rebuild', though, which knows to
only use the last instance of git-svn-id: in a log message
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: several small bug fixes and changes
* Fixed manually-edited commit messages not going to
remotes/git-svn on sequential commits after the sequential
commit optimization.
* format help correctly after adding 'show-ignore'
* sha1_short regexp matches down to 4 hex characters
(from git-rev-parse --short documentation)
* Print the first line of the commit message when we commit to
SVN next to the sha1.
* Document 'T' (type change) in the comments
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: add -b/--branch switch for branch detection
I've said I don't like branches in Subversion, and I still don't.
This is a bit more flexible, though, as the argument for -b is any
arbitrary git head/tag reference.
This makes some things easier:
* Importing git history into a brand new SVN branch.
* Tracking multiple SVN branches via GIT_SVN_ID, even from multiple
repositories.
* Adding tags from SVN (still need to use GIT_SVN_ID, though).
* Even merge tracking is supported, if and only the heads end up with
100% equivalent tree objects. This is more stricter but more robust
and foolproof than parsing commit messages, imho.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
If git-update-index --index-info -z is used only the first
record given to the process will actually be updated as
the -z option is ignored until after all index records
have been read and processed. This meant that multiple
null terminated records were seen as a single record which
was lacking a trailing LF, however since the first record
ended in a null the C string handling functions ignored the
trailing garbage. So --index-info should be required to be
the last command line option, much as --stdin is required
to be the last command line option. Because --index-info
implies --stdin this isn't an issue as the user shouldn't
be passing --stdin when also passing --index-info.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
manpages: insert two missing [verse] markers for multi-line SYNOPSIS
Found with:
for i in *.txt; do
grep -A 2 "SYNOPSIS" "$i" | grep -q "^\[verse\]$" && continue
multiline=$(grep -A 3 "SYNOPSIS" "$i" | tail -n 1)
test -n "$multiline" && echo "$i: $multiline"
done
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'cvsserver' of locke.catalyst.net.nz/git/git-martinlanghoff; branch 'ml/cvsserver' into next
* 'cvsserver' of http://locke.catalyst.net.nz/git/git-martinlanghoff:
cvsserver: fix checkouts with -d <somedir>
cvsserver: checkout faster by sending files in a sensible order
* ml/cvsserver:
cvsserver: fix checkouts with -d <somedir>
cvsserver: checkout faster by sending files in a sensible order
A recent Eclipse compat fix broke checkouts with -d. Fix it so that the server
sends the correct module name instead of the destination directory name.
cvsserver: checkout faster by sending files in a sensible order
Just by sending the files in an ordered fashion, clients can process them
much faster. And we can optimize our check of whether we created this
directory already -- faster.
Timings for a checkout on a commandline cvs client for a project with
~13K files totalling ~100MB:
The "similarity" logic was giving added material way too much
negative weight. What we wanted to see was how similar the
post-change image was compared to the pre-change image, so the
natural definition of similarity is how much common things are
there, relative to the post-change image's size.
An earlier commit 8098a178b26dc7a158d129a092a5b78da6d12b72
accidentally lost race protection from git-commit command.
This commit reinstates it. When something else updates HEAD
pointer while you were editing your commit message, the command
would notice and abort the commit.
The new flag is used to amend the tip of the current branch. Prepare
the tree object you would want to replace the latest commit as usual
(this includes the usual -i/-o and explicit paths), and the commit log
editor is seeded with the commit message from the tip of the current
branch. The commit you create replaces the current tip -- if it was a
merge, it will have the parents of the current tip as parents -- so the
current top commit is discarded.
It is a rough equivalent for:
$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD
A recent Eclipse compat fix broke checkouts with -d. Fix it so that the server
sends the correct module name instead of the destination directory name.
cvsserver: checkout faster by sending files in a sensible order
Just by sending the files in an ordered fashion, clients can process them
much faster. And we can optimize our check of whether we created this
directory already -- faster.
Timings for a checkout on a commandline cvs client for a project with
~13K files totalling ~100MB:
This adds a new flag, --topics, to help managing topic
branches. When you have topic branches forked some time ago
from your primary line of development, show-branch would show
many "uninteresting" things that happend on the primary line of
development when trying to see what are still not merged from
the topic branches.
With this flag, the first ref given to show-branch is taken as
the primary branch, and the rest are taken as the topic
branches. Output from the command is modified so that commits
only on the primary branch are not shown. In other words,
GIT-VERSION-GEN: squelch unneeded error from "cat version"
Now this is really a corner case, but if you have the git source
tree from somewhere other than the official tarball, you do not
have version file. And if git-describe does not work for you
(maybe you do not have git yet), we spilled an error message
from "cat version".
setup_revisions(): handle -n<n> and -<n> internally.
This moves the handling of max-count shorthand from the internal
implementation of "git log" to setup_revisions() so other users
of setup_revisions() can use it.
Here is an updated version of git-blame. The main changes compared to
the first version are:
* Use the new revision.h interface to do the revision walking
* Do the right thing in a lot of more cases than before. In particular
parallel development tracks are hopefully handled sanely.
* Lots of clean-up
I think git-blame is correct in this case. This patterns occur in
several other places, git-annotate seems to sometimes assign lines to
merge commits when the lines actually changed in some other commit
which precedes the merge.
[jc: I have conned Ryan into doing test cases, so that it would
help development and fixes on both implementations. Let the
battle begin! ;-) ]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
Now blame will depend on the new revision walker infrastructure,
we need to make it depend on earlier parts of Linus' rev-list
topic branch, hence this merge.
* master:
contrib/git-svn: use refs/remotes/git-svn instead of git-svn-HEAD
Merge branch 'maint'
read-tree --aggressive: remove deleted entry from the working tree.
Merge branch 'jc/tag'
Merge part of 'jc/diff'
contrib/git-svn: use refs/remotes/git-svn instead of git-svn-HEAD
After reading a lengthy discussion on the list, I've come to the
conclusion that creating a 'remotes' directory in refs isn't
such a bad idea.
You can still branch from it by specifying remotes/git-svn (not
needing the leading 'refs/'), and the documentation has been
updated to reflect that.
The 'git-svn' part of the ref can of course be set to whatever
you want by using the GIT_SVN_ID environment variable, as
before.
I'm using refs/remotes/git-svn, and not going with something
like refs/remotes/git-svn/HEAD as it's redundant for Subversion
where there's zero distinction between branches and directories.
Run git-svn rebuild --upgrade to upgrade your repository to use
the new head. git-svn-HEAD must be manually deleted for safety
reasons.
Side note: if you ever (and I hope you never) want to run
git-update-refs on a 'remotes/' ref, make sure you have the
'refs/' prefix as you don't want to be clobbering your
'remotes/' in $GIT_DIR (where remote URLs are stored).
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/delta:
diff-delta: allow reusing of the reference buffer index
diff-delta: bound hash list length to avoid O(m*n) behavior
diff-delta: produce optimal pack data
Merge branch 'kh/svnimport'
Merge branch 'js/refs'
annotate: fix -S parameter to take a string
annotate: Add a basic set of test cases.
annotate: handle \No newline at end of file.
gitview: Use horizontal scroll bar in the tree view
diff-delta: allow reusing of the reference buffer index
When a reference buffer is used multiple times then its index can be
computed only once and reused multiple times. This patch adds an extra
pointer to a pointer argument (from_index) to diff_delta() for this.
If from_index is NULL then everything is like before.
If from_index is non NULL and *from_index is NULL then the index is
created and its location stored to *from_index. In this case the caller
has the responsibility to free the memory pointed to by *from_index.
If from_index and *from_index are non NULL then the index is reused as
is.
This currently saves about 10% of CPU time to repack the git archive.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-delta: bound hash list length to avoid O(m*n) behavior
The diff-delta code can exhibit O(m*n) behavior with some patological
data set where most hash entries end up in the same hash bucket.
The latest code rework reduced the block size making it particularly
vulnerable to this issue, but the issue was always there and can be
triggered regardless of the block size.
This patch does two things:
1) the hashing has been reworked to offer a better distribution to
atenuate the problem a bit, and
2) a limit is imposed to the number of entries that can exist in the
same hash bucket.
Because of the above the code is a bit more expensive on average, but
the problematic samples used to diagnoze the issue are now orders of
magnitude less expensive to process with only a slight loss in
compression.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Indexing based on adler32 has a match precision based on the block size
(currently 16). Lowering the block size would produce smaller deltas
but the indexing memory and computing cost increases significantly.
For optimal delta result the indexing block size should be 3 with an
increment of 1 (instead of 16 and 16). With such low params the adler32
becomes a clear overhead increasing the time for git-repack by a factor
of 3. And with such small blocks the adler 32 is not very useful as the
whole of the block bits can be used directly.
This patch replaces the adler32 with an open coded index value based on
3 characters directly. This gives sufficient bits for hashing and
allows for optimal delta with reasonable CPU cycles.
The resulting packs are 6% smaller on average. The increase in CPU time
is about 25%. But this cost is now hidden by the delta reuse patch
while the saving on data transfers is always there.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsserver: Eclipse compat -- now "compare with latest from HEAD" works
The Eclipse client uses cvs update when that menu option is triggered.
And doesn't like the standard cvs update response. Give it *exactly* what
it wants.
And hope the other clients don't lose the plot too badly.