* [PATCH 0/4] gitweb feed metadata tuneups
From: Giuseppe Bilotta @ 2009-01-23 4:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
The next four patches add some metadata to gitweb generated feeds:
channel image, managing editor and last-update dates are added to RSS
feeds, and the feed generator (gitweb, with version specification) is
added to both RSS and Atom feeds.
Giuseppe Bilotta (4):
gitweb: channel image in rss feed
gitweb: feed generator metadata
gitweb: rss feed managingEditor
gitweb: rss channel date
gitweb/gitweb.perl | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH 1/4] gitweb: channel image in rss feed
From: Giuseppe Bilotta @ 2009-01-23 4:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
In-Reply-To: <1232686121-1800-1-git-send-email-giuseppe.bilotta@gmail.com>
Define the channel image for the rss feed when the logo or favicon are
defined, preferring the former to the latter. As suggested in the RSS
2.0 specifications, the image's title and link as set to the same as the
channel's.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..f8a5d2e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6075,6 +6075,16 @@ XML
"<link>$alt_url</link>\n" .
"<description>$descr</description>\n" .
"<language>en</language>\n";
+ if (defined $logo || defined $favicon) {
+ # prefer the logo to the favicon, since RSS
+ # doesn't allow both
+ my $img = esc_url($logo || $favicon);
+ print "<image>\n" .
+ "<url>$img</url>\n" .
+ "<title>$title</title>\n" .
+ "<link>$alt_url</link>\n" .
+ "</image>\n";
+ }
} elsif ($format eq 'atom') {
print <<XML;
<feed xmlns="http://www.w3.org/2005/Atom">
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/4] gitweb: feed generator metadata
From: Giuseppe Bilotta @ 2009-01-23 4:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
In-Reply-To: <1232686121-1800-2-git-send-email-giuseppe.bilotta@gmail.com>
Add <generator> tag to RSS and Atom feed. Versioning info (gitweb/git
core versions, separated by a literal slash) is stored in the
appropriate attribute for the Atom feed, and in the tag content for the
RSS feed.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f8a5d2e..3d94f50 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6085,6 +6085,7 @@ XML
"<link>$alt_url</link>\n" .
"</image>\n";
}
+ print "<generator>gitweb v.$version/$git_version</generator>\n";
} elsif ($format eq 'atom') {
print <<XML;
<feed xmlns="http://www.w3.org/2005/Atom">
@@ -6111,6 +6112,7 @@ XML
} else {
print "<updated>$latest_date{'iso-8601'}</updated>\n";
}
+ print "<generator version='$version/$git_version'>gitweb</generator>\n";
}
# contents
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/4] gitweb: rss feed managingEditor
From: Giuseppe Bilotta @ 2009-01-23 4:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
In-Reply-To: <1232686121-1800-3-git-send-email-giuseppe.bilotta@gmail.com>
The RSS 2.0 specification allows an optional managingEditor tag for the
channel, containing the "email address for person responsible for editorial
content", which is basically the project owner.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d94f50..cc6d0fb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6074,7 +6074,9 @@ XML
print "<title>$title</title>\n" .
"<link>$alt_url</link>\n" .
"<description>$descr</description>\n" .
- "<language>en</language>\n";
+ "<language>en</language>\n" .
+ # project owner is responsible for 'editorial' content
+ "<managingEditor>$owner</managingEditor>\n";
if (defined $logo || defined $favicon) {
# prefer the logo to the favicon, since RSS
# doesn't allow both
--
1.5.6.5
^ permalink raw reply related
* [PATCH 4/4] gitweb: rss channel date
From: Giuseppe Bilotta @ 2009-01-23 4:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
In-Reply-To: <1232686121-1800-4-git-send-email-giuseppe.bilotta@gmail.com>
The RSS 2.0 specifications defines not one but _two_ dates for its
channel element! Woohoo! Luckily, it seems that consensus seems to be
that if both are present they should be equal, except for some very
obscure and discouraged cases. Since lastBuildDate would make more sense
for us and pubDate seems to be the most commonly used, we defined both
and make them equal.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6d0fb..756868a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6087,6 +6087,10 @@ XML
"<link>$alt_url</link>\n" .
"</image>\n";
}
+ if (%latest_date) {
+ print "<pubDate>$latest_date{'rfc2822'}</pubDate>\n";
+ print "<lastBuildDate>$latest_date{'rfc2822'}</lastBuildDate>\n";
+ }
print "<generator>gitweb v.$version/$git_version</generator>\n";
} elsif ($format eq 'atom') {
print <<XML;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] git-cvsserver: run post-update hook *after* update.
From: Stefan Karpinski @ 2009-01-23 5:43 UTC (permalink / raw)
To: git
In-Reply-To: <1232144521-21947-2-git-send-email-stefan.karpinski@gmail.com>
I know that this and the other patch I sent are completely trivial and
uninteresting, but they would appear to be correct. Do I need to prod
more to get them included or what? Did I submit them incorrectly?
On Fri, Jan 16, 2009 at 2:22 PM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
>
> CVS server was running the hook before the update
> action was actually done. This performs the update
> before the hook is called.
> ---
>
> Unless I'm severely misunderstanding the meaning of
> a *post-update* hook, I think this is a no-brainer.
>
> git-cvsserver.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index c1e09ea..d2e6003 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -1413,14 +1413,14 @@ sub req_ci
> close $pipe || die "bad pipe: $! $?";
> }
>
> + $updater->update();
> +
> ### Then hooks/post-update
> $hook = $ENV{GIT_DIR}.'hooks/post-update';
> if (-x $hook) {
> system($hook, "refs/heads/$state->{module}");
> }
>
> - $updater->update();
> -
> # foreach file specified on the command line ...
> foreach my $filename ( @committedfiles )
> {
> --
> 1.6.0.3.3.g08dd8
>
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Junio C Hamano @ 2009-01-23 6:13 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Jeff King, René Scharfe, git
In-Reply-To: <200901220113.32711.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Jeff King, 22.01.2009:
> ...
>> > ...
>> > That would probably be better.
>>
>> Do you want to work on it, or should it go into the "yeah, right, one
>> day" section of my todo list?
>
> Yes, feel free to enlarge your todo list :)
> There are some other things that I want to work on before, so better
> don't count on me for this. But maybe I'll come up to it, before your
> todo list pointer reaches this item, who knows.
Whatever.
I merged and pushed out these two patches but they seem to break
format-patch big time if you have ui.color set to auto.
I will be reverting them out of 'next'. Grumble.
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Junio C Hamano @ 2009-01-23 6:15 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Sixt, Nathan Yergler, Michael J Gruber, Asheesh Laroia,
git
In-Reply-To: <20090123094509.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> But Nathan's first sentence is a different matter. I do not think it is
> coming from the same confusion, and I think the question is a valid
> one. Your answer does not explain why it is a bad idea to change the
> behavior of "git commit path" to what "git commit -i path" does during a
> merge.
>
> The answer of course can be "because it changes the behavior people are
> very much used to."
[jc: how many times do I have to ask you to wrap your lines, by the way?]
I tend to agree that "very much used to" argument carries much weight, but
I'll be sending a three-patch series to weatherbaloon the idea.
^ permalink raw reply
* [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Junio C Hamano @ 2009-01-23 6:17 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Sixt, Nathan Yergler, Michael J Gruber, Asheesh Laroia,
git
In-Reply-To: <7viqo64kfo.fsf@gitster.siamese.dyndns.org>
We are supposed to reject "--only path..." aka "a partial commit" during a
conflicted merge resolution, and accept "--include path..." aka "an also
commit" in such a case.
Recent git (since v1.3.0) always assumes that "git commit" with paths but
without --only nor --include requests the "--only" semantics, but there is
a discussion that it might be a good idea to assume "--include" semantics
during a merge.
The last test this commit adds expects such a behaviour and marked as
"expect_failure". It will be changed by the third patch in the series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7501-commit.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index b4e2b4d..0c10105 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -365,4 +365,48 @@ test_expect_success 'amend using the message from a commit named with tag' '
'
+test_expect_success 'setup merge commit with paths test' '
+ git reset --hard &&
+ git checkout HEAD^0 &&
+ echo frotz >file &&
+ test_tick &&
+ git add file &&
+ git commit -a -m "one side says frotz" &&
+ git tag one-side-says-frotz &&
+ git reset --hard HEAD^ &&
+ echo nitfol >file &&
+ test_tick &&
+ git add file &&
+ git commit -a -m "the other side says nitfol" &&
+ git tag the-other-side-says-nitfol
+'
+
+test_expect_success 'reject --only during a merge' '
+ git checkout HEAD^0 &&
+ git reset --hard the-other-side-says-nitfol &&
+ test_must_fail git merge one-side-says-frotz &&
+ echo yomin-only >file &&
+ test_must_fail git commit -m merge --only file &&
+ git reset --hard
+'
+
+test_expect_success 'allow --include during a merge' '
+ git checkout HEAD^0 &&
+ git reset --hard the-other-side-says-nitfol &&
+ test_must_fail git merge one-side-says-frotz &&
+ echo yomin-include >file &&
+ git commit -m merge --include file &&
+ git reset --hard
+'
+
+test_expect_failure 'assume --include during a merge' '
+ git checkout HEAD^0 &&
+ git reset --hard the-other-side-says-nitfol &&
+ test_must_fail git merge one-side-says-frotz &&
+ echo yomin-assumed >file &&
+ git add file &&
+ git commit -m merge file &&
+ git reset --hard
+'
+
test_done
--
1.6.1.265.g9a013
^ permalink raw reply related
* [PATCH 2/3] builtin-commit: shorten eye-sore overlong lines
From: Junio C Hamano @ 2009-01-23 6:19 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Sixt, Nathan Yergler, Michael J Gruber, Asheesh Laroia,
git
In-Reply-To: <7viqo64kfo.fsf@gitster.siamese.dyndns.org>
This does not change anything other than the way the variable to hold
an informative message thrown in the commit log buffer is assigned.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This does not really belong to the series in the sense that it is
needed to implement the new semantics, but these long lines have always
bothered me.
builtin-commit.c | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7aaa530..d861263 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -71,6 +71,29 @@ static int use_editor = 1, initial_commit, in_merge;
static const char *only_include_assumed;
static struct strbuf message;
+enum {
+ MSG_AMEND_CLEVER,
+ MSG_ASSUME_PARTIAL,
+};
+
+static void set_partial_commit_message(int msgnum)
+{
+ const char *msg;
+
+ switch (msgnum) {
+ case MSG_AMEND_CLEVER:
+ msg = "Clever... amending the last one with dirty index.";
+ break;
+ case MSG_ASSUME_PARTIAL:
+ msg = "Explicit paths specified without -i nor -o; assuming --only paths...";
+ break;
+ default:
+ die("Oops (%d) is not a valid message number", msgnum);
+ break;
+ }
+ only_include_assumed = msg;
+}
+
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -788,9 +811,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (argc == 0 && (also || (only && !amend)))
die("No paths with --include/--only does not make sense.");
if (argc == 0 && only && amend)
- only_include_assumed = "Clever... amending the last one with dirty index.";
+ set_partial_commit_message(MSG_AMEND_CLEVER);
if (argc > 0 && !also && !only)
- only_include_assumed = "Explicit paths specified without -i nor -o; assuming --only paths...";
+ set_partial_commit_message(MSG_ASSUME_PARTIAL);
if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
else if (!strcmp(cleanup_arg, "verbatim"))
--
1.6.1.265.g9a013
^ permalink raw reply related
* Re: RFC: git diff colorization idea
From: Wincent Colaiuta @ 2009-01-23 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org List
In-Reply-To: <7vhc3q6evi.fsf@gitster.siamese.dyndns.org>
El 23/1/2009, a las 1:32, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> I'm also thinking that perhaps a per-character approach might be
>> useful here instead of a per-word one (it would make that last hunk
>> look better in the mock-up screenshot that I posted); if I go the
>> per-
>> character route then that suggests that "--color-chars" might be the
>> right option name, and the color slots would then be
>> color.diff.new.char and color.diff.old.char.
>>
>> Any feedback or suggestions before I get in too deep?
>
> I personally find your "prposal" picture too loud to my eye.
Yes, mine too. I wouldn't actually use those colors in practice.
(Doubly so because the "removed" color looks like the "whitespace
error" color.)
I'll whip something up with non-garish defaults.
Cheers,
Wincent
^ permalink raw reply
* [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge
From: Junio C Hamano @ 2009-01-23 6:21 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Sixt, Nathan Yergler, Michael J Gruber, Asheesh Laroia,
git
In-Reply-To: <7viqo64kfo.fsf@gitster.siamese.dyndns.org>
"git commit paths..." has been a short-hand for "git commit -o paths..."
since v1.3.0 and let you create a commit skipping any other updated state
staged in the index. The "--only" semantics (aka "partial commit") is
always wrong during a conflicted merge resolution, and we rejected both
"git commit paths..." and "git commit -o paths..." forms during a merge.
On the other hand, "git commit -i paths..." (aka "an also commit", which
asks to commit what you staged in the index, and also the paths you may or
may not have git-add'ed) is accepted, as it is a way to register the
contents you fixed up to the index and commit the result.
This makes "git commit paths..." form default to "git commit -i paths"
semantics only during a merge, restoring the pre-v1.3.0 behaviour. The
codepath to create a non-merge commit is not affected and still defaults
to the "--only" semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 14 ++++++++++++--
t/t7501-commit.sh | 2 +-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index d861263..4cb1985 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -74,6 +74,7 @@ static struct strbuf message;
enum {
MSG_AMEND_CLEVER,
MSG_ASSUME_PARTIAL,
+ MSG_ASSUME_ALSO_DURING_MERGE
};
static void set_partial_commit_message(int msgnum)
@@ -87,6 +88,9 @@ static void set_partial_commit_message(int msgnum)
case MSG_ASSUME_PARTIAL:
msg = "Explicit paths specified without -i nor -o; assuming --only paths...";
break;
+ case MSG_ASSUME_ALSO_DURING_MERGE:
+ msg = "Paths specified without -i nor -o during a merge; assuming -i";
+ break;
default:
die("Oops (%d) is not a valid message number", msgnum);
break;
@@ -812,8 +816,14 @@ static int parse_and_validate_options(int argc, const char *argv[],
die("No paths with --include/--only does not make sense.");
if (argc == 0 && only && amend)
set_partial_commit_message(MSG_AMEND_CLEVER);
- if (argc > 0 && !also && !only)
- set_partial_commit_message(MSG_ASSUME_PARTIAL);
+ if (argc > 0 && !also && !only) {
+ if (!in_merge)
+ set_partial_commit_message(MSG_ASSUME_PARTIAL);
+ else {
+ set_partial_commit_message(MSG_ASSUME_ALSO_DURING_MERGE);
+ also = 1;
+ }
+ }
if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
else if (!strcmp(cleanup_arg, "verbatim"))
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0c10105..68892de 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -399,7 +399,7 @@ test_expect_success 'allow --include during a merge' '
git reset --hard
'
-test_expect_failure 'assume --include during a merge' '
+test_expect_success 'assume --include during a merge' '
git checkout HEAD^0 &&
git reset --hard the-other-side-says-nitfol &&
test_must_fail git merge one-side-says-frotz &&
--
1.6.1.265.g9a013
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Junio C Hamano @ 2009-01-23 6:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901212321.50526.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>>* js/diff-color-words (Tue Jan 20 21:46:57 2009 -0600) 8 commits
>> + color-words: Support diff.wordregex config option
>> + color-words: make regex configurable via attributes
>> + color-words: expand docs with precise semantics
>> + color-words: enable REG_NEWLINE to help user
>> + color-words: take an optional regular expression describing words
>> + color-words: change algorithm to allow for 0-character word
>> boundaries
>> + color-words: refactor word splitting and use ALLOC_GROW()
>> + Add color_fwrite_lines(), a function coloring each line
>> individually
>
> I think my patch in
> http://thread.gmane.org/gmane.comp.version-control.git/106567 should be
> applied to the top of this.
Thanks.
^ permalink raw reply
* Re: RFC: git diff colorization idea
From: Junio C Hamano @ 2009-01-23 6:45 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git@vger.kernel.org List
In-Reply-To: <5034E8A9-2B17-4368-8EDF-5FEE61BB2BAD@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
>>> Any feedback or suggestions before I get in too deep?
>>
>> I personally find your "prposal" picture too loud to my eye.
>
> Yes, mine too. I wouldn't actually use those colors in practice.
> (Doubly so because the "removed" color looks like the "whitespace
> error" color.)
I did not mean that your choice of colors is loud. Not at all. What I
meant was the use of color _everywhere_ makes it too loud, and also the
use of _larger number of_ colors makes it too loud.. In other words, you
are painting the output more than what the current output does, and that
made me find it too loud, no matter what the choice of colors are.
You might have misunderstood my illustration, but what I meant to suggest
was to leave most of the characters on both - and + lines in monochrome
(or whatever the "normal" is), and paint _only_ the words that are
different. The outcome would become _less_ colorful than the current
"whole -/+ lines are painted" output, but "only different words are
coloured; the words that are unmodified are left uncoloured, without
distracting the eyes." Much less louder than even the current one, yet
giving more information.
As -/+ has a marker value, I think colouring them may be Ok, too. That
would make something like this:
| {
|<red>-</red> <gray>local subcommands="add rm show prune<gray> <red>update</red>"
|<green>+</green> local subcommands="add <green>rename</green> rm show prune"
| if ...
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Johannes Sixt @ 2009-01-23 7:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <7vbpty4kby.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> +test_expect_success 'setup merge commit with paths test' '
> + git reset --hard &&
> + git checkout HEAD^0 &&
> + echo frotz >file &&
> + test_tick &&
> + git add file &&
> + git commit -a -m "one side says frotz" &&
> + git tag one-side-says-frotz &&
> + git reset --hard HEAD^ &&
> + echo nitfol >file &&
> + test_tick &&
> + git add file &&
> + git commit -a -m "the other side says nitfol" &&
> + git tag the-other-side-says-nitfol
> +'
> +
> +test_expect_success 'reject --only during a merge' '
> + git checkout HEAD^0 &&
> + git reset --hard the-other-side-says-nitfol &&
> + test_must_fail git merge one-side-says-frotz &&
> + echo yomin-only >file &&
> + test_must_fail git commit -m merge --only file &&
I don't see why this must fail: 'file' is the only file that is different
from HEAD. Yes, currently we fail; but if something is about to be
changed, then this can change as well.
> + git reset --hard
> +'
> +
> +test_expect_success 'allow --include during a merge' '
> + git checkout HEAD^0 &&
> + git reset --hard the-other-side-says-nitfol &&
> + test_must_fail git merge one-side-says-frotz &&
> + echo yomin-include >file &&
> + git commit -m merge --include file &&
> + git reset --hard
> +'
> +
> +test_expect_failure 'assume --include during a merge' '
> + git checkout HEAD^0 &&
> + git reset --hard the-other-side-says-nitfol &&
> + test_must_fail git merge one-side-says-frotz &&
> + echo yomin-assumed >file &&
> + git add file &&
> + git commit -m merge file &&
> + git reset --hard
> +'
If I read the test case correctly, there is only 'file' that is different
from HEAD, and it had a conflict. But IMO, the test should stress the
point that after the conflicted merge there are at least two files that
are different from HEAD, one was trivially merged, and the other had a
conflict.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Junio C Hamano @ 2009-01-23 7:16 UTC (permalink / raw)
To: Johannes Sixt
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <49796D0C.5070408@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> +test_expect_success 'reject --only during a merge' '
>> + git checkout HEAD^0 &&
>> + git reset --hard the-other-side-says-nitfol &&
>> + test_must_fail git merge one-side-says-frotz &&
>> + echo yomin-only >file &&
>> + test_must_fail git commit -m merge --only file &&
>
> I don't see why this must fail: 'file' is the only file that is different
> from HEAD. Yes, currently we fail; but if something is about to be
> changed, then this can change as well.
Not at all.
Avoiding --only is to prevent a much more dangerous glitch.
Suppose you and the other have two paths diverged, and one merges cleanly
and the other results in conflict. When "git merge" gives control back to
you, the cleanly merged result is ALREADY IN THE INDEX.
Now you futz with the other path, and say
git commit --only other
What --only tells git is "I do not care what I've staged in the index.
Start from the contents of HEAD commit, and update the index entry at these
paths (and these path _ONLY_), and commit the contents registered in the
index.
That is why --include is the only sane semantics during a conflicted
merge. I thought you should know better, as you were the one who gave the
explanation to Nathan, which triggered Nana's response, which resulted in
this series.
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jay Soffian @ 2009-01-23 7:18 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <200901222113.31082.robin.rosenberg.lists@dewire.com>
On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:
>> Mmm. I use opendiff, which is generally ok, but in this case produced
>> a merge looking like this :
>>
>> http://pastie.org/paste/asset/367587/Picture_6.png
>>
>> Which, in my mind, isn't any clearer about the fact that both lines
>> ought to be deleted than the text conflict markers are. Do any of the
>> other graphical tools present conflicts like that differently?
>
> Try a three-way merge tool instead like, e.g. xxdiff.
opendiff (aka FileMerge) *is* a three-way merge tool. If the
screenshot above is not clear, I'm not sure what would be. The left
pane shows your copy of the file with only line1, line3, and line4.
The right pane shows the other copy, with only line1, line2, and
line4.
The lower pane shows the merge resolution, which currently has the
single conflict highlighted, and is being resolved toward the right.
You can use the Action drop down menu to resolve the conflict one of
five ways: left, right, both (left first), both (right first),
neither. You've currently got "right" selected. The appropriate
resolution is "neither", which keeps neither line3 from the left, nor
line2 from the right.
Shrug.
j.
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Johannes Sixt @ 2009-01-23 7:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <7vab9i331g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>>> +test_expect_success 'reject --only during a merge' '
>>> + git checkout HEAD^0 &&
>>> + git reset --hard the-other-side-says-nitfol &&
>>> + test_must_fail git merge one-side-says-frotz &&
>>> + echo yomin-only >file &&
>>> + test_must_fail git commit -m merge --only file &&
>> I don't see why this must fail: 'file' is the only file that is different
>> from HEAD. Yes, currently we fail; but if something is about to be
>> changed, then this can change as well.
>
> Not at all.
Read again what I said: 'file' is the *ONLY* file that is different from
HEAD. Why should an explicit --only not work in this case?
> Avoiding --only is to prevent a much more dangerous glitch.
[...]
We are in total agreement about what you said in the rest of the message.
I'm proposing that, during a merge, if --only was given (or remains the
implicit choice), then we compare the index with HEAD, and if nothing
outside the given pathspec differs from HEAD, then allow the commit.
-- Hannes
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Junio C Hamano @ 2009-01-23 7:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git list, Christian MICHON
In-Reply-To: <20090123094529.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> Perhaps something like this totally untested patch.
>
> You have test scripts already, but you say it is untested?
Correct. I did not run that new test, let alone existing ones ;-)
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Junio C Hamano @ 2009-01-23 7:39 UTC (permalink / raw)
To: Johannes Sixt
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <4979727F.80007@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Read again what I said: 'file' is the *ONLY* file that is different from
> HEAD. Why should an explicit --only not work in this case?
I know what you said.
If you study the codepath, the code does not know nor care if 'file' is
the only one or if there are other changed paths.
Too much additional code is needed and for too little gain.
^ permalink raw reply
* Re: [PATCH] git-cvsserver: run post-update hook *after* update.
From: Junio C Hamano @ 2009-01-23 8:00 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: git
In-Reply-To: <d4bc1a2a0901222143i1a7dd051h1778dcb563120195@mail.gmail.com>
Stefan Karpinski <stefan.karpinski@gmail.com> writes:
> I know that this and the other patch I sent are completely trivial and
> uninteresting, but they would appear to be correct. Do I need to prod
> more to get them included or what? Did I submit them incorrectly?
If you spend the bandwidth to quote the whole patch, don't quote it, but
please use the same bandwidth to resend it --- that way, if the reason
your patch left unapplied was because your earlier submission was lost in
the noise or too heavy maintainer workload, it can be easily picked up.
Upon my cursory look the patch looks sane, even though it risks breaking
people's scripts that relied on the incorrect behaviour of running the
hook before the update is done, which is slightly worrysome. Find out who
are knowledgeable in the area of the code you are touching, and Cc them to
ask their input. "git shortlog -s -n git-cvsserver.perl" may help.
Please sign your patch.
Thanks.
Oh, and one more thing. Please do not top post.
> On Fri, Jan 16, 2009 at 2:22 PM, Stefan Karpinski
> <stefan.karpinski@gmail.com> wrote:
>>
>> CVS server was running the hook before the update
>> action was actually done. This performs the update
>> before the hook is called.
>> ---
>>
>> Unless I'm severely misunderstanding the meaning of
>> a *post-update* hook, I think this is a no-brainer.
>>
>> git-cvsserver.perl | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
>> index c1e09ea..d2e6003 100755
>> --- a/git-cvsserver.perl
>> +++ b/git-cvsserver.perl
>> @@ -1413,14 +1413,14 @@ sub req_ci
>> close $pipe || die "bad pipe: $! $?";
>> }
>>
>> + $updater->update();
>> +
>> ### Then hooks/post-update
>> $hook = $ENV{GIT_DIR}.'hooks/post-update';
>> if (-x $hook) {
>> system($hook, "refs/heads/$state->{module}");
>> }
>>
>> - $updater->update();
>> -
>> # foreach file specified on the command line ...
>> foreach my $filename ( @committedfiles )
>> {
>> --
>> 1.6.0.3.3.g08dd8
>>
> --
> 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
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Christian MICHON @ 2009-01-23 8:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <alpine.DEB.1.00.0901230119490.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 1:21 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 22 Jan 2009, Christian MICHON wrote:
>
>> I've a big set of patches in a mbox file: there's sufficient info inside
>> for git-am to work.
>>
>> Yet, each time I do import these, my sha1sums are changing because of
>> different commit dates.
>>
>> I'd like to force the commit date to match the info/date from the time I
>> received the email (and therefore always get back the right sha1sums).
>>
>> is this possible ?
>
> Have you tried setting GIT_COMMITTER_DATE to the given date?
yes, I did. This is what I want to change: I can fix the same
GIT_COMMITTER_DATE for all patches in the mbox, but I really want +
GIT_COMMITTER_DATE=GIT_AUTHOR_DATE
>
> Alternatively, you can always use a commit-message filter with
> filter-branch to fix it up.
>
> Ciao,
> Dscho
>
I'm curious if this could be done: the problem I quickly faced was
that this approach would double the amount of commits.
So I'm eager to test Junio's patch :)
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Christian MICHON @ 2009-01-23 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vljt26fp9.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 1:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian MICHON <christian.michon@gmail.com> writes:
>
>> I'd like to force the commit date to match the info/date from the time
>> I received the email (and therefore always get back the right
>> sha1sums).
>>
>> is this possible ?
>
> "am" being a tool to accept patches written in some past to faithfully
> record both author timestamp and committer timestamp, what you seem to
> want is outside of the current scope of the tool.
>
> A patch to butcher "git-am" to copy GIT_COMMITTER_DATE from
> GIT_AUTHOR_DATE and export it should be trivial to implement, though.
>
> Perhaps something like this totally untested patch.
>
I love this idea. I'll try to test it asap. Thanks!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [PATCH] Change octal literals to be XEmacs friendly
From: Junio C Hamano @ 2009-01-23 8:09 UTC (permalink / raw)
To: malc, Vassili Karpov; +Cc: git, Alexandre Julliard
In-Reply-To: <871vuwbnio.fsf@linmac.oyster.ru>
malc@pulsesoft.com writes:
> case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
> (probably because some internal type of ?\001 is char)
And I presume the new way to spell is compatible with non XEmacs emacs?
It may be obvious to you, but please spell it out. Parenthesized
"probably" does not help building the confidence in the patch either.
> Signed-off-by: Vassili Karpov <av1474@comtv.ru>
How are the (nameless) author of the patch malc@pulsesoft.com and Vassili
Karpov, the person who signed off, related?
Next time, please spend a few minutes to see if there are active
developers who are familiar in the area you are touching, and Cc your
patch to ask their input.
git blame -L562,+29 contrib/emacs/git.el
tells me that most of this came from 40f162b (git.el: Display file types
and type changes., 2008-01-06) by Alexandre, so I am Cc'ing him.
> ---
> contrib/emacs/git.el | 30 +++++++++++++++---------------
> 1 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 09e8bae..715580a 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -562,29 +562,29 @@ the process output as a string, or nil if the git command failed."
> (let* ((old-type (lsh (or old-perm 0) -9))
> (new-type (lsh (or new-perm 0) -9))
> (str (case new-type
> - (?\100 ;; file
> + (#o100 ;; file
> (case old-type
> - (?\100 nil)
> - (?\120 " (type change symlink -> file)")
> - (?\160 " (type change subproject -> file)")))
> - (?\120 ;; symlink
> + (#o100 nil)
> + (#o120 " (type change symlink -> file)")
> + (#o160 " (type change subproject -> file)")))
> + (#o120 ;; symlink
> (case old-type
> - (?\100 " (type change file -> symlink)")
> - (?\160 " (type change subproject -> symlink)")
> + (#o100 " (type change file -> symlink)")
> + (#o160 " (type change subproject -> symlink)")
> (t " (symlink)")))
> - (?\160 ;; subproject
> + (#o160 ;; subproject
> (case old-type
> - (?\100 " (type change file -> subproject)")
> - (?\120 " (type change symlink -> subproject)")
> + (#o100 " (type change file -> subproject)")
> + (#o120 " (type change symlink -> subproject)")
> (t " (subproject)")))
> - (?\110 nil) ;; directory (internal, not a real git state)
> - (?\000 ;; deleted or unknown
> + (#o110 nil) ;; directory (internal, not a real git state)
> + (#o000 ;; deleted or unknown
> (case old-type
> - (?\120 " (symlink)")
> - (?\160 " (subproject)")))
> + (#o120 " (symlink)")
> + (#o160 " (subproject)")))
> (t (format " (unknown type %o)" new-type)))))
> (cond (str (propertize str 'face 'git-status-face))
> - ((eq new-type ?\110) "/")
> + ((eq new-type #o110) "/")
> (t ""))))
>
> (defun git-rename-as-string (info)
>
> --
> mailto:av1474@comtv.ru
>
> --
> 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
^ permalink raw reply
* Re: [PATCH] git mergetool: Don't repeat merge tool candidates
From: Junio C Hamano @ 2009-01-23 8:16 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git, Theodore Ts'o
In-Reply-To: <1232569442-12480-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> git mergetool listed some candidates for mergetools twice, depending on
> the environment.
>
> Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
> ---
> git-mergetool.sh | 13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..8f09e4a 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -390,21 +390,18 @@ fi
>
> if test -z "$merge_tool" ; then
> if test -n "$DISPLAY"; then
> - merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
> - merge_tool_candidates="meld $merge_tool_candidates"
> - fi
> - if test "$KDE_FULL_SESSION" = "true"; then
> - merge_tool_candidates="kdiff3 $merge_tool_candidates"
> + merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
> + else
> + merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> fi
> fi
> if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
> - merge_tool_candidates="$merge_tool_candidates emerge"
> + merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
> fi
> if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
> - merge_tool_candidates="$merge_tool_candidates vimdiff"
> + merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
> fi
> - merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
> echo "merge tool candidates: $merge_tool_candidates"
> for i in $merge_tool_candidates; do
> init_merge_tool_path $i
Doesn't this change the order of the tools listed in the variable,
affecting which one ends up being used? I think that is a worse
regression than repeating the same name twice in an otherwise no-op
informational message.
Please spend a few minutes to see if there are active developers who are
familiar with the area of code you are touching and Cc them to ask their
input.
git blame -L390,+20 git-mergetool.sh
tells me that most of this came from 301ac38 (git-mergetool: Make default
selection of merge-tool more intelligent, 2007-06-10), so I am Cc'ing Ted.
^ 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