The --attach patch to git-format-patch to attach patches instead of
inlining them. Some mailers linewrap inlined patches (eg. Mozilla).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Entries may be added to the config file as follows:
[format]
headers = "Organization: CodeWeavers\nTo: wine-patches
<wine-patches@winehq.org>\n"
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commit 604c86d15b changed the
original "diff -u0" to "diff -u -U 0" for portability.
A big mistake without proper testing.
The form "diff -u -U 0" shows the default 3-line contexts,
because -u and -U 0 contradicts with each other; "diff -U 0" (or
its longhand "diff --unified=0") is what we meant.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just I am old fashioned. Source inclusion in bourne shell is
"." (dot), not "source" -- that's csh.
[jc: yes I know bash groks it, but I am old fashioned.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This rewrites the result check code a bit. The earlier one
using awk was splitting columns at any whitespace, which
confused lines attributed incorrectly to the merge made by the
default author "A U Thor <author@example.com>" with lines
attributed to author "A".
The latest test by Ryan to add the "starting from older commit"
test is also included, with another older commit test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a bug fix, and cleans up one or two other things spotted during the
course of tracking down the main bug here.
[jc: the part that updates test-suite is split out to the next
one. Also I dropped "use Data::Dumper;" which seemed leftover
from debugging session.]
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier they showed gmtime and timezone, which was inconsistent
with the way our commits and tags are pretty-printed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The default output mode is slightly different from git-annotate's.
However, git-annotate's output mode can be obtained by using the
'-c' flag.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pair up git-add and git-rm by adding a 'see also' section that
references the opposite command to each of their documentation files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
... and stripped trailing whitespace to appease the Gods...
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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).
Here is the way I made this commit:
(1) Inspect "gitk --no-merges --parents master..next"
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:
cfcbd3427e cvsserver
c436eb8cf1 diff-delta
38fd0721d0 diff-delta
f0bcd511ee cvsserver
2b8d9347aa diff-delta
(3) Shorten the list by finding independent ones from the
above.
$ git show-branch --independent $the $above $tips
cfcbd3427ec436eb8cf1
(4) Checkout "master" and cauterize them with "ours" strategy:
$ git merge -s ours "`cat $this-file`" HEAD cfcbd3 c436eb
If `git-append-signed-off-by' is non-nil, automatically append a
sign-off line to the log message when editing it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update .gitignore files in the status list as they are created or
modified.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also set the list-buffers-directory variable for nicer buffer list
display.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
* 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>
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>