* Re: [PATCH v5 2/3] Refactor submodule push check to use string list instead of integer
From: Junio C Hamano @ 2012-02-14 3:28 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Fredrik Gustafsson, Jens Lehmann
In-Reply-To: <20120213092900.GC15585@t1405.greatnet.de>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> This allows us to tell the user which submodules have not been pushed.
> Additionally this is helpful when we want to automatically try to push
> submodules that have not been pushed.
Makes sense.
> diff --git a/submodule.c b/submodule.c
> index 645ff5d..3c714c2 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -357,21 +357,20 @@ static void collect_submodules_from_diff(struct diff_queue_struct *q,
> void *data)
> {
> int i;
> - int *needs_pushing = data;
> + struct string_list *needs_pushing = data;
>
> for (i = 0; i < q->nr; i++) {
> struct diff_filepair *p = q->queue[i];
> if (!S_ISGITLINK(p->two->mode))
> continue;
> if (submodule_needs_pushing(p->two->path, p->two->sha1)) {
> - *needs_pushing = 1;
> - break;
> + if (!string_list_has_string(needs_pushing, p->two->path))
> + string_list_insert(needs_pushing, p->two->path);
Does string_list API have "look for this and insert if it doesn't exist
but otherwise don't do anything"? Running get_entry_index() to answer
has_string() once and then calling it again to find where to insert to
respond to insert() looks a bit wasteful.
Just wondering.
> }
> }
> }
>
> -
> -static void commit_need_pushing(struct commit *commit, int *needs_pushing)
> +static void commit_need_pushing(struct commit *commit, struct string_list *needs_pushing)
> {
> struct rev_info rev;
>
> @@ -382,14 +381,15 @@ static void commit_need_pushing(struct commit *commit, int *needs_pushing)
> diff_tree_combined_merge(commit, 1, &rev);
> }
>
> -int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remotes_name)
> +int check_submodule_needs_pushing(unsigned char new_sha1[20],
> + const char *remotes_name, struct string_list *needs_pushing)
> {
> struct rev_info rev;
> struct commit *commit;
> const char *argv[] = {NULL, NULL, "--not", "NULL", NULL};
> int argc = ARRAY_SIZE(argv) - 1;
> char *sha1_copy;
> - int needs_pushing = 0;
> +
> struct strbuf remotes_arg = STRBUF_INIT;
>
> strbuf_addf(&remotes_arg, "--remotes=%s", remotes_name);
> @@ -401,14 +401,14 @@ int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remote
> if (prepare_revision_walk(&rev))
> die("revision walk setup failed");
>
> - while ((commit = get_revision(&rev)) && !needs_pushing)
> - commit_need_pushing(commit, &needs_pushing);
> + while ((commit = get_revision(&rev)) != NULL)
> + commit_need_pushing(commit, needs_pushing);
Now the helper function to find list of submodules that need pushing given
one commit starting to look more and more misnamed. It used to be "learn
if something needs pushing", but now it is "find what needs pushing".
Can somebody think of a good adjective to describe a submodule (or a set
of submodules) in this state, so that we can name this helper function
find_blue_submodules(), if the adjective were "blue"?
"Unpushed" submodule is the word used in the later part of the patch.
^ permalink raw reply
* Re: [PATCH v5 3/3] push: teach --recurse-submodules the on-demand option
From: Junio C Hamano @ 2012-02-14 3:34 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Fredrik Gustafsson, Jens Lehmann
In-Reply-To: <20120213093008.GD15585@t1405.greatnet.de>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> diff --git a/submodule.c b/submodule.c
> index 3c714c2..ff0cfd8 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -411,6 +411,54 @@ int check_submodule_needs_pushing(unsigned char new_sha1[20],
> return needs_pushing->nr;
> }
>
> +static int push_submodule(const char *path)
> +{
> + if (add_submodule_odb(path))
> + return 1;
> +
> + if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {
> + struct child_process cp;
> + const char *argv[] = {"push", NULL};
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.argv = argv;
> + cp.env = local_repo_env;
> + cp.git_cmd = 1;
> + cp.no_stdin = 1;
> + cp.dir = path;
> + if (run_command(&cp))
> + return 0;
> + close(cp.out);
> + }
> +
> + return 1;
> +}
Hmm, this makes me wonder if we fire subprocesses and have them run in
parallel (to a reasonably limited parallelism), it might make the overall
user experience more pleasant, and if we did the same on the fetching
side, it would be even nicer.
We would need to keep track of children and after firing a handful of them
we would need to start waiting for some to finish and collect their exit
status before firing more, and at the end we would need to wait for the
remaining ones and find how each one of them did before returning from
push_unpushed_submodules(). If we were to do so, what are the missing
support we would need from the run_command() subsystem?
> +int push_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name)
> +{
> + int i, ret = 1;
> + struct string_list needs_pushing;
> +
> + memset(&needs_pushing, 0, sizeof(struct string_list));
> + needs_pushing.strdup_strings = 1;
> +
> + if (!check_submodule_needs_pushing(new_sha1, remotes_name, &needs_pushing))
> + return 1;
> +
> + for (i = 0; i < needs_pushing.nr; i++) {
> + const char *path = needs_pushing.items[i].string;
> + fprintf(stderr, "Pushing submodule '%s'\n", path);
> + if (!push_submodule(path)) {
> + fprintf(stderr, "Unable to push submodule '%s'\n", path);
> + ret = 0;
> + }
> + }
^ permalink raw reply
* git-cherry filter
From: Neal Kreitzinger @ 2012-02-14 4:20 UTC (permalink / raw)
To: git
Is there a way to add a pre-git-patch-id filter to git-cherry?
e.g.,
(a) perform "keyword contraction" to the patch before generating the
git-patch-id.
e.g. I want to run a git-cherry to see if two patches are identical other
than keyword expansion values like $User: foo$ vs. $User: bar$. (I would
have to tell git-cherry which keyword formats to "contract".)
(b) ignore comments in the source code.
e.g. I want to run a git-cherry to see if the patches are identical in
regards to executable source. (I would have to tell git-cherry what the
comment rules are for the various source files.)
(c) exclude certain files from the diff (ie., binaries, comment files,
etc.).
e.g. I want to run a git-cherry to see which source code fixes from the old
system have already been applied to the new system regardless of whether
certain files differ (ie., binaries (ie, compile date), comment files (ie.,
fixed a typo), etc.). (I would have to tell git-cherry which
paths/filenames to disregard.)
I suppose these may be git-patch-id options that are passed via git-cherry
like the git-fetch options passable via git-pull.
v/r,
neal
^ permalink raw reply
* Re: [PATCH] diff-highlight: Work for multiline changes too
From: Jeff King @ 2012-02-14 6:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michał Kiedrowicz, git
In-Reply-To: <7vk43q9pp6.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 05:19:33PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I chose reverse because I like the way it looks, and because it should
> > Just Work if people have selected alternate colors (I never dreamed
> > somebody would use "reverse" all the time, as I find it horribly ugly.
> > But to each his own).
>
> I also find it ugly, but I am on black-letters on white background window,
> and I do not see my terminal's red very well, so it is hard to tell the
> old from the context if I use the "diff.color.old=red" default; that is
> the primary reason for my setting.
I find black-on-white ugly, too, but I have heard some people find it
more readable. You might try setting color.diff.old to "bold red" to
make it more readable. Depending on your terminal, that may end up as a
brighter shade of red.
Configurable colors for diff-highlight would look like the patch below:
diff --git a/contrib/diff-highlight/diff-highlight b/contrib/diff-highlight/diff-highlight
index c4404d4..f43832b 100755
--- a/contrib/diff-highlight/diff-highlight
+++ b/contrib/diff-highlight/diff-highlight
@@ -2,11 +2,13 @@
use warnings FATAL => 'all';
use strict;
+use Git;
+
+my $repo = Git->repository;
+my $color_old = $repo->get_color('color.diff.highlightold', 'reverse');
+my $color_new = $repo->get_color('color.diff.highlightnew', 'reverse');
+my $color_end = $repo->get_color('color.diff.highlightend', 'noreverse');
-# Highlight by reversing foreground and background. You could do
-# other things like bold or underline if you prefer.
-my $HIGHLIGHT = "\x1b[7m";
-my $UNHIGHLIGHT = "\x1b[27m";
my $COLOR = qr/\x1b\[[0-9;]*m/;
my $BORING = qr/$COLOR|\s/;
@@ -128,8 +130,8 @@ sub highlight_pair {
}
if (is_pair_interesting(\@a, $pa, $sa, \@b, $pb, $sb)) {
- return highlight_line(\@a, $pa, $sa),
- highlight_line(\@b, $pb, $sb);
+ return highlight_line(\@a, $pa, $sa, $color_old, $color_end),
+ highlight_line(\@b, $pb, $sb, $color_new, $color_end);
}
else {
return join('', @a),
@@ -144,13 +146,13 @@ sub split_line {
}
sub highlight_line {
- my ($line, $prefix, $suffix) = @_;
+ my ($line, $prefix, $suffix, $highlight, $unhighlight) = @_;
return join('',
@{$line}[0..($prefix-1)],
- $HIGHLIGHT,
+ $highlight,
@{$line}[$prefix..$suffix],
- $UNHIGHLIGHT,
+ $unhighlight,
@{$line}[($suffix+1)..$#$line]
);
}
However, there are two problems:
1. Git's color-parsing support does not understand the "noreverse"
attribute. There is no way to turn off attributes short of doing a
whole "reset". But we don't want to do that here, because we want
whatever other colors were in effect to continue after the
highlight ends. The patch to teach "noreverse" is below (though it
should probably also teach "normal" and "noblink", too).
2. The Git.pm:get_color code requires that we have a repository
object, which means we will die() if we are not in a git
repository. Yet "git config" will do the right thing whether we are
in a repository or not. I would have thought all of the _maybe_self
stuff in Git.pm would handle "Git->get_color" properly, but it
doesn't. That's probably a bug that should be fixed.
I don't especially care about this feature, as I won't use it. But if
you are interested in using diff-highlight and the lack of configurable
colors is blocking you, then I at least know there will be one user and
I don't mind putting a little bit of time into it.
Here's the patch for (1) above.
diff --git a/color.c b/color.c
index e8e2681..b0f53a7 100644
--- a/color.c
+++ b/color.c
@@ -47,9 +47,9 @@ static int parse_color(const char *name, int len)
static int parse_attr(const char *name, int len)
{
- static const int attr_values[] = { 1, 2, 4, 5, 7 };
+ static const int attr_values[] = { 1, 2, 4, 5, 7, 27 };
static const char * const attr_names[] = {
- "bold", "dim", "ul", "blink", "reverse"
+ "bold", "dim", "ul", "blink", "reverse", "noreverse"
};
int i;
for (i = 0; i < ARRAY_SIZE(attr_names); i++) {
@@ -128,7 +128,7 @@ void color_parse_mem(const char *value, int value_len, const char *var,
attr &= ~bit;
if (sep++)
*dst++ = ';';
- *dst++ = '0' + i;
+ dst += sprintf(dst, "%d", i);
}
if (fg >= 0) {
if (sep++)
^ permalink raw reply related
* Re: [PATCH] diff-highlight: Work for multiline changes too
From: Michal Kiedrowicz @ 2012-02-14 6:28 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120213222702.GA19393@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Feb 10, 2012 at 10:47:13PM +0100, Michał Kiedrowicz wrote:
>
> > contrib/diff-highlight/diff-highlight | 96
> > ++++++++++++++++++++++----------- 1 files changed, 65
> > insertions(+), 31 deletions(-)
>
> Thanks for sending. I looked at a whole bunch of patches, and I was
> pleasantly surprised to find how infrequently we hit false positives
> in practice.
Yeah, I completely agree with that.
> In fact, the only things that looked worse with your
> patch were places where your patch happened to turn on highlighting
> for lines where the existing heuristics already were a little ugly
> (i.e., the problem was not your patch, but that the existing
> heuristic is sometimes non-optimal).
>
> I ended up pulling your changes out into a few distinct commits. That
> made it easier for me to review and understand what was going on (and
> hopefully ditto for other reviewers, or people who end up bisecting or
> reading the log later). I'll post that series in a moment.
Very nicely done.
>
> > After looking at outputs I noticed that it can also ignore lines
> > with prefixes/suffixes that consist only of punctuation (asterisk,
> > semicolon, dot, etc), because otherwise whole line is highlighted
> > except for terminating punctuation.
>
> I missed this note when I applied the patch and started looking at the
> outputs, and ended up having a similar thought. However, I don't know
> that it buys much in practice, and it's nice to be fairly agnostic
> about content. I did leave that open to easy tweaking in my series,
> though.
>
> [1/5]: diff-highlight: make perl strict and warnings fatal
> [2/5]: diff-highlight: don't highlight whole lines
> [3/5]: diff-highlight: refactor to prepare for multi-line hunks
> [4/5]: diff-highlight: match multi-line hunks
> [5/5]: diff-highlight: document some non-optimal cases
>
> -Peff
^ permalink raw reply
* Re: [PATCH 2/5] diff-highlight: don't highlight whole lines
From: Michal Kiedrowicz @ 2012-02-14 6:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120213223247.GB19521@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> Regarding attribution: I kept myself as author, because I rewrote it a
> bit and figured that I would take primary responsibility for bugs in
> this patch, and in the long run would be responsible for maintaining
> it. But the idea and the substance of the patch are yours, and I
> would be happy to list you as author if you prefer getting the credit
> that way (after all, it bumps your shortlog numbers :) ).
I'm completely OK with that. I don't care much about shortlog :). It's
nice enough to see that you liked my idea :)
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michal Kiedrowicz @ 2012-02-14 6:54 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Jeff King
In-Reply-To: <m339aivn4z.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
>
> > 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.
>
> I was thinking that if gitweb were to support "diff refinement
> highlighting", it would either use one of *Diff* packages from CPAN,
> or "git diff --word-diff" output.
>
I just started to wonder if we couldn't use output from Jeff's
diff-highlight for gitweb. We could tech diff-highlight to produce diffs
marked with -{} and +{} (this is the notation used by Jeff in one of his
recent patches) or something like this and then just convert that into
HTML markup. Changes in gitweb would be minimal, we would reduce
redundancy and could focus on improving matching algorithm in one place.
^ permalink raw reply
* Re: [PATCH 5/5] diff-highlight: document some non-optimal cases
From: Michal Kiedrowicz @ 2012-02-14 6:48 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120213223733.GE19521@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> The diff-highlight script works on heuristics, so it can be
> wrong. Let's document some of the wrong-ness in case
> somebody feels like working on it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> These were just some that I considered while looking at the output of
> the original and the current code. Suggestions are welcome for more.
I would also add (feel free to reword if my English is not very clear):
3. Sometimes the prefix or suffix is very small but because it exists,
almost whole line is highlighted. For example:
----------------------------------------------
--{This is a very long line}.
++{I like apples}.
----------------------------------------------
or:
----------------------------------------------
-Th-{is is an apple}
+Th+{at was a car}
----------------------------------------------
>
> contrib/diff-highlight/README | 93
> +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93
> insertions(+)
>
> diff --git a/contrib/diff-highlight/README
> b/contrib/diff-highlight/README index 4a58579..502e03b 100644
> --- a/contrib/diff-highlight/README
> +++ b/contrib/diff-highlight/README
> @@ -57,3 +57,96 @@ following in your git configuration:
> show = diff-highlight | less
> diff = diff-highlight | less
> ---------------------------------------------
> +
> +Bugs
> +----
> +
> +Because diff-highlight relies on heuristics to guess which parts of
> +changes are important, there are some cases where the highlighting is
> +more distracting than useful. Fortunately, these cases are rare in
> +practice, and when they do occur, the worst case is simply a little
> +extra highlighting. This section documents some cases known to be
> +sub-optimal, in case somebody feels like working on improving the
> +heuristics.
> +
> +1. Two changes on the same line get highlighted in a blob. For
> example,
> + highlighting:
> +
> +----------------------------------------------
> +-foo(buf, size);
> ++foo(obj->buf, obj->size);
> +----------------------------------------------
> +
> + yields (where the inside of "+{}" would be highlighted):
> +
> +----------------------------------------------
> +-foo(buf, size);
> ++foo(+{obj->buf, obj->}size);
> +----------------------------------------------
> +
> + whereas a more semantically meaningful output would be:
> +
> +----------------------------------------------
> +-foo(buf, size);
> ++foo(+{obj->}buf, +{obj->}size);
> +----------------------------------------------
> +
> + Note that doing this right would probably involve a set of
> + content-specific boundary patterns, similar to word-diff.
> Otherwise
> + you get junk like:
> +
> +-----------------------------------------------------
> +-this line has some -{i}nt-{ere}sti-{ng} text on it
> ++this line has some +{fa}nt+{a}sti+{c} text on it
> +-----------------------------------------------------
> +
> + which is less readable than the current output.
> +
> +2. The multi-line matching assumes that lines in the pre- and
> post-image
> + match by position. This is often the case, but can be fooled when
> a
> + line is removed from the top and a new one added at the bottom (or
> + vice versa). Unless the lines in the middle are also changed,
> diffs
> + will show this as two hunks, and it will not get highlighted at
> all
> + (which is good). But if the lines in the middle are changed, the
> + highlighting can be misleading. Here's a pathological case:
> +
> +-----------------------------------------------------
> +-one
> +-two
> +-three
> +-four
> ++two 2
> ++three 3
> ++four 4
> ++five 5
> +-----------------------------------------------------
> +
> + which gets highlighted as:
> +
> +-----------------------------------------------------
> +-one
> +-t-{wo}
> +-three
> +-f-{our}
> ++two 2
> ++t+{hree 3}
> ++four 4
> ++f+{ive 5}
> +-----------------------------------------------------
> +
> + because it matches "two" to "three 3", and so forth. It would be
> + nicer as:
> +
> +-----------------------------------------------------
> +-one
> +-two
> +-three
> +-four
> ++two +{2}
> ++three +{3}
> ++four +{4}
> ++five 5
> +-----------------------------------------------------
> +
> + which would probably involve pre-matching the lines into pairs
> + according to some heuristic.
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Junio C Hamano @ 2012-02-14 7:14 UTC (permalink / raw)
To: Michal Kiedrowicz; +Cc: git, Jakub Narebski, Jeff King
In-Reply-To: <20120214075439.14f1d2b7@mkiedrowicz.ivo.pl>
Michal Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> I just started to wonder if we couldn't use output from Jeff's
> diff-highlight for gitweb.
That could be a sensible approach, but
> We could tech diff-highlight to produce diffs
> marked with -{} and +{} (this is the notation used by Jeff in one of his
> recent patches) or something like this and then just convert that into
> HTML markup.
this implementation strategy would not work well, given that the payload
can contain arbitrary letter sequence (e.g. a Perl script that wants be
explicit when writing a hashref literal write +{...} to disambiguate it
from a block). If you are going to modularize diff-highlight and reuse
it, it needs to learn how to talk HTML to properly escape the payload.
^ permalink raw reply
* An incremental update to "What's cooking"
From: Junio C Hamano @ 2012-02-14 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <7v4nuuea7r.fsf@alter.siamese.dyndns.org>
Here is the tonight's snapshot as an incremental update to the issue #5
of "What's cooking" for this month.
I'd like to merge jn/merge-no-edit-fix topic to 'maint' and release the
first maintenance release 1.7.9.1 soonish. The topic is merged to 'master'
already, and it is very much appreciated if people can test and eyeball it
to make sure we fixed what is broken in the vanilla 1.7.9 release without
causing regression in unexpected places.
Thanks, and goodnight.
----------------------------------------------------------------
Born topics
[New Topics]
* cb/maint-rev-list-verify-object (2012-02-13) 1 commit
- git rev-list: fix invalid typecast
Fixes an obscure bug in "rev-list --verify" that skipped verification
depending on the phase of the moon, which dates back to 1.7.8.x series.
* cb/maint-t5541-make-server-port-portable (2012-02-13) 1 commit
- t5541: check error message against the real port number used
Test fix.
* cb/receive-pack-keep-errors (2012-02-13) 1 commit
- do not override receive-pack errors
One hunk and the word "override" in the description were a bit iffy.
* cb/transfer-no-progress (2012-02-13) 1 commit
- push/fetch/clone --no-progress suppresses progress output
The transport programs semi-ignored --no-progress and showed progress when
sending their output to a terminal.
* jk/diff-highlight (2012-02-13) 5 commits
- diff-highlight: document some non-optimal cases
- diff-highlight: match multi-line hunks
- diff-highlight: refactor to prepare for multi-line hunks
- diff-highlight: don't highlight whole lines
- diff-highlight: make perl strict and warnings fatal
Updates diff-highlight (in contrib/).
* zj/decimal-width (2012-02-13) 1 commit
- (sign-off???) make lineno_width() from blame reusable for others
(this branch is used by zj/diff-stat-dyncol.)
Refactoring.
* zj/term-columns (2012-02-13) 1 commit
- pager: find out the terminal width before spawning the pager
(this branch is used by zj/diff-stat-dyncol.)
Fixes "git -p cmd" for any subcommand that cares about the true terminal
width.
* hv/submodule-recurse-push (2012-02-13) 3 commits
- push: teach --recurse-submodules the on-demand option
- Refactor submodule push check to use string list instead of integer
- Teach revision walking machinery to walk multiple times sequencially
The bottom one was not clearly explained.
* zj/diff-stat-dyncol (2012-02-13) 2 commits
- diff --stat: use the full terminal width
- Merge branch 'zj/term-columns' into zj/diff-stat-dyncol
(this branch uses zj/decimal-width and zj/term-columns.)
This breaks tests. Perhaps it is not worth using the decimal-width stuff
for this series, at least initially.
--------------------------------------------------
[Cooking]
-* ld/git-p4-expanded-keywords (2012-02-09) 2 commits
+* ld/git-p4-expanded-keywords (2012-02-13) 3 commits
+ - git-p4: more RCS tests
- git-p4: initial demonstration of possible RCS keyword fixup
- git-p4: add test case for RCS keywords
-Waiting for reviews and user reports.
+Waiting for the dust to settle.
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jeff King @ 2012-02-14 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Kiedrowicz, git, Jakub Narebski
In-Reply-To: <7vpqdh999t.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 11:14:22PM -0800, Junio C Hamano wrote:
> > We could tech diff-highlight to produce diffs
> > marked with -{} and +{} (this is the notation used by Jeff in one of his
> > recent patches) or something like this and then just convert that into
> > HTML markup.
>
> this implementation strategy would not work well, given that the payload
> can contain arbitrary letter sequence (e.g. a Perl script that wants be
> explicit when writing a hashref literal write +{...} to disambiguate it
> from a block). If you are going to modularize diff-highlight and reuse
> it, it needs to learn how to talk HTML to properly escape the payload.
They're both written in perl; perhaps a more sensible solution would be
to lib-ify diff-highlight and use it directly inside gitweb.
-Peff
^ permalink raw reply
* Re: [PATCH 2/5] do not override receive-pack errors
From: Clemens Buchacher @ 2012-02-14 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8vk6csx9.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 01:41:38PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > Receive runs rev-list --verify-objects in order to detect missing
> > objects. However, such errors are ignored and overridden later.
>
> This makes me worried (not about the patch, but about the current code).
>
> Are there codepaths where an earlier pass of verify-objects mark a cmd as
> bad with a non-NULL error_string, and later code that checks other aspect
> of the push says the update does not violate its criteria, and flips the
> non-NULL error_string back to NULL? Or is the only offence you found in
> such later code that it fills error_string with its own non-NULL string
> when it finds a violation (and otherwise does not touch error_string)?
>
> In other words, is this really "ignored and overridden", not merely
> "overwritten"?
Yes, it really is. For example, in t5504 rev-list --verify-objects (it
was turned on for me if called from there) detects the corrupt object.
But the error string is later overwritten with the return value of
update, which is NULL in this case.
That is why I had to change the t5504 tests from a successful git push
to a test_must_fail git push with this fix. To keep the previous
behavior we would have to replace the corrupt blob with a more subtle
corruption that rev-list --verify-objects would not detect, but fsck
would (e.g., a malformed commit header).
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > index fa7448b..0afb8b2 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -642,8 +642,10 @@ static void check_aliased_updates(struct command *commands)
> > }
> > sort_string_list(&ref_list);
> >
> > - for (cmd = commands; cmd; cmd = cmd->next)
> > - check_aliased_update(cmd, &ref_list);
> > + for (cmd = commands; cmd; cmd = cmd->next) {
> > + if (!cmd->error_string)
> > + check_aliased_update(cmd, &ref_list);
> > + }
>
[...]
> If we have already decided the former cmd is deemed to fail and skip
> this check, we would not catch that the latter cmd is trying to make
> an inconsistent update request, and we would end up ignoring that
> case.
Actually, check_alias_update searches for aliases of cmd in ref_list,
which is a list of refs from all commands, irrespective of their error
status. So this change is correct.
However, after re-reading the code I now have the impression that the
alias detection is not entirely correct. It does find aliases between
symrefs and regular refs. But it does not find aliases between two
symrefs, because ref_list will not contain the actual ref pointed to,
and therefore the code considers neither symref an alias.
But that is independent of the hunk above.
^ permalink raw reply
* Re: Setting up a Git server (+ gitweb) with .htaccess files HOWTO
From: Matthieu Moy @ 2012-02-14 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1upyft1b.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> After seeing the section that runs "git init" in a throw-away CGI script,
> I started wondering what the point of this site in forbidding a shell
> access in the first place.
The sysadmin trusts users enough to allow running arbitrary CGI there.
Not giving shell access greatly limits the accidental mis-uses of the
server, or silly attacks by incompetent users (i.e. "students" ;-) ). A
few years ago, people had shell access on most servers, and they were
using it to run seti@home & other heavy stuff there.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 3/5] git push: verify refs early
From: Clemens Buchacher @ 2012-02-14 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce
In-Reply-To: <7v4nuucrbm.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 02:16:13PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > I suppose with some effort, this could be done for smart HTTP as well.
> > But I am not sure if we actually want the overhead of the additional
> > ping-pong for HTTP.
>
> Hrm, I am confused.
>
> The updated protocol exchange, if I am reading your patch correctly, would
> go like this (S stands for the sender, R for the receiver):
>
> R: Here are the tips of my refs
> ----
> S: I'd like to update your refs this way
> ----
> + R: No you cannot because all updates will fail, go away
> or
> + R: You may proceed, as some updates may succeed
> ----
> S: Here is the packfile
> ----
> R: Here is how I processed your request
>
> Given that this makes the sender stall for both smart HTTP and native
> protocol, don't your worries about the additional ping-pong apply equally
> to both transports?
That is true. However, my assumption was that the overhead is greater
for HTTP, because the native protocol is full-duplex, while HTTP tears
down the connection and starts from scratch with each request. But to be
honest, I am not confident that this assumption is correct.
So, the stall might be an issue for both the native and the HTTP
protocol, or for neither. We should probably find out and then decide
whether to make this change for both protocols or not at all.
> If it is not worth doing for smart HTTP, I wonder if it is worth doing for
> native transport. After all, "all updates will fail" is hopefully the
> less likely case, and with this protocol extension, we end up penalizing
> the common case with an extra stall for everybody, regardless of the
> transport.
Indeed. I wish we could make the ref validation asynchronous. The client
would start sending object data right away, while listening for an
"abort" command on the side-band. But if I understand correctly, that is
not possible for HTTP.
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Clemens Buchacher @ 2012-02-14 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <7vhayuctwm.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 01:20:25PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> >> Erm,... do you really need the alias if you add git-p4 in a directory on
> >> your $PATH?
> >
> > With recent git versions, this has stopped working.
>
> Erm, I am confused.
Looks like in my case it did not work because I had a PATH entry with a
'~' in it. It probably stopped working for me because I moved some
executables around.
It's not a regression (I just tried with 1.6.0 and I get the same
result). And dash does not apply tilde expansion to PATH either. So
maybe it's not even a bug.
^ permalink raw reply
* [PATCH] filter-branch: cd to the correct directory when -d is used
From: Per Cederqvist @ 2012-02-14 9:49 UTC (permalink / raw)
To: git; +Cc: cederp, ceder
git-filter-branch changes directory to $tempdir/t, which by default is
.git-rewrite/t. Before doing the read-tree to update the working tree
it uses "cd ../.." to get back to the working tree. This breaks if
you use something like "-d /tmp/tempdir", as the read-tree will be
executed in /tmp instead of in your working tree.
Fixed by adding a variable that holds the original value of $(pwd),
and cd back to that value.
Added tests that demonstrates some issues that can happen without this
fix.
Signed-off-by: Per Cederqvist <cederp@opera.com>
---
git-filter-branch.sh | 3 ++-
t/t7003-filter-branch.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index add2c02..a58b50b 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -217,6 +217,7 @@ t)
test -d "$tempdir" &&
die "$tempdir already exists, please remove it"
esac
+oldpwd="$(pwd)"
mkdir -p "$tempdir/t" &&
tempdir="$(cd "$tempdir"; pwd)" &&
cd "$tempdir/t" &&
@@ -489,7 +490,7 @@ if [ "$filter_tag_name" ]; then
done
fi
-cd ../..
+cd "$oldpwd"
rm -rf "$tempdir"
trap - 0
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index e022773..fa464a2 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -367,4 +367,42 @@ test_expect_success 'replace submodule revision' '
test $orig_head != `git show-ref --hash --head HEAD`
'
+test_expect_success 'get a fresh tree' '
+ rm -fr ?* .git .gitmodules
+'
+
+deep_tree() {
+ test_expect_success 'setup deep tree' '
+ rm -fr drepo &&
+ mkdir drepo &&
+ ( cd drepo &&
+ git init &&
+ mkdir kom++ &&
+ test_commit authors kom++/AUTHORS "Fake authors file" &&
+ test_commit changelog kom++/ChangeLog "Fake ChangeLog file"
+ )
+ '
+
+ test_expect_success '-d tempdir with --subdirectory-filter' '
+ (cd drepo &&
+ git filter-branch -d "$TRASHDIR/tmpdir" --subdirectory-filter kom++
--tag-name-filter cat -- --all
+ )
+ '
+
+ test_expect_success 'content after -d with --subdirectory-filter' '
+ test_path_is_missing AUTHORS "AUTHORS created in tmpdir/.."
+ test_path_is_missing ChangeLog "ChangeLog created in tmpdir/.."
+ test_path_is_missing drepo/kom++ "kom++ remains"
+ test_path_is_file drepo/AUTHORS "AUTHORS not moved to top-level"
+ test_path_is_file drepo/ChangeLog "ChangeLog not moved to top-level"
+ '
+
+ test_expect_success 'Clean workdir' '
+ cd drepo&&git diff --quiet
+ '
+}
+
+deep_tree
+deep_tree # In Git 1.7.9 and earlier filter-branch fails the second time.
+
test_done
--
1.7.9
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Thomas Rast @ 2012-02-14 11:34 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Git Mailing List, Nguyen Thai Ngoc Duy
In-Reply-To: <CAA01Csp6_9fP2rg4104UWUXwOxZmUVdQNDAaBe6fRou6agBz6g@mail.gmail.com>
Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> On Fri, Feb 10, 2012 at 10:42 AM, Piotr Krukowiecki
> <piotr.krukowiecki@gmail.com> wrote:
>> 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
[...]
> I can't reproduce this behavior at the moment. 'status' on the
> directory takes about 1.5s instead of 17s. status on whole repository
> takes 27s.
> This is my work repository, so it was changed today.
To me these timings smell like a combination of either a network
filesystem or a slow/busy disk, and non-packed repositories. Next time
this happens look at 'git count-objects', run 'git gc' and redo the
timings.
If you are indeed on a network filesystem, also look at the
core.preloadIndex setting.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/2] Save terminal width before setting up pager and export term_columns()
From: Nguyen Thai Ngoc Duy @ 2012-02-14 11:44 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1329055953-29632-1-git-send-email-zbyszek@in.waw.pl>
2012/2/12 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
> This replaces cb0850f (Save terminal width before setting up pager -
> 2012-02-04) from Nguyễn Thái Ngọc Duy and my previous patch to export
> term_columns().
>
> This is directly on top of v1.7.9 as requested.
>
> I removed Signed-off-by from Nguyễn and Junio because the patch is
> substantially changed.
No problems. I will rebase my series on top of this patch (its final
version, that is).
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] Save terminal width before setting up pager and export term_columns()
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-14 11:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <CACsJy8Da=JMF7B9hW+WXzRXQFiGJxh0S7HYFg9+uweZ=pMOmTQ@mail.gmail.com>
On 02/14/2012 12:44 PM, Nguyen Thai Ngoc Duy wrote:
> 2012/2/12 Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>:
>> This replaces cb0850f (Save terminal width before setting up pager -
>> 2012-02-04) from Nguyễn Thái Ngọc Duy and my previous patch to export
>> term_columns().
>>
>> This is directly on top of v1.7.9 as requested.
>>
>> I removed Signed-off-by from Nguyễn and Junio because the patch is
>> substantially changed.
>
> No problems. I will rebase my series on top of this patch (its final
> version, that is).
Hi, I think that Junio's will be the final version. I have no objections
to it.
Zbyszek
^ permalink raw reply
* cvs2git migration
From: supadhyay @ 2012-02-14 12:01 UTC (permalink / raw)
To: git
Hi All,
I want to migrate my version control CVS to GIT. I have few links which
mentioned about how to migrate CVS repositories to GIT but there is no
description about how to migrate existing CVS users to GIT?
Can you please suggest me or forward me some links which mentioned about how
to migrate users as well.
Thanks in advance.
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-migration-tp7283631p7283631.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Support wrapping commit messages when you read them
From: Holger Hellmuth @ 2012-02-14 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sidney San Martín, git
In-Reply-To: <7vzkcmbcbq.fsf@alter.siamese.dyndns.org>
On 13.02.2012 23:25, Junio C Hamano wrote:
> "Computers are good at automating" is true, and that is why real editors
> give an easy way to auto-wrap long prose in a paragraph while composing.
> But "computers are good at automating" is not a convincing justification
> to let the composer leave unreasonably long lines in the commit log object
> and force the reader side to line-wrap the mess only to fix it up.
Maybe this is more convincing: Only the reader side knows the
line-length of the display or window.
^ permalink raw reply
* [PATCH v2] make lineno_width() from blame reusable for others
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-14 12:24 UTC (permalink / raw)
To: git, gitster, pclouds; +Cc: Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <7vhayub9d3.fsf@alter.siamese.dyndns.org>
builtin/blame.c has a helper function to compute how many columns we
need to show a line-number, whose implementation is reusable as a more
generic helper function to count the number of columns necessary to
show any cardinal number.
Rename it to decimal_width(), move it to pager.c and export it for use
by future callers. The argument type is changed to unsigned to underline
the fact that the function supports only non-negative numbers.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
I'll be using this in the 'diff --stat: use the full terminal width'
patch.
v2: - change arg type to unsigned
- corrected commit message
builtin/blame.c | 18 +++---------------
cache.h | 1 +
| 12 ++++++++++++
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 5a67c20..f028e8a 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1829,18 +1829,6 @@ static int read_ancestry(const char *graft_file)
}
/*
- * How many columns do we need to show line numbers in decimal?
- */
-static int lineno_width(int lines)
-{
- int i, width;
-
- for (width = 1, i = 10; i <= lines; width++)
- i *= 10;
- return width;
-}
-
-/*
* How many columns do we need to show line numbers, authors,
* and filenames?
*/
@@ -1880,9 +1868,9 @@ static void find_alignment(struct scoreboard *sb, int *option)
if (largest_score < ent_score(sb, e))
largest_score = ent_score(sb, e);
}
- max_orig_digits = lineno_width(longest_src_lines);
- max_digits = lineno_width(longest_dst_lines);
- max_score_digits = lineno_width(largest_score);
+ max_orig_digits = decimal_width(longest_src_lines);
+ max_digits = decimal_width(longest_dst_lines);
+ max_score_digits = decimal_width(largest_score);
}
/*
diff --git a/cache.h b/cache.h
index 2f30b3a..3504bcc 100644
--- a/cache.h
+++ b/cache.h
@@ -1176,6 +1176,7 @@ extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
extern int term_columns(void);
+extern int decimal_width(unsigned number);
extern const char *editor_program;
extern const char *askpass_program;
--git a/pager.c b/pager.c
index e06cfa0..2e16a9c 100644
--- a/pager.c
+++ b/pager.c
@@ -153,3 +153,15 @@ int term_columns(void)
#endif
return term_columns_at_startup;
}
+
+/*
+ * How many columns do we need to show this number in decimal?
+ */
+int decimal_width(unsigned number)
+{
+ int i, width;
+
+ for (width = 1, i = 10; i <= number; width++)
+ i *= 10;
+ return width;
+}
--
1.7.9.3.g2429d.dirty
^ permalink raw reply related
* Re: git-p4 useclientspec broken?
From: Pete Wyckoff @ 2012-02-14 12:36 UTC (permalink / raw)
To: Laurent Charrière; +Cc: git
In-Reply-To: <4F39AF04.5080607@promptu.com>
lcharriere@promptu.com wrote on Mon, 13 Feb 2012 16:47 -0800:
> Since I've upgraded to 1.7.9 (on OS X Lion, FWIW), git-p4 submit
> fails to apply any patches if I use useclientspec=true when cloning.
>
> My p4 client is as follows:
>
> Client: malibu
> (...)
> Root: /Users/lcharriere/Documents/Perforce/all
> (...)
> View:
> //sandbox/... //malibu/sandbox/...
> //depot/... //malibu/depot/...
>
> Sequence of steps to reproduce:
>
> $ git p4 clone //sandbox/lcharriere/foo --use-client-spec
> $ cd foo && find .
> ./.git
> (...)
> ./sandbox/lcharriere/foo/.gitignore
> ./sandbox/lcharriere/foo/foo.py
>
> -- This is new behavior to me, BTW. Previously, I would have seen
> ./.git
> (...)
> ./.gitignore
> ./foo.py
I did try to clean up our handling of --use-client-spec. This
behavior was done on purpose, but maybe I didn't the implications
on people who were relying on the old way. In particular the
behavior of multi-line view specs and those with + and - was
largely unpredictable.
The client spec now has absolute control over what files get put
where in the git repo, just like in p4. The argument
"//sandbox/lcharriere/foo" in your clone command limits the scope
of what is checked out, but does not affect where it is placed.
You can get the git layout you expect with this view:
//sandbox/lcharriere/foo/... //malibu/...
or simply just don't use --use-client-spec at all:
git p4 clone //sandbox/lcharriere/foo
Is this new behavior bad for you? Suggestions welcome.
> $ cat "test" >> sandbox/lcharriere/foo/.gitignore
> $ git commit -a -m "test"
> git commit -a -m "test"
> [master 7398144] test
> 1 files changed, 1 insertions(+), 0 deletions(-)
> $ git p4 submit
> Perforce checkout for depot path //sandbox/lcharriere/foo/ located
> at /Users/lcharriere/Documents/Perforce/all/sandbox/lcharriere/foo/
> Synchronizing p4 checkout...
> ... - file(s) up-to-date.
> Applying 739814457a8faa84dc0bddd830f671569576b177 test
>
> sandbox/lcharriere/foo/.gitignore - file(s) not on client.
> error: sandbox/lcharriere/foo/.gitignore: No such file or directory
> Unfortunately applying the change failed!
> What do you want to do?
> [s]kip this patch / [a]pply the patch forcibly and with .rej files /
> [w]rite the patch to a file (patch.txt)
This is definitely a bug. I reproduced a similar problem.
> I tried to follow what's going on with pdb:
> * self.depotPath is //sandbox/lcharriere/foo, so git-p4 chdir's to
> /Users/lcharriere/Documents/Perforce/all/sandbox/lcharriere/foo/
> * In P4Submit.applyCommit, line 926 is:
> p4_edit(path)
> At this point path is 'sandbox/lcharriere/foo/.gitignore'
The path should be plain old ".gitignore", as you noticed.
> I'm guessing this is why the p4 executable doesn't find it. The path
> should be .gitignore. Is it possible that the new behavior I
> mentioned above of reproducing the depot hierarchy when
> useclientspec is true is having unintended side effects, or is a
> bug?
I'll get a patch out tonight or soon. Need to do gobs of testing
on the submit path to make sure nothing else is broken.
-- Pete
^ permalink raw reply
* git-latexdiff: Git and Latexdiff working together
From: Matthieu Moy @ 2012-02-14 13:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi,
You may know latexdiff, a neat tool to visualize differences between
LaTeX files (it annotates your .tex file with colors for removed/added
parts, producing another compilable .tex file).
I wrote a little shell-script that allows one to use latexdiff on files
versionned by Git, with e.g.
git latexdiff HEAD^ --main foo.tex --output foo.pdf
Essentially, it does a checkout of the old and new revisions, and calls
latexdiff + pdflatex for you.
The result is attached in case anyone is interested.
It may be relevant to add this to contrib/ in git.git. If anyone's
interested, let me know, and I'll resend the code in the form of a
patch doing that.
Regards,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
[-- Attachment #2: git-latexdiff --]
[-- Type: application/octet-stream, Size: 4613 bytes --]
#! /bin/sh
usage () {
cat << EOF
Usage: $(basename $0) [options] OLD [NEW]
Call latexdiff on two Git revisions of a file.
OLD and NEW are Git revision identifiers. NEW defaults to HEAD.
Options:
--help This help message
--main FILE.tex Name of the main LaTeX file
--no-view Don't display the resulting PDF file
--view View the resulting PDF file
(default if -o is not used)
--no-cleanup Don't cleanup temp dir after running
-o FILE, --output FILE
Copy resulting PDF into FILE
(usually ending with .pdf)
EOF
}
die () {
echo "fatal: $@"
exit 1
}
verbose () {
if [ "$verbose" = 1 ]; then
printf "%s ..." "$@"
fi
}
verbose_progress () {
if [ "$verbose" = 1 ]; then
printf "." "$@"
fi
}
verbose_done () {
if [ "$verbose" = 1 ]; then
echo " done."
fi
}
old=
new=
main=
view=maybe
cleanup=1
verbose=0
output=
initial_dir=$PWD
while test $# -ne 0; do
case "$1" in
"--help"|"-h")
usage
exit 0
;;
"--main")
shift
main=$1
;;
"--no-view")
view=0
;;
"--view")
view=1
;;
"--no-cleanup")
cleanup=0
;;
"-o"|"--output")
shift
output=$1
;;
"--verbose"|"-v")
verbose=1
;;
*)
if [ "$1" = "" ]; then
echo "Empty string not allowed as argument"
usage
exit 1
elif [ "$old" = "" ]; then
old=$1
elif [ "$new" = "" ]; then
new=$1
else
echo "Bad argument $1"
usage
exit 1
fi
;;
esac
shift
done
if [ "$new" = "" ]; then
new=HEAD
fi
if [ "$old" = "" ]; then
echo "fatal: Please, provide at least one revision to diff with."
usage
exit 1
fi
if [ "$main" = "" ]; then
printf "%s" "No --main provided, trying to guess ... "
main=$(git grep -l '^[ \t]*\\documentclass')
# May return multiple results, but if so the result won't be a file.
if [ -r "$main" ]; then
echo "Using $main as the main file."
else
if [ "$main" = "" ]; then
echo "No candidate for main file."
else
echo "Multiple candidates for main file:"
printf "%s\n" "$main" | sed 's/^/\t/'
fi
die "Please, provide a main file with --main FILE.tex."
fi
fi
if [ ! -r "$main" ]; then
die "Cannot read $main."
fi
verbose "Creating temporary directories"
git_prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-cdup)" || die "Can't cd back to repository root"
git_dir="$(git rev-parse --git-dir)" || die "Not a git repository?"
git_dir=$(cd "$git_dir"; pwd)
main=$git_prefix/$main
tmpdir=$initial_dir/git-latexdiff.$$
mkdir "$tmpdir" || die "Cannot create temporary directory."
cd "$tmpdir" || die "Cannot cd to $tmpdir"
mkdir old new diff || die "Cannot create old, new and diff directories."
verbose_done
verbose "Checking out old and new version"
cd old || die "Cannot cd to old/"
git --git-dir="$git_dir" --work-tree=. checkout "$old" -- . || die "checkout failed for old/"
verbose_progress
cd ../new || die "Cannot cd to new/"
git --git-dir="$git_dir" --work-tree=. checkout "$new" -- . || die "checkout failed for new/"
verbose_progress
cd ../diff || die "Cannot cd to diff/"
git --git-dir="$git_dir" --work-tree=. checkout "$new" -- . || die "checkout failed for diff/"
verbose_progress
cd .. || die "Cannot cd back to toplevel"
verbose_done
verbose "Running latexdiff --flatten old/$main new/$main > diff/$main"
latexdiff --flatten old/$main new/$main > diff/$main || die "latexdiff failed"
verbose_done
mainbase=$(basename "$main" .tex)
maindir=$(dirname "$main")
verbose "Compiling result"
compile_error=0
cd diff/"$maindir" || die "Can't cd to diff/$maindir"
if [ -f Makefile ]; then
make || compile_error=1
else
pdflatex --interaction errorstopmode "$mainbase" || compile_error=1
fi
verbose_done
pdffile="$mainbase".pdf
if [ ! -r "$pdffile" ]; then
echo "No PDF file generated."
compile_error=1
fi
if [ ! -s "$pdffile" ]; then
echo "PDF file generated is empty."
compile_error=1
fi
if [ "$compile_error" = "1" ]; then
echo "Error during compilation. Please examine and cleanup if needed:"
echo "Directory: $tmpdir/diff/$maindir/"
echo " File: $mainbase.tex"
# Don't clean up to let the user diagnose.
exit 1
fi
if [ "$output" != "" ]; then
abs_pdffile="$PWD/$pdffile"
(cd "$initial_dir" && cp "$abs_pdffile" "$output")
echo "Output written on $output"
fi
if [ "$view" = 1 ] || [ "$view" = maybe ] && [ "$output" = "" ]; then
xpdf "$pdffile"
fi
if [ "$cleanup" = 1 ]; then
verbose "Cleaning-up result"
rm -fr "$tmpdir"
verbose_done
fi
^ permalink raw reply
* Git submodules with usernames in the URL
From: Tillmann.Crueger @ 2012-02-14 13:26 UTC (permalink / raw)
To: git
Hi,
I already had a look at the mailinglist archive, but I could not find any mention of this problem. There is a posting on Stackoverflow.com about this (http://stackoverflow.com/questions/7714326/git-submodule-url-not-including-username) with a workaround, but it would nice to have an official position.
Here is the problem:
When I am using git-submodule over an authorized https it is convenient to be able to specify the username directly in the url in the form https://user@domain.com/path/to/repo. So I am able to do a
> git submodule add https://user@domain.com/path/to/repo
Howver if I do this, the username becomes baked into the URL of the submodule, so other people working with the repository will not be able to use the submodule and have to change the URL first.
Is there an actual rationale for including the username in the URL in this case, or is this just because it is simpler than removing it?
One thing I noticed, is that automatically removing it would basically eliminate the convinience for the person who has been using that URL in the first place. If the username was removed every update would have to query the username again. Also having a username in the repo could be correct, in case this isn't a real user, but a role for using that repository.
Still I feel that having a username within a repository is hardly ever what someone wants and most often a mistake. For now I will try to educate everybody about this and fix all repositories where this goes wrong, but a better solution would be nice to have.
Thanks for your time,
Till
^ 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