* 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
* [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: 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 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
* [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
* 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
* 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: [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
* [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
* [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 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 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 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
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Michael Haggerty @ 2009-01-23 4:14 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git, cvs2svn users
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6921@emailmn.mqsoftware.com>
Kelly F. Hickel wrote:
> I found the section in question, it is:
> -- snip --
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> This commit was manufactured by cvs2svn to create tag
> 'T_BU_Problem_9xxx_Merge_3-21-2000'.
> merge :1000007126
> M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
> -- snap --
>
> By my count, 88 is the ending single quote character, leaving the '.' to
> be interpreted as a command.
>
> Looks like I should go post this on the cvs2svn list.....
Yes, that would be helpful. Please include enough information and data
to enable me to reproduce your problem, because it is very mysterious.
The lines in question are (in Python)
self.f.write('data %d\n' % (len(log_msg),))
self.f.write('%s\n' % (log_msg,))
where self.f is a file that was opened in binary mode, and log_msg is an
8-bit or unicode string. Since the log message is being output to a
binary file, f.write() should squeal if the string includes any
non-ascii characters (I just verified this with Python 2.2, 2.4, and
2.5). Nevertheless, I suspect that your problem is caused by some kind
of character encoding problem, perhaps dependent on platform or Python
version.
You might also try the trunk version of cvs2svn; there have been a lot
of changes to cvs2git since release 2.1.1--even a new command that is
actually called cvs2git! (though for now you still need to use an
options file to start conversions).
Michael
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=1044191
To unsubscribe from this discussion, e-mail: [users-unsubscribe@cvs2svn.tigris.org].
^ permalink raw reply
* Re: does git config get any side effect other than changing .gitconfig
From: bill lam @ 2009-01-23 3:41 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: bill lam, git
In-Reply-To: <200901222126.46964.bss@iguanasuicide.net>
On Thu, 22 Jan 2009, Boyd Stephen Smith Jr. wrote:
> >Suppose I got several git repositories to maintain, instead of using
> >command git config [--global] again and again. Can I call up a text
> >editor to edit .git/config or .gitconfig manually, or just copy from
> >another .gitconfig ?
>
> Yes. Absolutely.
Thanks for confirmation. I realised that the subject is in the
opposite tone to the message body.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩157 李商隱 風雨
淒涼寶劍篇 羈泊欲窮年 黃葉仍風雨 青樓自管絃
新知遭薄俗 舊好隔良緣 心斷新豐酒 銷愁斗幾千
^ permalink raw reply
* Re: does git config get any side effect other than changing .gitconfig
From: Boyd Stephen Smith Jr. @ 2009-01-23 3:26 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090123031210.GB6931@b2j>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Thursday 22 January 2009, bill lam <cbill.lam@gmail.com> wrote
about 'does git config get any side effect other than
changing .gitconfig':
>Suppose I got several git repositories to maintain, instead of using
>command git config [--global] again and again. Can I call up a text
>editor to edit .git/config or .gitconfig manually, or just copy from
>another .gitconfig ?
Yes. Absolutely.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-23 3:20 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0901221847u6b8aeadcl580a091751de3d26@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Sverre Rabbelier wrote:
> On Fri, Jan 23, 2009 at 03:42, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > HTTP being 2nd class citizen anyway (and we can always fix it after
> > Mike's cleanups), I'd say this patch is ready to roll.
>
> Aside from that, am I correct in asserting that in the "worst case"
> scenario the repo is cloned instead of erroring out, and a simple "git
> fetch" would fix the issue?
Probably. Note, however, that scripts might rely on a fail if there were
problems.
But then, scripts have no business cloning repositories (fetching, yes.
But cloning?)
Ciao,
Dscho
^ permalink raw reply
* does git config get any side effect other than changing .gitconfig
From: bill lam @ 2009-01-23 3:12 UTC (permalink / raw)
To: git
Suppose I got several git repositories to maintain, instead of using
command git config [--global] again and again. Can I call up a text
editor to edit .git/config or .gitconfig manually, or just copy from
another .gitconfig ?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩096 宋之問 題大庾嶺北驛
陽月南飛雁 傳聞至此回 我行殊未已 何日復歸來
江靜潮初落 林昏瘴不開 明朝望鄉處 應見隴頭梅
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Asheesh Laroia @ 2009-01-23 2:55 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Sixt, Nathan Yergler, Michael J Gruber, git
In-Reply-To: <20090123094509.6117@nanako3.lavabit.com>
On Fri, 23 Jan 2009, Nanako Shiraishi wrote:
> Your explanation is a good answer to Nathan's misunderstanding; "git add
> path && git commit" and "git commit path" are different.
>
> But Nathan's first sentence is a different matter.
Thanks for seeing this!
> 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.
During a merge where the file called "file" is in conflict, I don't see
why the internal mechanism of how a merge gets resolved is important to
users like Nathan.
Sure, the index is nice, but let's look at the choices here. When he runs
$ git commit file -m 'fixed conflict'
git can do one of two things:
(a) Fail with an obscure (or less obscure) error message, or
(b) Succeed.
The way in which it can suceed is unambiguous. Now, in the case of more
than one file being in conflict, it makes sense to abort; success isn't
possible. But in this case, no one really benefits from the user having to
type something else to have the command actually succeed.
Those are my thoughts.
> The answer of course can be "because it changes the behavior people are
> very much used to."
I don't think anyone is "very much used to" this error message, or that
making something succeed in the only possible way is going to confuse
anyone. If you're worried about confusing people, git could print a note
like:
$ git commit file -m "Fixed conflict"
NOTE: Merge was in progress. If you have more than one file in conflict
in a future merge, be sure to "git add" each file separately and then
commit them all at once.
Created commit 12ede36: Fixed conflict
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
$
-- Asheesh.
--
In the Spring, I have counted 136 different kinds of weather inside of
24 hours.
-- Mark Twain, on New England weather
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 2:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230333060.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 03:42, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> HTTP transport, however, would not die() on connection errors, from my
> cursory look.
Heh, this is why I asked you, my cursory look told me "no clue" instead.
> HTTP being 2nd class citizen anyway (and we can always fix it after Mike's
> cleanups), I'd say this patch is ready to roll.
Aside from that, am I correct in asserting that in the "worst case"
scenario the repo is cloned instead of erroring out, and a simple "git
fetch" would fix the issue?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-23 2:42 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0901221746h258f548etf857ab37399133da@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Sverre Rabbelier wrote:
> On Fri, Jan 23, 2009 at 02:24, Junio C Hamano <gitster@pobox.com> wrote:
> > I think the basic idea is Ok, but is it a reliable check at this point to
> > see if (refs == NULL) to tell if the target repository is an empty one?
>
> This is the question I asked Dscho, and he said/guessed that it was.
>
> > I am mostly worried about a failure case (connected but couldn't get
> > the refs, or perhaps connection failed to start). If you get a NULL
> > in such a case you may end up saying "oh you cloned a void" when you
> > should say "nah, such a remote repository does not exist".
>
> Yes, this was my concern as well.
>From what I can see in get_remote_heads(), the native protocols would
die(), as would rsync().
HTTP transport, however, would not die() on connection errors, from my
cursory look.
That might be skewed, though, as I am on top of Mike's patches (in the
hopefully not so futile hope that Mike -- after letting me wait for over
one year -- finishes his work.
HTTP being 2nd class citizen anyway (and we can always fix it after Mike's
cleanups), I'd say this patch is ready to roll.
Ciao,
Dscho
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Stephen Bannasch @ 2009-01-23 1:56 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
In-Reply-To: <p0624085fc592d385c7fb@[192.168.1.114]>
At 6:27 PM -0500 1/13/09, Stephen Bannasch wrote:
>At 10:37 PM +0100 1/13/09, Robin Rosenberg wrote:
>> > To hack around Eclipse's problem with projects in nested directories
>>> I clone a repo and then create a new top-level dir that just has
>>> symbolic links to all the project directories.
>>>
>>> However when I Team/Share with git using egit the resources become
>>> untracked when displayed in Eclipse -- they still are tracked however
>>> when I check from the command line.
>>
>>I've seen this too, but so far not got myself to actually fix it. I
>>think it has do with
>>that we ask eclipse project for it's path end there we gets off track. Thanks
>>for providing a good example that help "someone" to fix it.
>>
>>Could you add an issue at http://code.google.com/p/egit/issues/list and maybe
>>include a tar ball with a simple project displaying this
>>behaviour? (with a note
>>that the symlinks makes this impossible to recreate on Windows).
>
>Done: http://code.google.com/p/egit/issues/detail?id=52
>
>Fxing this will make using Eclipse and Git together SO much nicer!
Robin and Shawn,
Can you suggest where in the egit code I should look to see if I can fix this?
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Sverre Rabbelier @ 2009-01-23 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vwscm4xx0.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 02:24, Junio C Hamano <gitster@pobox.com> wrote:
> I think the basic idea is Ok, but is it a reliable check at this point to
> see if (refs == NULL) to tell if the target repository is an empty one?
This is the question I asked Dscho, and he said/guessed that it was.
> I am mostly worried about a failure case (connected but couldn't get the
> refs, or perhaps connection failed to start). If you get a NULL in such a
> case you may end up saying "oh you cloned a void" when you should say
> "nah, such a remote repository does not exist".
Yes, this was my concern as well.
> If transport_get_remote_refs() dies without returning NULL, that would be
> sufficient, but I didn't check.
It does, transport_get_remote_refs() calls fetch_pack, which dies when
'refs' (the fourth argument) is NULL:
static int fetch_refs_via_pack(...) {
// setup code snipped
if (!data->conn) {
connect_setup(transport);
get_remote_heads(data->fd[0], &refs_tmp, 0, NULL, 0, NULL);
}
refs = fetch_pack(&args, data->fd, data->conn,
refs_tmp ? refs_tmp : transport->remote_refs,
dest, nr_heads, heads, &transport->pack_lockfile);
So unless get_remote_heads messes with it, it will remain NULL. Now I
must admit that I'm not familiar enough with get_remote_heads to know
if this could cause a false positive, Dscho?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [kha/safe PATCH] completion bugfix: Place double pipes in front of alternate command.
From: Karl Hasselström @ 2009-01-23 1:35 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, catalin.marinas
In-Reply-To: <1232670372-20000-1-git-send-email-ted@tedpavlic.com>
On 2009-01-22 19:26:12 -0500, Ted Pavlic wrote:
> - 'complete -o default -F _stg stg' ] ]
> + '|| complete -o default -F _stg stg' ] ]
Thanks, I've edited the patch and pushed it out again.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Junio C Hamano @ 2009-01-23 1:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <1232669252-21881-1-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> diff --git a/builtin-clone.c b/builtin-clone.c
> index f7e5a7b..d5bba0e 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -522,14 +522,23 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> option_upload_pack);
>
> refs = transport_get_remote_refs(transport);
> - transport_fetch_refs(transport, refs);
> + if(refs)
> + transport_fetch_refs(transport, refs);
Thanks.
I think the basic idea is Ok, but is it a reliable check at this point to
see if (refs == NULL) to tell if the target repository is an empty one?
I am mostly worried about a failure case (connected but couldn't get the
refs, or perhaps connection failed to start). If you get a NULL in such a
case you may end up saying "oh you cloned a void" when you should say
"nah, such a remote repository does not exist".
If transport_get_remote_refs() dies without returning NULL, that would be
sufficient, but I didn't check.
^ 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