* Re: Bug in git-show-branch, or in core-tutorial?
From: Sergei Organov @ 2007-11-01 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5ictrx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think that is a simple typo of "these", not "three".
No, the explanation text explicitly mentions merge~1 revision that is
not there in the git-show-branch output, so those "three" is consistent
with explanation text itself, but not with git-show-branch output.
--
Sergei.
^ permalink raw reply
* Re: [PATCH 1/5] prune-packed: don't call display_progress() for every file
From: Nicolas Pitre @ 2007-11-01 12:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071101025830.GX14735@spearce.org>
On Wed, 31 Oct 2007, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > The progress count is per fanout directory, so it is useless to call
> > it for every file as the count doesn't change that often.
>
> If you go back into the history and look at the commit message for
> when I introduced this per-object display_progress() call we find
> the following:
>
> commit b5d72f0a4cd3cce945ca0d37e4fa0ebbfcdcdb52
> Author: Shawn O. Pearce <spearce@spearce.org>
> Date: Fri Oct 19 00:08:37 2007 -0400
>
> [...snip...]
> We perform the display_progress() call from within the very innermost
> loop in case we spend more than 1 second within any single object
> directory. This ensures that a progress_update event from the
> timer will still trigger in a timely fashion and allow the user to
> see the progress meter.
Hmmmm OK. I overlooked that.
> During my testing with a 40,000 loose object case (yea, I fully
> unpacked a git.git clone I had laying around) my system stalled
> hard in the first object directory. A *lot* longer than 1 second.
> So I got no progress meter for a long time, and then a progress
> meter appeared on the second directory.
But then don't you get a "0% (1/256)" on the screen for a while, like if
it was stalled? Might be better than nothing at all I suppose...
> So I'm a little against this patch. But I think I understand why
> you think its worth doing. I just consider the progress feedback
> more important than the few machine cycles avoiding it saves.
OK, I don't mind reverting the patch, or actually providing another one
to move the call back inside the loop since other changes will prevent a
clean revert.
Nicolas
^ permalink raw reply
* [PATCH 3/3] gitweb: Use href(-replay=>1, action=>...) to generate alternate views
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Use href(action=>..., -replay=>1) to generate links to alternate views
of current page in the $formats_nav (bottom) part of page_nav
navigation bar. This form is used only when all parameters are
repeated, and when the replay form is shorter.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 29 +++++++++++------------------
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 20d4009..827f977 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3911,11 +3911,11 @@ sub git_blame2 {
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
- $cgi->a({-href => href(action=>"blob", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blob", -replay=>1)},
"blob") .
" | " .
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
- "history") .
+ $cgi->a({-href => href(action=>"history", -replay=>1)},
+ "history") .
" | " .
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
"HEAD");
@@ -4191,18 +4191,15 @@ sub git_blob {
if (defined $file_name) {
if ($have_blame) {
$formats_nav .=
- $cgi->a({-href => href(action=>"blame", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blame", -replay=>1)},
"blame") .
" | ";
}
$formats_nav .=
- $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"history", -replay=>1)},
"history") .
" | " .
- $cgi->a({-href => href(action=>"blob_plain",
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blob_plain", -replay=>1)},
"raw") .
" | " .
$cgi->a({-href => href(action=>"blob",
@@ -4210,7 +4207,8 @@ sub git_blob {
"HEAD");
} else {
$formats_nav .=
- $cgi->a({-href => href(action=>"blob_plain", hash=>$hash)}, "raw");
+ $cgi->a({-href => href(action=>"blob_plain", -replay=>1)},
+ "raw");
}
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
@@ -4273,8 +4271,7 @@ sub git_tree {
my @views_nav = ();
if (defined $file_name) {
push @views_nav,
- $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"history", -replay=>1)},
"history"),
$cgi->a({-href => href(action=>"tree",
hash_base=>"HEAD", file_name=>$file_name)},
@@ -4742,10 +4739,7 @@ sub git_blobdiff {
# header
if ($format eq 'html') {
my $formats_nav =
- $cgi->a({-href => href(action=>"blobdiff_plain",
- hash=>$hash, hash_parent=>$hash_parent,
- hash_base=>$hash_base, hash_parent_base=>$hash_parent_base,
- file_name=>$file_name, file_parent=>$file_parent)},
+ $cgi->a({-href => href(action=>"blobdiff_plain", -replay=>1)},
"raw");
git_header_html(undef, $expires);
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
@@ -4819,8 +4813,7 @@ sub git_commitdiff {
my $formats_nav;
if ($format eq 'html') {
$formats_nav =
- $cgi->a({-href => href(action=>"commitdiff_plain",
- hash=>$hash, hash_parent=>$hash_parent)},
+ $cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
"raw");
if (defined $hash_parent &&
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/3] gitweb: Use href(-replay=>1, page=>...) to generate pagination links
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Use href(-replay=>1, page=>$page-1) and href(-replay=>1, page=>$page+1)
to generate previous page and next page links.
Generate next page link only once.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 44 +++++++++++++++-----------------------------
1 files changed, 15 insertions(+), 29 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index eaab895..20d4009 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2518,7 +2518,7 @@ sub format_paging_nav {
if ($page > 0) {
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>$action, hash=>$hash, page=>$page-1),
+ $cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
$paging_nav .= " ⋅ prev";
@@ -2526,7 +2526,7 @@ sub format_paging_nav {
if ($nrevs >= (100 * ($page+1)-1)) {
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>$action, hash=>$hash, page=>$page+1),
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
} else {
$paging_nav .= " ⋅ next";
@@ -4448,7 +4448,7 @@ sub git_log {
}
if ($#commitlist >= 100) {
print "<div class=\"page_nav\">\n";
- print $cgi->a({-href => href(action=>"log", hash=>$hash, page=>$page+1),
+ print $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
print "</div>\n";
}
@@ -5015,27 +5015,20 @@ sub git_history {
file_name=>$file_name)},
"first");
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name, page=>$page-1),
+ $cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
$paging_nav .= "first";
$paging_nav .= " ⋅ prev";
}
- if ($#commitlist >= 100) {
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- } else {
- $paging_nav .= " ⋅ next";
- }
my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name, page=>$page+1),
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
+ $paging_nav .= " ⋅ $next_link";
+ } else {
+ $paging_nav .= " ⋅ next";
}
git_header_html();
@@ -5105,30 +5098,23 @@ sub git_search {
searchtext=>$searchtext, searchtype=>$searchtype)},
"first");
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"search", hash=>$hash,
- searchtext=>$searchtext, searchtype=>$searchtype,
- page=>$page-1),
+ $cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
$paging_nav .= "first";
$paging_nav .= " ⋅ prev";
}
+ my $next_link = '';
if ($#commitlist >= 100) {
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"search", hash=>$hash,
- searchtext=>$searchtext, searchtype=>$searchtype,
- page=>$page+1),
+ $next_link =
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
+ $paging_nav .= " ⋅ $next_link";
} else {
$paging_nav .= " ⋅ next";
}
- my $next_link = '';
+
if ($#commitlist >= 100) {
- $next_link =
- $cgi->a({-href => href(action=>"search", hash=>$hash,
- searchtext=>$searchtext, searchtype=>$searchtype,
- page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
}
git_print_page_nav('','', $hash,$co{'tree'},$hash, $paging_nav);
@@ -5327,7 +5313,7 @@ sub git_shortlog {
my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
- $cgi->a({-href => href(action=>"shortlog", hash=>$hash, page=>$page+1),
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/3] gitweb: Easier adding/changing parameters to current URL
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Add boolean option '-replay' to href() subroutine, which is used to
generate links in gitweb. This option "replays" current URL,
overriding it with provided parameters. It means that current value
of each CGI parameter is used unless otherwise provided.
This change is meant to make it easier to generate links which differ
from current page URL only by one parameter, for example the same view
but sorted by different column:
href(-replay=>1, order=>"age")
or view which differs by some option, e.g. in log views
href(-replay=>1, extra_options=>"--no-merges")
or alternate view of the same object, e.g. in the 'blob' view
href(-replay=>1, action=>"blob_plain")
Actual use of this functionality is left for later.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e36dec1..eaab895 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -611,6 +611,15 @@ sub href(%) {
);
my %mapping = @mapping;
+ if ($params{-replay}) {
+ while (my ($name, $symbol) = each %mapping) {
+ if (!exists $params{$name}) {
+ # to allow for multivalued params we use arrayref form
+ $params{$name} = [ $cgi->param($symbol) ];
+ }
+ }
+ }
+
$params{'project'} = $project unless exists $params{'project'};
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
--
1.5.3.4
^ permalink raw reply related
* [PATCH 0/3] gitweb: Simplify some gitweb URLs generation
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git
This series of patches simplifies some gitweb URLs generation by
providing -replay option to href() subroutine, and then using this
feature in gitweb code.
Shortlog:
gitweb: Easier adding/changing parameters to current URL
gitweb: Use href(-replay=>1, page=>...) to generate pagination links
gitweb: Use href(-replay=>1, action=>...) to generate alternate views
Diffstat:
gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
1 files changed, 35 insertions(+), 47 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 0/3] gitweb: Simplify some gitweb URLs generation
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
1 files changed, 35 insertions(+), 47 deletions(-)
gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
1 files changed, 35 insertions(+), 47 deletions(-)
[PATCH 1/3] gitweb: Easier adding/changing parameters to current URL
[PATCH 2/3] gitweb: Use href(-replay=>1, page=>...) to generate pagination links
[PATCH 3/3] gitweb: Use href(-replay=>1, action=>...) to generate alternate views
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-01 11:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710280943090.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> The cost is not generally in outputting the commits. The real cost is in
> traversing them in the first place.
Actually, the biggest cost is still gitk reading in the commits from
git log and doing the processing that gitk needs to do on each commit
(which I have tried to minimize, and is way smaller than it used to
be, but is still significant).
In fact that would go significantly faster if git log could output the
data for each commit in a slightly different format. What would be
good is to get one header line for each commit in the form:
id flag {parent parent parent...} length
where:
id is the 40-char SHA1 for the commit
flag is normally 1, but is 0 for "boundary" commits, 2 for "left-side"
commits (with --merge), or 3 for "right-side" commits
length is the number of characters of commit data that follow
(which may differ from the number of bytes, so there would need
to be agreement on the encoding)
followed by the body of the commit (with no null or other separator
character between commits).
That would be easier to parse in Tcl, and looks like it would knock
another 1.5 seconds off the gitk startup time (for the kernel
repository on my G5).
Paul.
^ permalink raw reply
* [PATCH 1/2] gitweb: Always set 'from_file' and 'to_file' in parse_difftree_raw_line
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193917089-15920-1-git-send-email-jnareb@gmail.com>
Always set 'from_file' and 'to_file' keys when parsing raw diff output
format line, even if filename didn't change (file was not renamed).
This allows for simpler code (and no problems with file named '0').
Use
$diffinfo->{'from_file'}
instead of
$diffinfo->{'from_file'} || $diffinfo->{'file'}
from now on.
While at it, replace (for merge commits)
$diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'}
by
defined $diffinfo->{'from_file'}[$i] ?
$diffinfo->{'from_file'}[$i] :
$diffinfo->{'to_file'};
to have no problems woth file named '0'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2e00756..79ea7ec 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1995,7 +1995,7 @@ sub parse_difftree_raw_line {
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
} else {
- $res{'file'} = unquote($7);
+ $res{'from_file'} = $res{'to_file'} = $res{'file'} = unquote($7);
}
}
# '::100755 100755 100755 60e79ca1b01bc8b057abe17ddab484699a7f5fdb 94067cc5f73388f33722d52ae02f44692bc07490 94067cc5f73388f33722d52ae02f44692bc07490 MR git-gui/git-gui.sh'
@@ -2062,7 +2062,10 @@ sub parse_from_to_diffinfo {
fill_from_file_info($diffinfo, @parents)
unless exists $diffinfo->{'from_file'};
for (my $i = 0; $i < $diffinfo->{'nparents'}; $i++) {
- $from->{'file'}[$i] = $diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'};
+ $from->{'file'}[$i] =
+ defined $diffinfo->{'from_file'}[$i] ?
+ $diffinfo->{'from_file'}[$i] :
+ $diffinfo->{'to_file'};
if ($diffinfo->{'status'}[$i] ne "A") { # not new (added) file
$from->{'href'}[$i] = href(action=>"blob",
hash_base=>$parents[$i],
@@ -2074,7 +2077,7 @@ sub parse_from_to_diffinfo {
}
} else {
# ordinary (not combined) diff
- $from->{'file'} = $diffinfo->{'from_file'} || $diffinfo->{'file'};
+ $from->{'file'} = $diffinfo->{'from_file'};
if ($diffinfo->{'status'} ne "A") { # not new (added) file
$from->{'href'} = href(action=>"blob", hash_base=>$hash_parent,
hash=>$diffinfo->{'from_id'},
@@ -2084,7 +2087,7 @@ sub parse_from_to_diffinfo {
}
}
- $to->{'file'} = $diffinfo->{'to_file'} || $diffinfo->{'file'};
+ $to->{'file'} = $diffinfo->{'to_file'};
if (!is_deleted($diffinfo)) { # file exists in result
$to->{'href'} = href(action=>"blob", hash_base=>$hash,
hash=>$diffinfo->{'to_id'},
@@ -2829,7 +2832,7 @@ sub is_patch_split {
my ($diffinfo, $patchinfo) = @_;
return defined $diffinfo && defined $patchinfo
- && ($diffinfo->{'to_file'} || $diffinfo->{'file'}) eq $patchinfo->{'to_file'};
+ && $diffinfo->{'to_file'} eq $patchinfo->{'to_file'};
}
@@ -4667,8 +4670,8 @@ sub git_blobdiff {
}
%diffinfo = parse_difftree_raw_line($difftree[0]);
- $file_parent ||= $diffinfo{'from_file'} || $file_name || $diffinfo{'file'};
- $file_name ||= $diffinfo{'to_file'} || $diffinfo{'file'};
+ $file_parent ||= $diffinfo{'from_file'} || $file_name;
+ $file_name ||= $diffinfo{'to_file'};
$hash_parent ||= $diffinfo{'from_id'};
$hash ||= $diffinfo{'to_id'};
--
1.5.3.4
^ permalink raw reply related
* [PATCH 0/2] gitweb: Simplify dealing with raw diff output
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git
This series of patches simplifies (and improves) gitweb code dealing
with (parsed) raw diff output format.
See individual patches for more detail.
Table of contents:
[PATCH 1/2] gitweb: Always set 'from_file' and 'to_file'
in parse_difftree_raw_line
[PATCH 2/2] gitweb: Add 'status_str' to parse_difftree_raw_line output
Diffstat:
gitweb/gitweb.perl | 22 +++++++++++++---------
1 files changed, 13 insertions(+), 9 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/2] gitweb: Add 'status_str' to parse_difftree_raw_line output
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193917089-15920-1-git-send-email-jnareb@gmail.com>
Add 'status_str' to diffinfo output, which stores status (also for
merge commit) as a string. This allows for easy checking if there is
given status among all for merge commit, e.g.
$diffinfo->{'status_str'} =~ /D/;
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 79ea7ec..e36dec1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1990,7 +1990,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = $2;
$res{'from_id'} = $3;
$res{'to_id'} = $4;
- $res{'status'} = $5;
+ $res{'status'} = $res{'status_str'} = $5;
$res{'similarity'} = $6;
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
@@ -2006,6 +2006,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = pop @{$res{'from_mode'}};
$res{'from_id'} = [ split(' ', $3) ];
$res{'to_id'} = pop @{$res{'from_id'}};
+ $res{'status_str'} = $4;
$res{'status'} = [ split('', $4) ];
$res{'to_file'} = unquote($5);
}
@@ -2821,7 +2822,7 @@ sub fill_from_file_info {
sub is_deleted {
my $diffinfo = shift;
- return $diffinfo->{'to_id'} eq ('0' x 40);
+ return $diffinfo->{'status_str'} =~ /D/;
}
# does patch correspond to [previous] difftree raw line
--
1.5.3.4
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-01 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vmytycykt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Will revert at least the latter one, but perhaps both, from
> 'next'. The traditional behaviour of refusing to work in a
> dirty tree is much safer, as the tool cannot decide where to
> unstash for you.
One of frequently requested features is ability to rebase and merge
in a dirty tree (CVS-like). Perhaps we should advocate git-stash better,
e.g. in error message for git-rebase / git-merge / git-pull when in dirty
state.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Mike Hommey @ 2007-11-01 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vejfag40g.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 06:15:27PM -0700, Junio C Hamano wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
>
> Why do people want "workaround"? Is installing cpio such a
> hassle?
Note that to do what git-merge does with cpio, i wonder if it wouldn't
be sensible to use git stash, now.
Mike
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-01 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710280943090.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> (And as mentioned many times earlier - if you can avoid topo-order and
> date-order entirely, you are going to perform a million times better at
> startup for the cold-cache case. Since you seem to be doing the graph
> layout lazily now, maybe you could aim for that some day? It does mean
> that you might - occasionally - end up having to add a commit to
> *before* one you already laid out).
The other thing --topo-order does is reorder the commits so that
related commits come together. So far, doing that in Tcl has turned
out to be much slower than having it done in C (within git log) for
the hot-cache case (which I expect is the common case).
I'm now thinking that the best approach would be to have gitk cache
the topology, and on startup only read in the part of the graph that
isn't in the cache. Mostly that will be small and so git log should
be fast even in the cold-cache case with --topo-order.
Paul.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 9:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <0A8A6A99-4C8B-4056-9068-DA54B69B08B5@zib.de>
Steffen Prohaska wrote:
>
> On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
>
>> Junio C Hamano wrote:
>>
>>> (actually, shared repository people seem to
>>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>>
>> That's definitely true. The number of useless merge-commits we
>> have in our repos is annoying, and has twice made bisect a bit
>> troublesome for no good reason.
>
> Can you describe a bit more what's "annoying" about them?
> Is it the visualization? Or are there more problems; like
> the trouble with bisect?
>
Visualization is a small nuissance. git-bisect troubles are more
worrisome. I've been in the seat where useless merges means git
bisect needs constant babysitting and constant manual handling.
It's no fun at all, so we're sticking with the fetch+rebase flow.
> I'm trying to estimate if it's worth teaching _all_
> developers rebase or if we should just live with the "useless"
> merge-commits.
>
I'd say that depends on how valuable you find gitk, qgit and
git-bisect are. To me, I'd happily use any scm in the world,
so long as it has git-bisect. Otoh, I'm a lazy bastard and
love bisect so much that all our automated tests are focused
around "git bisect run". This means bugs in software released
to customers are few and far apart. When we get one reported,
we just create a new test that exposes it, fire up git-bisect
and then go to lunch. Quality costs, however. We pay that bill
by using a workflow that's perhaps more convoluted than
necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 9:11 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <6B0CD829-A964-410B-8C23-74D26BD2C0FA@zib.de>
Steffen Prohaska wrote:
>
> On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>>> You forgot a lot more important part. Pushing into publishing
>>>> repositories. And the discussion is about git-push command.
>>>
>>> Exactly, here are two examples:
>>>
>>> If you push only to publishing repositories that are read
>>> only by others, you'll never encounter the problem that
>>> 10/10 tried to solve. The publishing repository is never
>>> changed by others. You are the only one who pushes to this
>>> repository. Therefore the remote never advances unexpectedly.
>>
>> Wrong.
>>
>> People can and do work from more than one private repositories
>> (I do). In a sense, that is sharing the repository with
>> oneself.
>
> I do, too. But as long as I do not forget what I've done, the
> branches do not advance _unexpectedly_. I am in full control.
>
>
>> I may do an emergency patch to fix breakage on 'maint' (and
>> 'maint' only) from a location that is not my primary development
>> box and push the fix out. I fully expect that the push will
>> push out 'maint' and expect the other branches such as 'master'
>> on the remote side to stay the same, as I haven't touched
>> 'master' on that box for quite a while and it is now stale. In
>> that situation, I _want_ the "git push" itself to report failure
>> to notify me that it did not push what _I_ asked it to push out,
>> so that I can be reminded that I'd better do "git push $remote
>> maint" the next time. In the meantime, even though it reports
>> a failure, 'master' on the remote side is _not_ updated, so the
>> behaviour is still _safe_.
>
> You're right it is safe, but it may be confusing.
>
>
>>> Another difference is the way changes are integrated. In
>>> a workflow without shared repositories, only pull is used
>>> for integration, while push in only used for publishing the
>>> changes.
>>
>> Wrong. push is a mirror of fetch and does not do _any_
>> integration. It is just a safe (because it insists on
>> fast-forward) propagation mechanism. Your integration still
>> happens with pull (actually, shared repository people seem to
>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
> Right; but you can't push without doing the integration. If you
> have new changes on the remote side you _must_ pull before
> you can push.
Yes, because otherwise you'd rewrite published history. That's not
a good thing.
> You're forced to do the integration immediately.
Yes, but you get to choose how. Perhaps git-push should list more
options than just git-pull, such as the three commands required to
rebase the currently checked out branch onto its remote counterpart.
That would support more workflows.
> Your main objective was to push, but the shared workflow forces
> you to do the integration _now_ (by using pull). In a pull-only
> workflow, you can just push and defere the integration for later.
>
No, you can also fetch + rebase.
> Some people claim fetch + rebase is superior to fetch + merge.
> The only point I can see is that fetch + rebase gives a linear
> history without loops, which is nicer to visualize. I recently
> asked on the list if there are any benefits of fetch + rebase
> over fetch + merge, besides a nicer visualization.
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
> I didn't
> receive many interesting comments. One comment explained
> that rebase can shift the merge conflict resolution from
> the maintainer (merge) to the original author (rebase). But
> this is not very interesting in a shared workflow, because
> the author must resolve conflicts in any case before he can
> push. It doesn't matter much if he uses merge or rebase to
> do so.
>
It depends. When commit ordering doesn't matter the original
author can use "git rebase --skip" and then continue with the
rebase to get as much as possible out as quickly as possible.
I'm in the unfortunate position of having a boss that likes
to fiddle with help-texts in code when it's in alpha-testing.
Sometimes that causes conflicts but it's often not important
enough to spend 30 minutes figuring out how to resolve it
properly. I tend to just skip those patches and send them as
emails to our tech-writer instead, asking him to rephrase the
text to incorporate both changes, and then manually applying
the text to the end result.
>
> I am searching for a solution that just works for them. They
> currently use CVS. I'll give them a detailed getting started
> document for git. The workflow described should be as simple as
> possible, but safe and reliable.
If they're used to CVS and want to use more than one branch without
having to learn additional syntax, nothing can help, methinks.
>
> Another question is what to do with a local branch after
> you finished work. We recently had the
> "Re: best git practices, was Re: Git User's Survey 2007
> unfinished summary continued" aka the 200-local-branches
> discussion.
>
We're at 224 branches now, having added 7 new repos.
> There were different suggestions what to do. A reasonable
> suggestion was to delete the local branch after you're done.
Except that it doesn't work unless you either detach the HEAD
(which prints a big fat ugly message) or give it -D to force
it, which I really, really don't recommend. We use git because
I'm pretty confident in its capabilities of never ever losing
anything. Using the seemingly harmless -D switch to git-branch
puts us at risk of wiping history quite without noticing.
> This clearly distinguishes between remote branches (which are
> mirrored as a remote tracking branch) and local branches. Local
> branches are _your_ branches while the remote branches contain
> the shared work. If you're done with your local work, delete
> your local branch. So maybe you should do
>
> git checkout origin/devel
Except that this gives a warning-esque message:
Note: moving to "origin/devel" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at deadbeef... Ma! Pa butchered all the cows!
To me, this indicates I've done something git thinks I shouldn't have.
>
> Independently of what the best practice is, leaving the local
> work branch there shouldn't do any harm because I'm sure that
> some devs will forget to clean up, independently of what I tell
> them.
>
I wholeheartedly agree with this one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] git-clone.txt: Improve --depth description.
From: Ralf Wildenhues @ 2007-11-01 8:46 UTC (permalink / raw)
To: git, Junio C Hamano
Avoid abbreviation 'revs', improve the language a bit.
---
Documentation/git-clone.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 253f4f0..cca14d6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -111,11 +111,11 @@ OPTIONS
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
- specified number of revs. A shallow repository has
+ specified number of revisions. A shallow repository has a
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
- want to only look at near the tip of a large project
- with a long history, and would want to send in a fixes
+ are only interested in the recent history of a large project
+ with a long history, and would want to send in fixes
as patches.
<repository>::
--
1.5.3.1.522.g85b0
^ permalink raw reply related
* [PATCH] git-rev-list.txt: rev stands for revision, not reverse.
From: Ralf Wildenhues @ 2007-11-01 8:45 UTC (permalink / raw)
To: git, Junio C Hamano
Mention revs, revisions as aliases for commit objects,
to clarify that rev-list is not an abbreviation for
listing in reverse order, but for listing revisions.
---
Yes, believe it or not, but I stumbled over the synopsis
| git-rev-list - Lists commit objects in reverse chronological order
asking myself whether rev could possibly mean "reverse".
I hope this helps avoid this pitfall for others.
Cheers,
Ralf
Documentation/git-rev-list.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 4852804..8afe34b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -44,9 +44,9 @@ SYNOPSIS
DESCRIPTION
-----------
-Lists commit objects in reverse chronological order starting at the
-given commit(s), taking ancestry relationship into account. This is
-useful to produce human-readable log output.
+Lists commit objects (revs, revisions) in reverse chronological order
+starting at the given commit(s), taking ancestry relationship into
+account. This is useful to produce human-readable log output.
Commits which are stated with a preceding '{caret}' cause listing to
stop at that point. Their parents are implied. Thus the following
--
1.5.3.3.g34c6d
^ permalink raw reply related
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-01 8:36 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <47298BD7.2000902@op5.se>
On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>
>> (actually, shared repository people seem to
>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
> That's definitely true. The number of useless merge-commits we
> have in our repos is annoying, and has twice made bisect a bit
> troublesome for no good reason.
Can you describe a bit more what's "annoying" about them?
Is it the visualization? Or are there more problems; like
the trouble with bisect?
I'm trying to estimate if it's worth teaching _all_
developers rebase or if we should just live with the "useless"
merge-commits.
Steffen
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git
In-Reply-To: <7vlk9jgeee.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>>> You forgot a lot more important part. Pushing into publishing
>>> repositories. And the discussion is about git-push command.
>> Exactly, here are two examples:
>>
>> If you push only to publishing repositories that are read
>> only by others, you'll never encounter the problem that
>> 10/10 tried to solve. The publishing repository is never
>> changed by others. You are the only one who pushes to this
>> repository. Therefore the remote never advances unexpectedly.
>
> Wrong.
>
> People can and do work from more than one private repositories
> (I do). In a sense, that is sharing the repository with
> oneself.
>
I believe your troubles are alleviated a great deal by the fact
that you actually know when upstream has changes, and what those
changes are supposed to be. A communications breakdown with only
one person involved is sort of hard to imagine.
> (actually, shared repository people seem to
> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
That's definitely true. The number of useless merge-commits we
have in our repos is annoying, and has twice made bisect a bit
troublesome for no good reason.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: remote#branch
From: Andreas Ericsson @ 2007-11-01 7:29 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <20071031091529.GA25025@glandium.org>
Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae@op5.se> wrote:
>>> Or copied from gitweb.
>>>
>> Perhaps, but I've never seen that done. Partly because you can't be sure
>> the HTTP url is the same as the git address (perhaps people are used to
>> this from CVS and the likes), and partly because you'd, for most cases,
>> want to use git:// or ssh transport instead of http.
>>
>> It might be nifty to have gitweb print some git-valid locator for a repo
>> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
>> command-line thingie. I'll look into it when I have leisure.
>
> Hum... it already does print http and git "Mirror URL"s which are ready to
> be copy/pasted to feed git clone arguments.
>
True that. I went looking for such an option a long time ago and didn't find
it. I should do my research better.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Bug in git-show-branch, or in core-tutorial?
From: Junio C Hamano @ 2007-11-01 7:24 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <878x5j3uos.fsf@osv.gnss.ru>
I think that is a simple typo of "these", not "three".
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-01 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk9jgeee.fsf@gitster.siamese.dyndns.org>
On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>>> You forgot a lot more important part. Pushing into publishing
>>> repositories. And the discussion is about git-push command.
>>
>> Exactly, here are two examples:
>>
>> If you push only to publishing repositories that are read
>> only by others, you'll never encounter the problem that
>> 10/10 tried to solve. The publishing repository is never
>> changed by others. You are the only one who pushes to this
>> repository. Therefore the remote never advances unexpectedly.
>
> Wrong.
>
> People can and do work from more than one private repositories
> (I do). In a sense, that is sharing the repository with
> oneself.
I do, too. But as long as I do not forget what I've done, the
branches do not advance _unexpectedly_. I am in full control.
> I may do an emergency patch to fix breakage on 'maint' (and
> 'maint' only) from a location that is not my primary development
> box and push the fix out. I fully expect that the push will
> push out 'maint' and expect the other branches such as 'master'
> on the remote side to stay the same, as I haven't touched
> 'master' on that box for quite a while and it is now stale. In
> that situation, I _want_ the "git push" itself to report failure
> to notify me that it did not push what _I_ asked it to push out,
> so that I can be reminded that I'd better do "git push $remote
> maint" the next time. In the meantime, even though it reports
> a failure, 'master' on the remote side is _not_ updated, so the
> behaviour is still _safe_.
You're right it is safe, but it may be confusing.
>> Another difference is the way changes are integrated. In
>> a workflow without shared repositories, only pull is used
>> for integration, while push in only used for publishing the
>> changes.
>
> Wrong. push is a mirror of fetch and does not do _any_
> integration. It is just a safe (because it insists on
> fast-forward) propagation mechanism. Your integration still
> happens with pull (actually, shared repository people seem to
> prefer "fetch + rebase" over "pull" which is "fetch + merge").
Right; but you can't push without doing the integration. If you
have new changes on the remote side you _must_ pull before
you can push. You're forced to do the integration immediately.
Your main objective was to push, but the shared workflow forces
you to do the integration _now_ (by using pull). In a pull-only
workflow, you can just push and defere the integration for later.
Some people claim fetch + rebase is superior to fetch + merge.
The only point I can see is that fetch + rebase gives a linear
history without loops, which is nicer to visualize. I recently
asked on the list if there are any benefits of fetch + rebase
over fetch + merge, besides a nicer visualization. I didn't
receive many interesting comments. One comment explained
that rebase can shift the merge conflict resolution from
the maintainer (merge) to the original author (rebase). But
this is not very interesting in a shared workflow, because
the author must resolve conflicts in any case before he can
push. It doesn't matter much if he uses merge or rebase to
do so.
I evaluated if teaching people fetch + rebase before teaching
fetch + merge is a good idea. Therefore I tested some scenarios
with people who are new to git. The result is that there are
too many situations where fetch + rebase might be confusing.
I abandoned my idea.
I decided that fetch + merge is _easier_. It works in all
situations, it's easier to explain, it's better supported
(automerge), it can be used to work on shared topic branches.
Definitely fetch + merge is the first workflow you should
learn. At the moment I'm not anymore interested in the fetch +
rebase approach.
>> This is different if you work with a shared repository. Bob
>> checks out the shared branch foo to his local branch bar and
>> later he needs to push bar back to the shared branch foo. Bob
>> needs to push changes from his local branch bar to the branch
>> foo in the remote repository, a branch with a different name.
>> This need does not emerge when working with two publishing
>> repositories, as described above.
>
> So you do "git push $remote bar:foo". If you do that regulary,
> there are configuration mechanisms to help you reduce your
> keyboard wear. What's the problem?
Too complex and not flexible enough.
The configuration is in the remote section. Therefore I can
tell git what to do only on a per-branch basis. What do you
think about my recent proposal to add branch.$name.push?
And I want to avoid that people need to learn about the details
of the configuration mechanism on the first time they use git.
I am searching for a solution that just works for them. They
currently use CVS. I'll give them a detailed getting started
document for git. The workflow described should be as simple as
possible, but safe and reliable. No confusing error messages
should appear. Only a few commands should be needed to
contribute to a shared branch. The workflow described should
use git in a sane way that provides opportunities to use more
of its power later.
So here is what I'd like to have.
git clone ssh://server/git/project.git project
[ On Windows the hassel already starts because it actually is
git clone -n ssh://sever/git/project.git project
git config core.autocrlf true
And here's the next point. git config doesn't validate the
variable. It accepts _any_ variable. If you have a typo
you go without autocrlf. ... but this is a different story. ]
cd project
git checkout -b devel origin/devel
# work, commit, work, commit
git push # maybe git pull first, but git would tell you
The last command, git push, can already cause trouble. git
automatically created a local master and the remote master
may have advanced, so git push would complain with an error.
Currently the correct command would be
"git push origin devel".
An alternative scenario is that you want to start work that
will not be ready right away. So you start a topic branch
git checkout -b topic origin/devel
# work, commit, some time passes, work, commit
git pull # integrate changes from devel
# work, commit
git pull
git push # this one should push to origin/devel
In scenario three you planned to finish your work right away
but the problem turned out to be harder. Here, the following
would be nice
git checkout -b devel origin/devel
# work, commit, hmm... much harder ...
git branch -m devel dolater
# do something else
git checkout dolater
# finish work
git pull # integrate with other work on devel
git push # push back to shared branch
Another question is what to do with a local branch after
you finished work. We recently had the
"Re: best git practices, was Re: Git User's Survey 2007
unfinished summary continued" aka the 200-local-branches
discussion.
There were different suggestions what to do. A reasonable
suggestion was to delete the local branch after you're done.
This clearly distinguishes between remote branches (which are
mirrored as a remote tracking branch) and local branches. Local
branches are _your_ branches while the remote branches contain
the shared work. If you're done with your local work, delete
your local branch. So maybe you should do
git checkout origin/devel
git branch -d devel
Now you're on a detached branch that points to origin/work.
But how to do you get new changes from others? git pull would
not work and git fetch neither.
Independently of what the best practice is, leaving the local
work branch there shouldn't do any harm because I'm sure that
some devs will forget to clean up, independently of what I tell
them.
Steffen
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-11-01 6:45 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Mike Hommey, git
In-Reply-To: <fcaeb9bf0710311825k715900a0sa32a95b87cb146c7@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> It is on Windows because busybox cpio is not really good and busybox
> tar is even worse (for cpio emulation). Maybe I should just improve
> busybox cpio :-)
Sounds sensible, as it (at least its -p mode of operation) is
one of the programs that is very useful yet not so well known to
people new to UNIX.
^ permalink raw reply
* Re: [PATCH] git-diff.txt: add section "output format" describing the diff formats
From: Junio C Hamano @ 2007-11-01 6:33 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071031135916.5625.qmail@134c5e95d8ec4d.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
> index 0015032..a580f18 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" and
> -"git-diff-files" are very similar.
> +The output format from "git-diff-index", "git-diff-tree",
> +"git-diff-files" and "git diff --raw" are very similar.
I like this attention to the detail of mentioning "--raw".
> @@ -62,9 +62,9 @@ respectively.
> diff format for merges
> ----------------------
>
> -"git-diff-tree" and "git-diff-files" 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:
> +"git-diff-tree", "git-diff-files" and "git-diff" 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:
... and this part should do so, too.
^ 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