git-mv: fix moves into a subdir from outside
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>
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>
send-email: accept --no-signed-off-by-cc as the documentation states
--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>
--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>
contrib/git-svn: better documenting of CLI switches
Also, fix a asciidoc formatting error
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, fix a asciidoc formatting error
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: add --id/-i=$GIT_SVN_ID command-line switch
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>
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>
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>
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>
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: cleanup option parsing
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: allow --authors-file to be specified
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>
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>
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>
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>
* 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>
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>
Prevent --index-info from ignoring -z.
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>
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>
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>
gitview: pass the missing argument _show_clicked_cb.
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>
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>
Fix test case for some sed
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>
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>
git-branch: add -r switch to list refs/remotes/*
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>
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: fix checkouts with -d <somedir>
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.
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:
Unsorted:
603.12 real 16.89 user 42.88 sys
Sorted:
298.19 real 26.37 user 42.42 sys
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
git-commit: make sure we protect against races.
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-commit --amend
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
but can be used to amend a merge commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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
but can be used to amend a merge commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
show-branch --topics
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 show-branch --topics master topic1 topic2 ...
shows an (almost) equivalent of
$ git rev-list ^master topic1 topic2 ...
The major differences are that (1) you can tell which commits
are on which branch, and (2) the commit at the fork point is
shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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 show-branch --topics master topic1 topic2 ...
shows an (almost) equivalent of
$ git rev-list ^master topic1 topic2 ...
The major differences are that (1) you can tell which commits
are on which branch, and (2) the commit at the fork point is
shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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".
Signed-off-by: Junio C Hamano <junkio@cox.net>
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".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'ml/cvsserver'
* ml/cvsserver:
cvsserver: Eclipse compat -- now "compare with latest from HEAD" works
cvsserver: Checkout correctly on Eclipse
* ml/cvsserver:
cvsserver: Eclipse compat -- now "compare with latest from HEAD" works
cvsserver: Checkout correctly on Eclipse
annotate: resurrect raw timestamps.
For scripted use this is quite useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For scripted use this is quite useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: rev-list --objects-edge
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: read-tree --aggressive
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
war on whitespaces: documentation.
We were missing the --whitespace option in the usage string for
git-apply and git-am, so this commit adds them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We were missing the --whitespace option in the usage string for
git-apply and git-am, so this commit adds them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
Merge branch 'maint'
* maint:
read-tree --aggressive: remove deleted entry from the working tree.
* maint:
read-tree --aggressive: remove deleted entry from the working tree.
read-tree --aggressive: remove deleted entry from the working tree.
When both heads deleted, or our side deleted while the other
side did not touch, we did not have to update the working tree.
However, we forgot to remove existing working tree file when we
did not touch and the other side did.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When both heads deleted, or our side deleted while the other
side did not touch, we did not have to update the working tree.
However, we forgot to remove existing working tree file when we
did not touch and the other side did.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'jc/tag'
* jc/tag:
Pretty-print tagger dates.
* jc/tag:
Pretty-print tagger dates.
Merge part of 'jc/diff'
Merge branch 'kh/svnimport'
* kh/svnimport:
Save username -> Full Name <email@addr.es> map file
* kh/svnimport:
Save username -> Full Name <email@addr.es> map file
Merge branch 'js/refs'
* js/refs:
Warn about invalid refs
* js/refs:
Warn about invalid refs
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
annotate: fix -S parameter to take a string
In the conversion to Getopt::Long, the -S / --rev-list parameter stopped
working. We need to tell Getopt::Long that it is a string.
As a bonus, the open() now does some useful error handling.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the conversion to Getopt::Long, the -S / --rev-list parameter stopped
working. We need to tell Getopt::Long that it is a string.
As a bonus, the open() now does some useful error handling.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
annotate: Add a basic set of test cases.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
annotate: handle \No newline at end of file.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitview: Use horizontal scroll bar in the tree view
Earlier we set up the window to never scroll
horizontally, which made it harder to use on a narrow screen.
This patch allows scrollbar to be used as needed by Gtk
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we set up the window to never scroll
horizontally, which made it harder to use on a narrow screen.
This patch allows scrollbar to be used as needed by Gtk
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsserver: Checkout correctly on Eclipse
Initial checkouts were failing to create Entries files under Eclipse.
Eclipse was waiting for two non-standard directory-resets to prepare for a new
directory from the server.
This patch is tricky, because the same directory resets tend to confuse other
clients. It's taken a bit of fiddling to get the commandline cvs client and
Eclipse to get a good, clean checkout.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Initial checkouts were failing to create Entries files under Eclipse.
Eclipse was waiting for two non-standard directory-resets to prepare for a new
directory from the server.
This patch is tricky, because the same directory resets tend to confuse other
clients. It's taken a bit of fiddling to get the commandline cvs client and
Eclipse to get a good, clean checkout.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Re-fix compilation warnings.
Commit 8fcf1ad9c68e15d881194c8544e7c11d33529c2b has a
combination of double cast and Andreas' switch to using
unsigned long ... just the latter is sufficient (and a lot less
ugly than using the double cast).
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 8fcf1ad9c68e15d881194c8544e7c11d33529c2b has a
combination of double cast and Andreas' switch to using
unsigned long ... just the latter is sufficient (and a lot less
ugly than using the double cast).
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Up to date with GIT 1.2.4 fixes
Pretty-print tagger dates.
We can show commit objects with human readable dates using
various --pretty options, but there was no way to do so with
tags. This introduces two such ways:
$ git-cat-file -p v1.2.3
shows the tag object with tagger dates in human readable format.
$ git-verify-tag --verbose v1.2.3
uses it to show the contents of the tag object as well as doing
GPG verification.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We can show commit objects with human readable dates using
various --pretty options, but there was no way to do so with
tags. This introduces two such ways:
$ git-cat-file -p v1.2.3
shows the tag object with tagger dates in human readable format.
$ git-verify-tag --verbose v1.2.3
uses it to show the contents of the tag object as well as doing
GPG verification.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'lt/fix-apply' into maint
* lt/fix-apply:
git-am: --whitespace=x option.
git-apply: war on whitespace -- finishing touches.
git-apply --whitespace=nowarn
apply --whitespace: configuration option.
apply: squelch excessive errors and --whitespace=error-all
apply --whitespace fixes and enhancements.
The war on trailing whitespace
* lt/fix-apply:
git-am: --whitespace=x option.
git-apply: war on whitespace -- finishing touches.
git-apply --whitespace=nowarn
apply --whitespace: configuration option.
apply: squelch excessive errors and --whitespace=error-all
apply --whitespace fixes and enhancements.
The war on trailing whitespace
Merge branch 'lt/apply'
* lt/apply:
git-am: --whitespace=x option.
git-apply: war on whitespace -- finishing touches.
git-apply --whitespace=nowarn
apply --whitespace: configuration option.
apply: squelch excessive errors and --whitespace=error-all
apply --whitespace fixes and enhancements.
The war on trailing whitespace
* lt/apply:
git-am: --whitespace=x option.
git-apply: war on whitespace -- finishing touches.
git-apply --whitespace=nowarn
apply --whitespace: configuration option.
apply: squelch excessive errors and --whitespace=error-all
apply --whitespace fixes and enhancements.
The war on trailing whitespace
Merge early parts of 'np/delta' branch
Merge git-mv fixes from 'maint'
git-mv: fixes for path handling
Moving a directory ending in a slash was not working as the
destination was not calculated correctly.
E.g. in the git repo,
git-mv t/ Documentation
gave the error
Error: destination 'Documentation' already exists
To get rid of this problem, strip trailing slashes from all arguments.
The comment in cg-mv made me curious about this issue; Pasky, thanks!
As result, the workaround in cg-mv is not needed any more.
Also, another bug was shown by cg-mv. When moving files outside of
a subdirectory, it typically calls git-mv with something like
git-mv Documentation/git.txt Documentation/../git-mv.txt
which triggers the following error from git-update-index:
Ignoring path Documentation/../git-mv.txt
The result is a moved file, removed from git revisioning, but not
added again. To fix this, the paths have to be normalized not have ".."
in the middle. This was already done in git-mv, but only for
a better visual appearance :(
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Moving a directory ending in a slash was not working as the
destination was not calculated correctly.
E.g. in the git repo,
git-mv t/ Documentation
gave the error
Error: destination 'Documentation' already exists
To get rid of this problem, strip trailing slashes from all arguments.
The comment in cg-mv made me curious about this issue; Pasky, thanks!
As result, the workaround in cg-mv is not needed any more.
Also, another bug was shown by cg-mv. When moving files outside of
a subdirectory, it typically calls git-mv with something like
git-mv Documentation/git.txt Documentation/../git-mv.txt
which triggers the following error from git-update-index:
Ignoring path Documentation/../git-mv.txt
The result is a moved file, removed from git revisioning, but not
added again. To fix this, the paths have to be normalized not have ".."
in the middle. This was already done in git-mv, but only for
a better visual appearance :(
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-mv: Allow -h without repo & fix error message
This fixes "git-mv -h" to output the usage without the need
to be in a git repository.
Additionally:
- fix confusing error message when only one arg was given
- fix typo in error message
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes "git-mv -h" to output the usage without the need
to be in a git repository.
Additionally:
- fix confusing error message when only one arg was given
- fix typo in error message
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow git-mv to accept ./ in paths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 9a0e6731c632c841cd2de9dec0b9091b2f10c6fd commit)
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 9a0e6731c632c841cd2de9dec0b9091b2f10c6fd commit)
combine-diff: Honour -z option correctly.
Combined diffs don't null terminate things in the same way as standard
diffs. This is presumably wrong.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 6baf0484efcd29bb5e58ccd5ea0379481d4a83f4 commit)
Combined diffs don't null terminate things in the same way as standard
diffs. This is presumably wrong.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 6baf0484efcd29bb5e58ccd5ea0379481d4a83f4 commit)
combine-diff: Honour --full-index.
For some reason, combined diffs don't honour the --full-index flag when
emitting patches. Fix this.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from e70c6b35749c316f6e97099bd6bdac895c9d6f68 commit)
For some reason, combined diffs don't honour the --full-index flag when
emitting patches. Fix this.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from e70c6b35749c316f6e97099bd6bdac895c9d6f68 commit)
diffcore-break: micro-optimize by avoiding delta between identical files.
We did not check if we have the same file on both sides when
computing break score. This is usually not a problem, but if
the user said --find-copies-harde with -B, we ended up trying a
delta between the same data even when we know the SHA1 hash of
both sides match.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from aeecd23ae2785a0462d42191974e9d9a8e439fbe commit)
We did not check if we have the same file on both sides when
computing break score. This is usually not a problem, but if
the user said --find-copies-harde with -B, we ended up trying a
delta between the same data even when we know the SHA1 hash of
both sides match.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from aeecd23ae2785a0462d42191974e9d9a8e439fbe commit)
Warn about invalid refs
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsserver: Eclipse compat - browsing 'modules' (heads in our case) works
Eclipse CVS clients have an odd way of perusing the top level of
the repository, by calling update on module "". So reproduce cvs'
odd behaviour in the interest of compatibility.
It makes it much easier to get a checkout when using Eclipse.
Eclipse CVS clients have an odd way of perusing the top level of
the repository, by calling update on module "". So reproduce cvs'
odd behaviour in the interest of compatibility.
It makes it much easier to get a checkout when using Eclipse.
cvsserver: Eclipse compat fixes - implement Questionable, alias rlog, add a space after the U
A few things to satisfy Eclipse's strange habits as a cvs client:
- Implement Questionable
- Aliased rlog to log, but more work may be needed
- Add a space after the U that indicates updated
A few things to satisfy Eclipse's strange habits as a cvs client:
- Implement Questionable
- Aliased rlog to log, but more work may be needed
- Add a space after the U that indicates updated
cvsserver: add notes on how to get a checkout under Eclipse
git-am: --whitespace=x option.
This is passed down to git-apply to override the built-in
default and per-repository configuration at runtime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is passed down to git-apply to override the built-in
default and per-repository configuration at runtime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-am: --whitespace=x option.
This is passed down to git-apply to override the built-in
default and per-repository configuration at runtime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is passed down to git-apply to override the built-in
default and per-repository configuration at runtime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diffcore-rename: split out the delta counting code.
This is to rework diffcore break/rename/copy detection code
so that it does not affected when deltifier code gets improved.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to rework diffcore break/rename/copy detection code
so that it does not affected when deltifier code gets improved.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diffcore-break: micro-optimize by avoiding delta between identical files.
We did not check if we have the same file on both sides when
computing break score. This is usually not a problem, but if
the user said --find-copies-harde with -B, we ended up trying a
delta between the same data even when we know the SHA1 hash of
both sides match.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We did not check if we have the same file on both sides when
computing break score. This is usually not a problem, but if
the user said --find-copies-harde with -B, we ended up trying a
delta between the same data even when we know the SHA1 hash of
both sides match.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Darwin: Ignore missing /sw/lib
When on Darwin platforms don't include Fink or DarwinPorts
into the link path unless the related library directory
is actually present. The linker on MacOS 10.4 complains
if it is given a directory which does not exist.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When on Darwin platforms don't include Fink or DarwinPorts
into the link path unless the related library directory
is actually present. The linker on MacOS 10.4 complains
if it is given a directory which does not exist.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitview: Set the default width of graph cell
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitview: Some window layout changes.
This makes menubar look nice
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes menubar look nice
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
18 years agogitview: Select the text color based on whether the entry in highlighted. Use standar...
gitview: Select the text color based on whether the entry in highlighted. Use standard font.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply: war on whitespace -- finishing touches.
This changes the default --whitespace policy to nowarn when we
are only getting --stat, --summary etc. IOW when not applying
the patch. When applying the patch, the default is warn (spit
out warning message but apply the patch).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the default --whitespace policy to nowarn when we
are only getting --stat, --summary etc. IOW when not applying
the patch. When applying the patch, the default is warn (spit
out warning message but apply the patch).
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply: war on whitespace -- finishing touches.
This changes the default --whitespace policy to nowarn when we
are only getting --stat, --summary etc. IOW when not applying
the patch. When applying the patch, the default is warn (spit
out warning message but apply the patch).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the default --whitespace policy to nowarn when we
are only getting --stat, --summary etc. IOW when not applying
the patch. When applying the patch, the default is warn (spit
out warning message but apply the patch).
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply --whitespace=nowarn
Andrew insists --whitespace=warn should be the default, and I
tend to agree. This introduces --whitespace=warn, so if your
project policy is more lenient, you can squelch them by having
apply.whitespace=nowarn in your configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Andrew insists --whitespace=warn should be the default, and I
tend to agree. This introduces --whitespace=warn, so if your
project policy is more lenient, you can squelch them by having
apply.whitespace=nowarn in your configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
apply --whitespace: configuration option.
The new configuration option apply.whitespace can take one of
"warn", "error", "error-all", or "strip". When git-apply is run
to apply the patch to the index, they are used as the default
value if there is no command line --whitespace option.
Andrew can now tell people who feed him git trees to update to
this version and say:
git repo-config apply.whitespace error
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new configuration option apply.whitespace can take one of
"warn", "error", "error-all", or "strip". When git-apply is run
to apply the patch to the index, they are used as the default
value if there is no command line --whitespace option.
Andrew can now tell people who feed him git trees to update to
this version and say:
git repo-config apply.whitespace error
Signed-off-by: Junio C Hamano <junkio@cox.net>
apply: squelch excessive errors and --whitespace=error-all
This by default makes --whitespace=warn, error, and strip to
warn only the first 5 additions of trailing whitespaces. A new
option --whitespace=error-all can be used to view all of them
before applying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This by default makes --whitespace=warn, error, and strip to
warn only the first 5 additions of trailing whitespaces. A new
option --whitespace=error-all can be used to view all of them
before applying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
apply --whitespace fixes and enhancements.
In addition to fixing obvious command line parsing bugs in the
previous round, this changes the following:
* Adds "--whitespace=strip". This applies after stripping the
new trailing whitespaces introduced to the patch.
* The output error message format is changed to say
"patch-filename:linenumber:contents of the line". This makes
it similar to typical compiler error message format, and
helps C-x ` (next-error) in Emacs compilation buffer.
* --whitespace=error and --whitespace=warn do not stop at the
first error. We might want to limit the output to say first
20 such lines to prevent cluttering, but on the other hand if
you are willing to hand-fix after inspecting them, getting
everything with a single run might be easier to work with.
After all, somebody has to do the clean-up work somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition to fixing obvious command line parsing bugs in the
previous round, this changes the following:
* Adds "--whitespace=strip". This applies after stripping the
new trailing whitespaces introduced to the patch.
* The output error message format is changed to say
"patch-filename:linenumber:contents of the line". This makes
it similar to typical compiler error message format, and
helps C-x ` (next-error) in Emacs compilation buffer.
* --whitespace=error and --whitespace=warn do not stop at the
first error. We might want to limit the output to say first
20 such lines to prevent cluttering, but on the other hand if
you are willing to hand-fix after inspecting them, getting
everything with a single run might be easier to work with.
After all, somebody has to do the clean-up work somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The war on trailing whitespace
On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.
This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.
Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.
Totally untested, of course. But it compiles, so it must be fine.
HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.
I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).
Linus
On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.
This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.
Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.
Totally untested, of course. But it compiles, so it must be fine.
HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.
I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).
Linus
git-apply --whitespace=nowarn
Andrew insists --whitespace=warn should be the default, and I
tend to agree. This introduces --whitespace=warn, so if your
project policy is more lenient, you can squelch them by having
apply.whitespace=nowarn in your configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Andrew insists --whitespace=warn should be the default, and I
tend to agree. This introduces --whitespace=warn, so if your
project policy is more lenient, you can squelch them by having
apply.whitespace=nowarn in your configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge part of kh/svnimport branch into master
contrib/git-svn: correct commit example in manpage
Thanks to Nicolas Vilz <niv@iaglans.de> for noticing this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Thanks to Nicolas Vilz <niv@iaglans.de> for noticing this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Save username -> Full Name <email@addr.es> map file
When the user specifies a username -> Full Name <email@addr.es> map
file with the -A option, save a copy of that file as
$git_dir/svn-authors. When running git-svnimport with an existing GIT
directory, use $git_dir/svn-authors (if it exists) unless a file was
explicitly specified with -A.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the user specifies a username -> Full Name <email@addr.es> map
file with the -A option, save a copy of that file as
$git_dir/svn-authors. When running git-svnimport with an existing GIT
directory, use $git_dir/svn-authors (if it exists) unless a file was
explicitly specified with -A.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let git-svnimport's author file use same syntax as git-cvsimport's
git-cvsimport uses a username => Full Name <email@addr.es> mapping
file with this syntax:
kha=Karl Hasselström <kha@treskal.com>
Since there is no reason to use another format for git-svnimport, use
the same format.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsimport uses a username => Full Name <email@addr.es> mapping
file with this syntax:
kha=Karl Hasselström <kha@treskal.com>
Since there is no reason to use another format for git-svnimport, use
the same format.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
apply --whitespace: configuration option.
The new configuration option apply.whitespace can take one of
"warn", "error", "error-all", or "strip". When git-apply is run
to apply the patch to the index, they are used as the default
value if there is no command line --whitespace option.
Andrew can now tell people who feed him git trees to update to
this version and say:
git repo-config apply.whitespace error
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new configuration option apply.whitespace can take one of
"warn", "error", "error-all", or "strip". When git-apply is run
to apply the patch to the index, they are used as the default
value if there is no command line --whitespace option.
Andrew can now tell people who feed him git trees to update to
this version and say:
git repo-config apply.whitespace error
Signed-off-by: Junio C Hamano <junkio@cox.net>
apply: squelch excessive errors and --whitespace=error-all
This by default makes --whitespace=warn, error, and strip to
warn only the first 5 additions of trailing whitespaces. A new
option --whitespace=error-all can be used to view all of them
before applying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This by default makes --whitespace=warn, error, and strip to
warn only the first 5 additions of trailing whitespaces. A new
option --whitespace=error-all can be used to view all of them
before applying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: tell the user to not modify git-svn-HEAD directly
As a rule, interface branches to different SCMs should never be modified
directly by the user. They are used exclusively for talking to the
foreign SCM.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As a rule, interface branches to different SCMs should never be modified
directly by the user. They are used exclusively for talking to the
foreign SCM.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitview: Remove trailing white space
Do the cleanup using Dave jones vim script
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do the cleanup using Dave jones vim script
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitview: Fix the encoding related bug
Get the encoding information from repository and convert it to utf-8 before
passing to gtk.TextBuffer.set_text. gtk.TextBuffer.set_text work only with utf-8
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Get the encoding information from repository and convert it to utf-8 before
passing to gtk.TextBuffer.set_text. gtk.TextBuffer.set_text work only with utf-8
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-format-patch: Always add a blank line between headers and body.
If the second line of the commit message isn't empty, git-format-patch
needs to add an empty line in order to generate a properly formatted
mail. Otherwise git-rebase drops the rest of the commit message.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the second line of the commit message isn't empty, git-format-patch
needs to add an empty line in order to generate a properly formatted
mail. Otherwise git-rebase drops the rest of the commit message.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: Honour -z option correctly.
Combined diffs don't null terminate things in the same way as standard
diffs. This is presumably wrong.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Combined diffs don't null terminate things in the same way as standard
diffs. This is presumably wrong.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
combine-diff: Honour --full-index.
For some reason, combined diffs don't honour the --full-index flag when
emitting patches. Fix this.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For some reason, combined diffs don't honour the --full-index flag when
emitting patches. Fix this.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
apply --whitespace fixes and enhancements.
In addition to fixing obvious command line parsing bugs in the
previous round, this changes the following:
* Adds "--whitespace=strip". This applies after stripping the
new trailing whitespaces introduced to the patch.
* The output error message format is changed to say
"patch-filename:linenumber:contents of the line". This makes
it similar to typical compiler error message format, and
helps C-x ` (next-error) in Emacs compilation buffer.
* --whitespace=error and --whitespace=warn do not stop at the
first error. We might want to limit the output to say first
20 such lines to prevent cluttering, but on the other hand if
you are willing to hand-fix after inspecting them, getting
everything with a single run might be easier to work with.
After all, somebody has to do the clean-up work somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition to fixing obvious command line parsing bugs in the
previous round, this changes the following:
* Adds "--whitespace=strip". This applies after stripping the
new trailing whitespaces introduced to the patch.
* The output error message format is changed to say
"patch-filename:linenumber:contents of the line". This makes
it similar to typical compiler error message format, and
helps C-x ` (next-error) in Emacs compilation buffer.
* --whitespace=error and --whitespace=warn do not stop at the
first error. We might want to limit the output to say first
20 such lines to prevent cluttering, but on the other hand if
you are willing to hand-fix after inspecting them, getting
everything with a single run might be easier to work with.
After all, somebody has to do the clean-up work somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The war on trailing whitespace
On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.
This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.
Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.
Totally untested, of course. But it compiles, so it must be fine.
HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.
I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).
Linus
On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.
This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.
Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.
Totally untested, of course. But it compiles, so it must be fine.
HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.
I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).
Linus
svnimport: Read author names and emails from a file
Read a file with lines on the form
username User's Full Name <email@addres.org>
and use "User's Full Name <email@addres.org>" as the GIT author and
committer for Subversion commits made by "username". If encountering a
commit made by a user not in the list, abort.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Read a file with lines on the form
username User's Full Name <email@addres.org>
and use "User's Full Name <email@addres.org>" as the GIT author and
committer for Subversion commits made by "username". If encountering a
commit made by a user not in the list, abort.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
svnimport: Convert the svn:ignore property
Put the value of the svn:ignore property in a regular file when
converting a Subversion repository to GIT. The Subversion and GIT
ignore syntaxes are similar enough that it often just works to set the
filename to .gitignore and do nothing else.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Put the value of the svn:ignore property in a regular file when
converting a Subversion repository to GIT. The Subversion and GIT
ignore syntaxes are similar enough that it often just works to set the
filename to .gitignore and do nothing else.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
svnimport: Convert executable flag
Convert the svn:executable property to file mode 755 when converting
an SVN repository to GIT.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Convert the svn:executable property to file mode 755 when converting
an SVN repository to GIT.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
svnimport: Mention -r in usage summary
I added the -r option to git-svnimport some time ago, but forgot to
update the usage summary in the documentation.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I added the -r option to git-svnimport some time ago, but forgot to
update the usage summary in the documentation.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git diff-generation use a simpler spawn-like interface
Instead of depending of fork() and execve() and doing things in between
the two, make the git diff functions do everything up front, and then do
a single "spawn_prog()" invocation to run the actual external diff
program (if any is even needed).
This actually ends up simplifying the code, and should make it much
easier to make it efficient under broken operating systems (read: Windows).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of depending of fork() and execve() and doing things in between
the two, make the git diff functions do everything up front, and then do
a single "spawn_prog()" invocation to run the actual external diff
program (if any is even needed).
This actually ends up simplifying the code, and should make it much
easier to make it efficient under broken operating systems (read: Windows).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merge branch 'maint'
* maint:
sample hooks template.
* maint:
sample hooks template.
sample hooks template.
These two sample hooks try to detect and use the corresponding
commit hook from the same repository. However, they forgot to
set up GIT_DIR for their own use, so was not in effect.
Signed-off-by: Junio C Hamano <junkio@cox.net>
These two sample hooks try to detect and use the corresponding
commit hook from the same repository. However, they forgot to
set up GIT_DIR for their own use, so was not in effect.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach the "git" command to handle some commands internally
This is another patch in the "prepare to do more in C" series, where the
git wrapper command is taught about the notion of handling some
functionality internally.
Right now, the only internal commands are "version" and "help", but the
point being that we can now easily extend it to handle some of the trivial
scripts internally. Things like "git log" and "git diff" wouldn't need
separate external scripts any more.
This also implies that to support the old "git-log" and "git-diff" syntax,
the "git" wrapper now automatically looks at the name it was executed as,
and if it is "git-xxxx", it will assume that it is to internally do what
"git xxxx" would do.
In other words, you can (once you implement an internal command) soft- or
hard-link that command to the "git" wrapper command, and it will do the
right thing, whether you use the "git xxxx" or the "git-xxxx" format.
There's one other change: the search order for external programs is
modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
second entry is the same directory as the git wrapper itself was executed
out of - if we can figure it out from argv[0], of course.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is another patch in the "prepare to do more in C" series, where the
git wrapper command is taught about the notion of handling some
functionality internally.
Right now, the only internal commands are "version" and "help", but the
point being that we can now easily extend it to handle some of the trivial
scripts internally. Things like "git log" and "git diff" wouldn't need
separate external scripts any more.
This also implies that to support the old "git-log" and "git-diff" syntax,
the "git" wrapper now automatically looks at the name it was executed as,
and if it is "git-xxxx", it will assume that it is to internally do what
"git xxxx" would do.
In other words, you can (once you implement an internal command) soft- or
hard-link that command to the "git" wrapper command, and it will do the
right thing, whether you use the "git xxxx" or the "git-xxxx" format.
There's one other change: the search order for external programs is
modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
second entry is the same directory as the git wrapper itself was executed
out of - if we can figure it out from argv[0], of course.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use setenv(), fix warnings
- Fix -Wundef -Wold-style-definition warnings
- Make pll_free() static
[jc: original patch by Timo had another unrelated bits:
- Use setenv() instead of putenv()
I'm postponing that part for now.]
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Fix -Wundef -Wold-style-definition warnings
- Make pll_free() static
[jc: original patch by Timo had another unrelated bits:
- Use setenv() instead of putenv()
I'm postponing that part for now.]
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: version 0.10.0
New features deserve an increment of the minor version. This will very
likely become 1.0.0 unless release-critical bugs are found.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
New features deserve an increment of the minor version. This will very
likely become 1.0.0 unless release-critical bugs are found.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: optimize sequential commits to svn
Avoid running 'svn up' to a previous revision if we know the
revision we just committed is the first descendant of the
revision we came from.
This reduces the time to do a series of commits by about 25%.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Avoid running 'svn up' to a previous revision if we know the
revision we just committed is the first descendant of the
revision we came from.
This reduces the time to do a series of commits by about 25%.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn: add show-ignore command
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to the
$GIT_DIR/info/exclude file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to the
$GIT_DIR/info/exclude file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
annotate: Use qx{} for pipes on activestate.
Note: This needs someone to tell me what the value of $^O is on ActiveState.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Note: This needs someone to tell me what the value of $^O is on ActiveState.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>