* Re: [PATCH] difftool: add support for an extended revision syntax
From: Michael J Gruber @ 2009-03-23 14:51 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1237803348-9329-1-git-send-email-davvid@gmail.com>
David Aguilar venit, vidit, dixit 23.03.2009 11:15:
> 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?
I like the idea of having a shortcut like that a lot, but I'm sorry I'm
not supportive of a tool-specific rev syntax extension; for principal
reasons, but also because diff, checkout and maybe others could make
good use of it.
Work is underway on clearing out the issue of forbidden characters in
revision specifiers. We already have commit:file. I think something like
~2:file would be short enough as well as in line with the usual
semantics. Similarly,
git diff ~3 ~2 file
git diff ~3 file
would be short and simple as soon as ~3 is implemented to be a shortcut
for HEAD~3. (I'm not sure we can actually use ~, even though it would
fit in with the usual "if it's not specified it's HEAD".) This would
only need a shortcut for HEAD, such as not even specifying it (as above)
or c~ with c being our new fancy character for that.
> 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
^ permalink raw reply
* Re: [RFC/WIP 1/2] Documentation: fix minor inconsistency
From: Matthieu Moy @ 2009-03-23 14:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <1237818533-31577-2-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> While we don't always write out commands in full (`git command`) we
> should do it consistently in adjacent paragraphs.
> - If set to true or "refuse", receive-pack will deny a ref update
> + If set to true or "refuse", git-receive-pack will deny a ref update
Then, shouldn't this be `git receive-pack` ?
--
Matthieu
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Finn Arne Gangstad @ 2009-03-23 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk56jfgt2.fsf@gitster.siamese.dyndns.org>
On Sat, Mar 21, 2009 at 12:58:33AM -0700, Junio C Hamano wrote:
[...]
> * fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits
> - Display warning for default git push with no push.default config
> + New config push.default to decide default behavior for push
>
> Replaced the old series with the first step to allow a smooth transition.
> Some might argue that this should not give any warning but just give users
> this new configuration to play with first, and after we know we are going
> to switch default some day, start the warning.
If you feel that talking about a possible future change is premature,
you could omit that part of the second commit I guess, but I think
printing some kind of warning is valuable. Are you waiting for more
input? It seems that this topic is pretty dead now.
Most people who get bitten by this directly are probably not active on
this list so I don't think you will hear from many of them.
- Finn Arne
^ permalink raw reply
* Re: Summer of Code - Cached Packs/Object Lists
From: Nicolas Pitre @ 2009-03-23 14:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Thomas Coppi, git
In-Reply-To: <20090323025244.GO23521@spearce.org>
On Sun, 22 Mar 2009, Shawn O. Pearce wrote:
> Thomas Coppi <thisnukes4u@gmail.com> wrote:
> > On Sun, Mar 22, 2009 at 7:59 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >> You could do both. ??But I think most people on the list will argue
> >> that doing both is overkill and only one is necessary, and further,
> >> that only the one that offers the "biggest bank for the buck"
> >> should be implemented.
> >
> > Alright, that seems reasonable. Given that I think I would lean
> > towards implementing an object list caching mechanism, since that seems
> > to be more generally applicable. The logic for this would then need to
> > be in the rev-list code(as mentioned in the JGit discussion), correct?
>
> Probably. IIRC upload-pack forks a rev-list to produce the
> object list, and pipes that into the forked pack-objects' stdin.
> Thus rev-list is probably what would need to know how to include
> the cached list to its output.
Related to this, the first optimization is probably to avoid the fork
altogether. The pack-objects code knows how to list objects by itself
already, and that is used by git-repack. At the moment, packed tree
objects during a fetch are probably accessed one extra time needlessly.
Nicolas
^ permalink raw reply
* Re: [RFC/WIP 0/2] Documentation clean-up: git commands
From: Michael J Gruber @ 2009-03-23 14:31 UTC (permalink / raw)
Cc: git, Junio C Hamano
In-Reply-To: <1237818533-31577-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 23.03.2009 15:28:
> In current git documentation, git commands are still written in various
> styles: with and without dash, unformatted and formatted with `, ' or ".
>
> I propose to use `git command` consistently. In asciidoc, backticks are
> for commands, ticks for paths. [Quotes should be like ``this''.]
>
> A first step is reaching a consistent use of backticks. A second step
> would be sed magic to get rid of the dashes in the text, not in the
> links (linkgit:...).
>
> Patch 1 is a preparation patch where I spotted the use of a command with
> "git" in an instance where it looks very inconsistent. (It feels OK when
s/with/without/
Sorry :|
^ permalink raw reply
* [RFC/WIP 2/2] Documentation: format git commands consistently
From: Michael J Gruber @ 2009-03-23 14:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1237818533-31577-2-git-send-email-git@drmicha.warpmail.net>
Commands should be formatted `command` in asciidoc. So, try and catch all
present styles ("command", 'command', command) and convert to this at
least for git commands.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/config.txt | 114 ++++++++++++++++----------------
Documentation/diff-format.txt | 6 +-
Documentation/diff-generate-patch.txt | 12 ++--
Documentation/diff-options.txt | 4 +-
Documentation/everyday.txt | 6 +-
Documentation/fetch-options.txt | 12 ++--
Documentation/git-add.txt | 28 ++++----
Documentation/git-am.txt | 16 ++--
8 files changed, 99 insertions(+), 99 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e093ff3..ea15552 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -63,7 +63,7 @@ The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1 or true/false. Case is not significant in boolean values, when
converting value to the canonical form using '--bool' type specifier;
-'git-config' will ensure that the output is "true" or "false".
+`git-config` will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
@@ -393,8 +393,8 @@ core.pager::
core.whitespace::
A comma separated list of common whitespace problems to
- notice. 'git-diff' will use `color.diff.whitespace` to
- highlight them, and 'git-apply --whitespace=error' will
+ notice. `git-diff` will use `color.diff.whitespace` to
+ highlight them, and `git-apply --whitespace=error` will
consider them as errors. You can prefix `-` to disable
any of them (e.g. `-trailing-space`):
+
@@ -419,9 +419,9 @@ journalling (traditional UNIX filesystems) or that only journal metadata
and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
core.preloadindex::
- Enable parallel index preload for operations like 'git diff'
+ Enable parallel index preload for operations like `git diff`
+
-This can speed up operations like 'git diff' and 'git status' especially
+This can speed up operations like `git diff` and `git status` especially
on filesystems like NFS that have weak caching semantics and thus
relatively high IO latencies. With this set to 'true', git will do the
index comparison to the filesystem data in parallel, allowing
@@ -430,7 +430,7 @@ overlapping IO's.
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
- "git last" is equivalent to "git cat-file commit HEAD". To avoid
+ `git last` is equivalent to `git cat-file commit HEAD`. To avoid
confusion and troubles with script usage, aliases that
hide existing git commands are ignored. Arguments are split by
spaces, the usual shell quoting and escaping is supported.
@@ -439,15 +439,15 @@ alias.*::
If the alias expansion is prefixed with an exclamation point,
it will be treated as a shell command. For example, defining
"alias.new = !gitk --all --not ORIG_HEAD", the invocation
-"git new" is equivalent to running the shell command
-"gitk --all --not ORIG_HEAD".
+`git new` is equivalent to running the shell command
+`gitk --all --not ORIG_HEAD`.
apply.whitespace::
- Tells 'git-apply' how to handle whitespaces, in the same way
+ Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See linkgit:git-apply[1].
branch.autosetupmerge::
- Tells 'git-branch' and 'git-checkout' to setup new branches
+ Tells `git-branch` and `git-checkout` to setup new branches
so that linkgit:git-pull[1] will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
@@ -458,7 +458,7 @@ branch.autosetupmerge::
branch. This option defaults to true.
branch.autosetuprebase::
- When a new branch is created with 'git-branch' or 'git-checkout'
+ When a new branch is created with `git-branch` or `git-checkout`
that tracks another branch, this variable tells git to set
up pull to rebase instead of merge (see "branch.<name>.rebase").
When `never`, rebase is never automatically set to true.
@@ -473,20 +473,20 @@ branch.autosetuprebase::
This option defaults to never.
branch.<name>.remote::
- When in branch <name>, it tells 'git-fetch' which remote to fetch.
- If this option is not given, 'git-fetch' defaults to remote "origin".
+ When in branch <name>, it tells `git-fetch` which remote to fetch.
+ If this option is not given, `git-fetch` defaults to remote "origin".
branch.<name>.merge::
- When in branch <name>, it tells 'git-fetch' the default
+ When in branch <name>, it tells `git-fetch` the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.<name>.remote".
- The merge information is used by 'git-pull' (which at first calls
- 'git-fetch') to lookup the default branch for merging. Without
- this option, 'git-pull' defaults to merge the first refspec fetched.
+ The merge information is used by `git-pull` (which at first calls
+ `git-fetch`) to lookup the default branch for merging. Without
+ this option, `git-pull` defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
- If you wish to setup 'git-pull' so that it merges into <name> from
+ If you wish to setup `git-pull` so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting
`.` (a period) for branch.<name>.remote.
@@ -500,7 +500,7 @@ branch.<name>.mergeoptions::
branch.<name>.rebase::
When true, rebase the branch <name> on top of the fetched branch,
instead of merging the default branch from the default remote when
- "git pull" is run.
+ `git pull` is run.
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
@@ -516,7 +516,7 @@ browser.<tool>.path::
working repository in gitweb (see linkgit:git-instaweb[1]).
clean.requireForce::
- A boolean to make git-clean do nothing unless given -f
+ A boolean to make `git-clean` do nothing unless given -f
or -n. Defaults to true.
color.branch::
@@ -574,12 +574,12 @@ color.grep.match::
color.interactive::
When set to `always`, always use colors for interactive prompts
- and displays (such as those used by "git-add --interactive").
+ and displays (such as those used by `git-add --interactive`).
When false (or `never`), never. When set to `true` or `auto`, use
colors only when the output is to the terminal. Defaults to false.
color.interactive.<slot>::
- Use customized color for 'git-add --interactive'
+ Use customized color for `git-add --interactive`
output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
four distinct types of normal output from interactive
programs. The values of these variables may be specified as
@@ -616,14 +616,14 @@ commit.template::
Specify a file to use as the template for new commit messages.
diff.autorefreshindex::
- When using 'git-diff' to compare with work tree
+ When using `git-diff` to compare with work tree
files, do not consider stat-only change as changed.
Instead, silently run `git update-index --refresh` to
update the cached stat information for paths whose
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
- affects only 'git-diff' Porcelain, and not lower level
- 'diff' commands, such as 'git-diff-files'.
+ affects only `git-diff` Porcelain, and not lower level
+ `diff` commands, such as `git-diff-files`.
diff.external::
If this config variable is set, diff generation is not
@@ -635,24 +635,24 @@ diff.external::
your files, you might want to use linkgit:gitattributes[5] instead.
diff.mnemonicprefix::
- If set, 'git-diff' uses a prefix pair that is different from the
+ If set, `git-diff` uses a prefix pair that is different from the
standard "a/" and "b/" depending on what is being compared. When
this configuration is in effect, reverse diff output also swaps
the order of the prefixes:
-'git-diff';;
+`git-diff`;;
compares the (i)ndex and the (w)ork tree;
-'git-diff HEAD';;
+`git-diff HEAD`;;
compares a (c)ommit and the (w)ork tree;
-'git diff --cached';;
+`git diff --cached`;;
compares a (c)ommit and the (i)ndex;
-'git-diff HEAD:file1 file2';;
+`git-diff HEAD:file1 file2`;;
compares an (o)bject and a (w)ork tree entity;
-'git diff --no-index a b';;
+`git diff --no-index a b`;;
compares two non-git things (1) and (2).
diff.renameLimit::
The number of files to consider when performing the copy/rename
- detection; equivalent to the 'git-diff' option '-l'.
+ detection; equivalent to the `git-diff` option '-l'.
diff.renames::
Tells git to detect renames. If set to any boolean value, it
@@ -719,7 +719,7 @@ format.pretty::
linkgit:git-whatchanged[1].
format.thread::
- The default threading style for 'git-format-patch'. Can be
+ The default threading style for `git-format-patch`. Can be
either a boolean value, `shallow` or `deep`. 'Shallow'
threading makes every mail a reply to the head of the series,
where the head is chosen from the cover letter, the
@@ -730,7 +730,7 @@ format.thread::
gc.aggressiveWindow::
The window size parameter used in the delta compression
- algorithm used by 'git-gc --aggressive'. This defaults
+ algorithm used by `git-gc --aggressive`. This defaults
to 10.
gc.auto::
@@ -747,39 +747,39 @@ gc.autopacklimit::
default value is 50. Setting this to 0 disables it.
gc.packrefs::
- 'git-gc' does not run `git pack-refs` in a bare repository by
+ `git-gc` does not run `git pack-refs` in a bare repository by
default so that older dumb-transport clients can still fetch
- from the repository. Setting this to `true` lets 'git-gc'
+ from the repository. Setting this to `true` lets `git-gc`
to run `git pack-refs`. Setting this to `false` tells
- 'git-gc' never to run `git pack-refs`. The default setting is
+ `git-gc` never to run `git pack-refs`. The default setting is
`notbare`. Enable it only when you know you do not have to
support such clients. The default setting will change to `true`
at some stage, and setting this to `false` will continue to
- prevent `git pack-refs` from being run from 'git-gc'.
+ prevent `git pack-refs` from being run from `git-gc`.
gc.pruneexpire::
- When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
+ When `git-gc` is run, it will call `prune --expire 2.weeks.ago`.
Override the grace period with this config variable. The value
"now" may be used to disable this grace period and always prune
unreachable objects immediately.
gc.reflogexpire::
- 'git-reflog expire' removes reflog entries older than
+ `git-reflog expire` removes reflog entries older than
this time; defaults to 90 days.
gc.reflogexpireunreachable::
- 'git-reflog expire' removes reflog entries older than
+ `git-reflog expire` removes reflog entries older than
this time and are not reachable from the current tip;
defaults to 30 days.
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
- kept for this many days when 'git-rerere gc' is run.
+ kept for this many days when `git-rerere gc` is run.
The default is 60 days. See linkgit:git-rerere[1].
gc.rerereunresolved::
Records of conflicted merge you have not resolved are
- kept for this many days when 'git-rerere gc' is run.
+ kept for this many days when `git-rerere gc` is run.
The default is 15 days. See linkgit:git-rerere[1].
gitcvs.commitmsgannotation::
@@ -814,7 +814,7 @@ gitcvs.allbinary::
it is binary, similar to 'core.autocrlf'.
gitcvs.dbname::
- Database used by git-cvsserver to cache revision information
+ Database used by `git-cvsserver` to cache revision information
derived from the git repository. The exact meaning depends on the
used database driver, for SQLite (which is the default driver) this
is a filename. Supports variable substitution (see
@@ -823,7 +823,7 @@ gitcvs.dbname::
gitcvs.dbdriver::
Used Perl DBI driver. You can specify any available driver
- for this here, but it might not work. git-cvsserver is tested
+ for this here, but it might not work. `git-cvsserver` is tested
with 'DBD::SQLite', reported to work with 'DBD::Pg', and
reported *not* to work with 'DBD::mysql'. Experimental feature.
May not contain double colons (`:`). Default: 'SQLite'.
@@ -887,19 +887,19 @@ gui.spellingdictionary::
off.
gui.fastcopyblame::
- If true, 'git gui blame' uses '-C' instead of '-C -C' for original
+ If true, `git gui blame` uses '-C' instead of '-C -C' for original
location detection. It makes blame significantly faster on huge
repositories at the expense of less thorough copy detection.
gui.copyblamethreshold::
- Specifies the threshold to use in 'git gui blame' original location
+ Specifies the threshold to use in `git gui blame` original location
detection, measured in alphanumeric characters. See the
linkgit:git-blame[1] manual for more information on copy detection.
gui.blamehistoryctx::
Specifies the radius of history context in days to show in
linkgit:gitk[1] for the selected commit, when the `Show History
- Context` menu item is invoked from 'git gui blame'. If this
+ Context` menu item is invoked from `git gui blame`. If this
variable is set to zero, the whole history is shown.
guitool.<name>.cmd::
@@ -1026,7 +1026,7 @@ i18n.commitEncoding::
i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
- running 'git-log' and friends.
+ running `git-log` and friends.
imap::
The configuration variables in the 'imap' section are described
@@ -1060,7 +1060,7 @@ interactive.singlekey::
log.date::
Set default date-time mode for the log command. Setting log.date
- value is similar to using 'git-log'\'s --date option. The value is one of the
+ value is similar to using `git-log`\'s --date option. The value is one of the
following alternatives: {relative,local,default,iso,rfc,short}.
See linkgit:git-log[1].
@@ -1212,7 +1212,7 @@ pull.twohead::
The default merge strategy to use when pulling a single branch.
push.default::
- Defines the action git push should take if no refspec is given
+ Defines the action `git push` should take if no refspec is given
on the command line, no refspec is configured in the remote, and
no refspec is implied by any of the options given on the command
line.
@@ -1234,7 +1234,7 @@ rebase.stat::
rebase. False by default.
receive.fsckObjects::
- If it is set to true, git-receive-pack will check all received
+ If it is set to true, `git-receive-pack` will check all received
objects. It will abort in the case of a malformed object or a
broken link. The result of an abort are only dangling objects.
Defaults to false.
@@ -1250,11 +1250,11 @@ receive.unpackLimit::
`transfer.unpackLimit` is used instead.
receive.denyDeletes::
- If set to true, git-receive-pack will deny a ref update that deletes
+ If set to true, `git-receive-pack` will deny a ref update that deletes
the ref. Use this to prevent such a ref deletion via a push.
receive.denyCurrentBranch::
- If set to true or "refuse", git-receive-pack will deny a ref update
+ If set to true or "refuse", `git-receive-pack` will deny a ref update
to the currently checked out branch of a non-bare repository.
Such a push is potentially dangerous because it brings the HEAD
out of sync with the index and working tree. If set to "warn",
@@ -1263,7 +1263,7 @@ receive.denyCurrentBranch::
message. Defaults to "warn".
receive.denyNonFastForwards::
- If set to true, git-receive-pack will deny a ref update which is
+ If set to true, `git-receive-pack` will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
set when initializing a shared repository.
@@ -1306,8 +1306,8 @@ remote.<name>.tagopt::
fetching from remote <name>
remotes.<group>::
- The list of remotes which are fetched by "git remote update
- <group>". See linkgit:git-remote[1].
+ The list of remotes which are fetched by `git remote update
+ <group>`. See linkgit:git-remote[1].
repack.usedeltabaseoffset::
By default, linkgit:git-repack[1] creates packs that use
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 1eeb1c7..31653c1 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -1,5 +1,5 @@
-The output format from "git-diff-index", "git-diff-tree",
-"git-diff-files" and "git diff --raw" are very similar.
+The output format from `git-diff-index`, `git-diff-tree`,
+`git-diff-files` and `git diff --raw` are very similar.
These commands all compare two sets of things; what is
compared differs:
@@ -78,7 +78,7 @@ respectively.
diff format for merges
----------------------
-"git-diff-tree", "git-diff-files" and "git-diff --raw"
+`git-diff-tree`, `git-diff-files` and `git-diff --raw`
can take '-c' or '--cc' option
to generate diff output also for merge commits. The output differs
from the format described above in the following way:
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 0f25ba7..8889d19 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -1,9 +1,9 @@
Generating patches with -p
--------------------------
-When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
-with a '-p' option, "git diff" without the '--raw' option, or
-"git log" with the "-p" option, they
+When `git-diff-index`, `git-diff-tree`, or `git-diff-files` are run
+with a '-p' option, `git diff` without the '--raw' option, or
+`git log` with the "-p" option, they
do not produce the output described above; instead they produce a
patch file. You can customize the creation of such patches via the
GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
@@ -11,7 +11,7 @@ GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
What the -p option produces is slightly different from the traditional
diff format.
-1. It is preceded with a "git diff" header, that looks like
+1. It is preceded with a `git diff` header, that looks like
this:
diff --git a/file1 b/file2
@@ -54,9 +54,9 @@ file made it into the new one.
combined diff format
--------------------
-"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+`git-diff-tree`, `git-diff-files` and `git-diff` can take '-c' or
'--cc' option to produce 'combined diff'. For showing a merge commit
-with "git log -p", this is the default format.
+with `git log -p`, this is the default format.
A 'combined diff' format looks like this:
------------
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9276fae..8fc26b3 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -78,7 +78,7 @@ endif::git-format-patch[]
-z::
NUL-line termination on output. This affects the --raw
output field terminator. Also output from commands such
- as "git-log" will be delimited with NUL between commits.
+ as `git-log` will be delimited with NUL between commits.
--name-only::
Show only names of changed files.
@@ -128,7 +128,7 @@ override configuration settings.
--binary::
In addition to --full-index, output "binary diff" that
- can be applied with "git apply".
+ can be applied with `git apply`.
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 9310b65..da3dfa0 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -360,7 +360,7 @@ $ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
------------
-Run git-daemon to serve /pub/scm from inetd.::
+Run `git-daemon` to serve /pub/scm from inetd.::
+
------------
$ grep git /etc/inetd.conf
@@ -370,7 +370,7 @@ git stream tcp nowait nobody \
+
The actual configuration line should be on one line.
-Run git-daemon to serve /pub/scm from xinetd.::
+Run `git-daemon` to serve /pub/scm from xinetd.::
+
------------
$ cat /etc/xinetd.d/git-daemon
@@ -405,7 +405,7 @@ $ grep git /etc/shells <2>
/usr/bin/git-shell
------------
+
-<1> log-in shell is set to /usr/bin/git-shell, which does not
+<1> log-in shell is set to `/usr/bin/git-shell`, which does not
allow anything but `git push` and `git pull`. The users should
get an ssh access to the machine.
<2> in many distributions /etc/shells needs to list what is used
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index d313795..4aed833 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,6 +1,6 @@
-q::
--quiet::
- Pass --quiet to git-fetch-pack and silence any other internally
+ Pass --quiet to `git-fetch-pack` and silence any other internally
used programs.
-v::
@@ -15,13 +15,13 @@
--upload-pack <upload-pack>::
When given, and the repository to fetch from is handled
- by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+ by `git-fetch-pack`, `--exec=<upload-pack>` is passed to
the command to specify non-default path for the command
run on the other end.
-f::
--force::
- When 'git-fetch' is used with `<rbranch>:<lbranch>`
+ When `git-fetch` is used with `<rbranch>:<lbranch>`
refspec, it refuses to update the local branch
`<lbranch>` unless the remote branch `<rbranch>` it
fetches is a descendant of `<lbranch>`. This option
@@ -53,10 +53,10 @@ endif::git-pull[]
-u::
--update-head-ok::
- By default 'git-fetch' refuses to update the head which
+ By default `git-fetch` refuses to update the head which
corresponds to the current branch. This flag disables the
- check. This is purely for the internal use for 'git-pull'
- to communicate with 'git-fetch', and unless you are
+ check. This is purely for the internal use for `git-pull`
+ to communicate with `git-fetch`, and unless you are
implementing your own Porcelain you are not supposed to
use it.
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ce71838..ef9c136 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -8,7 +8,7 @@ git-add - Add file contents to the index
SYNOPSIS
--------
[verse]
-'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
+`git add` [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--all | [--update | -u]] [--intent-to-add | -N]
[--refresh] [--ignore-errors] [--] <filepattern>...
@@ -20,22 +20,22 @@ index, thus staging that content for inclusion in the next commit.
The "index" holds a snapshot of the content of the working tree, and it
is this snapshot that is taken as the contents of the next commit. Thus
after making any changes to the working directory, and before running
-the commit command, you must use the 'add' command to add any new or
+the commit command, you must use the `add` command to add any new or
modified files to the index.
This command can be performed multiple times before a commit. It only
adds the content of the specified file(s) at the time the add command is
run; if you want subsequent changes included in the next commit, then
-you must run 'git add' again to add the new content to the index.
+you must run `git add` again to add the new content to the index.
-The 'git status' command can be used to obtain a summary of which
+The `git status` command can be used to obtain a summary of which
files have changes that are staged for the next commit.
-The 'git add' command will not add ignored files by default. If any
-ignored files were explicitly specified on the command line, 'git add'
+The `git add` command will not add ignored files by default. If any
+ignored files were explicitly specified on the command line, `git add`
will fail with a list of ignored files. Ignored files reached by
directory recursion or filename globbing performed by Git (quote your
-globs before the shell) will be silently ignored. The 'add' command can
+globs before the shell) will be silently ignored. The `add` command can
be used to add ignored files with the `-f` (force) option.
Please see linkgit:git-commit[1] for alternative ways to add content to a
@@ -81,7 +81,7 @@ OPTIONS
Update only files that git already knows about, staging modified
content for commit and marking deleted files for removal. This
is similar
- to what "git commit -a" does in preparation for making a commit,
+ to what `git commit -a` does in preparation for making a commit,
except that the update is limited to paths specified on the
command line. If no paths are specified, all tracked files in the
current directory and its subdirectories are updated.
@@ -98,8 +98,8 @@ OPTIONS
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
- such files with 'git diff' and committing them with 'git commit
- -a'.
+ such files with `git diff` and committing them with `git commit
+ -a`.
--refresh::
Don't add the file(s), but only refresh their stat()
@@ -120,7 +120,7 @@ Configuration
-------------
The optional configuration variable 'core.excludesfile' indicates a path to a
-file containing patterns of file names to exclude from git-add, similar to
+file containing patterns of file names to exclude from `git-add`, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
those in info/exclude. See linkgit:gitrepository-layout[5].
@@ -175,9 +175,9 @@ The main command loop has 6 subcommands (plus help and quit).
status::
This shows the change between HEAD and index (i.e. what will be
- committed if you say "git commit"), and between index and
+ committed if you say `git commit`), and between index and
working tree files (i.e. what you could stage further before
- "git commit" using "git-add") for each path. A sample output
+ `git commit` using `git-add`) for each path. A sample output
looks like this:
+
------------
@@ -191,7 +191,7 @@ binary so line count cannot be shown) and there is no
difference between indexed copy and the working tree
version (if the working tree version were also different,
'binary' would have been shown in place of 'nothing'). The
-other file, git-add--interactive.perl, has 403 lines added
+other file, `git-add--interactive.perl`, has 403 lines added
and 35 lines deleted if you commit what is in the index, but
working tree file has further modifications (one addition and
one deletion).
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 1e71dd5..c9a444b 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -9,13 +9,13 @@ git-am - Apply a series of patches from a mailbox
SYNOPSIS
--------
[verse]
-'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
+`git am` [--signoff] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
[--reject]
[<mbox> | <Maildir>...]
-'git am' (--skip | --resolved | --abort)
+`git am` (--skip | --resolved | --abort)
DESCRIPTION
-----------
@@ -37,11 +37,11 @@ OPTIONS
-k::
--keep::
- Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
+ Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
-u::
--utf8::
- Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
+ Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
The proposed commit log message taken from the e-mail
is re-coded into UTF-8 encoding (configuration variable
`i18n.commitencoding` can be used to specify project's
@@ -51,7 +51,7 @@ This was optional in prior versions of git, but now it is the
default. You can use `--no-utf8` to override this.
--no-utf8::
- Pass `-n` flag to 'git-mailinfo' (see
+ Pass `-n` flag to `git-mailinfo` (see
linkgit:git-mailinfo[1]).
-3::
@@ -66,7 +66,7 @@ default. You can use `--no-utf8` to override this.
-p<n>::
--directory=<dir>::
--reject::
- These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
+ These flags are passed to the `git-apply` (see linkgit:git-apply[1])
program that applies
the patch.
@@ -106,7 +106,7 @@ default. You can use `--no-utf8` to override this.
to the screen before exiting. This overrides the
standard message informing you to use `--resolved`
or `--skip` to handle the failure. This is solely
- for internal use between 'git-rebase' and 'git-am'.
+ for internal use between `git-rebase` and `git-am`.
--abort::
Restore the original branch and abort the patching operation.
@@ -159,7 +159,7 @@ names.
Before any patches are applied, ORIG_HEAD is set to the tip of the
current branch. This is useful if you have problems with multiple
-commits, like running 'git am' on the wrong branch or an error in the
+commits, like running `git am` on the wrong branch or an error in the
commits that is more easily fixed by changing the mailbox (e.g.
errors in the "From:" lines).
--
1.6.2.149.g6462
^ permalink raw reply related
* [RFC/WIP 1/2] Documentation: fix minor inconsistency
From: Michael J Gruber @ 2009-03-23 14:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1237818533-31577-1-git-send-email-git@drmicha.warpmail.net>
While we don't always write out commands in full (`git command`) we
should do it consistently in adjacent paragraphs.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 089569a..e093ff3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1254,7 +1254,7 @@ receive.denyDeletes::
the ref. Use this to prevent such a ref deletion via a push.
receive.denyCurrentBranch::
- If set to true or "refuse", receive-pack will deny a ref update
+ If set to true or "refuse", git-receive-pack will deny a ref update
to the currently checked out branch of a non-bare repository.
Such a push is potentially dangerous because it brings the HEAD
out of sync with the index and working tree. If set to "warn",
--
1.6.2.149.g6462
^ permalink raw reply related
* [RFC/WIP 0/2] Documentation clean-up: git commands
From: Michael J Gruber @ 2009-03-23 14:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In current git documentation, git commands are still written in various
styles: with and without dash, unformatted and formatted with `, ' or ".
I propose to use `git command` consistently. In asciidoc, backticks are
for commands, ticks for paths. [Quotes should be like ``this''.]
A first step is reaching a consistent use of backticks. A second step
would be sed magic to get rid of the dashes in the text, not in the
links (linkgit:...).
Patch 1 is a preparation patch where I spotted the use of a command with
"git" in an instance where it looks very inconsistent. (It feels OK when
talking about commands more colloquially.)
Patch 2 is an example for the first step.
Questions:
- Do we want this at all?
- Do we want it this way (`git command`)?
- How to prepare: 1 patch per file/per 5 files/per 50 changes?
- How to submit: single patch once ready or whole series at end (5 years
from now)?
- How to send: Bother the list or send pull requests only?
I don't know what I'm getting myself into...
Michael
Michael J Gruber (2):
Documentation: fix minor inconsistency
Documentation: format git commands consistently
Documentation/config.txt | 114 ++++++++++++++++----------------
Documentation/diff-format.txt | 6 +-
Documentation/diff-generate-patch.txt | 12 ++--
Documentation/diff-options.txt | 4 +-
Documentation/everyday.txt | 6 +-
Documentation/fetch-options.txt | 12 ++--
Documentation/git-add.txt | 28 ++++----
Documentation/git-am.txt | 16 ++--
8 files changed, 99 insertions(+), 99 deletions(-)
^ permalink raw reply
* Re: Importing Bzr revisions
From: Pieter de Bie @ 2009-03-23 14:18 UTC (permalink / raw)
To: David Reitter; +Cc: Junio C Hamano, git
In-Reply-To: <03AC7EDA-2A9F-4626-A67B-CE9F2A88FC7D@gmail.com>
On Mar 23, 2009, at 1:27 PM, David Reitter wrote:
> On Mar 23, 2009, at 4:06 AM, Junio C Hamano wrote:
>>
>>> 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
>
> I'm just experimenting with "bzr fast-export", which converts to
> git, and it seems to take about 4 minutes for 1000 revisions on our
> (modern) server. That would be around 7 hours for my emacs
> repository; I can't do that daily.
>
> I wonder if there's a way for (bzr) fast-export / (git) fast-import
> to work incrementally, i.e. for selected or most recent revisions.
>
> Or, one could do something like bzr diff -r $REV.. $BBRANCH | (cd
> $GBRANCH; patch -p0; git commit), plus preserving authors and log
> messages. Is this roughly what the fast-export format does anyways?
You might want to take a look at git-bzr (http://github.com/pieter/git-bzr/tree/master
) it allows incremental bidirectional interaction between git and bzr
using the fast-export/import, so it might just work in your case.
There are some issues with it, so you might want to check the
'network' part on github and use one of the other variants.
That said, it's a 100 line script that hasn't been used much, so good
luck :)
- Pieter
^ permalink raw reply
* Re: git repack: --depth=100000 causing larger not smaler pack file?
From: Nicolas Pitre @ 2009-03-23 14:14 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <86y6uwzgzo.fsf@broadpark.no>
On Mon, 23 Mar 2009, Kjetil Barvik wrote:
> 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.
This is a bit intriguing.
Of course, before going any further, you must realize that having a
depth of 15000 is a bit excessive. That means that, if you have a delta
chain with a depth of 15000 that means access to the object at the end
of the chain will require that 14999 other objects be accessed before
the 15000th one is retrieved. This will have horrible runtime
performances for something like 10% reduction in the best cases which is
probably not a good tradeoff.
This being said, I still stand by my assertion that, in theory, greater
delta depth should not make the pack bigger. And your table appears to
confirm that, even to the point of reaching a stable size as one would
expect, until a breaking point is reached after which results tend to
become rather random.
What I'm suspecting in that case is some computation overflow in
try_delta(). Consider for instance this piece:
max_size = max_size * (max_depth - src->depth) /
(max_depth - ref_depth + 1);
[ This is the treshold slope I was talking about, but contrary to
what I said before, it is affected by the depth not the window size. ]
In this case, if you have a max_depth of 95000, then any object larger
than 90461 bytes will cause a multiplication overflow, and the resulting
max_size will be capped to some random smaller value than expected
depending on the remaining bits. For example, suppose max_size = 45211,
max_depth = 95000 and src->depth = 0 then you should have max_size still
equal to 45211, but in this case it'll become 0 and no delta will be
attempted at all. The number of deltas reported at the end of the
repack process probably reflects that.
> > 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.
See explanation (and self correction) above.
> 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..
Yes -- see the -v option of 'git verify-pack'.
Nicolas
^ permalink raw reply
* Re: [PATCH] documentation: Makefile accounts for SHELL_PATH setting
From: Mike Hommey @ 2009-03-23 14:12 UTC (permalink / raw)
To: Jeff King; +Cc: Ben Walton, GIT List
In-Reply-To: <20090323140302.GA11005@coredump.intra.peff.net>
On Mon, Mar 23, 2009 at 10:03:02AM -0400, Jeff King <peff@peff.net> wrote:
> On Mon, Mar 23, 2009 at 08:57:27AM -0400, Ben Walton wrote:
>
> > That's a fair point. I've been lugging this around for a bit in the
> > build tree I use, so I don't recall specifically what was breaking.
> > The sh in question is the one found in solaris 8. When I get a few
> > mintues, I'll build without the patch to see what the problem was...
>
> I wouldn't worry about it. The /bin/sh on Solaris 8 is pretty hopelessly
> broken for our use. At the very least it doesn't understand $()
> subsititution.
Neither does it on solaris 10. Fortunately, there is /usr/xpg4/bin/sh.
Mike
^ permalink raw reply
* Re: [PATCH 3/3] completion: add --thread=deep/shallow to format-patch
From: Shawn O. Pearce @ 2009-03-23 14:11 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1237804011-15419-4-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> wrote:
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
All three patches...
Trivially-Acked-By: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: Importing Bzr revisions
From: Teemu Likonen @ 2009-03-23 14:07 UTC (permalink / raw)
To: David Reitter; +Cc: Junio C Hamano, git, bazaar
In-Reply-To: <03AC7EDA-2A9F-4626-A67B-CE9F2A88FC7D@gmail.com>
[I'll Cc to Bazaar list too because this subject is half-Git and
half-Bazaar and we may need help from both sides.]
On 2009-03-23 09:27 (-0400), David Reitter wrote:
> I'm just experimenting with "bzr fast-export", which converts to git,
> and it seems to take about 4 minutes for 1000 revisions on our
> (modern) server. That would be around 7 hours for my emacs repository;
> I can't do that daily.
>
> I wonder if there's a way for (bzr) fast-export / (git) fast-import to
> work incrementally, i.e. for selected or most recent revisions.
They can or should work incrementally, and actually I have succesfully
done that. The idea is to use --import-marks and --export-marks options
with "git fast-import" and --marks option with "bzr fast-export.
I noticed some problems with newer versions of "bzr fast-export", though
(since it was converted to a proper Bzr command). It seems to corrupt
the marks file when doing the first incremental export after the initial
export. At least the revisions are not in right order in the marks file
anymore. "git fast-import" can't continue to import from the same
revision where it left last time and it seems to create alternative
history -- or something.
Really I don't know if this is a bug in Bzr or in Git and haven't
figured out how to file a useful bug report.
^ permalink raw reply
* Re: git rebase + fuzz = possible bad merge
From: Benny Halevy @ 2009-03-23 14:06 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List
In-Reply-To: <200903231454.48600.trast@student.ethz.ch>
On Mar. 23, 2009, 15:54 +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> Benny Halevy wrote:
>> I'm hitting bad merges with (non interactive) git rebase
>> when a hunk is merged pre-maturely into an inexact match
>> when there's fuzz.
> [...]
>> { for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
> [...]
>> git rebase --onto test_branch master^ master
>
> git-am, and by extension rebase, by default doesn't take history into
> account. It just applies the patches "blindly". Thus, there's no way
> to know which series of 'line N' you really wanted it to go onto.
>
> To avoid this issue, use the -m option to git-rebase so that it uses a
> "real" merge. (You can achieve similar effects for git-am with the -3
> option.)
>
OK. -m indeed helps and I'm certainly going to adopt it for my rebase scripts.
git rebase -i does too, BTW.
I would expect though that the default mode for automatic rebase would be
the strictest and safest...
Benny
^ permalink raw reply
* Re: git repack: --depth=100000 causing larger not smaler pack file?
From: Peter Harris @ 2009-03-23 14:05 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: Nicolas Pitre, git
In-Reply-To: <86y6uwzgzo.fsf@broadpark.no>
On Mon, Mar 23, 2009 at 6:11 AM, Kjetil Barvik wrote:
> 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..
git verify-pack -v <pack.idx>
The columns are: SHA1 type size size-in-packfile offset-in-packfile
depth base-SHA1
(the last two columns are only present for deltified objects)
Peter Harris
^ permalink raw reply
* Re: [PATCH] documentation: Makefile accounts for SHELL_PATH setting
From: Jeff King @ 2009-03-23 14:03 UTC (permalink / raw)
To: Ben Walton; +Cc: GIT List
In-Reply-To: <1237812904-sup-3864@ntdws12.chass.utoronto.ca>
On Mon, Mar 23, 2009 at 08:57:27AM -0400, Ben Walton wrote:
> That's a fair point. I've been lugging this around for a bit in the
> build tree I use, so I don't recall specifically what was breaking.
> The sh in question is the one found in solaris 8. When I get a few
> mintues, I'll build without the patch to see what the problem was...
I wouldn't worry about it. The /bin/sh on Solaris 8 is pretty hopelessly
broken for our use. At the very least it doesn't understand $()
subsititution.
-Peff
^ permalink raw reply
* Re: [PATCH v2 6/7] check_ref_format(): tighten refname rules
From: Shawn O. Pearce @ 2009-03-23 13:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <345e795e1891c628ad8356b730fade9f7a81e2f6.1237791716.git.gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> This changes the rules for refnames to forbid:
>
> (1) a refname that contains "@{" in it.
> (2) a refname that ends with a dot.
How about also "that end in .lock" ?
$ git branch foo.lock
$ git branch foo
fatal: Unable to create '.git/refs/heads/foo.lock': File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to contin
Oh, apparently there is also something wrong with the error message...
$ git version
git version 1.6.2.1.433.g0cbc
--
Shawn.
^ permalink raw reply
* Re: git rebase + fuzz = possible bad merge
From: Thomas Rast @ 2009-03-23 13:54 UTC (permalink / raw)
To: Benny Halevy; +Cc: Git List
In-Reply-To: <49C7675E.9000309@panasas.com>
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
Benny Halevy wrote:
> I'm hitting bad merges with (non interactive) git rebase
> when a hunk is merged pre-maturely into an inexact match
> when there's fuzz.
[...]
> { for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
[...]
> git rebase --onto test_branch master^ master
git-am, and by extension rebase, by default doesn't take history into
account. It just applies the patches "blindly". Thus, there's no way
to know which series of 'line N' you really wanted it to go onto.
To avoid this issue, use the -m option to git-rebase so that it uses a
"real" merge. (You can achieve similar effects for git-am with the -3
option.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Importing Bzr revisions
From: Shawn O. Pearce @ 2009-03-23 13:55 UTC (permalink / raw)
To: David Reitter; +Cc: Junio C Hamano, git
In-Reply-To: <03AC7EDA-2A9F-4626-A67B-CE9F2A88FC7D@gmail.com>
David Reitter <david.reitter@gmail.com> wrote:
>
> I'm just experimenting with "bzr fast-export", which converts to git,
> and it seems to take about 4 minutes for 1000 revisions on our (modern)
> server. That would be around 7 hours for my emacs repository; I can't do
> that daily.
No, you'd want to incrementally do that...
> I wonder if there's a way for (bzr) fast-export / (git) fast-import to
> work incrementally, i.e. for selected or most recent revisions.
fast-import supports incremental use; git-p4 does it from Perforce.
The trick is the application writing the stream (bzr fast-export
in this case) needs to do something to pick up the prior revisions.
It might do that by using the same mark numbers, and requiring you
to use --import-marks and --export-marks on the git side to save the
mark database between runs. I don't know, I haven't looked at it.
> Or, one could do something like bzr diff -r $REV.. $BBRANCH | (cd
> $GBRANCH; patch -p0; git commit), plus preserving authors and log
> messages. Is this roughly what the fast-export format does anyways?
Eh, sort of.
The fast-import format works on whole files, not patches. So we
have to get the entire file from bzr each time it is modified.
If the file is a small source file, you almost can't tell the
difference in performance. If its a huge binary that changes often,
it hurts to keep dumping the entire thing over the stream.
But at the commit level, yes, it preserves authorship and log
messages, assuming the bzr fast-export program incldued that data.
And I'm rather certain it does.
--
Shawn.
^ permalink raw reply
* Re: Importing Bzr revisions
From: David Reitter @ 2009-03-23 13:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiwo8xz7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
On Mar 23, 2009, at 4:06 AM, Junio C Hamano wrote:
>
>> 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
I'm just experimenting with "bzr fast-export", which converts to git,
and it seems to take about 4 minutes for 1000 revisions on our
(modern) server. That would be around 7 hours for my emacs
repository; I can't do that daily.
I wonder if there's a way for (bzr) fast-export / (git) fast-import to
work incrementally, i.e. for selected or most recent revisions.
Or, one could do something like bzr diff -r $REV.. $BBRANCH | (cd
$GBRANCH; patch -p0; git commit), plus preserving authors and log
messages. Is this roughly what the fast-export format does anyways?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply
* Re: [PATCH] documentation: Makefile accounts for SHELL_PATH setting
From: Ben Walton @ 2009-03-23 12:57 UTC (permalink / raw)
To: Jeff King; +Cc: GIT List
In-Reply-To: <20090323065710.GA7048@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
Excerpts from Jeff King's message of Mon Mar 23 02:57:10 -0400 2009:
> 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.
That's a fair point. I've been lugging this around for a bit in the
build tree I use, so I don't recall specifically what was breaking.
The sh in question is the one found in solaris 8. When I get a few
mintues, I'll build without the patch to see what the problem was...
> The patch itself looks fine; thanks for addressing my concerns.
Thanks for the helpful feedback! :)
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Live Gentoo Ebuild (Git via Git on Gentoo)
From: Sebastian Pipping @ 2009-03-23 12:47 UTC (permalink / raw)
To: git
It's in the "sping" overlay, get it through ..
layman -a sping
autounmask -n dev-util/git-9999-r3
emerge git -v
Sebastian
^ permalink raw reply
* [PATCH 4/4] builtin-fast-export.c: handle nested tags
From: Erik Faye-Lund @ 2009-03-23 12:53 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1237812789-1360-3-git-send-email-kusmabite@gmail.com>
When tags that points to tags are passed to fast-export, an error saying
"Tag [TAGNAME] points nowhere?". This fix calls parse_object() on the object
before referencing it's tag, to ensure the tag-info is fully initialized. In
addition, it inserts a comment to point out where nested tags are handled. This
is consistent with the comment for signed tags.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 5 ++++-
t/t9301-fast-export.sh | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index e716eee..8083c5f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -362,7 +362,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
break;
case OBJ_TAG:
tag = (struct tag *)e->item;
+
+ /* handle nested tags */
while (tag && tag->object.type == OBJ_TAG) {
+ parse_object(tag->object.sha1);
string_list_append(full_name, extra_refs)->util = tag;
tag = (struct tag *)tag->tagged;
}
@@ -375,7 +378,7 @@ static void get_tags_and_duplicates(struct object_array *pending,
case OBJ_BLOB:
handle_object(tag->object.sha1);
continue;
- default:
+ default: /* OBJ_TAG (nested tags) is already handled */
warning("Tag points to object of unexpected type %s, skipping.",
typename(tag->object.type));
continue;
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index 79ca832..7e94893 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -267,7 +267,7 @@ test_expect_success 'cope with tagger-less tags' '
# NEEDSWORK: not just check return status, but validate the output
test_expect_success 'tree_tag' 'git fast-export tree_tag'
test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
-test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
-test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
+test_expect_success 'tag-obj_tag' 'git fast-export tag-obj_tag'
+test_expect_success 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
test_done
--
1.6.2.1.225.g9a4a0.dirty
^ permalink raw reply related
* [PATCH 3/4] builtin-fast-export.c: fix crash on tagged trees
From: Erik Faye-Lund @ 2009-03-23 12:53 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1237812789-1360-2-git-send-email-kusmabite@gmail.com>
If a tag object points to a tree (or another unhandled type), the commit-
pointer is left uninitialized and later dereferenced. This patch adds a default
case to the switch that issues a warning and skips the object.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 4 ++++
t/t9301-fast-export.sh | 5 ++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 02bad1f..e716eee 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -375,6 +375,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
case OBJ_BLOB:
handle_object(tag->object.sha1);
continue;
+ default:
+ warning("Tag points to object of unexpected type %s, skipping.",
+ typename(tag->object.type));
+ continue;
}
break;
default:
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index db4b0b3..79ca832 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -265,9 +265,8 @@ test_expect_success 'cope with tagger-less tags' '
'
# NEEDSWORK: not just check return status, but validate the output
-# two tests commented out due to crash and thus unreliable return code
-#test_expect_success 'tree_tag' 'git fast-export tree_tag'
-#test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
+test_expect_success 'tree_tag' 'git fast-export tree_tag'
+test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
--
1.6.2.1.225.g9a4a0.dirty
^ permalink raw reply related
* [PATCH 2/4] builtin-fast-export.c: turn error into warning
From: Erik Faye-Lund @ 2009-03-23 12:53 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
In-Reply-To: <1237812789-1360-1-git-send-email-kusmabite@gmail.com>
fast-import doesn't have a syntax to support tree-objects (and some other
object-types), so fast-export shouldn't handle them. However, aborting the
operation is a bit drastic. This patch turns the error into a warning instead.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
builtin-fast-export.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index fdf4ae9..02bad1f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -378,8 +378,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
}
break;
default:
- die ("Unexpected object of type %s",
- typename(e->item->type));
+ warning("%s: Unexpected object of type %s, skipping.",
+ e->name,
+ typename(e->item->type));
+ continue;
}
if (commit->util)
/* more than one name for the same object */
--
1.6.2.1.225.g9a4a0.dirty
^ permalink raw reply related
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