Fixed octal constants for XEmacs.
Added highlighting support in log-edit buffer for Emacs CVS.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a companion patch to the previous fix to diffcore-rename.
The merging-back process should use a logic similar to what is used
there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a companion patch to e29e1147e4
which made diffcore similarity estimator independent from the packfile
deltifier. There is no reason for us to be counting the xdelta anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 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
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver now knows how to do the pserver auth chat when the user
is anonymous. To get it to work, add a line to your inetd.conf like
cvspserver stream tcp nowait nobody git-cvsserver pserver
(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.
We now have different error messages when the repo is not found vs repo is
not configured to allow gitcvs. Should help users during initial checkouts.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes two bugs introduced when we switched to generic tree
traversal code.
(1) directory mode recorded silently became 0755, not 0777
(2) if passed a tree object (not a commit), it emitted an
alarming error message (but proceeded anyway).
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 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/*
C programmers are well used to counting from zero, but every
other text file tool starts counting from 1.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
--no-signed-off-cc is still supported, for backwards compatibility
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I ended up using GIT_SVN_ID far more than I ever thought I
would. Typing less is good.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
Syntax is compatible with git-svnimport and git-cvsimport:
normalperson = Eric Wong <normalperson@yhbt.net>
If this option is specified and git-svn encounters an SVN
committer name that it cannot parse, it git-svn will abort.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
* 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>
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>
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>
In our last update to use the encoding while showing the commit
diff we added a new argument to this function. But we missed
updating all the callers.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some versions of sed lack the "-i" option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we decide to use refs/remotes/, having a convenient way to
list them would be nice.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* '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.
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:
Unsorted:
603.12 real 16.89 user 42.88 sys
Sorted:
298.19 real 26.37 user 42.42 sys
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.
This simplifies things a lot.
Signed-off-by: Junio C Hamano <junkio@cox.net>
