* [PATCH] Documentation: git-format-patch.txt rewordings and cleanups
From: Stephen Boyd @ 2009-03-23 10:21 UTC (permalink / raw)
To: git
Clarify --no-binary description using some words from the original
commit 37c22a4b (add --no-binary, 2008-05-9). Cleanup --suffix and
--thread descriptions. Add --thread style option to synopsis. Clarify
renaming patches example.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Is the synopsis getting too heavy? Maybe it should be changed to:
git format-patch [<options>] [<common diff options>] [<revision range>]
Documentation/git-format-patch.txt | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..f31098b 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,9 +9,9 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
-'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
+'git format-patch' [-k] [-o <dir> | --stdout] [--thread[=<style>]]
[--attach[=<boundary>] | --inline[=<boundary>] |
- [--no-attach]]
+ --no-attach]
[-s | --signoff] [<common diff options>]
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
@@ -132,9 +132,9 @@ include::diff-options.txt[]
the Message-Id header to reference.
+
The optional <style> argument can be either `shallow` or `deep`.
-'Shallow' threading makes every mail a reply to the head of the
+'shallow' threading makes every mail a reply to the head of the
series, where the head is chosen from the cover letter, the
-`\--in-reply-to`, and the first patch mail, in this order. 'Deep'
+`\--in-reply-to`, and the first patch mail, in this order. 'deep'
threading makes every mail a reply to the previous one. If not
specified, defaults to the 'format.thread' configuration, or `shallow`
if that is not set.
@@ -169,24 +169,24 @@ if that is not set.
--suffix=.<sfx>::
Instead of using `.patch` as the suffix for generated
filenames, use specified suffix. A common alternative is
- `--suffix=.txt`.
+ `--suffix=.txt`. Leaving this empty will remove the `.patch`
+ suffix.
+
-Note that you would need to include the leading dot `.` if you
-want a filename like `0001-description-of-my-change.patch`, and
-the first letter does not have to be a dot. Leaving it empty would
-not add any suffix.
+Note the first letter is not required to be a dot, you will need to
+include the leading dot `.` if you want a filename like
+`0001-description-of-my-change.patch`.
--no-binary::
- Don't output contents of changes in binary files, just take note
- that they differ. Note that this disable the patch to be properly
- applied. By default the contents of changes in those files are
- encoded in the patch.
+ Do not output contents of changes in binary files, instead
+ display a notice that those files changed. Patches generated
+ using this option cannot be applied properly, but they are
+ still useful for code review.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message
-in the repository configuration, new defaults for the subject prefix
-and file suffix, control attachements, and number patches when outputting
+in the repository configuration, defaults for the subject prefix
+and file suffix, configure attachments, and number patches when outputting
more than one.
------------
@@ -234,8 +234,8 @@ $ git format-patch -M -B origin
+
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
-the amount of text output, and generally makes it easier to review it.
-Note that the "patch" program does not understand renaming patches, so
+the amount of text output, and generally makes it easier to review.
+Note that non-git "patch" programs won't understand renaming patches, so
use it only when you know the recipient uses git to apply your patch.
* Extract three topmost commits from the current branch and format them
--
1.6.2
^ permalink raw reply related
* Re: git repack: --depth=100000 causing larger not smaler pack file?
From: Mike Ralphson @ 2009-03-23 10:20 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: Nicolas Pitre, git
In-Reply-To: <86y6uwzgzo.fsf@broadpark.no>
2009/3/23 Kjetil Barvik <barvik@broadpark.no>:
> PS! I have the following in my $HOME/.gitconfig file:
>
> [repack]
> UseDeltaBaseOffset = true
> [gc]
> auto = 25
> autopacklimit = 1
Just an aside, but from my reading of how it works, there's very
little point in setting gc.auto to anything less than 257 and
statistically it won't kick in predictably unless set quite a bit
higher (say an order of magnitude).
Mike
^ permalink raw reply
* [PATCH] difftool: add support for an extended revision syntax
From: David Aguilar @ 2009-03-23 10:15 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
This adds an extended revision syntax to git-difftool.
Users often ask "how do I compare a file against its
previous version" and the answer is typically a combination
of 'git log <file>' and 'git difftool <sha1> <sha1> <file>'.
This makes answering that question considerably easier.
Users can now simply say:
$ git difftool <file>~
to compare <file> in the worktree against its
previous version, and:
$ git difftool <file>~2 <file>~
to compare <file> from 2 versions ago to <file>'s
previous version, etc.
The extended revision syntax also expands revisions
that are suffixed with '!' as a convenient way to
see commit diffs. Specifying only '!' is equivalent
to specifying 'HEAD!'.
This makes the following statements equivalent:
$ git difftool !
$ git difftool HEAD!
$ git difftool HEAD~ HEAD
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This patch is based on top of the "add tests to difftool"
patch which itself is based upon the "move difftool out of contrib"
patch currently in the "pu" and "da/difftool" branches.
This feature is incredibly useful but it also adds a brand new
way of specifying revisions that is only understood by git-difftool.
This was specifically asked for by a git-difftool user
who was disapointed to learn that they had to dig through
git-log just to use git-difftool effectively.
I do not think git-diff should know anything about the
"extended revision syntax" which is why this behavior
is best suited for a porcelain such as difftool.
I can imagine that 'file~' would be a useful construct
in core git, but changing the plumbing just for something
like that seems both daunting and misguided.
Some of the conditional expressions were modified to match
the style used in git-add--interactive.perl. I can split
this patch into two if needed, but I figured they were
trivial and didn't warrant a separate patch.
I had to escape some tilde characters in the documentation
because asciidoc kept generating invalid html when the
{tilde} notation was used within single quotes multiple times.
In case anyone asks, git-diff understands this new syntax too
(though we did have to twist its arm ;))
$ git config alias.ddiff 'difftool --no-ext-diff'
$ git ddiff Makefile~
Any thoughts on whether adding this syntax to git-diff/rev-parse
would be feasible/sane/worth it?
Documentation/git-difftool.txt | 55 ++++++++++++++++++-
git-difftool.perl | 119 ++++++++++++++++++++++++++++++++++++++--
t/t7800-difftool.sh | 43 ++++++++++++++
3 files changed, 210 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 5ae02f8..2911b84 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -7,7 +7,9 @@ git-difftool - Show changes using common diff tools
SYNOPSIS
--------
-'git difftool' [--tool=<tool>] [--no-prompt] [<'git diff' options>]
+'git difftool' [--tool=<tool>] [--no-prompt]
+ [<'git diff' options>]
+ [<extended revision syntax>]
DESCRIPTION
-----------
@@ -54,6 +56,57 @@ with custom merge tool commands and has the same value as `$LOCAL`.
See linkgit:git-diff[1] for the full list of supported options.
+EXTENDED REVISION SYNTAX
+------------------------
+'git-difftool' understands an extended syntax for specifying revisions.
+
+* A suffix '{tilde}' to a file means the previous commit that touched file.
+
+* A suffix '{tilde}<n>' to a file means the <n>th previous commit that
+touched file. E.g. 'file\~3' is equivalent to 'file\~\~\~'.
+
+* A revision suffixed with an exclamation mark '!' expands to
+'revision\~..revision', i.e. the commit diff for that revision.
+
+'git-difftool' recognizes this syntax and passes the corresponding
+commits to 'git-diff'.
+
+Examples
+~~~~~~~~
+
+---------------------------------------------------
+# File Revision Specifiers
+$ git difftool Makefile~2 <1>
+$ git difftool Makefile~4 Makefile~2 <2>
+$ git difftool Makefile~~~~ Makefile~~ <3>
+
+# Commit Diff Specifiers
+$ git difftool origin/next~! <4>
+$ git difftool HEAD! <5>
+$ git difftool ! <6>
+---------------------------------------------------
+
+<1> compare 'Makefile' in the worktree against 'Makefile'
+as it existed two `versions` ago. `Versions` here means
+"changes to Makefile" such that only commits that touch
+'Makefile' are considered when finding commits.
+
+<2> compare 'Makefile' as it existed four versions ago to
+'Makefile' as it existed two versions ago.
+
+<3> equivalent to example 2 and illustrates what happens when
+multiple '{tilde}' characters are used.
+
+<4> show the commit diff for 'origin/next\~'.
+Specifying '!' expands 'origin/next\~' to
+'origin/next\~\~..origin/next\~'.
+
+<5> show the commit diff for the most recent commit.
+'HEAD!' is equivalent to 'HEAD\~..HEAD'.
+
+<6> '!' is a shorthand for 'HEAD!' and is equivalent to example 5.
+
+
CONFIG VARIABLES
----------------
'git-difftool' falls back to 'git-mergetool' config variables when the
diff --git a/git-difftool.perl b/git-difftool.perl
index 0deda3a..4845f9b 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -12,13 +12,17 @@ use warnings;
use Cwd qw(abs_path);
use File::Basename qw(dirname);
+binmode(STDOUT, ":raw");
+
my $DIR = abs_path(dirname($0));
sub usage
{
print << 'USAGE';
-usage: git difftool [--tool=<tool>] [--no-prompt] ["git diff" options]
+usage: git difftool [--tool=<tool>] [--no-prompt]
+ [<'git diff' options>]
+ [<extended revision specifier>]
USAGE
exit 1;
}
@@ -33,12 +37,18 @@ sub setup_environment
sub exe
{
my $exe = shift;
- return defined $ENV{COMSPEC} ? "$exe.exe" : $exe;
+ if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ return "$exe.exe";
+ }
+ return $exe;
}
sub generate_command
{
+ # Generate a git-diff command line and set environment
+ # variables recognized by git-difftool-helper
my @command = (exe('git'), 'diff');
+ my @args = ();
my $skip_next = 0;
my $idx = -1;
for my $arg (@ARGV) {
@@ -47,7 +57,7 @@ sub generate_command
$skip_next = 0;
next;
}
- if ($arg eq '-t' or $arg eq '--tool') {
+ if ($arg eq '-t' || $arg eq '--tool') {
usage() if $#ARGV <= $idx;
$ENV{GIT_DIFF_TOOL} = $ARGV[$idx + 1];
$skip_next = 1;
@@ -61,12 +71,109 @@ sub generate_command
$ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
next;
}
- if ($arg eq '-h' or $arg eq '--help') {
+ if ($arg eq '-h' || $arg eq '--help') {
usage();
}
- push @command, $arg;
+ push @args, $arg;
+ }
+ return (@command, interpolate_args(@args));
+}
+
+
+sub interpolate_args
+{
+ # Interpolates arguments that should be expanded out to
+ # corresponding commits, e.g. 'file~3' or 'master!'.
+ my @args = @_;
+ my $file = undef;
+ my @command = ();
+ for my $arg (@args) {
+ if (defined $file && $arg eq $file) {
+ # This allows 'git difftool file~ file'
+ next;
+ }
+ if ($arg =~ /^(.+?)(~+\d*)$/) {
+ # This arg might be a file-revision specifier
+ my $cur_file = $1;
+ my $rev_spec = $2;
+ if (defined $file && $file ne $cur_file) {
+ # We don't currently support comparing
+ # file~ to other_file~
+ usage();
+ }
+ if (!-e $cur_file) {
+ # This arg is a revision parameter and should
+ # be passed along to git-diff as-is
+ push @command, $arg;
+ next;
+ }
+ # This arg is a file-revision specifier so find the
+ # corresponding commits
+ $file = $cur_file;
+ push @command,
+ find_commit_for_file($cur_file, $rev_spec);
+ }
+ elsif ($arg =~ /^(.*?)!$/) {
+ # Expand 'sha1!' to 'sha1~ sha1'
+ my $head = $1;
+ if (length($head) == 0) {
+ # Expand '!' to 'HEAD~ HEAD'
+ $head = 'HEAD';
+ }
+ push @command, $head.'~';
+ push @command, $head;
+ }
+ else {
+ # This is a regular arg so just pass it along
+ push @command, $arg;
+ }
+ }
+ if (defined $file) {
+ # We're using a 'file~' revision specifier so
+ # automatically limit git-diff to just a single file
+ $ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
+ push @command, '--', $file;
+ }
+ return @command;
+}
+
+sub find_commit_for_file
+{
+ # Searches back in $file's history according to $rev_spec
+ # and finds the corresponding commits.
+ # $rev_spec usually looks like '~' or '~2'.
+ my ($file, $rev_spec) = @_;
+ my $num = 0;
+ if ($rev_spec =~ /^(~+)(\d+)$/) {
+ $num = length($1);
+ $num += $2;
+ }
+ else {
+ $num = 1;
+ $num += length($rev_spec);
+ }
+ my @cmd = (exe('git'), 'log');
+ my @opts = ('--reverse', '--pretty=format:%H', '--max-count='.$num);
+ my @args = ('--', $file);
+ return read_first_line(@cmd, @opts, @args);
+}
+
+sub read_first_line
+{
+ # Runs a command in a child process and returns the first line
+ my @command = @_;
+ my $pid = open(CHILD, '-|');
+ if ($pid) {
+ # Grab the first line and loop over stdout until we're done
+ my $line = <CHILD>;
+ while(<CHILD>) {};
+ close(CHILD);
+ chomp $line;
+ return $line;
+ } else {
+ # Execute the command and pipe output to our parent
+ exec(@command) or exit 1;
}
- return @command
}
setup_environment();
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index c7cd2b1..88af30a 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -136,4 +136,47 @@ test_expect_success 'difftool + mergetool config variables' '
restore_test_defaults
'
+test_expect_success 'extended file revision syntax' '
+ git checkout branch &&
+
+ diff=$(git difftool file~) &&
+ test "$diff" = "master" &&
+
+ diff=$(git difftool file~ file) &&
+ test "$diff" = "master" &&
+
+ echo branch 2 >file &&
+ git commit -a -m "branch changes again" &&
+
+ diff=$(git difftool file~~ file) &&
+ test "$diff" = "master" &&
+
+ diff=$(git difftool file~2 file) &&
+ test "$diff" = "master" &&
+
+ git reset --hard HEAD~ &&
+ git checkout master
+'
+
+test_expect_success 'extended commit-ish revision syntax' '
+ git checkout branch &&
+
+ diff=$(git difftool --no-prompt HEAD!) &&
+ test "$diff" = "master" &&
+
+ diff=$(git difftool --no-prompt !) &&
+ test "$diff" = "master" &&
+
+ echo branch again >file &&
+ git commit -a -m "branch again" &&
+ git checkout master &&
+
+ diff=$(git difftool --no-prompt branch!) &&
+ test "$diff" = "branch" &&
+
+ git checkout branch &&
+ git reset --hard HEAD~ &&
+ git checkout master
+'
+
test_done
--
1.6.2.1.303.g63699
^ permalink raw reply related
* Re: git repack: --depth=100000 causing larger not smaler pack file?
From: Kjetil Barvik @ 2009-03-23 10:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0903171608080.30483@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 17 Mar 2009, Kjetil Barvik wrote:
>
>> aloha!
>>
>> Yesterday I run the following command on the updated GIT respository:
>>
>> git repack -adf --window=250000 --depth=100000
>>
>> After 280 minutes or so it finished, but the strange thing was that
>> the resulting pack-file was larger than before. I had expected that
>> it should be smaler, or at least the same size as before.
[snip]
>> I can think of one thing which is spesial with the "--depth=100000"
>> number, and that is that it is now larger than the total number of
>> objects in the pack, which is around 96000 to 97000, or so.
>
> No, the depth should have zero negative influence on the pack size.
> For tight compression, the larger the better. What this will impact
> though is runtime access to the pack data afterward. The deeper a
> given object is, the slower its access will be. But since the object
> recency order tend to put newer objects at the top of a delta chain,
> this should impact older objects more than recent ones.
I have done some more tests, and have copied the whole git/ directory
to a new directory (such that I do not accidentally add or delete any
objects/commits), and have made the following table:
All pack file sizes, F, below was computed with the following git
command:
git repack -adf --window=250000 --depth=D
D | F | (F - F_prev) / (D - D_prev)
-------|------------|----------------------------
5000 | 19129934 |
10000 | 19128956 | -978 / 5000 = -0.1956
15000 | 19126077 | -2879 / 5000 = -0.5758
20000 | 19126077 | 0 / 5000 = 0
25000 | 19126077 | 0 / 5000 = 0
30000 | 19197575 | 71498 / 5000 = 14.2996
45000 | 19312240 | 114665 / 15000 = 7.6443
60000 | 19560083 | 247843 / 15000 = 16.5229
75000 | 19803043 | 242960 / 15000 = 16.1973
90000 | 19669923 | -133120 / 15000 = -8.8746
95000 | 20463780 | 793857 / 5000 = 155.7714
From the table it seems that you get the smallest pack file (for this
particular repository) when --depth value is somewhere between 15000
and 25000. And, when the --depth value was 95000 the resulting pack
file was (- 20463780 19126077) = 1 337 703 bytes, 1.25 MiB, or 7%
larger than this.
> I doubt there is anything to debug. In this case the window size is
> used to evaluate a threshold slope for matching objects in the delta
> search. What we want is a broader delta tree more than a deep one in
> order to have more deltas with a lower depth limit. Therefore a size
> threshold is applied, based on the object distance in the delta search
> window (see commit c83f032e and the other ones referenced therein).
>
> By providing a big window value, the threshold slope becomes rather flat
> and ineffective, and this changes the delta match outcome. While delta
> selection is based on the uncompressed delta result, the compressed size
> of different deltas with the same size may vary. I suspect you might
> have been unlucky in that regard and this could explain the negative
> effect on the pack size.
From the table above it seems that I have been unlucky with _all_
--depth values above 25000 or so.
Question: is there some low level GIT command I can run to compare 2
pack files to maybe be able to see the reason behind the above table?
Maybe to see some details about how many delta's, how big each are,
total sizes, etc..
-- kjetil
PS! I have the following in my $HOME/.gitconfig file:
[repack]
UseDeltaBaseOffset = true
[gc]
auto = 25
autopacklimit = 1
^ permalink raw reply
* Re: Merge format documented?
From: Johannes Sixt @ 2009-03-23 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Gruenbacher, git
In-Reply-To: <7viqm08ymb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Andreas Gruenbacher <agruen@suse.de> writes:
>
>> On Monday, 23 March 2009 4:50:24 Junio C Hamano wrote:
>>> Andreas Gruenbacher <agruen@suse.de> writes:
>>>> is the format that git normally uses for indicating merge conflicts in
>>>> files (the <<< === >>> markers) documented somewhere? How exactly does
>>>> it differ from the diff3 format (<<< ||| === >>>)? Diff3's -m mode seems
>>>> to come close to what git does, except that git doesn't produce the |||
>>>> section:
>>> It is an imitation of output from "merge" program of RCS suite Paul you
>>> know maintains ;-)
>> So it's the same format except that diff3's ||| section isn't shown. I was
>> wondering if there are any additional tricks.
>
> No additional tricks.
I think there's one additional trick: git moves common parts of the
conflict section outside of the conflict markers, and it even splits the
sections into two if there are common parts between two conflicting lines.
(But that doesn't change how the conflict markers look.)
-- Hannes
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Karl Hasselström @ 2009-03-23 8:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090320161233.28989.82497.stgit@pc1117.cambridge.arm.com>
On 2009-03-20 16:15:45 +0000, Catalin Marinas wrote:
> This patch adds support for checking which patches were already
> merged upstream. This checking is done by trying to reverse-apply
> the patches in the index before pushing them onto the stack. The
> trivial merge cases in Index.merge() are ignored when performing
> this operation otherwise the results could be wrong (e.g. a patch
> adding a hunk and a subsequent patch canceling the previous change
> would both be considered merged).
>
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
> ---
>
> This is in preparation for the updating of the push command where we
> have this functionality (I think we had it for goto as well but was
> lost with the update to stgit.lib). Test cases with --merged are
> already done for the push command, so I haven't added any for goto
> (but I'll push this patch only after push is updated).
Looks good, except for a few things:
> @@ -732,7 +732,7 @@ class Index(RunWithEnv):
> # to use --binary.
> self.apply(self.__repository.diff_tree(tree1, tree2, ['--full-index']),
> quiet)
> - def merge(self, base, ours, theirs, current = None):
> + def merge(self, base, ours, theirs, current = None, check_trivial = True):
> """Use the index (and only the index) to do a 3-way merge of the
> L{Tree}s C{base}, C{ours} and C{theirs}. The merge will either
> succeed (in which case the first half of the return value is
Please update the documentation with your new option. :-)
> @@ -752,12 +752,13 @@ class Index(RunWithEnv):
> assert current == None or isinstance(current, Tree)
>
> # Take care of the really trivial cases.
> - if base == ours:
> - return (theirs, current)
> - if base == theirs:
> - return (ours, current)
> - if ours == theirs:
> - return (ours, current)
> + if check_trivial:
> + if base == ours:
> + return (theirs, current)
> + if base == theirs:
> + return (ours, current)
> + if ours == theirs:
> + return (ours, current)
Uh, what? What's the point of not doing this unconditionally?
> @@ -379,3 +385,25 @@ class StackTransaction(object):
> assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
> self.unapplied = unapplied
> self.hidden = hidden
> +
> + def check_merged(self, patches):
> + """Return a subset of patches already merged."""
> + merged = []
> + temp_index = self.__stack.repository.temp_index()
> + temp_index_tree = None
There's no need to create a new temp index here. The transaction
object already has one.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] difftool: add various git-difftool tests
From: David Aguilar @ 2009-03-23 8:41 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
In-Reply-To: <1237797676-32047-1-git-send-email-davvid@gmail.com>
t7800-difftool.sh tests the various command-line flags,
git-config variables, and environment settings supported by
git-difftool.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7800-difftool.sh | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 139 insertions(+), 0 deletions(-)
create mode 100755 t/t7800-difftool.sh
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
new file mode 100755
index 0000000..c7cd2b1
--- /dev/null
+++ b/t/t7800-difftool.sh
@@ -0,0 +1,139 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 David Aguilar
+#
+
+test_description='git-difftool
+
+Testing basic diff tool invocation
+'
+
+. ./test-lib.sh
+
+remove_config_vars()
+{
+ # Unset all config variables used by git-difftool
+ git config --unset diff.tool
+ git config --unset difftool.test-tool.cmd
+ git config --unset merge.tool
+ git config --unset mergetool.test-tool.cmd
+ return 0
+}
+
+restore_test_defaults()
+{
+ # Restores the test defaults used by several tests
+ remove_config_vars
+ unset GIT_DIFF_TOOL &&
+ unset GIT_MERGE_TOOL &&
+ unset GIT_DIFFTOOL_NO_PROMPT &&
+ git config diff.tool test-tool &&
+ git config difftool.test-tool.cmd "cat \$LOCAL"
+}
+
+# Create a file on master and change it on branch
+test_expect_success 'setup' '
+ echo master >file &&
+ git add file &&
+ git commit -m "added file" &&
+
+ git checkout -b branch master &&
+ echo branch >file &&
+ git commit -a -m "branch changed file" &&
+ git checkout master
+'
+
+# Configure a custom difftool.<tool>.cmd and use it
+test_expect_success 'custom commands' '
+ restore_test_defaults &&
+ git config difftool.test-tool.cmd "cat \$REMOTE" &&
+
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "master" &&
+
+ restore_test_defaults &&
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "branch"
+'
+
+# Ensures that git-difftool ignores bogus --tool values
+test_expect_success 'difftool ignores bad --tool values' '
+ diff=$(git difftool --no-prompt --tool=bogus-tool branch)
+ test "$?" = 1 &&
+ test "$diff" = ""
+'
+
+# Specify the diff tool using $GIT_DIFF_TOOL
+test_expect_success 'GIT_DIFF_TOOL variable' '
+ git config --unset diff.tool &&
+ GIT_DIFF_TOOL=test-tool &&
+ export GIT_DIFF_TOOL &&
+
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# Test the $GIT_*_TOOL variables and ensure
+# that $GIT_DIFF_TOOL always wins unless --tool is specified
+test_expect_success 'GIT_DIFF_TOOL overrides' '
+ git config diff.tool bogus-tool &&
+ git config merge.tool bogus-tool &&
+
+ GIT_MERGE_TOOL=test-tool &&
+ export GIT_MERGE_TOOL &&
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "branch" &&
+ unset GIT_MERGE_TOOL &&
+
+ GIT_MERGE_TOOL=bogus-tool &&
+ GIT_DIFF_TOOL=test-tool &&
+ export GIT_MERGE_TOOL &&
+ export GIT_DIFF_TOOL &&
+
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "branch" &&
+
+ GIT_DIFF_TOOL=bogus-tool &&
+ export GIT_DIFF_TOOL &&
+
+ diff=$(git difftool --no-prompt --tool=test-tool branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# Test that we don't have to pass --no-prompt to difftool
+# when $GIT_DIFFTOOL_NO_PROMPT is true
+test_expect_success 'GIT_DIFFTOOL_NO_PROMPT variable' '
+ GIT_DIFFTOOL_NO_PROMPT=true &&
+ export GIT_DIFFTOOL_NO_PROMPT &&
+
+ diff=$(git difftool branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# git-difftool falls back to git-mergetool config variables
+# so test that behavior here
+test_expect_success 'difftool + mergetool config variables' '
+ remove_config_vars
+ git config merge.tool test-tool &&
+ git config mergetool.test-tool.cmd "cat \$LOCAL" &&
+
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "branch" &&
+
+ # set merge.tool to something bogus, diff.tool to test-tool
+ git config merge.tool bogus-tool &&
+ git config diff.tool test-tool &&
+
+ diff=$(git difftool --no-prompt branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+test_done
--
1.6.2.1.303.g63699
^ permalink raw reply related
* [PATCH] difftool: add git-difftool to the list of commands
From: David Aguilar @ 2009-03-23 8:41 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
Signed-off-by: David Aguilar <davvid@gmail.com>
---
command-list.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/command-list.txt b/command-list.txt
index 3583a33..fb03a2e 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -33,6 +33,7 @@ git-diff mainporcelain common
git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
git-diff-tree plumbinginterrogators
+git-difftool ancillaryinterrogators
git-fast-export ancillarymanipulators
git-fast-import ancillarymanipulators
git-fetch mainporcelain common
--
1.6.2.1.303.g63699
^ permalink raw reply related
* Re: [PATCH] t0060: fix whitespace in "wc -c" invocation
From: Junio C Hamano @ 2009-03-23 8:11 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Mike Ralphson, git
In-Reply-To: <20090323062229.GA5535@coredump.intra.peff.net>
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/7] Clean up interpret_nth_last_branch feature
From: Junio C Hamano @ 2009-03-23 8:10 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> The changes since the previous round are:
>
> - Tightening of the refname rule comes very late in the series, so that
> we can optionally drop it;
>
> - In addition to allowing "git branch -d bad@{name}ref.", we also allow
> "git branch -d bad@{name}ref. good-one" as another escape hatch;
Sorry, the "also allow" one is about renaming, i.e. "branch -m bad. good".
> - Update documentation to git-check-ref-format to describe the tightened
> rules.
>
> Junio C Hamano (7):
> Rename interpret/substitute nth_last_branch functions
> strbuf_branchname(): a wrapper for branch name shorthands
> check-ref-format --branch: give Porcelain a way to grok branch
> shorthand
> Fix branch -m @{-1} newname
> strbuf_check_branch_ref(): a helper to check a refname for a branch
> check_ref_format(): tighten refname rules
> checkout -: make "-" to mean "previous branch" everywhere
>
> Documentation/git-check-ref-format.txt | 18 ++++++++++++++++-
> branch.c | 10 +--------
> builtin-branch.c | 32 +++++++++++++++++-------------
> builtin-check-ref-format.c | 9 ++++++++
> builtin-checkout.c | 26 ++++++++++--------------
> builtin-merge.c | 5 +--
> cache.h | 2 +-
> refs.c | 16 +++++++++++---
> sha1_name.c | 33 ++++++++++++++++++-------------
> strbuf.c | 17 ++++++++++++++++
> strbuf.h | 3 ++
> 11 files changed, 110 insertions(+), 61 deletions(-)
^ permalink raw reply
* Re: [PATCH] remote: improve sorting of "configure for git push" list
From: Junio C Hamano @ 2009-03-23 8:09 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jeff King, Johannes Schindelin, Jay Soffian, Git Mailing List
In-Reply-To: <49C74099.3090806@viscovery.net>
Thanks.
^ permalink raw reply
* Re: Importing Bzr revisions
From: Junio C Hamano @ 2009-03-23 8:06 UTC (permalink / raw)
To: David Reitter; +Cc: git
In-Reply-To: <90DBD254-1810-4B11-AA9F-C5661A028FA5@gmail.com>
David Reitter <david.reitter@gmail.com> writes:
> Suppose I have a bzr branch that has been converted (somehow) to a git
> branch, is it then possible to merge new revisions from the bzr branch
> into the git one?
It entirely depends on how that "somehow" goes.
If that "somehow" procedure performs a reliably reproducible conversion
(i.e. not only it will produce the identical git history when you feed the
same bzr history to the procedure twice, but it will produce the identical
git history followed by new history if you feed the bzr history after new
commits are added to the bzr history), you should be able to re-convert
the updated bzr history to git and merge the result with the result of the
earlier conversion. The re-conversion process may not even have to be a
whole re-conversion; it could be incremental. But that is entirely up to
the quality of the conversion "somehow" procedure implements.
^ permalink raw reply
* [PATCH v2 6/7] check_ref_format(): tighten refname rules
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
This changes the rules for refnames to forbid:
(1) a refname that contains "@{" in it.
Some people and foreign SCM converter may have named their branches
as frotz@24 and we still want to keep supporting it.
However, "git branch frotz@{24}" is a disaster. It cannot even
checked out because "git checkout frotz@{24}" will interpret it as
"detach the HEAD at twenty-fourth reflog entry of the frotz branch".
(2) a refname that ends with a dot.
We already reject a path component that begins with a dot, primarily
to avoid ambiguous range interpretation. If we allowed ".B" as a
valid ref, it is unclear if "A...B" means "in dot-B but not in A" or
"either in A or B but not in both".
But for this to be complete, we need also to forbid "A." to avoid "in
B but not in A-dot". This was not a problem in the original range
notation, but we should have added this restriction when three-dot
notation was introduced.
Unlike "no dot at the beginning of any path component" rule, this
rule does not have to be "no dot at the end of any path component",
because you cannot abbreviate the tail end away, similar to you can
say "dot-B" to mean "refs/heads/dot-B".
For these reasons, it is not likely people created branches with these
names on purpose, but we have allowed such names to be used for quite some
time, and it is possible that people created such branches by mistake or
by accident.
To help people with branches with such unfortunate names to recover,
we still allow "branch -d 'bad.'" to delete such branches, and also allow
"branch -m bad. good" to rename them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-check-ref-format.txt | 6 +++++-
builtin-branch.c | 16 ++++++++++++++--
refs.c | 13 +++++++++----
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 51579f6..58e53cc 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -32,7 +32,9 @@ imposes the following rules on how refs are named:
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
or open bracket `[` anywhere;
-. It cannot end with a slash `/`.
+. It cannot end with a slash `/` nor a dot `.`.
+
+. It cannot contain a sequence `@{`.
These rules makes it easy for shell script based tools to parse
refnames, pathname expansion by the shell when a refname is used
@@ -51,6 +53,8 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
It may also be used to select a specific object such as with
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
+. at-open-brace `@{` is used as a notation to access a reflog entry.
+
With the `--branch` option, it expands a branch name shorthand and
prints the name of the branch the shorthand refers to.
diff --git a/builtin-branch.c b/builtin-branch.c
index afeed68..330e0c3 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -464,12 +464,21 @@ static void rename_branch(const char *oldname, const char *newname, int force)
struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;
unsigned char sha1[20];
struct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;
+ int recovery = 0;
if (!oldname)
die("cannot rename the current branch while not on any.");
- if (strbuf_check_branch_ref(&oldref, oldname))
- die("Invalid branch name: '%s'", oldname);
+ if (strbuf_check_branch_ref(&oldref, oldname)) {
+ /*
+ * Bad name --- this could be an attempt to rename a
+ * ref that we used to allow to be created by accident.
+ */
+ if (resolve_ref(oldref.buf, sha1, 1, NULL))
+ recovery = 1;
+ else
+ die("Invalid branch name: '%s'", oldname);
+ }
if (strbuf_check_branch_ref(&newref, newname))
die("Invalid branch name: '%s'", newname);
@@ -484,6 +493,9 @@ static void rename_branch(const char *oldname, const char *newname, int force)
die("Branch rename failed");
strbuf_release(&logmsg);
+ if (recovery)
+ warning("Renamed a misnamed branch '%s' away", oldref.buf + 11);
+
/* no need to pass logmsg here as HEAD didn't really move */
if (!strcmp(oldname, head) && create_symref("HEAD", newref.buf, NULL))
die("Branch renamed to %s, but HEAD is not updated!", newname);
diff --git a/refs.c b/refs.c
index 8d3c502..e355489 100644
--- a/refs.c
+++ b/refs.c
@@ -693,7 +693,7 @@ static inline int bad_ref_char(int ch)
int check_ref_format(const char *ref)
{
- int ch, level, bad_type;
+ int ch, level, bad_type, last;
int ret = CHECK_REF_FORMAT_OK;
const char *cp = ref;
@@ -717,19 +717,24 @@ int check_ref_format(const char *ref)
return CHECK_REF_FORMAT_ERROR;
}
+ last = ch;
/* scan the rest of the path component */
while ((ch = *cp++) != 0) {
bad_type = bad_ref_char(ch);
- if (bad_type) {
+ if (bad_type)
return CHECK_REF_FORMAT_ERROR;
- }
if (ch == '/')
break;
- if (ch == '.' && *cp == '.')
+ if (last == '.' && ch == '.')
+ return CHECK_REF_FORMAT_ERROR;
+ if (last == '@' && ch == '{')
return CHECK_REF_FORMAT_ERROR;
+ last = ch;
}
level++;
if (!ch) {
+ if (ref <= cp - 2 && cp[-2] == '.')
+ return CHECK_REF_FORMAT_ERROR;
if (level < 2)
return CHECK_REF_FORMAT_ONELEVEL;
return ret;
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 5/7] strbuf_check_branch_ref(): a helper to check a refname for a branch
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
This allows a common calling sequence
strbuf_branchname(&ref, name);
strbuf_splice(&ref, 0, 0, "refs/heads/", 11);
if (check_ref_format(ref.buf))
die(...);
to be refactored into
if (strbuf_check_branch_ref(&ref, name))
die(...);
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 5 +----
builtin-branch.c | 8 ++------
builtin-check-ref-format.c | 5 ++---
builtin-checkout.c | 7 +++----
strbuf.c | 8 ++++++++
strbuf.h | 1 +
6 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/branch.c b/branch.c
index 558f092..62030af 100644
--- a/branch.c
+++ b/branch.c
@@ -135,10 +135,7 @@ void create_branch(const char *head,
struct strbuf ref = STRBUF_INIT;
int forcing = 0;
- strbuf_branchname(&ref, name);
- strbuf_splice(&ref, 0, 0, "refs/heads/", 11);
-
- if (check_ref_format(ref.buf))
+ if (strbuf_check_branch_ref(&ref, name))
die("'%s' is not a valid branch name.", name);
if (resolve_ref(ref.buf, sha1, 1, NULL)) {
diff --git a/builtin-branch.c b/builtin-branch.c
index 0df82bf..afeed68 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -468,14 +468,10 @@ static void rename_branch(const char *oldname, const char *newname, int force)
if (!oldname)
die("cannot rename the current branch while not on any.");
- strbuf_branchname(&oldref, oldname);
- strbuf_splice(&oldref, 0, 0, "refs/heads/", 11);
- if (check_ref_format(oldref.buf))
+ if (strbuf_check_branch_ref(&oldref, oldname))
die("Invalid branch name: '%s'", oldname);
- strbuf_branchname(&newref, newname);
- strbuf_splice(&newref, 0, 0, "refs/heads/", 11);
- if (check_ref_format(newref.buf))
+ if (strbuf_check_branch_ref(&newref, newname))
die("Invalid branch name: '%s'", newname);
if (resolve_ref(newref.buf, sha1, 1, NULL) && !force)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index 39db6cb..f9381e0 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -11,9 +11,8 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
{
if (argc == 3 && !strcmp(argv[1], "--branch")) {
struct strbuf sb = STRBUF_INIT;
- strbuf_branchname(&sb, argv[2]);
- strbuf_splice(&sb, 0, 0, "refs/heads/", 11);
- if (check_ref_format(sb.buf))
+
+ if (strbuf_check_branch_ref(&sb, argv[2]))
die("'%s' is not a valid branch name", argv[2]);
printf("%s\n", sb.buf + 11);
exit(0);
diff --git a/builtin-checkout.c b/builtin-checkout.c
index b268046..66df0c0 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -733,12 +733,11 @@ no_reference:
if (opts.new_branch) {
struct strbuf buf = STRBUF_INIT;
- strbuf_addstr(&buf, "refs/heads/");
- strbuf_addstr(&buf, opts.new_branch);
+ if (strbuf_check_branch_ref(&buf, opts.new_branch))
+ die("git checkout: we do not like '%s' as a branch name.",
+ opts.new_branch);
if (!get_sha1(buf.buf, rev))
die("git checkout: branch %s already exists", opts.new_branch);
- if (check_ref_format(buf.buf))
- die("git checkout: we do not like '%s' as a branch name.", opts.new_branch);
strbuf_release(&buf);
}
diff --git a/strbuf.c b/strbuf.c
index a60b0ad..a884960 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "refs.h"
int prefixcmp(const char *str, const char *prefix)
{
@@ -366,3 +367,10 @@ int strbuf_branchname(struct strbuf *sb, const char *name)
strbuf_add(sb, name, len);
return len;
}
+
+int strbuf_check_branch_ref(struct strbuf *sb, const char *name)
+{
+ strbuf_branchname(sb, name);
+ strbuf_splice(sb, 0, 0, "refs/heads/", 11);
+ return check_ref_format(sb->buf);
+}
diff --git a/strbuf.h b/strbuf.h
index 68923e1..9ee908a 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -132,5 +132,6 @@ extern void stripspace(struct strbuf *buf, int skip_comments);
extern int launch_editor(const char *path, struct strbuf *buffer, const char *const *env);
extern int strbuf_branchname(struct strbuf *sb, const char *name);
+extern int strbuf_check_branch_ref(struct strbuf *sb, const char *name);
#endif /* STRBUF_H */
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 7/7] checkout -: make "-" to mean "previous branch" everywhere
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
This is iffy, in that it teaches the very low level machinery to interpret
it as "the tip of the previous branch" when "-" is fed to it, and has a
high risk of unintended side effects.
This makes "git log ..-" to work as expected, which is marginally useful
because the revision parameter parser misinterprets the other direction
"git log -..". It also makes "git check-ref-format --branch -" to work,
which is not very useful because Porcelains can always ask for @{-1}.
It also makes a refname whose last component is "-" forbidden.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 8 +++++---
refs.c | 3 +++
sha1_name.c | 21 +++++++++++++--------
3 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 66df0c0..6b3b450 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -666,9 +666,11 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
arg = argv[0];
has_dash_dash = (argc > 1) && !strcmp(argv[1], "--");
- if (!strcmp(arg, "-"))
- arg = "@{-1}";
-
+ {
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_branchname(&sb, arg);
+ arg = strbuf_detach(&sb, NULL);
+ }
if (get_sha1(arg, rev)) {
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
diff --git a/refs.c b/refs.c
index e355489..7e27537 100644
--- a/refs.c
+++ b/refs.c
@@ -735,6 +735,9 @@ int check_ref_format(const char *ref)
if (!ch) {
if (ref <= cp - 2 && cp[-2] == '.')
return CHECK_REF_FORMAT_ERROR;
+ if (ref <= cp - 2 && cp[-2] == '-' &&
+ (cp - 3 < ref || cp[-3] == '/'))
+ return CHECK_REF_FORMAT_ERROR;
if (level < 2)
return CHECK_REF_FORMAT_ONELEVEL;
return ret;
diff --git a/sha1_name.c b/sha1_name.c
index 904bcd9..3972f4c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -758,14 +758,19 @@ int interpret_branch_name(const char *name, struct strbuf *buf)
const char *brace;
char *num_end;
- if (name[0] != '@' || name[1] != '{' || name[2] != '-')
- return -1;
- brace = strchr(name, '}');
- if (!brace)
- return -1;
- nth = strtol(name+3, &num_end, 10);
- if (num_end != brace)
- return -1;
+ if (name[0] == '-' && !name[1]) {
+ nth = 1;
+ brace = name; /* "end of branch name expression" */
+ } else {
+ if (name[0] != '@' || name[1] != '{' || name[2] != '-')
+ return -1;
+ brace = strchr(name, '}');
+ if (!brace)
+ return -1;
+ nth = strtol(name+3, &num_end, 10);
+ if (num_end != brace)
+ return -1;
+ }
if (nth <= 0)
return -1;
cb.alloc = nth;
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 4/7] Fix branch -m @{-1} newname
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
The command is supposed to rename the branch we were on before switched
from to a new name, but was not aware of the short-hand notation we added
recently.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 7452db1..0df82bf 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -468,18 +468,18 @@ static void rename_branch(const char *oldname, const char *newname, int force)
if (!oldname)
die("cannot rename the current branch while not on any.");
- strbuf_addf(&oldref, "refs/heads/%s", oldname);
-
+ strbuf_branchname(&oldref, oldname);
+ strbuf_splice(&oldref, 0, 0, "refs/heads/", 11);
if (check_ref_format(oldref.buf))
- die("Invalid branch name: %s", oldref.buf);
-
- strbuf_addf(&newref, "refs/heads/%s", newname);
+ die("Invalid branch name: '%s'", oldname);
+ strbuf_branchname(&newref, newname);
+ strbuf_splice(&newref, 0, 0, "refs/heads/", 11);
if (check_ref_format(newref.buf))
- die("Invalid branch name: %s", newref.buf);
+ die("Invalid branch name: '%s'", newname);
if (resolve_ref(newref.buf, sha1, 1, NULL) && !force)
- die("A branch named '%s' already exists.", newname);
+ die("A branch named '%s' already exists.", newref.buf + 11);
strbuf_addf(&logmsg, "Branch: renamed %s to %s",
oldref.buf, newref.buf);
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 3/7] check-ref-format --branch: give Porcelain a way to grok branch shorthand
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
The command may not be the best place to add this new feature, but
$ git check-ref-format --branch "@{-1}"
allows Porcelains to figure out what branch you were on before the last
branch switching.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-check-ref-format.txt | 12 ++++++++++++
builtin-check-ref-format.c | 10 ++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 034223c..51579f6 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -7,7 +7,9 @@ git-check-ref-format - Make sure ref name is well formed
SYNOPSIS
--------
+[verse]
'git check-ref-format' <refname>
+'git check-ref-format' [--branch] <branchname-shorthand>
DESCRIPTION
-----------
@@ -49,6 +51,16 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
It may also be used to select a specific object such as with
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
+With the `--branch` option, it expands a branch name shorthand and
+prints the name of the branch the shorthand refers to.
+
+EXAMPLE
+-------
+
+git check-ref-format --branch @{-1}::
+
+Print the name of the previous branch.
+
GIT
---
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index 701de43..39db6cb 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -5,9 +5,19 @@
#include "cache.h"
#include "refs.h"
#include "builtin.h"
+#include "strbuf.h"
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
{
+ if (argc == 3 && !strcmp(argv[1], "--branch")) {
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_branchname(&sb, argv[2]);
+ strbuf_splice(&sb, 0, 0, "refs/heads/", 11);
+ if (check_ref_format(sb.buf))
+ die("'%s' is not a valid branch name", argv[2]);
+ printf("%s\n", sb.buf + 11);
+ exit(0);
+ }
if (argc != 2)
usage("git check-ref-format refname");
return !!check_ref_format(argv[1]);
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 2/7] strbuf_branchname(): a wrapper for branch name shorthands
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
The function takes a user-supplied string that is supposed to be a branch
name, and puts it in a strbuf after expanding possible shorthand notation.
A handful of open coded sequence to do this in the existing code have been
changed to use this helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 7 +------
builtin-branch.c | 6 +-----
builtin-checkout.c | 11 +++--------
builtin-merge.c | 5 ++---
strbuf.c | 9 +++++++++
strbuf.h | 2 ++
6 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/branch.c b/branch.c
index 313bcf1..558f092 100644
--- a/branch.c
+++ b/branch.c
@@ -134,13 +134,8 @@ void create_branch(const char *head,
char *real_ref, msg[PATH_MAX + 20];
struct strbuf ref = STRBUF_INIT;
int forcing = 0;
- int len;
- len = strlen(name);
- if (interpret_branch_name(name, &ref) != len) {
- strbuf_reset(&ref);
- strbuf_add(&ref, name, len);
- }
+ strbuf_branchname(&ref, name);
strbuf_splice(&ref, 0, 0, "refs/heads/", 11);
if (check_ref_format(ref.buf))
diff --git a/builtin-branch.c b/builtin-branch.c
index cacd7da..7452db1 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -121,11 +121,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
die("Couldn't look up commit object for HEAD");
}
for (i = 0; i < argc; i++, strbuf_release(&bname)) {
- int len = strlen(argv[i]);
-
- if (interpret_branch_name(argv[i], &bname) != len)
- strbuf_add(&bname, argv[i], len);
-
+ strbuf_branchname(&bname, argv[i]);
if (kinds == REF_LOCAL_BRANCH && !strcmp(head, bname.buf)) {
error("Cannot delete the branch '%s' "
"which you are currently on.", bname.buf);
diff --git a/builtin-checkout.c b/builtin-checkout.c
index a8d9d97..b268046 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -353,16 +353,11 @@ struct branch_info {
static void setup_branch_path(struct branch_info *branch)
{
struct strbuf buf = STRBUF_INIT;
- int ret;
- if ((ret = interpret_branch_name(branch->name, &buf))
- && ret == strlen(branch->name)) {
+ strbuf_branchname(&buf, branch->name);
+ if (strcmp(buf.buf, branch->name))
branch->name = xstrdup(buf.buf);
- strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
- } else {
- strbuf_addstr(&buf, "refs/heads/");
- strbuf_addstr(&buf, branch->name);
- }
+ strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
branch->path = strbuf_detach(&buf, NULL);
}
diff --git a/builtin-merge.c b/builtin-merge.c
index e94ea7c..6a51823 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -360,9 +360,8 @@ static void merge_name(const char *remote, struct strbuf *msg)
const char *ptr;
int len, early;
- len = strlen(remote);
- if (interpret_branch_name(remote, &bname) == len)
- remote = bname.buf;
+ strbuf_branchname(&bname, remote);
+ remote = bname.buf;
memset(branch_head, 0, sizeof(branch_head));
remote_head = peel_to_type(remote, 0, NULL, OBJ_COMMIT);
diff --git a/strbuf.c b/strbuf.c
index bfbd816..a60b0ad 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -357,3 +357,12 @@ int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint)
return len;
}
+
+int strbuf_branchname(struct strbuf *sb, const char *name)
+{
+ int len = strlen(name);
+ if (interpret_branch_name(name, sb) == len)
+ return 0;
+ strbuf_add(sb, name, len);
+ return len;
+}
diff --git a/strbuf.h b/strbuf.h
index 89bd36e..68923e1 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -131,4 +131,6 @@ extern int strbuf_getline(struct strbuf *, FILE *, int);
extern void stripspace(struct strbuf *buf, int skip_comments);
extern int launch_editor(const char *path, struct strbuf *buffer, const char *const *env);
+extern int strbuf_branchname(struct strbuf *sb, const char *name);
+
#endif /* STRBUF_H */
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 1/7] Rename interpret/substitute nth_last_branch functions
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1237791716.git.gitster@pobox.com>
These allow you to say "git checkout @{-2}" to switch to the branch two
"branch switching" ago by pretending as if you typed the name of that
branch. As it is likely that we will be introducing more short-hands to
write the name of a branch without writing it explicitly, rename the
functions from "nth_last_branch" to more generic "branch_name", to prepare
for different semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 2 +-
builtin-branch.c | 2 +-
builtin-checkout.c | 2 +-
builtin-merge.c | 2 +-
cache.h | 2 +-
sha1_name.c | 12 ++++++------
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/branch.c b/branch.c
index 5f889fe..313bcf1 100644
--- a/branch.c
+++ b/branch.c
@@ -137,7 +137,7 @@ void create_branch(const char *head,
int len;
len = strlen(name);
- if (interpret_nth_last_branch(name, &ref) != len) {
+ if (interpret_branch_name(name, &ref) != len) {
strbuf_reset(&ref);
strbuf_add(&ref, name, len);
}
diff --git a/builtin-branch.c b/builtin-branch.c
index 14d4b91..cacd7da 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -123,7 +123,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
for (i = 0; i < argc; i++, strbuf_release(&bname)) {
int len = strlen(argv[i]);
- if (interpret_nth_last_branch(argv[i], &bname) != len)
+ if (interpret_branch_name(argv[i], &bname) != len)
strbuf_add(&bname, argv[i], len);
if (kinds == REF_LOCAL_BRANCH && !strcmp(head, bname.buf)) {
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 9fdfc58..a8d9d97 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -355,7 +355,7 @@ static void setup_branch_path(struct branch_info *branch)
struct strbuf buf = STRBUF_INIT;
int ret;
- if ((ret = interpret_nth_last_branch(branch->name, &buf))
+ if ((ret = interpret_branch_name(branch->name, &buf))
&& ret == strlen(branch->name)) {
branch->name = xstrdup(buf.buf);
strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
diff --git a/builtin-merge.c b/builtin-merge.c
index 4c11935..e94ea7c 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -361,7 +361,7 @@ static void merge_name(const char *remote, struct strbuf *msg)
int len, early;
len = strlen(remote);
- if (interpret_nth_last_branch(remote, &bname) == len)
+ if (interpret_branch_name(remote, &bname) == len)
remote = bname.buf;
memset(branch_head, 0, sizeof(branch_head));
diff --git a/cache.h b/cache.h
index 39789ee..d28fd74 100644
--- a/cache.h
+++ b/cache.h
@@ -671,7 +671,7 @@ extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *);
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
-extern int interpret_nth_last_branch(const char *str, struct strbuf *);
+extern int interpret_branch_name(const char *str, struct strbuf *);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
diff --git a/sha1_name.c b/sha1_name.c
index 2f75179..904bcd9 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -242,10 +242,10 @@ static int ambiguous_path(const char *path, int len)
* *string and *len will only be substituted, and *string returned (for
* later free()ing) if the string passed in is of the form @{-<n>}.
*/
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch_name(const char **string, int *len)
{
struct strbuf buf = STRBUF_INIT;
- int ret = interpret_nth_last_branch(*string, &buf);
+ int ret = interpret_branch_name(*string, &buf);
if (ret == *len) {
size_t size;
@@ -259,7 +259,7 @@ static char *substitute_nth_last_branch(const char **string, int *len)
int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
- char *last_branch = substitute_nth_last_branch(&str, &len);
+ char *last_branch = substitute_branch_name(&str, &len);
const char **p, *r;
int refs_found = 0;
@@ -288,7 +288,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
{
- char *last_branch = substitute_nth_last_branch(&str, &len);
+ char *last_branch = substitute_branch_name(&str, &len);
const char **p;
int logs_found = 0;
@@ -355,7 +355,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
struct strbuf buf = STRBUF_INIT;
int ret;
/* try the @{-N} syntax for n-th checkout */
- ret = interpret_nth_last_branch(str+at, &buf);
+ ret = interpret_branch_name(str+at, &buf);
if (ret > 0) {
/* substitute this branch name and restart */
return get_sha1_1(buf.buf, buf.len, sha1);
@@ -750,7 +750,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
* If the input was ok but there are not N branch switches in the
* reflog, it returns 0.
*/
-int interpret_nth_last_branch(const char *name, struct strbuf *buf)
+int interpret_branch_name(const char *name, struct strbuf *buf)
{
long nth;
int i, retval;
--
1.6.2.1.349.ga64c
^ permalink raw reply related
* [PATCH v2 0/7] Clean up interpret_nth_last_branch feature
From: Junio C Hamano @ 2009-03-23 7:58 UTC (permalink / raw)
To: git
The changes since the previous round are:
- Tightening of the refname rule comes very late in the series, so that
we can optionally drop it;
- In addition to allowing "git branch -d bad@{name}ref.", we also allow
"git branch -d bad@{name}ref. good-one" as another escape hatch;
- Update documentation to git-check-ref-format to describe the tightened
rules.
Junio C Hamano (7):
Rename interpret/substitute nth_last_branch functions
strbuf_branchname(): a wrapper for branch name shorthands
check-ref-format --branch: give Porcelain a way to grok branch
shorthand
Fix branch -m @{-1} newname
strbuf_check_branch_ref(): a helper to check a refname for a branch
check_ref_format(): tighten refname rules
checkout -: make "-" to mean "previous branch" everywhere
Documentation/git-check-ref-format.txt | 18 ++++++++++++++++-
branch.c | 10 +--------
builtin-branch.c | 32 +++++++++++++++++-------------
builtin-check-ref-format.c | 9 ++++++++
builtin-checkout.c | 26 ++++++++++--------------
builtin-merge.c | 5 +--
cache.h | 2 +-
refs.c | 16 +++++++++++---
sha1_name.c | 33 ++++++++++++++++++-------------
strbuf.c | 17 ++++++++++++++++
strbuf.h | 3 ++
11 files changed, 110 insertions(+), 61 deletions(-)
^ permalink raw reply
* Re: [PATCH] remote: improve sorting of "configure for git push" list
From: Johannes Sixt @ 2009-03-23 7:56 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johannes Schindelin, Jay Soffian,
Git Mailing List
In-Reply-To: <20090322085920.GA5201@coredump.intra.peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Thanks,
-- Hannes
^ permalink raw reply
* Re: Merge format documented?
From: Junio C Hamano @ 2009-03-23 7:52 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200903230818.20044.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> On Monday, 23 March 2009 4:50:24 Junio C Hamano wrote:
>> Andreas Gruenbacher <agruen@suse.de> writes:
>> > is the format that git normally uses for indicating merge conflicts in
>> > files (the <<< === >>> markers) documented somewhere? How exactly does
>> > it differ from the diff3 format (<<< ||| === >>>)? Diff3's -m mode seems
>> > to come close to what git does, except that git doesn't produce the |||
>> > section:
>>
>> It is an imitation of output from "merge" program of RCS suite Paul you
>> know maintains ;-)
>
> So it's the same format except that diff3's ||| section isn't shown. I was
> wondering if there are any additional tricks.
No additional tricks.
As far as I can remember, the format was not really chosen, but simply
fell out as a natural consequence of using "merge" rather than "diff3" as
a merge backend (we originally used to invoke "merge" from RCS suite
instead of performing file-level merges ourselves), but we could say we
chose "merge" over "diff3 -m" because the output format should be more
familiar than the diff3-m format with |||, especially to anybody who came
from subversion or CVS background.
^ permalink raw reply
* Re: Merge format documented?
From: Andreas Gruenbacher @ 2009-03-23 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtz5k99tr.fsf@gitster.siamese.dyndns.org>
On Monday, 23 March 2009 4:50:24 Junio C Hamano wrote:
> Andreas Gruenbacher <agruen@suse.de> writes:
> > is the format that git normally uses for indicating merge conflicts in
> > files (the <<< === >>> markers) documented somewhere? How exactly does
> > it differ from the diff3 format (<<< ||| === >>>)? Diff3's -m mode seems
> > to come close to what git does, except that git doesn't produce the |||
> > section:
>
> It is an imitation of output from "merge" program of RCS suite Paul you
> know maintains ;-)
So it's the same format except that diff3's ||| section isn't shown. I was
wondering if there are any additional tricks.
Patch should support that too, even from the more limited information it has.
> Recent versions of git supports merge.conflictstyle
> configuration variable and --conflict option in 'git-checkout' to write
> the conflicts out in a format that is an imitation of "diff3 -m" output.
>
> As far as I know, neither "git" format is documented anywhere, but I
> didn't find an official format specification of the "upstream" formats,
> and that is why I keep saying "imitation" in the above paragraph ;-)
The diff info pages describe the diff3 format; that may be enough
documentation:
info -f diff -n "Marking Conflicts"
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH] documentation: Makefile accounts for SHELL_PATH setting
From: Jeff King @ 2009-03-23 6:57 UTC (permalink / raw)
To: Ben Walton; +Cc: git
In-Reply-To: <1237728044-15651-1-git-send-email-bwalton@artsci.utoronto.ca>
On Sun, Mar 22, 2009 at 09:20:44AM -0400, Ben Walton wrote:
> Ensure that the Makefile that generates and installs the Documentation
> is aware of any SHELL_PATH setting. Use this value if found or the
> current setting for SHELL if not. This is an accommodation for systems
> where sh is not bash.
Nit: I have lots of systems where sh is not bash, and they work fine. It
is really about "where sh is not horribly broken". There aren't (AFAIK)
and should not be any bash-isms in these scripts.
The patch itself looks fine; thanks for addressing my concerns.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 3/8] docbook: radical style change
From: Jeff King @ 2009-03-23 6:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1237745121-6325-4-git-send-email-felipe.contreras@gmail.com>
On Sun, Mar 22, 2009 at 08:05:16PM +0200, Felipe Contreras wrote:
> Use smaller 'sans-serial' font. Sans-Serial fonts are supposed to be
> easier to read in screens. This format is similar to the one of
> Wikipedia.
I started to look up "sans-serial" before I realized it seems to be just
a typo for "sans-serif" (or is there something I'm missing)?
Is there a reason to apply this style change just to docbook-generated
HTML? Most of the HTML documentation is generated directly from
asciidoc.
> html body {
> margin: 1em 5% 1em 5%;
> - line-height: 1.2;
> + line-height: 1em;
> + font-family: sans-serif;
> + font-size: small;
Personally, I think collapsing the line spacing looks worse.
I'm not sure I see the point of putting "small" text for the entire
body. Since it covers the whole page, you are not "small" with respect
to anything else, but are basically just overriding the user's choice
through their browser of what is a reasonable default text size.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox