* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 2:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, Johannes Schindelin, Jeff King, git,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <16b87432-2862-4be9-afea-5b672101af62@email.android.com>
On Thu, Nov 1, 2012 at 2:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>>And finally, what do more do you expect me to do? About the code, and
>>only the code.
>
> The analysis that does in the log messages is an important part of "code" in this project, so that may be a good place to start. Both Jonathan and J6t asked specific updates to your log message, no?
Regarding git-remote-hg? No. They haven't said anything about any of
those patches.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 2:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <c0f8d214-4d61-4b02-8bda-4f26c33ae30f@email.android.com>
On Thu, Nov 1, 2012 at 2:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>>Junio wanted a more general solution, adding infrastructure to the
>>rev-list engine that I did not need -- and did not see the need for,
>>either -- and given the amount of time I had invested in a working
>>remote-hg and given that I needed it desperately for my day-job
>>project, ...
>
> This is relatively long ago (and I am away from my machine, so I cannot check) so I may misremembering things, but my impression is that since that discussion, we added a minimal "infrastructure" to the rev-list (I think we caled it rev-list-cmdline or something like that) and Sverre used it to update fast-export.
>
> It may well be that what we have is still not sufficient to do everything you need, but it may be close enough to get extended for your original use case.
I don't think there's missing, the following patch works fine:
http://article.gmane.org/gmane.comp.version-control.git/208730
There's a minute issue, but I think that would require changes in
fast-export itself and its marks, not rev-list. But nobody would care
anyway, it's not a problem.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 2:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, git,
Michael J Gruber, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow
In-Reply-To: <bec4d263-b458-4636-9fa6-1c1202416810@email.android.com>
On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>>On Wed, 31 Oct 2012, Felipe Contreras wrote:
>>
>>> It doesn't get any more obvious than that. But to each his own.
>>
>>In my opinion, Jonathan does not deserve any of such condescending
>>words.
>>But maybe the Git maintainers are okay with such a tone on this list?
>
> Agreed, and no.
>
> We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one.
Just for the record, what exactly is the problem with the above?
1) The fact that I say it's obvious
2) The fact that I say everyone is entitled to their own opinions
I don't think I said anything else.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 4:08 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s0KFJW2F3gbO_Xd9QKrZ1OoxvUCvecU084-zH2UDqXKag@mail.gmail.com>
On Wed, Oct 31, 2012 at 8:47 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, Oct 31, 2012 at 7:04 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>> How about performance?
>
>> 174.038642915 seconds time elapsed
>>
>> Compared to;
>
>> 340.976843750 seconds time elapsed
>>
>> Looks like there's something to improve in this area, but I wouldn't
>> be surprised if the reason for the better performance is that
>> something is not being done. I'll investigate.
>
> Turns out msysgit's remote-hg is not exporting the whole repository,
> that's why it's faster =/
It seems the reason is that it would only export to the point where
the branch is checked out. After updating the to the tip I noticed
there was a performance difference.
I investigated and found two reasons:
1) msysgit's version doesn't export files twice, I've now implemented the same
2) msysgit's version uses a very simple algorithm to find out file changes
This second point causes msysgit to miss some file changes. Using the
same algorithm I get the same performance, but the output is not
correct.
Here's after the latest updates:
Performance counter stats for 'git clone hg::~/dev/hg-clean hg-clean-5':
288338.286545 task-clock # 1.299 CPUs utilized
46,441 context-switches # 0.161 K/sec
6,098 CPU-migrations # 0.021 K/sec
509,600 page-faults # 0.002 M/sec
518,370,729,897 cycles # 1.798 GHz
204,476,102,906 stalled-cycles-frontend # 39.45% frontend cycles idle
<not supported> stalled-cycles-backend
726,005,034,102 instructions # 1.40 insns per cycle
# 0.28 stalled cycles per insn
127,662,400,651 branches # 442.752 M/sec
6,758,976,722 branch-misses # 5.29% of all branches
222.020233009 seconds time elapsed
Which is taking roughly 60% more time than msysgit, but the output is
actually correct.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 00/14] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 6:05 UTC (permalink / raw)
To: Chris Webb
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <20121030180021.GX26850@arachsys.com>
On Tue, Oct 30, 2012 at 7:00 PM, Chris Webb <chris@arachsys.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Yes, it seems this is an API issue; repo.branchtip doesn't exist in
>> python 2.2.
>
> Hi. Presumably this is a problem with old mercurial not a problem with old
> python as mentioned in the commit?
Yeah, mercurial.
>> Both issues should be fixed now :)
>
> They are indeed, and it now works nicely on all the repos I've tested it
> with, including http://selenic.com/hg: very impressive!
>
> I wonder whether it's worth ignoring heads with bookmarks pointing to them
> when it comes to considering heads of branches, or at least allowing the
> hg branch tracking to be easily disabled?
>
> A common idiom when working with hg bookmarks is to completely ignore the
> (not very useful) hg branches (i.e. all commits are on the default hg
> branch) and have a bookmark for each line of development used exactly as a
> git branch would be.
>
> On such a repository, at the moment you will always get a warning about
> multiple heads on branches/default, even though you actually don't care
> about branches/default (and would prefer it not to exist) and just want the
> branches coming from the bookmarks.
>
> I've also seen repositories with no hg branches, but with a single
> unbookmarked tip and bookmarks on some other heads to mark non-mainline
> development. It would be nice for branches/default to track the unbookmarked
> tip in this case, without warning about the other, bookmarked heads.
Implemented now. I'm not handling the 'tip' revision, but most likely
it's also the '.' revision. In this case a fake 'master' bookmark will
be created to track that revision.
> Finally, on a simple repo with no branches and where there's no clash with a
> bookmark called master, I'd love to be able to a get a more idiomatic
> origin/master rather than origin/branches/default.
Yeah, you can get that now. If there are no branches or bookmarks,
'master' will point to '.'.
As for your preference of not tracking branches, there's a new option:
% git config --global remote-hg.track-branches false
So you don't have to use hg-git-compat mode :)
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: pre-receive hook output invalid characters
From: mnaoumov @ 2012-11-01 0:54 UTC (permalink / raw)
To: msysgit; +Cc: GIT Mailing-list, Michael Naumov, kusmabite
In-Reply-To: <CABPQNSb0pWAwwrZ5LvOY2agdEa+MXPMvg+kFa1vODhXf6efAZw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]
Your suggestion seems to be logical for me :)
On Thursday, November 1, 2012 3:32:26 AM UTC+11, Erik Faye-Lund wrote:
>
> Sorry for resending, but the previous version got dropped from the
> main git mailing list due to a HTML-subpart. Converted to plain-text.
>
> On Wed, Oct 31, 2012 at 4:45 PM, Erik Faye-Lund <kusm...@gmail.com<javascript:>>
> wrote:
> >
> > On Wed, Oct 31, 2012 at 4:24 PM, <mnao...@gmail.com <javascript:>>
> wrote:
> >>
> >> If you add pre-receive hook in your git repository with the following
> >> content
> >>
> >> #!/bin/sh
> >>
> >> echo Message
> >> exit 1
> >>
> >> And then try to push you will get the following
> >>
> >> The bug is about these strange 3 last characters.
> >>
> >> Recently I raised a bug for GitExtensions but it seems to be msysgit
> >> issue as I could reproduce it from PowerShell as well
> >>
> >> https://github.com/gitextensions/gitextensions/issues/1313
>
>
>
> >
> > What you're seeing is most likely a CR (a carriage return character).
> > Windows has CRLF new-lines, and Unix uses only LF.
> >
> > My guess is that echo produces CRLF, and this gets carried through and
> > incorrecly displayed.
>
>
> OK, I can reproduce it in Git Bash now, and by doing "git push 2>&1 | od
> -c"
> I can see that I'm getting "Message\033[K\n".
>
> This looks a little bit puzzling, but the sequence matches ANSI_SUFFIX in
> sideband.c. So it seems this is intentional. This dates back to ebe8fa73.
>
> I wonder, shouldn't we check isatty also before assuming ANSI-sequences?
>
> ---8<---
> diff --git a/sideband.c b/sideband.c
> index d5ffa1c..bd3e5a8 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -29,7 +29,7 @@ int recv_sideband(const char *me, int in_stream, int
> out)
>
> memcpy(buf, PREFIX, pf);
> term = getenv("TERM");
> - if (term && strcmp(term, "dumb"))
> + if (isatty(out) && term && strcmp(term, "dumb"))
> suffix = ANSI_SUFFIX;
> else
> suffix = DUMB_SUFFIX;
> ---8<---
>
> Thoughts?
>
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
[-- Attachment #2: Type: text/html, Size: 3538 bytes --]
^ permalink raw reply
* Re: [OT] How to get the discussion details via notes
From: Peter Baumann @ 2012-11-01 7:49 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Jonathan Nieder, git
In-Reply-To: <20121031141024.GB24291@sigill.intra.peff.net>
On Wed, Oct 31, 2012 at 10:10:24AM -0400, Jeff King wrote:
> On Wed, Oct 31, 2012 at 10:53:27AM +0100, Peter Baumann wrote:
>
> > > covers the basics (current behavior and intent of the change) in its
> > > first two paragraphs and anyone wanting more detail can use
> > >
> > > GIT_NOTES_REF=refs/remotes/charon/notes/full \
> > > git show --show-notes <commit>
> > >
> > > to find more details.
> >
> > I seem to miss something here, but I don't get it how the notes ref
> > becomes magically filled with the details of this discussion.
>
> Thomas Rast (aka charon) keeps a mapping of commits to the email threads
> that led to them. You can fetch it from:
>
> git://repo.or.cz/git/trast.git
>
> (try the notes/full and notes/terse refs).
>
Nice! I didn't know about that.
-Peter
^ permalink raw reply
* [PATCH v2 0/3] Introduce diff.submodule
From: Ramkumar Ramachandra @ 2012-11-01 10:43 UTC (permalink / raw)
To: Git List; +Cc: Jens Lehmann
Hi,
v1 is here:
http://mid.gmane.org/1349196670-2844-1-git-send-email-artagnon@gmail.com
I've fixed the issues pointed out in the review by Jens.
Sorry about the delay; need to find a new dayjob.
Ramkumar Ramachandra (3):
Documentation: move diff.wordRegex from config.txt to diff-config.txt
diff: introduce diff.submodule configuration variable
submodule: display summary header in bold
Documentation/config.txt | 6 ------
Documentation/diff-config.txt | 13 +++++++++++++
Documentation/diff-options.txt | 3 ++-
builtin/diff.c | 4 ++++
cache.h | 1 +
diff.c | 7 ++++++-
submodule.c | 8 ++++----
submodule.h | 2 +-
t/t4041-diff-submodule-option.sh | 30 +++++++++++++++++++++++++++++-
9 files changed, 60 insertions(+), 14 deletions(-)
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply
* [PATCH 1/3] Documentation: move diff.wordRegex from config.txt to diff-config.txt
From: Ramkumar Ramachandra @ 2012-11-01 10:43 UTC (permalink / raw)
To: Git List; +Cc: Jens Lehmann
In-Reply-To: <1351766630-4837-1-git-send-email-artagnon@gmail.com>
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/config.txt | 6 ------
Documentation/diff-config.txt | 6 ++++++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 11f320b..d1de857 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -962,12 +962,6 @@ difftool.<tool>.cmd::
difftool.prompt::
Prompt before each invocation of the diff tool.
-diff.wordRegex::
- A POSIX Extended Regular Expression used to determine what is a "word"
- when performing word-by-word difference calculations. Character
- sequences that match the regular expression are "words", all other
- characters are *ignorable* whitespace.
-
fetch.recurseSubmodules::
This option can be either set to a boolean value or to 'on-demand'.
Setting it to a boolean changes the behavior of fetch and pull to
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 75ab8a5..decd370 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -107,6 +107,12 @@ diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.wordRegex::
+ A POSIX Extended Regular Expression used to determine what is a "word"
+ when performing word-by-word difference calculations. Character
+ sequences that match the regular expression are "words", all other
+ characters are *ignorable* whitespace.
+
diff.<driver>.command::
The custom diff driver command. See linkgit:gitattributes[5]
for details.
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* [PATCH 2/3] diff: introduce diff.submodule configuration variable
From: Ramkumar Ramachandra @ 2012-11-01 10:43 UTC (permalink / raw)
To: Git List; +Cc: Jens Lehmann
In-Reply-To: <1351766630-4837-1-git-send-email-artagnon@gmail.com>
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/diff-config.txt | 7 +++++++
Documentation/diff-options.txt | 3 ++-
builtin/diff.c | 4 ++++
cache.h | 1 +
diff.c | 5 +++++
t/t4041-diff-submodule-option.sh | 30 +++++++++++++++++++++++++++++-
6 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index decd370..89dd634 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -107,6 +107,13 @@ diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.submodule::
+ Specify the format in which differences in submodules are
+ shown. The "log" format lists the commits in the range like
+ linkgit:git-submodule[1] `summary` does. The "short" format
+ format just shows the names of the commits at the beginning
+ and end of the range. Defaults to short.
+
diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index cf4b216..f4f7e25 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -170,7 +170,8 @@ any of those replacements occurred.
the commits in the range like linkgit:git-submodule[1] `summary` does.
Omitting the `--submodule` option or specifying `--submodule=short`,
uses the 'short' format. This format just shows the names of the commits
- at the beginning and end of the range.
+ at the beginning and end of the range. Can be tweaked via the
+ `diff.submodule` configuration variable.
--color[=<when>]::
Show colored diff.
diff --git a/builtin/diff.c b/builtin/diff.c
index 9650be2..6d00311 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -297,6 +297,10 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
+ /* Set SUBMODULE_LOG if diff.submodule config var was set */
+ if (submodule_format_cfg && !strcmp(submodule_format_cfg, "log"))
+ DIFF_OPT_SET(&rev.diffopt, SUBMODULE_LOG);
+
if (nongit)
die(_("Not a git repository"));
argc = setup_revisions(argc, argv, &rev, NULL);
diff --git a/cache.h b/cache.h
index a58df84..5fc7ba3 100644
--- a/cache.h
+++ b/cache.h
@@ -1220,6 +1220,7 @@ int add_files_to_cache(const char *prefix, const char **pathspec, int flags);
/* diff.c */
extern int diff_auto_refresh_index;
+extern const char *submodule_format_cfg;
/* match-trees.c */
void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
diff --git a/diff.c b/diff.c
index 86e5f2a..835eb26 100644
--- a/diff.c
+++ b/diff.c
@@ -29,6 +29,7 @@ static int diff_use_color_default = -1;
static int diff_context_default = 3;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
+const char *submodule_format_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
static int diff_no_prefix;
@@ -168,6 +169,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
diff_stat_graph_width = git_config_int(var, value);
return 0;
}
+ if (!strcmp(var, "diff.submodule"))
+ return git_config_string(&submodule_format_cfg, var, value);
if (!strcmp(var, "diff.external"))
return git_config_string(&external_diff_cmd_cfg, var, value);
if (!strcmp(var, "diff.wordregex"))
@@ -3656,6 +3659,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (!prefixcmp(arg, "--submodule=")) {
if (!strcmp(arg + 12, "log"))
DIFF_OPT_SET(options, SUBMODULE_LOG);
+ if (!strcmp(arg + 12, "short"))
+ DIFF_OPT_CLR(options, SUBMODULE_LOG);
}
/* misc options */
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 6c01d0c..e401814 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -33,6 +33,7 @@ test_create_repo sm1 &&
add_file . foo >/dev/null
head1=$(add_file sm1 foo1 foo2)
+fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
test_expect_success 'added submodule' "
git add sm1 &&
@@ -43,6 +44,34 @@ EOF
test_cmp expected actual
"
+test_expect_success 'added submodule, set diff.submodule' "
+ git config diff.submodule log &&
+ git add sm1 &&
+ git diff --cached >actual &&
+ cat >expected <<-EOF &&
+Submodule sm1 0000000...$head1 (new submodule)
+EOF
+ git config --unset diff.submodule &&
+ test_cmp expected actual
+"
+
+test_expect_success '--submodule=short overrides diff.submodule' "
+ git config diff.submodule log &&
+ git add sm1 &&
+ git diff --submodule=short --cached >actual &&
+ cat >expected <<-EOF &&
+diff --git a/sm1 b/sm1
+new file mode 160000
+index 0000000..a2c4dab
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++Subproject commit $fullhead1
+EOF
+ git config --unset diff.submodule &&
+ test_cmp expected actual
+"
+
commit_file sm1 &&
head2=$(add_file sm1 foo3)
@@ -73,7 +102,6 @@ EOF
test_cmp expected actual
"
-fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
test_expect_success 'modified submodule(forward) --submodule=short' "
git diff --submodule=short >actual &&
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* [PATCH 3/3] submodule: display summary header in bold
From: Ramkumar Ramachandra @ 2012-11-01 10:43 UTC (permalink / raw)
To: Git List; +Cc: Jens Lehmann
In-Reply-To: <1351766630-4837-1-git-send-email-artagnon@gmail.com>
Currently, 'git diff --submodule' displays output with a bold diff
header for non-submodules. So this part is in bold:
diff --git a/file1 b/file1
index 30b2f6c..2638038 100644
--- a/file1
+++ b/file1
For submodules, the header looks like this:
Submodule submodule1 012b072..248d0fd:
Unfortunately, it's easy to miss in the output because it's not bold.
Change this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
diff.c | 2 +-
submodule.c | 8 ++++----
submodule.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index 835eb26..115f384 100644
--- a/diff.c
+++ b/diff.c
@@ -2244,7 +2244,7 @@ static void builtin_diff(const char *name_a,
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
show_submodule_summary(o->file, one ? one->path : two->path,
one->sha1, two->sha1, two->dirty_submodule,
- del, add, reset);
+ set, del, add, reset);
return;
}
diff --git a/submodule.c b/submodule.c
index e3e0b45..c10182e 100644
--- a/submodule.c
+++ b/submodule.c
@@ -258,7 +258,7 @@ int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg)
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
- unsigned dirty_submodule,
+ unsigned dirty_submodule, const char *set,
const char *del, const char *add, const char *reset)
{
struct rev_info rev;
@@ -292,15 +292,15 @@ void show_submodule_summary(FILE *f, const char *path,
return;
}
- strbuf_addf(&sb, "Submodule %s %s..", path,
+ strbuf_addf(&sb, "%sSubmodule %s %s..", set, path,
find_unique_abbrev(one, DEFAULT_ABBREV));
if (!fast_backward && !fast_forward)
strbuf_addch(&sb, '.');
strbuf_addf(&sb, "%s", find_unique_abbrev(two, DEFAULT_ABBREV));
if (message)
- strbuf_addf(&sb, " %s\n", message);
+ strbuf_addf(&sb, " %s%s\n", message, reset);
else
- strbuf_addf(&sb, "%s:\n", fast_backward ? " (rewind)" : "");
+ strbuf_addf(&sb, "%s:%s\n", fast_backward ? " (rewind)" : "", reset);
fwrite(sb.buf, sb.len, 1, f);
if (!message) {
diff --git a/submodule.h b/submodule.h
index f2e8271..997fd06 100644
--- a/submodule.h
+++ b/submodule.h
@@ -20,7 +20,7 @@ void handle_ignore_submodules_arg(struct diff_options *diffopt, const char *);
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
- unsigned dirty_submodule,
+ unsigned dirty_submodule, const char *set,
const char *del, const char *add, const char *reset);
void set_config_fetch_recurse_submodules(int value);
void check_for_new_submodule_commits(unsigned char new_sha1[20]);
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* Re: [git-users] Git clone fails with "bad pack header", how to get remote log
From: Jeff King @ 2012-11-01 11:15 UTC (permalink / raw)
To: kevin molcard; +Cc: Konstantin Khomoutov, git
In-Reply-To: <509136EE.6040705@gmail.com>
On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
> I forgot to mention that I am using scm manager:
> https://bitbucket.org/sdorra/scm-manager/wiki/Home
>
> So that maybe the " custom layer you are talking about.
Yeah, that is very important. If I am reading the scm-manager code right
(and I might not be, as I only just looked at it), it is built entirely
around JGit, and is not calling git-core programs at all. So it is
either an issue in scm-manager, or in JGit.
Your best bet is probably to report the issue to the scm-manager folks,
who can probably help you dig into the problem further (it may even have
more detailed logs of what happened, but I don't know).
-Peff
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: René Scharfe @ 2012-11-01 13:46 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Johannes Schindelin, Jonathan Nieder, Jeff King,
git, Michael J Gruber, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow
In-Reply-To: <CAMP44s2G2MGuPH-UXfoKNOpx0cuSE87Uz=6B-7H1MzJHf6VMjA@mail.gmail.com>
Am 01.11.2012 03:58, schrieb Felipe Contreras:
> On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>>> On Wed, 31 Oct 2012, Felipe Contreras wrote:
>>>
>>>> It doesn't get any more obvious than that. But to each his own.
>>>
>>> In my opinion, Jonathan does not deserve any of such condescending
>>> words.
>>> But maybe the Git maintainers are okay with such a tone on this list?
>>
>> Agreed, and no.
>>
>> We've been hoping we can do without a rigid code of conduct written down to maintain cordial community focused on technical merits, and instead relied on people's common sense, but sense may not be so common, unfortunately, so we may have to have one.
>
> Just for the record, what exactly is the problem with the above?
>
> 1) The fact that I say it's obvious
> 2) The fact that I say everyone is entitled to their own opinions
Obviousness is in the eye of the beholder. This is a fact that I tend
to forget just too easily as well.
You probably didn't intend it, but your sentences at the top can be read
more like: "This is a logical consequence. If you don't understand
that, your mental capabilities must be lacking.". That's obviously
(ha!) a rude thing to say.
Also, and I'm sure you didn't know that, "Jedem das Seine" (to each his
own) was the slogan of the Buchenwald concentration camp. For that
reason some (including me) hear the unspoken cynical half-sentence "and
some people just have to be sent to the gas chamber" when someone uses
this proverb.
No accusations intended, just trying to answer your question from my
point of view.
René
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Tomas Carnecky @ 2012-11-01 14:18 UTC (permalink / raw)
To: René Scharfe
Cc: Felipe Contreras, Junio C Hamano, Johannes Schindelin,
Jonathan Nieder, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <50927D29.3020703@lsrfire.ath.cx>
On Thu, Nov 1, 2012 at 1:46 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each his own)
> was the slogan of the Buchenwald concentration camp. For that reason some
> (including me) hear the unspoken cynical half-sentence "and some people just
> have to be sent to the gas chamber" when someone uses this proverb.
Godwin's Law. That went fast, just one day :)
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Martin Langhoff @ 2012-11-01 14:18 UTC (permalink / raw)
To: René Scharfe
Cc: Felipe Contreras, Junio C Hamano, Johannes Schindelin,
Jonathan Nieder, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <50927D29.3020703@lsrfire.ath.cx>
On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> You probably didn't intend it, but your sentences at the top can be read
> more like: "This is a logical consequence. If you don't understand that,
> your mental capabilities must be lacking.". That's obviously (ha!) a rude
> thing to say.
+1
> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each his own)
Ouch! I sure didn't know that. Thanks for that tidbit. Working with
people from all over the world always teaches me that I might be
saying the wrong thing... accidentally. And to be tolerant of others'
sayings.
{ To dispel any confusion, no, I am not German. I'm from a big
melting-pot of peoples :-) }
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 14:34 UTC (permalink / raw)
To: René Scharfe
Cc: Junio C Hamano, Johannes Schindelin, Jonathan Nieder, Jeff King,
git, Michael J Gruber, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow
In-Reply-To: <50927D29.3020703@lsrfire.ath.cx>
On Thu, Nov 1, 2012 at 2:46 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 01.11.2012 03:58, schrieb Felipe Contreras:
>
>> On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>
>>>> On Wed, 31 Oct 2012, Felipe Contreras wrote:
>>>>
>>>>> It doesn't get any more obvious than that. But to each his own.
>>>>
>>>>
>>>> In my opinion, Jonathan does not deserve any of such condescending
>>>> words.
>>>> But maybe the Git maintainers are okay with such a tone on this list?
>>>
>>>
>>> Agreed, and no.
>>>
>>> We've been hoping we can do without a rigid code of conduct written down
>>> to maintain cordial community focused on technical merits, and instead
>>> relied on people's common sense, but sense may not be so common,
>>> unfortunately, so we may have to have one.
>>
>>
>> Just for the record, what exactly is the problem with the above?
>>
>> 1) The fact that I say it's obvious
>> 2) The fact that I say everyone is entitled to their own opinions
>
>
> Obviousness is in the eye of the beholder.
Sometimes. Other times things are obviously obvious, not for the
person uttering the words, but for everyone. But I agree that others
would disagree, which is why I followed that sentence to one making
sure that I understand that there's a disagreement.
> This is a fact that I tend to forget just too easily as well.
I didn't.
And even if I did, what is the problem with saying "this is obvious"?
> You probably didn't intend it, but your sentences at the top can be read
> more like: "This is a logical consequence. If you don't understand that,
> your mental capabilities must be lacking.". That's obviously (ha!) a rude
> thing to say.
People can read things in many ways. If you need to pass every
sentence you write in a *technical* mailing list through a public
relation professional, well, the throughput of such mailing list is
going to suffer.
That being said, I did wonder what must be going through his mind to
not see that as obvious, but I did NOT *say* anything offensive.
Specially because I know people have different perspectives, and the
fact that a perspective doesn't allow you to see something obvious
doesn't say anything about your mental capabilities, only about your
perspectives, biases, or even current mental state. Who knows, maybe
you skipped your coffee.
To assume otherwise is reading too much into things. Read what is
being said, and nothing more. Don't make assumptions.
And a guideline I love from Wikipedia: Always assume *good faith*.
Sometimes, of course, even if you assume good faith things are
offensive. This is not the case here.
> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each his own)
> was the slogan of the Buchenwald concentration camp.
No, I don't know, and frankly, I don't care.
Cultural differences go both ways. You need to assume that whatever
cultural reference you are thinking of, might not be the same for the
other person. Again: assume *good faith*.
And in English, and probably most Latin language countries, "to each
his own" is pretty well understood:
http://en.wiktionary.org/wiki/to_each_his_own
Etymology
A calque of Latin suum cuique, short for suum cuique pulchrum est (“to
each his own is beautiful”).
Proverb
to each his own
Every person is entitled to his or her personal preferences and tastes.
I would never want my bathroom decorated in chartreuse and turquoise,
but to each his own, I suppose.
Synonyms
there's no accounting for taste
> For that reason some
> (including me) hear the unspoken cynical half-sentence "and some people just
> have to be sent to the gas chamber" when someone uses this proverb.
I never said anything of the sort, and assuming otherwise is a mistake.
If you always assume bad faith you will inevitably get offended by
things that were never meant to be offensive. It's not a good
guideline.
> No accusations intended, just trying to answer your question from my point
> of view.
Thanks, but I think if others are thinking along the same lines, this
is not good. Following the guideline of always assuming good faith
makes it easier for people to communicate, and people not getting hurt
when in fact no offense was intended, which it turns out to be most of
the time.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Martin Langhoff @ 2012-11-01 14:47 UTC (permalink / raw)
To: Felipe Contreras
Cc: René Scharfe, Junio C Hamano, Johannes Schindelin,
Jonathan Nieder, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s0TVQOKc=Ce_k1DTwZHuPUmroOaVMPg4t--bmt=3fDPuQ@mail.gmail.com>
Felipe,
I'll invite you to reread some of your words:
> That being said, I did wonder what must be going through his mind to
> not see that as obvious,
(...)
> Following the guideline of always assuming good faith
So perhaps it does apply that you could try to assume good
intellectual faith in others. When you wonder "what must be going
through his mind to not see it as obvious"... you should consider
"hey, maybe I am missing some aspect of this".
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [git-users] Git clone fails with "bad pack header", how to get remote log
From: kevin molcard @ 2012-11-01 15:38 UTC (permalink / raw)
To: Jeff King; +Cc: Konstantin Khomoutov, git
In-Reply-To: <20121101111544.GA19996@sigill.intra.peff.net>
Hi Peff,
thanks for this information.
I will report the issue to scm-manager. In the meantime I will try to
use ssh protocol to connect to my remote server.
Thanks again,
Kevin
2012/11/1 Jeff King <peff@peff.net>:
> On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
>
>> I forgot to mention that I am using scm manager:
>> https://bitbucket.org/sdorra/scm-manager/wiki/Home
>>
>> So that maybe the " custom layer you are talking about.
>
> Yeah, that is very important. If I am reading the scm-manager code right
> (and I might not be, as I only just looked at it), it is built entirely
> around JGit, and is not calling git-core programs at all. So it is
> either an issue in scm-manager, or in JGit.
>
> Your best bet is probably to report the issue to the scm-manager folks,
> who can probably help you dig into the problem further (it may even have
> more detailed logs of what happened, but I don't know).
>
> -Peff
^ permalink raw reply
* Wrap commit messages on `git commit -m`
From: Ramkumar Ramachandra @ 2012-11-01 16:07 UTC (permalink / raw)
To: Git List
Hi,
Some of my colleagues are lazy to fire up an editor and write proper
commit messages- they often write one-liners using `git commit -m`.
However, that line turns out to be longer than 72 characters, and the
resulting `git log` output is ugly. So, I was wondering if it would
be a good idea to wrap these one-liners to 72 characters
automatically.
Thanks.
Ram
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-01 17:13 UTC (permalink / raw)
To: Martin Langhoff
Cc: René Scharfe, Junio C Hamano, Johannes Schindelin,
Jonathan Nieder, Jeff King, git, Michael J Gruber,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CACPiFCJ2z38jTwrFpQQC08184JB5XkQ4q5c=yXvuGonY5WYKpQ@mail.gmail.com>
On Thu, Nov 1, 2012 at 3:47 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> Felipe,
>
> I'll invite you to reread some of your words:
>
>> That being said, I did wonder what must be going through his mind to
>> not see that as obvious,
> (...)
>
>> Following the guideline of always assuming good faith
>
> So perhaps it does apply that you could try to assume good
> intellectual faith in others. When you wonder "what must be going
> through his mind to not see it as obvious"... you should consider
> "hey, maybe I am missing some aspect of this".
That's what I did.
But even if I didn't, that's not offensive, that only means I made a
mistake and it is actually not obvious. But that would be a
*technical* mistake.
When I feel something is obvious, I say "I think this is obvious",
when I feel something is obvious to me, but not to others, I say "This
is obvious to me", when I believe with every fiber of my being that
something is obvious with a very low margin of error, not only to me,
but to other people, I say "this is as obvious as it gets". Of course,
there's the possibility that I missed something, there's always that
possibility, but even if I did, that would be a *technical* mistake.
If you want to discuss the technical aspect of whether or not that is
obvious, feel free to comment in the other thread. This one is about
netiquette. And I've yet to see what is wrong with saying "this is
obvious", *specially* if we are assuming good faith from both sides,
and both sides have already agreed that there's a disagreement, no
insults, no name calling, not ad hominem attacks; simply a
disagreement. Nothing wrong with disagreeing, even if it's strongly.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Wrap commit messages on `git commit -m`
From: Thomas Adam @ 2012-11-01 18:12 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0kQ+qCsOa87yY4wma279mp+9h+LFv3qCP_qrNdDyGNcsQ@mail.gmail.com>
Hi,
On 1 November 2012 16:07, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
>
> Hi,
>
> Some of my colleagues are lazy to fire up an editor and write proper
> commit messages- they often write one-liners using `git commit -m`.
> However, that line turns out to be longer than 72 characters, and the
> resulting `git log` output is ugly. So, I was wondering if it would
> be a good idea to wrap these one-liners to 72 characters
> automatically.
Can't you do this already? From "git-log(1)":
%w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
option of git-shortlog(1).
-- Thomas Adam
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Ramsay Jones @ 2012-11-01 18:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121029102114.GA14497@sigill.intra.peff.net>
Jeff King wrote:
> What's cooking in git.git (Oct 2012, #09; Mon, 29)
> --------------------------------------------------
>
[snip]
> * cr/cvsimport-local-zone (2012-10-16) 1 commit
> - git-cvsimport: allow author-specific timezones
>
> Allows "cvsimport" to read per-author timezone from the author info
> file.
>
> Will merge to 'next'.
Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.
I haven't spent too long on this yet, but I had hoped that setting
TZ would sidestep any DST issues. (I have downloaded new tzdata, but
have yet to install - actually I don't really want to!). It is not
clear from the tzset manpage what happens if you use the DST format
for TZ, but you don't provide the start/end date for DST, which is
what this test is doing.
Perhaps the test should use the non-DST format? e.g. "TZ=CST6 git ..."
Does the test really care about DST? (*if* that is indeed the problem).
Also: Note that the first test calls git-cvsimport twice, first *with*
TZ set then again without; I suspect a cut/paste editing error.
I have added the output of "./t9604-cvsimport-timestamps.sh -v" below.
ATB,
Ramsay Jones
ramsay@ramsay-laptop:$ ./t9604-cvsimport-timestamps.sh -v
Initialized empty Git repository in /home/ramsay/git/t/trash directory.t9604-cvsimport-timestamps/.git/
expecting success:
TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
git cvsimport -p"-x" -C module-1 module &&
(
cd module-1 &&
git log --format="%s %ai"
) >actual-1 &&
cat >expect-1 <<-EOF &&
Rev 16 2006-10-29 07:00:01 +0000
Rev 15 2006-10-29 06:59:59 +0000
Rev 14 2006-04-02 08:00:01 +0000
Rev 13 2006-04-02 07:59:59 +0000
Rev 12 2005-12-01 00:00:00 +0000
Rev 11 2005-11-01 00:00:00 +0000
Rev 10 2005-10-01 00:00:00 +0000
Rev 9 2005-09-01 00:00:00 +0000
Rev 8 2005-08-01 00:00:00 +0000
Rev 7 2005-07-01 00:00:00 +0000
Rev 6 2005-06-01 00:00:00 +0000
Rev 5 2005-05-01 00:00:00 +0000
Rev 4 2005-04-01 00:00:00 +0000
Rev 3 2005-03-01 00:00:00 +0000
Rev 2 2005-02-01 00:00:00 +0000
Rev 1 2005-01-01 00:00:00 +0000
EOF
test_cmp actual-1 expect-1
Initialized empty Git repository in /home/ramsay/git/t/trash directory.t9604-cvsimport-timestamps/module-1/.git/
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
Already up-to-date.
--- actual-1 2012-10-31 21:20:20.000000000 +0000
+++ expect-1 2012-10-31 21:20:20.000000000 +0000
@@ -13,4 +13,4 @@
Rev 4 2005-04-01 00:00:00 +0000
Rev 3 2005-03-01 00:00:00 +0000
Rev 2 2005-02-01 00:00:00 +0000
-Rev 1 2004-12-31 18:00:00 +0000
+Rev 1 2005-01-01 00:00:00 +0000
not ok 1 - check timestamps are UTC (TZ=CST6CDT)
#
#
# TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
# git cvsimport -p"-x" -C module-1 module &&
# (
# cd module-1 &&
# git log --format="%s %ai"
# ) >actual-1 &&
# cat >expect-1 <<-EOF &&
# Rev 16 2006-10-29 07:00:01 +0000
# Rev 15 2006-10-29 06:59:59 +0000
# Rev 14 2006-04-02 08:00:01 +0000
# Rev 13 2006-04-02 07:59:59 +0000
# Rev 12 2005-12-01 00:00:00 +0000
# Rev 11 2005-11-01 00:00:00 +0000
# Rev 10 2005-10-01 00:00:00 +0000
# Rev 9 2005-09-01 00:00:00 +0000
# Rev 8 2005-08-01 00:00:00 +0000
# Rev 7 2005-07-01 00:00:00 +0000
# Rev 6 2005-06-01 00:00:00 +0000
# Rev 5 2005-05-01 00:00:00 +0000
# Rev 4 2005-04-01 00:00:00 +0000
# Rev 3 2005-03-01 00:00:00 +0000
# Rev 2 2005-02-01 00:00:00 +0000
# Rev 1 2005-01-01 00:00:00 +0000
# EOF
# test_cmp actual-1 expect-1
#
expecting success:
cat >cvs-authors <<-EOF &&
user1=User One <user1@domain.org>
user2=User Two <user2@domain.org> CST6CDT
user3=User Three <user3@domain.org> EST5EDT
user4=User Four <user4@domain.org> MST7MDT
EOF
git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
(
cd module-2 &&
git log --format="%s %ai %an"
) >actual-2 &&
cat >expect-2 <<-EOF &&
Rev 16 2006-10-29 01:00:01 -0600 User Two
Rev 15 2006-10-29 01:59:59 -0500 User Two
Rev 14 2006-04-02 03:00:01 -0500 User Two
Rev 13 2006-04-02 01:59:59 -0600 User Two
Rev 12 2005-11-30 17:00:00 -0700 User Four
Rev 11 2005-10-31 19:00:00 -0500 User Three
Rev 10 2005-09-30 19:00:00 -0500 User Two
Rev 9 2005-09-01 00:00:00 +0000 User One
Rev 8 2005-07-31 18:00:00 -0600 User Four
Rev 7 2005-06-30 20:00:00 -0400 User Three
Rev 6 2005-05-31 19:00:00 -0500 User Two
Rev 5 2005-05-01 00:00:00 +0000 User One
Rev 4 2005-03-31 17:00:00 -0700 User Four
Rev 3 2005-02-28 19:00:00 -0500 User Three
Rev 2 2005-01-31 18:00:00 -0600 User Two
Rev 1 2005-01-01 00:00:00 +0000 User One
EOF
test_cmp actual-2 expect-2
Initialized empty Git repository in /home/ramsay/git/t/trash directory.t9604-cvsimport-timestamps/module-2/.git/
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
* UNKNOWN LINE * Branches:
--- actual-2 2012-10-31 21:20:21.000000000 +0000
+++ expect-2 2012-10-31 21:20:21.000000000 +0000
@@ -1,16 +1,16 @@
Rev 16 2006-10-29 01:00:01 -0600 User Two
Rev 15 2006-10-29 01:59:59 -0500 User Two
Rev 14 2006-04-02 03:00:01 -0500 User Two
-Rev 13 2006-04-02 00:59:59 -0600 User Two
-Rev 12 2005-11-30 19:00:00 -0700 User Four
-Rev 11 2005-10-31 18:00:00 -0500 User Three
-Rev 10 2005-10-01 01:00:00 -0500 User Two
-Rev 9 2005-08-31 18:00:00 +0000 User One
-Rev 8 2005-07-31 20:00:00 -0600 User Four
-Rev 7 2005-06-30 19:00:00 -0400 User Three
-Rev 6 2005-06-01 01:00:00 -0500 User Two
-Rev 5 2005-04-30 18:00:00 +0000 User One
-Rev 4 2005-03-31 19:00:00 -0700 User Four
-Rev 3 2005-02-28 18:00:00 -0500 User Three
-Rev 2 2005-02-01 00:00:00 -0600 User Two
+Rev 13 2006-04-02 01:59:59 -0600 User Two
+Rev 12 2005-11-30 17:00:00 -0700 User Four
+Rev 11 2005-10-31 19:00:00 -0500 User Three
+Rev 10 2005-09-30 19:00:00 -0500 User Two
+Rev 9 2005-09-01 00:00:00 +0000 User One
+Rev 8 2005-07-31 18:00:00 -0600 User Four
+Rev 7 2005-06-30 20:00:00 -0400 User Three
+Rev 6 2005-05-31 19:00:00 -0500 User Two
+Rev 5 2005-05-01 00:00:00 +0000 User One
+Rev 4 2005-03-31 17:00:00 -0700 User Four
+Rev 3 2005-02-28 19:00:00 -0500 User Three
+Rev 2 2005-01-31 18:00:00 -0600 User Two
Rev 1 2005-01-01 00:00:00 +0000 User One
not ok 2 - check timestamps with author-specific timezones
#
#
# cat >cvs-authors <<-EOF &&
# user1=User One <user1@domain.org>
# user2=User Two <user2@domain.org> CST6CDT
# user3=User Three <user3@domain.org> EST5EDT
# user4=User Four <user4@domain.org> MST7MDT
# EOF
# git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
# (
# cd module-2 &&
# git log --format="%s %ai %an"
# ) >actual-2 &&
# cat >expect-2 <<-EOF &&
# Rev 16 2006-10-29 01:00:01 -0600 User Two
# Rev 15 2006-10-29 01:59:59 -0500 User Two
# Rev 14 2006-04-02 03:00:01 -0500 User Two
# Rev 13 2006-04-02 01:59:59 -0600 User Two
# Rev 12 2005-11-30 17:00:00 -0700 User Four
# Rev 11 2005-10-31 19:00:00 -0500 User Three
# Rev 10 2005-09-30 19:00:00 -0500 User Two
# Rev 9 2005-09-01 00:00:00 +0000 User One
# Rev 8 2005-07-31 18:00:00 -0600 User Four
# Rev 7 2005-06-30 20:00:00 -0400 User Three
# Rev 6 2005-05-31 19:00:00 -0500 User Two
# Rev 5 2005-05-01 00:00:00 +0000 User One
# Rev 4 2005-03-31 17:00:00 -0700 User Four
# Rev 3 2005-02-28 19:00:00 -0500 User Three
# Rev 2 2005-01-31 18:00:00 -0600 User Two
# Rev 1 2005-01-01 00:00:00 +0000 User One
# EOF
# test_cmp actual-2 expect-2
#
# failed 2 among 2 test(s)
1..2
ramsay@ramsay-laptop:$
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Ramsay Jones @ 2012-11-01 19:19 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Oberndorfer, git, Junio C Hamano
In-Reply-To: <20121030121747.GA4231@sigill.intra.peff.net>
Jeff King wrote:
> Thinking on it more, my patch, hacky thought it seems, may not be the
> worst solution. Here are the options that I see:
>
> 1. Use a regex library that does not require NUL termination. If we
> are bound by the regular regexec interface, this is not feasible.
> But the GNU implementation works on arbitrary-length buffers (you
> just have to use a slightly different interface), and we already
> carry it in compat. It would mean platforms which provide a working
> but non-GNU regexec would have to start defining NO_REGEX.
I have thought about the possibility of doing this for unrelated reasons
in the past.
On cygwin, there have been two unexpected test passes since about v1.6.0
(I reported it to the list in passing), like so:
[ ... ]
All tests successful.
Test Summary Report
-------------------
t0050-filesystem.sh (Wstat: 0 Tests: 9 Failed: 0)
TODO passed: 5
t7008-grep-binary.sh (Wstat: 0 Tests: 20 Failed: 0)
TODO passed: 12
Files=604, Tests=8439, 11190 wallclock secs ( 2.59 usr 1.59 sys + 7294.86 cusr
3416.65 csys = 10715.70 CPU)
Result: PASS
In particular, t7008.12 passes on cygwin because the regex library apparently
matches '.' to NUL. Indeed if you add a test_pause to the script and execute
"grep .fi a" (note grep *not* git-grep) then "Binary file a matches" on Linux,
cygwin and MinGW. (So I assume the test was added to document a difference in
behaviour to GNU grep).
So, if we use the GNU interface to the regex routines in compat, then we may
specify the "grep syntax" for use in git-grep. (Well that's the theory, I've
not actually tried to code it up, so take this with a pinch of salt! :-P ).
ATB,
Ramsay Jones
^ permalink raw reply
* checkout-index: unable to create file foo (File exists)
From: Brian J. Murrell @ 2012-11-01 20:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]
When we use git on a network filesystem, occasionally and sporadically
we will see the following from a git checkout command:
error: git checkout-index: unable to create file foo (File exists)
Through a very basic grepping and following of the source it seems that
the core of the error message is coming from write_entry() in entry.c:
fd = open_output_fd(path, ce, to_tempfile);
if (fd < 0) {
free(new);
return error("unable to create file %s (%s)",
path, strerror(errno));
}
So looking into open_output_fd() there is a call to create_file() which
does:
return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
I am able to prevent the problem from happening with 100% success by
simply giving the git checkout a "-q" argument to prevent it from
emitting progress reports. This would seem to indicate that the problem
likely revolves around the fact that the progress reporting uses SIGALRM.
Given that O_CREAT | O_EXCL are used in the open() call and that SIGALRM
(along with SA_RESTART) is being used frequently to do progress updates,
it seems reasonable to suspect that the problem is that open() is being
interrupted (but only after it creates the file and before completing)
by the progress reporting mechanism's SIGALRM and when the progress
reporting is done, open() is restarted automatically (due to the use of
SA_RESTART) and fails because the file exists and O_CREAT | O_EXCL are
used in the open() call.
Does this seem like a reasonable hypothesis?
If it does, where does the problem lie here? Is it that SA_RESTART
should not be used since it's not safe with open() and O_CREAT | O_EXCL
(and every system call caller should be handling EINTR) or should the
open() be idempotent so that it can be restarted automatically with
SA_RESTART? If open(2) is supposed to be idempotent, it would be most
useful to have a citation to standard where that is specified.
If open() is not required to be idempotent, it's use with O_CREAT |
O_EXCL and SA_RESTART seems fatally flawed.
Any insight or opinions would be much appreciated.
Cheers,
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Jonathan Nieder @ 2012-11-01 20:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Felipe Contreras, Jeff King, git,
Michael J Gruber, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow
In-Reply-To: <bec4d263-b458-4636-9fa6-1c1202416810@email.android.com>
Junio C Hamano wrote:
> We've been hoping we can do without a rigid code of conduct written
> down to maintain cordial community focused on technical merits, and
> instead relied on people's common sense, but sense may not be so
> common, unfortunately, so we may have to have one.
I think that except for occasional lapses this list stays pretty close
to what, for example, the Fedora[1] and Ubuntu[2] codes of conduct
require, and what Emily Postnews's guide[3] explains not to do.
What's the next step?
[1] http://www.ubuntu.com/project/about-ubuntu/conduct
[2] http://www.ubuntu.com/project/about-ubuntu/conduct
[3] http://www.templetons.com/brad/emily.html
^ 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