* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Junio C Hamano @ 2012-02-10 4:09 UTC (permalink / raw)
To: git; +Cc: tbushnell, tytso, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vsjijs9rq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> It turns out that this series, as a side effect, fixes a long-standing bug
> that the --branch option cannot be used with the --mirror option.
>
> I am tempted to merge it also to 1.7.9.1 maintenance track. The issue is
> minor (you can always clone with --mirror and then switch the branch with
> "checkout") and it does not look like it warrants further backpointing to
> 1.7.8 and older releases, though.
>
> Comments and/or objections?
Replying to myself.
Regardless of "'refs/heads/$branch' is not found because we do not look
for in the right place" issue, shouldn't the use of the --mirror without
the --bare option forbidden or at least warned about?
Cloning as --mirror, with a working tree with a current branch, would mean
the next fetch would directly try to update it by overwriting. We do pass
the --update-head-ok from pull, so "git pull" in such a repository should
be "sort of" safe, as long as the repository is never used to create its
own commits on whatever local branches set to be overwritten by --mirror,
but still I have this gut feeling that such an arrangement should at least
be discouraged.
Comments and/or opinions?
^ permalink raw reply
* Re: nested git repos (not submodules)
From: Junio C Hamano @ 2012-02-10 4:16 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jh1vo3$7af$1@dough.gmane.org>
"Neal Kreitzinger" <neal@rsss.com> writes:
> In the worktree of a particular git repo, the user has made a subdir
> (worktree/subdir) of the worktree (worktree/.git) its own repo
> (worktree/subdir/.git). Is there a danger of worktree/.git and
> worktree/subdir/.git crossing wires?
The repository controlled by worktree/.git should behave as if subdir/
does not exist, except that obviously the project cannot have a regular
file "subdir" in it. When you chdir to worktree/subdir, everything in
there should behave as if worktree/.git directory does not exist.
At least that is the design, and it indeed is how I arrange my primary
working tree (I have two "clones" at /git/git.git/ and /git/git.git/Meta,
and the latter has a checkout of the "todo" branch), so I would make
noises about any breakage for such a layout.
I do not know offhand if an attempt to add files inside subdir to the
repository controlled by worktree/.git is always correctly prohibited by
the code, though, as our code often forgets to error out "stupid user
mistakes", and running "git add subdir/bar" when in worktree/ falls into
that category.
And the use of that layout predates the submodules by a large margin.
In fact, when people suggest use of submodules when the toplevel and the
sublevel do not even need tight version dependencies, some of their use
cases might be better supported by using the simply-nested layout without
even letting the toplevel be aware of the sublevel.
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Nguyen Thai Ngoc Duy @ 2012-02-10 4:27 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Catalin Marinas, Junio C Hamano, Karl Hasselström,
Andy Green (林安廸), git
In-Reply-To: <20120209175158.GA7384@burratino>
On Fri, Feb 10, 2012 at 12:51 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> No. There is one list of supported headers, and this list is the
> standards body that maintains it[*]. So if you end up needing an
> extension to the commit object format, that can be done, but it needs
> to be accepted here (and ideally checked by "git fsck", though it's
> lagging a bit in that respect lately).
>
> [*] http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138892
Doesn't this deserve a document in Documentation/technical? It's also
a good opportunity to document tree and tag object format in addition
to commit object. I did not check thoroughly but the commit that
introduced encoding field, 4b2bced, did not come with any document
updates, so I assume it has not been documented ever since.
--
Duy
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Nguyen Thai Ngoc Duy @ 2012-02-10 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tbushnell, tytso
In-Reply-To: <7vhayzs51s.fsf@alter.siamese.dyndns.org>
2012/2/10 Junio C Hamano <gitster@pobox.com>:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> It turns out that this series, as a side effect, fixes a long-standing bug
>> that the --branch option cannot be used with the --mirror option.
>>
>> I am tempted to merge it also to 1.7.9.1 maintenance track. The issue is
>> minor (you can always clone with --mirror and then switch the branch with
>> "checkout") and it does not look like it warrants further backpointing to
>> 1.7.8 and older releases, though.
>>
>> Comments and/or objections?
No objections. Does it fix a failed test? If not, should we add a test
to record this side effect fix?
> Replying to myself.
>
> Regardless of "'refs/heads/$branch' is not found because we do not look
> for in the right place" issue, shouldn't the use of the --mirror without
> the --bare option forbidden or at least warned about?
--mirror implies --bare in cmd_clone() if I read it correctly.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] ctype: implement islower/isupper macro
From: Namhyung Kim @ 2012-02-10 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vliobs5bh.fsf@alter.siamese.dyndns.org>
2012-02-10 1:03 PM, Junio C Hamano wrote:
> 김남형<namhyung.kim@lge.com> writes:
>
>> 2012-02-10 11:17 AM, Junio C Hamano wrote:
>>> Namhyung Kim<namhyung.kim@lge.com> writes:
>>>
>>>> The git-compat-util.h provides various ctype macros but lacks those two
>>>> (along with others). Add them.
>>>
>>> Isn't that because we do not use them ourselves? Uses in compat/ do not
>>> count, and judging from the way it is used in compat/fnmatch/fnmatch.c,
>>> the implementation of sane_iscase() might be overly protective.
>>>
>>> What problem are you trying to solve?
>>
>> There's no problem. In fact, these patches come from perf as it uses a
>> copy of git code in this part.
>
> Kim-ssi, the above is something I would have like to see in your first
> message.
>
>> If you don't
>> think it's worth applying I'm fine with dropping it.
>
> I never said these patches are worthless.
>
> I just was wondering what the motivation behind them were. If you are
> involved in maintaining Perf, and if it wants to keep its own forked copy
> as close as ours, that is a good enough justification, as long as the
> additions we do not use ourselves is still reasonably done.
>
Hamano-san, Thanks for your explanation. I'll try to write a better
description for the future.
Thanks,
Namhyung
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Junio C Hamano @ 2012-02-10 5:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, tbushnell, tytso
In-Reply-To: <CACsJy8B_nsZnSarbRaBoxviK1xa_PVP0-DbnMiP9HkwzrztfJg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> No objections. Does it fix a failed test? If not, should we add a test
> to record this side effect fix?
No, it was just "I tried this and it did not work" reported elsewhere, and
it is not v1.7.9 regression. Having seen a failure by a real user, having
a test would be a good idea to protect the fix from regressing.
I actually wish that the commit 9e58504 (clone: --branch=<branch> always
means refs/heads/<branch>, 2012-01-16) wasn't taken hostage to the earlier
changes that add new feature (addition of --single-branch and delaying of
the cloning before checking the remote HEAD); which would have been an
easier sell without violating the usual "no new features to maintenance
track". And the thing is, I do not find this grave enough an issue that
deserves a separate implementation of a fix to be queued to maintenance
tracks.
> --mirror implies --bare in cmd_clone() if I read it correctly.
Yeah, what was I thinking... feeling stupid.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/4] diff --stat: use the real terminal width
From: Nguyen Thai Ngoc Duy @ 2012-02-10 6:15 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-4-git-send-email-zbyszek@in.waw.pl>
2012/2/10 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
> @@ -1341,7 +1342,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
> line_prefix = msg->buf;
> }
>
> - width = options->stat_width ? options->stat_width : 80;
> + width = options->stat_width ? options->stat_width : term_columns();
> name_width = options->stat_name_width ? options->stat_name_width : 50;
> count = options->stat_count ? options->stat_count : data->nr;
I tried this in the past and "git log -p" looked ugly on git.git
mainly because commit messages are still ~70 char long lines on my 279
char wide terminal. If this is project dependent, perhaps a config
key? Also the "50" below the changed line, maybe you want to change it
to 0.6 * width.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Nguyen Thai Ngoc Duy @ 2012-02-10 6:34 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, gitster, peff
In-Reply-To: <1328816616-18124-1-git-send-email-tmgrennan@gmail.com>
On Fri, Feb 10, 2012 at 2:43 AM, Tom Grennan <tmgrennan@gmail.com> wrote:
> Please see the following patch which filters the tag list of "!" prefaced
> patterns. If this is deemed desirable and correct, I'll resubmit with updated
> documentation and unit tests.
git-branch, git-tag and git-for-each-ref are in the same family. I
think it's good to that all three commands share things, like this
pattern matching.
About the '!' for exclusion, maybe it's better to move from fnmatch()
as matching machinery to pathspec. Then when git learns negative
pathspec [1], we have this feature for free.
[1] http://thread.gmane.org/gmane.comp.version-control.git/189645/focus=190072
--
Duy
^ permalink raw reply
* Re: Git performance results on a large repository
From: Nguyen Thai Ngoc Duy @ 2012-02-10 7:12 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CB599BA0.42A6B%joshua.redstone@fb.com>
On Fri, Feb 10, 2012 at 4:06 AM, Joshua Redstone <joshua.redstone@fb.com> wrote:
> Hi Nguyen,
> I like the notion of using --assume-unchanged to cut down the set of
> things that git considers may have changed.
> It seems to me that there may still be situations that require operations
> on the order of the # of files in the repo and hence may still be slow.
> Following is a list of potential candidates that occur to me.
>
> 1. Switching branches, especially if you switch to an old branch.
> Sometimes I've seen branch switching taking a long time for what I thought
> was close to where HEAD was.
>
> 2. Interactive rebase in which you reorder a few commits close to the tip
> of the branch (I observed this taking a long time, but haven't profiled it
> yet). I include here other types of cherry-picking of commits.
>
> 3. Any working directory operations that fail part-way through and make
> you want to do a 'git reset --hard' or at least a full 'git-status'. That
> is, when you have reason to believe that files with 'assume-unchange' may
> have accidentally changed.
All these involve unpack_trees(), which is full tree operation. The
bigger your worktree is, the slower it is. Another good reason to
split unrelated parts into separate repositories.
> 4. Operations that require rewriting the index - I think git-add is one?
>
> If the working-tree representation is the full set of all files
> materialized on disk and it's the same as the representation of files
> changed, then I'm not sure how to avoid some of these without playing file
> system games or using wrapper scripts.
>
> What do you (or others) think?
>
>
> Josh
>
>
> On 2/7/12 8:43 AM, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
>
>>On Mon, Feb 6, 2012 at 10:40 PM, Joey Hess <joey@kitenet.net> wrote:
>>>> Someone on HN suggested making assume-unchanged files read-only to
>>>> avoid 90% accidentally changing a file without telling git. When
>>>> assume-unchanged bit is cleared, the file is made read-write again.
>>>
>>> That made me think about using assume-unchanged with git-annex since it
>>> already has read-only files.
>>>
>>> But, here's what seems a misfeature...
>>
>>because, well.. assume-unchanged was designed to avoid stat() and
>>nothing else. We are basing a new feature on top of it.
>>
>>> If an assume-unstaged file has
>>> modifications and I git add it, nothing happens. To stage a change, I
>>> have to explicitly git update-index --no-assume-unchanged and only then
>>> git add, and then I need to remember to reset the assume-unstaged bit
>>> when I'm done working on that file for now. Compare with running git mv
>>> on the same file, which does stage the move despite assume-unstaged. (So
>>> does git rm.)
>>
>>This is normal in the lock-based "checkout/edit/checkin" model. mv/rm
>>operates on directory content, which is not "locked - no edit allowed"
>>(in our case --assume-unchanged) in git. But lock-based model does not
>>map really well to git anyway. It does not have the index (which may
>>make things more complicated). Also at index level, git does not
>>really understand directories.
>>
>>I think we could add a protection layer to index, where any changes
>>(including removal) to an index entry are only allowed if the entry is
>>"unlocked" (i.e no assume-unchanged bit). Locked entries are read-only
>>and have assume-unchanged bit set. "git (un)lock" are introduced as
>>new UI. Does that make assume-unchanged friendlier?
>>--
>>Duy
>>--
>>To unsubscribe from this list: send the line "unsubscribe git" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: Jonathan Nieder @ 2012-02-10 8:23 UTC (permalink / raw)
To: David Aguilar; +Cc: Jeff Epler, git, Sebastian Schuberth, Charles Bailey
In-Reply-To: <CAJDDKr58LV9EDJZP+3S0YfyTOXFgJWD6nm=AiA19MkyBF-wb_g@mail.gmail.com>
David Aguilar wrote:
> On Thu, Feb 9, 2012 at 11:17 AM, Jeff Epler <jepler@unpythonic.net> wrote:
>> At $DAYJOB, I recently encountered a problem after upgrading from (don't
>> laugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to
>> run, instead displaying the error 'Wrong number of arguments (Got 5)'.
>>
>> We determined that this user was running a very old version of meld
>> (1.1.1) from his home directory, as opposed to the also very old system
>> version of meld (1.1.5).
[...]
> We originally used the --output test so that we wouldn't have to check
> for a specific version.
My bad. How about something like this patch (untested)?
-- >8 --
Subject: mergetools/meld: Use version number to detect '--output' support
In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
to use the --output option when calling versions of meld (1.5.0 and
later) that support it.
Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
supporting the option, so on systems with such meld, instead of
getting a nice merge helper, the operator gets a dialog box with the
text "Wrong number of arguments (Got 5)". (Version 1.1.5 is when meld
switched to using optparse. One consequence of that change was that
errors in usage are detected and signalled through the exit status
even when --help was passed.)
Just parse version numbers instead. We can detect the version number
by running "meld --version" and postprocessing it. As a
futureproofing measure, we are careful to handle all three --version
output formats encountered so far. When confused, the mergetool falls
back to assuming the --output option is not usable.
- [0.1, 0.8.5): "GNOME Meld 0.1".
- [0.8.5, 0.9.4.1):
"Meld 0.8.5
Written by Stephen Kennedy <steve9000@users.sf.net>"
- [0.9.4.1, 1.1.3): "GNOME Meld 0.9.4.1" again.
- [1.1.3, 1.1.5): back to the two-line form.
- [1.1.5, present): "$0 1.1.5". ($0 is typically "meld".)
Reported-by: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
mergetools/meld | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/mergetools/meld b/mergetools/meld
index eaa115cc..3de29629 100644
--- a/mergetools/meld
+++ b/mergetools/meld
@@ -23,10 +23,15 @@ check_meld_for_output_version () {
meld_path="$(git config mergetool.meld.path)"
meld_path="${meld_path:-meld}"
- if "$meld_path" --output /dev/null --help >/dev/null 2>&1
- then
- meld_has_output_option=true
- else
- meld_has_output_option=false
- fi
+ # "GNOME Meld 0.8.4" -> "0.8.4"
+ meld_version=$("$meld_path" --version 2>/dev/null)
+ meld_version=${meld_version#GNOME }
+ meld_version=${meld_version#* }
+
+ case $meld_version in
+ [2-9].* | [1-9][0-9]* | 1.[5-9]* | 1.[1-9][0-9]*) # >= 1.5.0
+ meld_has_output_option=true ;;
+ *)
+ meld_has_output_option=false ;;
+ esac
}
--
1.7.9
^ permalink raw reply related
* [PATCH 3/8] gitweb: Move HTML-formatting diff line back to process_diff_line()
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
Commit 6ba1eb51b (gitweb: Add a feature to show side-by-side diff,
2011-10-31) for no special reason moved wrapping diff line in <div> out
of format_diff_line(). Bring back old behavior.
This simplifies code in git_patchset_body() and keeps formatting of a
diff line in one place.
The more long-term purpose of this patch is to move formatting diff
lines down to print_diff_chunk(), to allow processing lines without
HTML-formatting.
This is just a refactoring patch. It's not meant to change gitweb
output.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ed63261..d2f75c4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2332,14 +2332,18 @@ sub process_diff_line {
if ($from && $to && $line =~ m/^\@{2} /) {
$line = format_unidiff_chunk_header($line, $from, $to);
- return $diff_class, $line;
} elsif ($from && $to && $line =~ m/^\@{3}/) {
$line = format_cc_diff_chunk_header($line, $from, $to);
- return $diff_class, $line;
-
+ } else {
+ $line = esc_html($line, -nbsp=>1);
}
- return $diff_class, esc_html($line, -nbsp=>1);
+
+ my $diff_classes = "diff";
+ $diff_classes .= " $diff_class" if ($diff_class);
+ $line = "<div class=\"$diff_classes\">$line</div>\n";
+
+ return $diff_class, $line;
}
# Generates undef or something like "_snapshot_" or "snapshot (_tbz2_ _zip_)",
@@ -5104,9 +5108,6 @@ sub git_patchset_body {
next PATCH if ($patch_line =~ m/^diff /);
my ($class, $line) = process_diff_line($patch_line, \%from, \%to);
- my $diff_classes = "diff";
- $diff_classes .= " $class" if ($class);
- $line = "<div class=\"$diff_classes\">$line</div>\n";
if ($class eq 'chunk_header') {
print_diff_chunk($diff_style, $is_combined, @chunk);
--
1.7.3.4
^ permalink raw reply related
* [PATCH 4/8] gitweb: Push formatting diff lines to print_diff_chunk()
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
Now git_patchset_body() only calls diff_line_class() (removed from
process_diff_line()). The latter function is renamed to
format_diff_line() and is called from print_diff_chunk().
This is a pure code movement, needed for processing raw diff lines in
the accumulator in print_diff_chunk(). No behavior change is intended by
this change.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d2f75c4..cae9dfa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2320,12 +2320,9 @@ sub format_cc_diff_chunk_header {
}
# process patch (diff) line (not to be used for diff headers),
-# returning class and HTML-formatted (but not wrapped) line
-sub process_diff_line {
- my $line = shift;
- my ($from, $to) = @_;
-
- my $diff_class = diff_line_class($line, $from, $to);
+# returning HTML-formatted (but not wrapped) line
+sub format_diff_line {
+ my ($line, $diff_class, $from, $to) = @_;
chomp $line;
$line = untabify($line);
@@ -2343,7 +2340,7 @@ sub process_diff_line {
$diff_classes .= " $diff_class" if ($diff_class);
$line = "<div class=\"$diff_classes\">$line</div>\n";
- return $diff_class, $line;
+ return $line;
}
# Generates undef or something like "_snapshot_" or "snapshot (_tbz2_ _zip_)",
@@ -4934,7 +4931,7 @@ sub print_diff_lines {
}
sub print_diff_chunk {
- my ($diff_style, $is_combined, @chunk) = @_;
+ my ($diff_style, $is_combined, $from, $to, @chunk) = @_;
my (@ctx, @rem, @add);
my $prev_class = '';
@@ -4954,6 +4951,8 @@ sub print_diff_chunk {
foreach my $line_info (@chunk) {
my ($class, $line) = @$line_info;
+ $line = format_diff_line($line, $class, $from, $to);
+
# print chunk headers
if ($class && $class eq 'chunk_header') {
print $line;
@@ -5107,19 +5106,19 @@ sub git_patchset_body {
next PATCH if ($patch_line =~ m/^diff /);
- my ($class, $line) = process_diff_line($patch_line, \%from, \%to);
+ my $class = diff_line_class($patch_line, \%from, \%to);
if ($class eq 'chunk_header') {
- print_diff_chunk($diff_style, $is_combined, @chunk);
- @chunk = ( [ $class, $line ] );
+ print_diff_chunk($diff_style, $is_combined, \%from, \%to, @chunk);
+ @chunk = ( [ $class, $patch_line ] );
} else {
- push @chunk, [ $class, $line ];
+ push @chunk, [ $class, $patch_line ];
}
}
} continue {
if (@chunk) {
- print_diff_chunk($diff_style, $is_combined, @chunk);
+ print_diff_chunk($diff_style, $is_combined, \%from, \%to, @chunk);
@chunk = ();
}
print "</div>\n"; # class="patch"
--
1.7.3.4
^ permalink raw reply related
* [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
Reading diff output is sometimes very hard, even if it's colored,
especially if lines differ only in few characters. This is often true
when a commit fixes a typo or renames some variables or functions.
This commit teaches gitweb to highlight characters that are different
between old and new line. This should work in the similar manner as in
Trac or GitHub.
The code that comares lines is based on
contrib/diff-highlight/diff-highlight, except that it works with
multiline changes too. It also won't highlight lines that are
completely different because that would only make the output unreadable.
Combined diffs are not supported but a following commit will change it.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 82 ++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 77 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index db61553..1a5b454 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2322,7 +2322,7 @@ sub format_cc_diff_chunk_header {
# wrap patch (diff) line into a <div> (not to be used for diff headers),
# the line must be esc_html()'ed
sub format_diff_line {
- my ($line, $diff_class, $from, $to) = @_;
+ my ($line, $diff_class) = @_;
my $diff_classes = "diff";
$diff_classes .= " $diff_class" if ($diff_class);
@@ -4923,14 +4923,85 @@ sub print_inline_diff_lines {
print foreach (@$add);
}
+# Highlight characters from $prefix to $suffix and escape HTML.
+# $str is a reference to the array of characters.
+sub esc_html_mark_range {
+ my ($str, $prefix, $suffix) = @_;
+
+ # Don't generate empty <span> element.
+ if ($prefix == $suffix + 1) {
+ return esc_html(join('', @$str), -nbsp=>1);
+ }
+
+ my $before = join('', @{$str}[0..($prefix - 1)]);
+ my $marked = join('', @{$str}[$prefix..$suffix]);
+ my $after = join('', @{$str}[($suffix + 1)..$#{$str}]);
+
+ return esc_html($before, -nbsp=>1) .
+ $cgi->span({-class=>'marked'}, esc_html($marked, -nbsp=>1)) .
+ esc_html($after,-nbsp=>1);
+}
+
+# Format removed and added line, mark changed part and HTML-format them.
+sub format_rem_add_line {
+ my ($rem, $add) = @_;
+ my @r = split(//, $rem);
+ my @a = split(//, $add);
+ my ($esc_rem, $esc_add);
+ my ($prefix, $suffix_rem, $suffix_add) = (1, $#r, $#a);
+ my ($prefix_is_space, $suffix_is_space) = (1, 1);
+
+ while ($prefix < @r && $prefix < @a) {
+ last if ($r[$prefix] ne $a[$prefix]);
+
+ $prefix_is_space = 0 if ($r[$prefix] !~ /\s/);
+ $prefix++;
+ }
+
+ while ($suffix_rem >= $prefix && $suffix_add >= $prefix) {
+ last if ($r[$suffix_rem] ne $a[$suffix_add]);
+
+ $suffix_is_space = 0 if ($r[$suffix_rem] !~ /\s/);
+ $suffix_rem--;
+ $suffix_add--;
+ }
+
+ # Mark lines that are different from each other, but have some common
+ # part that isn't whitespace. If lines are completely different, don't
+ # mark them because that would make output unreadable, especially if
+ # diff consists of multiple lines.
+ if (($prefix == 1 && $suffix_rem == $#r && $suffix_add == $#a)
+ || ($prefix_is_space && $suffix_is_space)) {
+ $esc_rem = esc_html($rem);
+ $esc_add = esc_html($add);
+ } else {
+ $esc_rem = esc_html_mark_range(\@r, $prefix, $suffix_rem);
+ $esc_add = esc_html_mark_range(\@a, $prefix, $suffix_add);
+ }
+
+ return format_diff_line($esc_rem, 'rem'),
+ format_diff_line($esc_add, 'add');
+}
+
# HTML-format diff context, removed and added lines.
sub format_ctx_rem_add_lines {
- my ($ctx, $rem, $add) = @_;
+ my ($ctx, $rem, $add, $is_combined) = @_;
my (@new_ctx, @new_rem, @new_add);
+ my $num_add_lines = @$add;
+
+ if (!$is_combined && $num_add_lines > 0 && $num_add_lines == @$rem) {
+ for (my $i = 0; $i < $num_add_lines; $i++) {
+ my ($line_rem, $line_add) = format_rem_add_line(
+ $rem->[$i], $add->[$i]);
+ push @new_rem, $line_rem;
+ push @new_add, $line_add;
+ }
+ } else {
+ @new_rem = map { format_diff_line(esc_html($_, -nbsp=>1), 'rem') } @$rem;
+ @new_add = map { format_diff_line(esc_html($_, -nbsp=>1), 'add') } @$add;
+ }
@new_ctx = map { format_diff_line(esc_html($_, -nbsp=>1), 'ctx') } @$ctx;
- @new_rem = map { format_diff_line(esc_html($_, -nbsp=>1), 'rem') } @$rem;
- @new_add = map { format_diff_line(esc_html($_, -nbsp=>1), 'add') } @$add;
return (\@new_ctx, \@new_rem, \@new_add);
}
@@ -4939,7 +5010,8 @@ sub format_ctx_rem_add_lines {
sub print_diff_lines {
my ($ctx, $rem, $add, $diff_style, $is_combined) = @_;
- ($ctx, $rem, $add) = format_ctx_rem_add_lines($ctx, $rem, $add);
+ ($ctx, $rem, $add) = format_ctx_rem_add_lines($ctx, $rem, $add,
+ $is_combined);
if ($diff_style eq 'sidebyside' && !$is_combined) {
print_sidebyside_diff_lines($ctx, $rem, $add);
--
1.7.3.4
^ permalink raw reply related
* [PATCH 5/8] gitweb: Format diff lines just before printing
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
Now we're ready to insert highlightning to diff output.
The call to untabify() remains in the main loop in print_diff_chunk().
The motivation is that it must be called before any call to esc_html()
(because that converts spaces to ) and to call it only once.
This is a refactoring patch. It's not meant to change gitweb output.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 42 +++++++++++++++++++++++++++++++-----------
1 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cae9dfa..db61553 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2319,13 +2319,22 @@ sub format_cc_diff_chunk_header {
return $line;
}
-# process patch (diff) line (not to be used for diff headers),
-# returning HTML-formatted (but not wrapped) line
+# wrap patch (diff) line into a <div> (not to be used for diff headers),
+# the line must be esc_html()'ed
sub format_diff_line {
my ($line, $diff_class, $from, $to) = @_;
- chomp $line;
- $line = untabify($line);
+ my $diff_classes = "diff";
+ $diff_classes .= " $diff_class" if ($diff_class);
+ $line = "<div class=\"$diff_classes\">$line</div>\n";
+
+ return $line;
+}
+
+# format diff chunk header line (not to be used for diff headers),
+# returning HTML-formatted line
+sub format_diff_chunk_header {
+ my ($line, $diff_class, $from, $to) = @_;
if ($from && $to && $line =~ m/^\@{2} /) {
$line = format_unidiff_chunk_header($line, $from, $to);
@@ -2336,11 +2345,7 @@ sub format_diff_line {
$line = esc_html($line, -nbsp=>1);
}
- my $diff_classes = "diff";
- $diff_classes .= " $diff_class" if ($diff_class);
- $line = "<div class=\"$diff_classes\">$line</div>\n";
-
- return $line;
+ return format_diff_line($line, $diff_class);
}
# Generates undef or something like "_snapshot_" or "snapshot (_tbz2_ _zip_)",
@@ -4918,10 +4923,24 @@ sub print_inline_diff_lines {
print foreach (@$add);
}
+# HTML-format diff context, removed and added lines.
+sub format_ctx_rem_add_lines {
+ my ($ctx, $rem, $add) = @_;
+ my (@new_ctx, @new_rem, @new_add);
+
+ @new_ctx = map { format_diff_line(esc_html($_, -nbsp=>1), 'ctx') } @$ctx;
+ @new_rem = map { format_diff_line(esc_html($_, -nbsp=>1), 'rem') } @$rem;
+ @new_add = map { format_diff_line(esc_html($_, -nbsp=>1), 'add') } @$add;
+
+ return (\@new_ctx, \@new_rem, \@new_add);
+}
+
# Print context lines and then rem/add lines.
sub print_diff_lines {
my ($ctx, $rem, $add, $diff_style, $is_combined) = @_;
+ ($ctx, $rem, $add) = format_ctx_rem_add_lines($ctx, $rem, $add);
+
if ($diff_style eq 'sidebyside' && !$is_combined) {
print_sidebyside_diff_lines($ctx, $rem, $add);
} else {
@@ -4951,11 +4970,12 @@ sub print_diff_chunk {
foreach my $line_info (@chunk) {
my ($class, $line) = @$line_info;
- $line = format_diff_line($line, $class, $from, $to);
+ $line = untabify($line);
# print chunk headers
if ($class && $class eq 'chunk_header') {
- print $line;
+ print format_diff_chunk_header($line, $class, $from,
+ $to);
next;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/8] gitweb: Use print_diff_chunk() for both side-by-side and inline diffs
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
This renames print_sidebyside_diff_chunk() to print_diff_chunk() and
makes use of it for both side-by-side and inline diffs. Now diff lines
are always accumulated before they are printed. This opens the
possibility to preprocess diff output before it's printed.
The new function print_inline_diff_lines() could reorder diff lines. It
first prints all context lines, then all removed lines and finally all
added lines. If the diff output consisted of mixed added and removed
lines, gitweb would reorder these lines. This is especially true for
combined diff output, for example:
- removed line for first parent
+ added line for first parent
-removed line for second parent
++added line for both parents
would be rendered as:
- removed line for first parent
-removed line for second parent
+ added line for first parent
++added line for both parents
To prevent gitweb from reordering lines, print_diff_chunk() calls
print_diff_lines() as soon as it detects that both added and removed
lines are present and there was a class change.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 53 +++++++++++++++++++++++++++++++++++++--------------
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1247607..ed63261 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4908,9 +4908,31 @@ sub print_sidebyside_diff_lines {
}
}
-sub print_sidebyside_diff_chunk {
- my @chunk = @_;
+# Print context lines and then rem/add lines in inline manner.
+sub print_inline_diff_lines {
+ my ($ctx, $rem, $add) = @_;
+
+ print foreach (@$ctx);
+ print foreach (@$rem);
+ print foreach (@$add);
+}
+
+# Print context lines and then rem/add lines.
+sub print_diff_lines {
+ my ($ctx, $rem, $add, $diff_style, $is_combined) = @_;
+
+ if ($diff_style eq 'sidebyside' && !$is_combined) {
+ print_sidebyside_diff_lines($ctx, $rem, $add);
+ } else {
+ # default 'inline' style and unknown styles
+ print_inline_diff_lines($ctx, $rem, $add);
+ }
+}
+
+sub print_diff_chunk {
+ my ($diff_style, $is_combined, @chunk) = @_;
my (@ctx, @rem, @add);
+ my $prev_class = '';
return unless @chunk;
@@ -4935,9 +4957,13 @@ sub print_sidebyside_diff_chunk {
}
## print from accumulator when have some add/rem lines or end
- # of chunk (flush context lines)
- if (((@rem || @add) && $class eq 'ctx') || !$class) {
- print_sidebyside_diff_lines(\@ctx, \@rem, \@add);
+ # of chunk (flush context lines), or when have add and rem
+ # lines and new block is reached (otherwise add/rem lines could
+ # be reordered)
+ if (((@rem || @add) && $class eq 'ctx') || !$class ||
+ (@rem && @add && $class ne $prev_class)) {
+ print_diff_lines(\@ctx, \@rem, \@add, $diff_style,
+ $is_combined);
@ctx = @rem = @add = ();
}
@@ -4954,6 +4980,8 @@ sub print_sidebyside_diff_chunk {
if ($class eq 'ctx') {
push @ctx, $line;
}
+
+ $prev_class = $class;
}
}
@@ -5080,22 +5108,17 @@ sub git_patchset_body {
$diff_classes .= " $class" if ($class);
$line = "<div class=\"$diff_classes\">$line</div>\n";
- if ($diff_style eq 'sidebyside' && !$is_combined) {
- if ($class eq 'chunk_header') {
- print_sidebyside_diff_chunk(@chunk);
- @chunk = ( [ $class, $line ] );
- } else {
- push @chunk, [ $class, $line ];
- }
+ if ($class eq 'chunk_header') {
+ print_diff_chunk($diff_style, $is_combined, @chunk);
+ @chunk = ( [ $class, $line ] );
} else {
- # default 'inline' style and unknown styles
- print $line;
+ push @chunk, [ $class, $line ];
}
}
} continue {
if (@chunk) {
- print_sidebyside_diff_chunk(@chunk);
+ print_diff_chunk($diff_style, $is_combined, @chunk);
@chunk = ();
}
print "</div>\n"; # class="patch"
--
1.7.3.4
^ permalink raw reply related
* [PATCH 7/8] gitweb: Use different colors to present marked changes
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
This makes use of the highlight diff feature.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
I decided to split mechanism (generate HTML page with <span> elements that
mark interesting fragments of diff output) from politics (use these
particular colors for this <span> elements), but otherwise this commit
may be squashed with the previous one. These colors work for me but if
someone comes out with better ones, I'd be happy.
gitweb/static/gitweb.css | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index c7827e8..4f87d16 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -438,6 +438,10 @@ div.diff.add {
color: #008800;
}
+div.diff.add span.marked {
+ background-color: #77ff77;
+}
+
div.diff.from_file a.path,
div.diff.from_file {
color: #aa0000;
@@ -447,6 +451,10 @@ div.diff.rem {
color: #cc0000;
}
+div.diff.rem span.marked {
+ background-color: #ff7777;
+}
+
div.diff.chunk_header a,
div.diff.chunk_header {
color: #990099;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 8/8] gitweb: Highlight combined diffs
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
The highlightning of combined diffs is currently disabled. This is
because output from a combined diff is much harder to highlight because
it's not obvious which removed and added lines should be compared.
Moreover, code that compares added and removed lines doesn't care about
combined diffs. It only skips first +/- character, treating second +/-
as a line content.
Let's start with a simple case: only highlight changes that come from
one parent, i.e. when every removed line has a corresponding added line
for the same parent. This way the highlightning cannot get wrong. For
example, following diffs would be highlighted:
- removed line for first parent
+ added line for first parent
context line
-removed line for second parent
+added line for second parent
or
- removed line for first parent
-removed line for second parent
+ added line for first parent
+added line for second parent
but following output will not:
- removed line for first parent
-removed line for second parent
+added line for second parent
++added line for both parents
Further changes may introduce more intelligent approach that better
handles combined diffs.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 40 +++++++++++++++++++++++++++++++++++++---
1 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1a5b454..2b6cb9e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4944,13 +4944,16 @@ sub esc_html_mark_range {
# Format removed and added line, mark changed part and HTML-format them.
sub format_rem_add_line {
- my ($rem, $add) = @_;
+ my ($rem, $add, $is_combined) = @_;
my @r = split(//, $rem);
my @a = split(//, $add);
my ($esc_rem, $esc_add);
my ($prefix, $suffix_rem, $suffix_add) = (1, $#r, $#a);
my ($prefix_is_space, $suffix_is_space) = (1, 1);
+ # In combined diff we must ignore two +/- characters.
+ $prefix = 2 if ($is_combined);
+
while ($prefix < @r && $prefix < @a) {
last if ($r[$prefix] ne $a[$prefix]);
@@ -4988,11 +4991,42 @@ sub format_ctx_rem_add_lines {
my ($ctx, $rem, $add, $is_combined) = @_;
my (@new_ctx, @new_rem, @new_add);
my $num_add_lines = @$add;
+ my $can_highlight;
+
+ # Highlight if every removed line has a corresponding added line.
+ if ($num_add_lines > 0 && $num_add_lines == @$rem) {
+ $can_highlight = 1;
+
+ # Highlight lines in combined diff only if the chunk contains
+ # diff between the same version, e.g.
+ #
+ # - a
+ # - b
+ # + c
+ # + d
+ #
+ # Otherwise the highlightling would be confusing.
+ if ($is_combined) {
+ for (my $i = 0; $i < $num_add_lines; $i++) {
+ my $prefix_rem = substr($rem->[$i], 0, 2);
+ my $prefix_add = substr($add->[$i], 0, 2);
+
+ $prefix_rem =~ s/-/+/g;
+
+ if ($prefix_rem ne $prefix_add) {
+ $can_highlight = 0;
+ last;
+ }
+ }
+ }
+ } else {
+ $can_highlight = 0;
+ }
- if (!$is_combined && $num_add_lines > 0 && $num_add_lines == @$rem) {
+ if ($can_highlight) {
for (my $i = 0; $i < $num_add_lines; $i++) {
my ($line_rem, $line_add) = format_rem_add_line(
- $rem->[$i], $add->[$i]);
+ $rem->[$i], $add->[$i], $is_combined);
push @new_rem, $line_rem;
push @new_add, $line_add;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
Reading diff output is sometimes very hard, even if it's colored,
especially if lines differ only in few characters. This is often true when
a commit fixes a typo or renames some variables or functions.
This patch series teaches gitweb to highlight fragments that are different
between old and new line. This should mimic the same feature in Trac or
GitHub.
To achieve that, added and removed lines must be accumulated and compared.
The current code in print_sidebyside_diff_chunk() already does this, so
this patch series reuses it in commits:
gitweb: Extract print_sidebyside_diff_lines()
gitweb: Use print_diff_chunk() for both side-by-side and inline diffs
Next, HTML-formatting diff lines is pushed down to the place where they
are about to be printed. This is required because comparision must be
performened on raw git-diff output and not on HTML-formatted lines. This
is done in commits:
gitweb: Move HTML-formatting diff line back to process_diff_line()
gitweb: Push formatting diff lines to print_diff_chunk()
gitweb: Format diff lines just before printing
The last three commits implement the advertised feature. They could be
squashed together but that would make them harder to review (I think).
gitweb: Highlight interesting parts of diff
gitweb: Use different colors to present marked changes
gitweb: Highlight combined diffs
This series is based on v1.7.9.
Michał Kiedrowicz (8):
gitweb: Extract print_sidebyside_diff_lines()
gitweb: Use print_diff_chunk() for both side-by-side and inline diffs
gitweb: Move HTML-formatting diff line back to process_diff_line()
gitweb: Push formatting diff lines to print_diff_chunk()
gitweb: Format diff lines just before printing
gitweb: Highlight interesting parts of diff
gitweb: Use different colors to present marked changes
gitweb: Highlight combined diffs
gitweb/gitweb.perl | 304 +++++++++++++++++++++++++++++++++++-----------
gitweb/static/gitweb.css | 8 ++
2 files changed, 238 insertions(+), 74 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH 1/8] gitweb: Extract print_sidebyside_diff_lines()
From: Michał Kiedrowicz @ 2012-02-10 9:18 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz
In-Reply-To: <1328865494-24415-1-git-send-email-michal.kiedrowicz@gmail.com>
Currently, print_sidebyside_diff_chunk() does two things: it
accumulates diff lines and prints them. Accumulation may be used to
perform additional operations on diff lines, so it makes sense to split
these two things. Thus, the code that prints diff lines in a side-by-side
manner is moved out of print_sidebyside_diff_chunk() to a separate
subroutine.
The outcome of this patch is that print_sidebyside_diff_chunk() is now
much shorter and easier to read.
This change is meant to be a simple code movement. No behavior change is
intended.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
gitweb/gitweb.perl | 97 ++++++++++++++++++++++++++++------------------------
1 files changed, 52 insertions(+), 45 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index abb5a79..1247607 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4861,6 +4861,53 @@ sub git_difftree_body {
print "</table>\n";
}
+# Print context lines and then rem/add lines in a side-by-side manner.
+sub print_sidebyside_diff_lines {
+ my ($ctx, $rem, $add) = @_;
+
+ # print context block before add/rem block
+ if (@$ctx) {
+ print join '',
+ '<div class="chunk_block ctx">',
+ '<div class="old">',
+ @$ctx,
+ '</div>',
+ '<div class="new">',
+ @$ctx,
+ '</div>',
+ '</div>';
+ }
+
+ if (!@$add) {
+ # pure removal
+ print join '',
+ '<div class="chunk_block rem">',
+ '<div class="old">',
+ @$rem,
+ '</div>',
+ '</div>';
+ } elsif (!@$rem) {
+ # pure addition
+ print join '',
+ '<div class="chunk_block add">',
+ '<div class="new">',
+ @$add,
+ '</div>',
+ '</div>';
+ } else {
+ # assume that it is change
+ print join '',
+ '<div class="chunk_block chg">',
+ '<div class="old">',
+ @$rem,
+ '</div>',
+ '<div class="new">',
+ @$add,
+ '</div>',
+ '</div>';
+ }
+}
+
sub print_sidebyside_diff_chunk {
my @chunk = @_;
my (@ctx, @rem, @add);
@@ -4887,51 +4934,11 @@ sub print_sidebyside_diff_chunk {
next;
}
- ## print from accumulator when type of class of lines change
- # empty contents block on start rem/add block, or end of chunk
- if (@ctx && (!$class || $class eq 'rem' || $class eq 'add')) {
- print join '',
- '<div class="chunk_block ctx">',
- '<div class="old">',
- @ctx,
- '</div>',
- '<div class="new">',
- @ctx,
- '</div>',
- '</div>';
- @ctx = ();
- }
- # empty add/rem block on start context block, or end of chunk
- if ((@rem || @add) && (!$class || $class eq 'ctx')) {
- if (!@add) {
- # pure removal
- print join '',
- '<div class="chunk_block rem">',
- '<div class="old">',
- @rem,
- '</div>',
- '</div>';
- } elsif (!@rem) {
- # pure addition
- print join '',
- '<div class="chunk_block add">',
- '<div class="new">',
- @add,
- '</div>',
- '</div>';
- } else {
- # assume that it is change
- print join '',
- '<div class="chunk_block chg">',
- '<div class="old">',
- @rem,
- '</div>',
- '<div class="new">',
- @add,
- '</div>',
- '</div>';
- }
- @rem = @add = ();
+ ## print from accumulator when have some add/rem lines or end
+ # of chunk (flush context lines)
+ if (((@rem || @add) && $class eq 'ctx') || !$class) {
+ print_sidebyside_diff_lines(\@ctx, \@rem, \@add);
+ @ctx = @rem = @add = ();
}
## adding lines to accumulator
--
1.7.3.4
^ permalink raw reply related
* Re: Git performance results on a large repository
From: Christian Couder @ 2012-02-10 9:39 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Joshua Redstone, git@vger.kernel.org
In-Reply-To: <CACsJy8DQNHm8sTgxKL=+Ui5OBsJBpvPn+dRmN9bVMwq4TfNuxQ@mail.gmail.com>
Hi,
On Fri, Feb 10, 2012 at 8:12 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
> All these involve unpack_trees(), which is full tree operation. The
> bigger your worktree is, the slower it is. Another good reason to
> split unrelated parts into separate repositories.
Maybe having different "views" would be enough to make a smaller
worktree and history, so that things are much faster for a developper?
(I already suggested "views" based on "git replace" in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/177146/focus=177639)
Best regards,
Christian.
^ permalink raw reply
* git status: small difference between stating whole repository and small subdirectory
From: Piotr Krukowiecki @ 2012-02-10 9:42 UTC (permalink / raw)
To: Git Mailing List
Hi,
I compared stating whole tree vs one small subdirectory, and I
expected that for the subdirectory status will be very very fast.
After all, it has only few files to stat. But it's not fast. Why?
With cold cache (echo 3 | sudo tee /proc/sys/vm/drop_caches):
$ time git status > /dev/null
real 0m41.670s
user 0m0.980s
sys 0m2.908s
$ time git status -- src/.../somedir > /dev/null
real 0m17.380s
user 0m0.748s
sys 0m0.328s
With warm cache:
$ time git status > /dev/null
real 0m0.792s
user 0m0.404s
sys 0m0.384s
$ time git status -- src/.../somedir > /dev/null
real 0m0.335s
user 0m0.288s
sys 0m0.048s
Repository/dir stats:
$ find * -type f | wc -l
127189
$ du -shc * | grep total
2.2G total
$ find src/.../somedir -type f | wc -l
55
$ du -shc src/.../somedir | grep total
224K total
$ git --version
git version 1.7.9.rc0.10.gbeecc
--
Piotr Krukowiecki
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Ævar Arnfjörð Bjarmason @ 2012-02-10 10:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Дилян Палаузов,
git
In-Reply-To: <7v1uq3toyq.fsf@alter.siamese.dyndns.org>
2012/2/10 Junio C Hamano <gitster@pobox.com>:
> Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>
>> Hello,
>>
>> git 1.7.9 makes use of libcharset and /Makefile contains:
>>
>> ifdef HAVE_LIBCHARSET_H
>> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>> endif
>> ...
>> and the problem is, that libcharset is not used when linking. To
>> solve this, please replace the above extract from /Makefile with
>>
>> ifdef HAVE_LIBCHARSET_H
>> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>> EXTLIBS += -lcharset
>> endif
>
> Thanks.
>
> What platform is this? Is there a guarantee that any and all system that
> use "#include <libcharset.h>" has to link with "-lcharset"?
>
> What I am wondering is there are systems that need to include the header,
> but locale_charset() does not live in /lib/libcharset.a, in which case we
> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
I've had some similar (privately sent) bug reports about the i18n
stuff from someone who built his own Linux distro.
Basically we make assumptions that certain stuff will be in the C
library on certain platforms, certain headers go with certain
libraries etc.
Evidently none of this can really be relied upon and we'd have to
probe for each one if we wanted to make it reliable.
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Дилян Палаузов @ 2012-02-10 10:21 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git
In-Reply-To: <CACBZZX45=mr=FMqFF+Pw4KPaDAtvs-ePLbFATpyFA93vSfZatw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]
Hello,
>> What platform is this? Is there a guarantee that any and all system that
>> use "#include<libcharset.h>" has to link with "-lcharset"?
>
> I've had some similar (privately sent) bug reports about the i18n
> stuff from someone who built his own Linux distro.
I run Linux from scratch.
>> What I am wondering is there are systems that need to include the header,
>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
I do not understand this. If you want to use a function from
libcharset, you have to use both #include <libcharset.h> and -lcharset.
Със здраве
Дилян
On 10.02.2012 11:06, Ævar Arnfjörð Bjarmason wrote:
> 2012/2/10 Junio C Hamano<gitster@pobox.com>:
>> Дилян Палаузов<dilyan.palauzov@aegee.org> writes:
>>
>>> Hello,
>>>
>>> git 1.7.9 makes use of libcharset and /Makefile contains:
>>>
>>> ifdef HAVE_LIBCHARSET_H
>>> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>> endif
>>> ...
>>> and the problem is, that libcharset is not used when linking. To
>>> solve this, please replace the above extract from /Makefile with
>>>
>>> ifdef HAVE_LIBCHARSET_H
>>> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>> EXTLIBS += -lcharset
>>> endif
>>
>> Thanks.
>>
>> What platform is this? Is there a guarantee that any and all system that
>> use "#include<libcharset.h>" has to link with "-lcharset"?
>>
>> What I am wondering is there are systems that need to include the header,
>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>
> I've had some similar (privately sent) bug reports about the i18n
> stuff from someone who built his own Linux distro.
>
> Basically we make assumptions that certain stuff will be in the C
> library on certain platforms, certain headers go with certain
> libraries etc.
>
> Evidently none of this can really be relied upon and we'd have to
> probe for each one if we wanted to make it reliable.
[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]
begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH 3/4] diff --stat: use the real terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-10 11:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, git, gitster; +Cc: Michael J Gruber
In-Reply-To: <CACsJy8APGeTNv_E3qD=xFCiLC25M_nm3aJbq6YU73J=X0Wxh2w@mail.gmail.com>
On 02/10/2012 07:15 AM, Nguyen Thai Ngoc Duy wrote:
> 2012/2/10 Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>:
>> @@ -1341,7 +1342,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
>> line_prefix = msg->buf;
>> }
>>
>> - width = options->stat_width ? options->stat_width : 80;
>> + width = options->stat_width ? options->stat_width : term_columns();
>> name_width = options->stat_name_width ? options->stat_name_width : 50;
>> count = options->stat_count ? options->stat_count : data->nr;
>
> I tried this in the past and "git log -p" looked ugly on git.git
> mainly because commit messages are still ~70 char long lines on my 279
> char wide terminal. If this is project dependent, perhaps a config
> key? Also the "50" below the changed line, maybe you want to change it
> to 0.6 * width.
Thanks for all the comments. I'll post a newer version, but I have two
questions:
I agree that making the output very wide with lots of +- is not very
elegant. (E.g. 8f24a6323ece9be1bf1a04b4b5856112438337f2 has
builtin/grep.c | 142 +++--------------------------------....--
which doesn't look right.). So I think it would make sense to limit
the graph part to something like 50 columns, even if there's more space.
I believe that git.git would look fine with this change. There are some
fairly long lines
(t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
is 86 chars) but with 50 columns of graph the output would take 140
columns -- with the graph part slightly sticking out from the 80 column
descriptions, but still not too ugly.
Should I add a new option --stat-graph-width in analogy to
--stat-name-width, or should this be hard-coded?
JC:
> The output from "git format-patch" shouldn't be affected at all by the
> width of the terminal the patch sender happened to have used when the
> command was run when the user did not explicitly ask a custom width by
> giving a --stat-width command line option.
>
> How do you prevent regression to the command in this series?
git format-patch is not affected by default. But with --stdout
the width is changed, iff stdout is a tty. When --stdout output
is connected to a pipe, the width is not changed. I think that
this behaviour is OK.
Should a test be added to check that 'git format-patch --stat' output
doesn't change? Should I test for something else?
--
Zbyszek
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: Sebastian Schuberth @ 2012-02-10 11:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Aguilar, Jeff Epler, git, Charles Bailey
In-Reply-To: <20120210082106.GA7871@burratino>
On Fri, Feb 10, 2012 at 09:23, Jonathan Nieder <jrnieder@gmail.com> wrote:
> + meld_version=${meld_version#GNOME }
> + meld_version=${meld_version#* }
Hmm, I might be mistaken, but aren't these string operations
Bash-only? And AFAIK Git is striving for standard sh compatibility ...
--
Sebastian Schuberth
^ 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