* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-23 8:56 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090823171819.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> How about doing it like this patch instead? This counterproposal replaces
>> your 3 patches starting from [3/6].
>>
>> -- >8 --
>> Subject: xutils: Fix xdl_recmatch() on incomplete lines
>>
>> Thell Fowler noticed that various "ignore whitespace" options to
>> git diff does not work well with whitespace glitches on an incomplete
>> line.
>
> I think this should be "options to git diff don't work".
Soory, I kant speel; thanks.
> (1) Why do you post patches to the list, instead of committing them
> yourself?
So that others can catch silly mistakes of mine, like the one you just
caught.
I play three separate roles here, two of which I should send patches out
while playing them.
* Just like everybody else, I find itches to scratch from time to time,
and I build my own topic branches locally for the changes to scratch
them, just like other contributors.
They are indeed committed and often immediately merged to 'pu', but I
send out format-patch output for them, because I firmly believe that
the development _process_, not just the end result, should be in the
open. Everybody's patch should go through the list, get reviewed and
improved by help from others. So should mine.
* I read others' patches, review, comment, and suggest improvements and
make counterproposals, just like others on the list.
The "how about" patches when I am playing this role are often not meant
as the final shape of the patch but to show the direction to improve
upon. They are output from "git diff", not format-patch nor even "git
diff --cached"---I do not commit, nor even add them to the index---and
after I send out e-mails, I typically reset them away to work on
something else, because they are usually not my itch.
* I accept patches that were reviewed favorably on the list by running
"git am" on them.
> (2) How do I apply a patch like this one to try to my tree? Am I
> expected to edit the mail message to remove everything before the shears
> mark before running the git-am command?
That is how I have been doing it. My workflow is:
(1) First read patches in my primary mailbox, while copying promising
ones to a separate mailbox;
(2) And then go through the separate mailbox as a separate pass, while
fixing obvious typos and minor coding style violations still inside
mailbox; and finally
(3) Run "git am" on the (possibly edited) patch to apply.
Because I'll be editing the messages (both log and code) _anyway_,
removing everything before the scissors mark is not much of a trouble.
Having said that, I could use something like this.
-- >8 -- cut here -- >8 --
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
This teaches mailinfo the scissors -- >8 -- mark; the command ignores
everything before it in the message body.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-mailinfo.c | 37 ++++++++++++++++++++++++++++++++++++-
1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b0b5d8f..461c47e 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -712,6 +712,34 @@ static inline int patchbreak(const struct strbuf *line)
return 0;
}
+static int scissors(const struct strbuf *line)
+{
+ size_t i, len = line->len;
+ int scissors_dashes_seen = 0;
+ const char *buf = line->buf;
+
+ for (i = 0; i < len; i++) {
+ if (isspace(buf[i]))
+ continue;
+ if (buf[i] == '-') {
+ scissors_dashes_seen |= 02;
+ continue;
+ }
+ if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
+ scissors_dashes_seen |= 01;
+ i++;
+ continue;
+ }
+ if (i + 7 < len && !memcmp(buf + i, "cut here", 8)) {
+ i += 7;
+ continue;
+ }
+ /* everything else --- not scissors */
+ break;
+ }
+ return scissors_dashes_seen == 03;
+}
+
static int handle_commit_msg(struct strbuf *line)
{
static int still_looking = 1;
@@ -723,10 +751,17 @@ static int handle_commit_msg(struct strbuf *line)
strbuf_ltrim(line);
if (!line->len)
return 0;
- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
+ still_looking = check_header(line, s_hdr_data, 0);
+ if (still_looking)
return 0;
}
+ if (scissors(line)) {
+ fseek(cmitmsg, 0L, SEEK_SET);
+ still_looking = 1;
+ return 0;
+ }
+
/* normalize the log message to UTF-8. */
if (metainfo_charset)
convert_to_utf8(line, charset.buf);
--
1.6.4.1
^ permalink raw reply related
* [PATCH] gitweb: pull ref markes pull out of subject <a> tag
From: Giuseppe Bilotta @ 2009-08-23 8:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
Since 4afbaefffa9095fe1391b4b61289a7dc954e9f7b ref markers that
accompain the subject in views such as shortlog and history point to
something different from the subject itself. Therefore, they should not
be included in the same <a> tag.
Benefits of the change are:
* better compliance to the XHTML standards, that forbid links within
links even though the restriction cannot be imposed via DTD; this also
benefits visualization in some older browsers;
* when hovering the subject, only the subject itself is underlined; when
hovering the ref markers, only the text in the hovered ref marker is
underlined; previously, hovering any written part of the subject
column led to complete underlying of everything at the same time,
with unpleasing effects.
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
The next step would be to find a way to layout decently the case when
some shortlog entries have a _humongous_ amount of ref markers. See
for example http://git.oblomov.eu/acecad/shortlog
I honestly doubt these cases happen in normal git repositories, but it
might still be worth taking them into consideration. Possibilities
include hard-limiting the title column maximum width (in browsers for
which the corresponding attributes and rules work), manual insertion of
hard line breaks <br/> every n-th ref marker, or something more dynamic
such as hiding most of the ref markers when they are more than, say, 5,
and showing them on hover.
Suggestions? Comments?
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ce6e8f6..bb9648b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1524,10 +1524,10 @@ sub format_subject_html {
$long =~ s/[[:cntrl:]]/?/g;
return $cgi->a({-href => $href, -class => "list subject",
-title => to_utf8($long)},
- esc_html($short) . $extra);
+ esc_html($short)) . $extra;
} else {
return $cgi->a({-href => $href, -class => "list subject"},
- esc_html($long) . $extra);
+ esc_html($long)) . $extra;
}
}
--
1.6.3.rc1.192.gdbfcb
^ permalink raw reply related
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Nanako Shiraishi @ 2009-08-23 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7vvdkfx8rl.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> How about doing it like this patch instead? This counterproposal replaces
> your 3 patches starting from [3/6].
>
> -- >8 --
> Subject: xutils: Fix xdl_recmatch() on incomplete lines
>
> Thell Fowler noticed that various "ignore whitespace" options to
> git diff does not work well with whitespace glitches on an incomplete
> line.
I think this should be "options to git diff don't work".
I have two unrelated questions.
(1) Why do you post patches to the list, instead of committing them yourself?
(2) How do I apply a patch like this one to try to my tree? Am I expected to edit the mail message to remove everything before the shears mark before running the git-am command?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-23 7:57 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Johannes.Schindelin
In-Reply-To: <1250999357-10827-3-git-send-email-git@tbfowler.name>
Thell Fowler <git@tbfowler.name> writes:
> @@ -191,12 +191,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
> int i1, i2;
>
> if (flags & XDF_IGNORE_WHITESPACE) {
> - for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
> + for (i1 = i2 = 0; i1 < s1 || i2 < s2; ) {
> if (isspace(l1[i1]))
> - while (isspace(l1[i1]) && i1 < s1)
> + while ((isspace(l1[i1]) && i1 < s1)
> + || (i1 + 1 == s1 && l1[s1] != '\n'))
This is wrong. If you ran out l1/s1/i1 but you still have remaining
characters in l2/s2/i2, you do not want to even look at l1[i1].
You can fudge this by sprinkling more "(i1 < s1) &&" in many places (and
reordering how your inner while() loop checks (i1 < s1) and l1[i1]), but I
do not think that is the right direction.
The thing is, the loop control in this function is extremely hard to read
to begin with, and now it is "if we haven't run out both", the complexity
seeps into the inner logic.
How about doing it like this patch instead? This counterproposal replaces
your 3 patches starting from [3/6].
-- >8 --
Subject: xutils: Fix xdl_recmatch() on incomplete lines
Thell Fowler noticed that various "ignore whitespace" options to
git diff does not work well with whitespace glitches on an incomplete
line.
The loop control of this function incorrectly handled incomplete lines,
and it was extremely difficult to follow. This restructures the loops for
three variants of "ignore whitespace" logic.
The basic idea of the re-written logic is this.
- An initial loop runs while the characters from both strings we are
looking at match. We declare unmatch immediately when we find
something that does not match and return false from the loop. And we
break out of the loop if we ran out of either side of the string.
The way we skip spaces inside this loop varies depending on the style
of ignoring whitespaces.
- After the loop, the lines can match only if the remainder consists of
nothing but whitespaces. This part of the logic is shared across all
three styles.
The new code is more obvious and should be much easier to follow.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
xdiff/xutils.c | 111 +++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 77 insertions(+), 34 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 9411fa9..dd8b7e7 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -186,50 +186,93 @@ long xdl_guess_lines(mmfile_t *mf) {
return nl + 1;
}
+static int remainder_all_ws(const char *l1, const char *l2,
+ int i1, int i2, long s1, long s2)
+{
+ if (i1 < s1) {
+ while (i1 < s1 && isspace(l1[i1]))
+ i1++;
+ return (s1 == i1);
+ }
+ if (i2 < s2) {
+ while (i2 < s2 && isspace(l2[i2]))
+ i2++;
+ return (s2 == i2);
+ }
+ return 1;
+}
+
int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
{
- int i1, i2;
+ int i1 = 0, i2 = 0;
if (flags & XDF_IGNORE_WHITESPACE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (isspace(l1[i1]))
- while (isspace(l1[i1]) && i1 < s1)
- i1++;
- if (isspace(l2[i2]))
- while (isspace(l2[i2]) && i2 < s2)
- i2++;
- if (i1 < s1 && i2 < s2 && l1[i1++] != l2[i2++])
- return 0;
+ while (1) {
+ while (i1 < s1 && isspace(l1[i1]))
+ i1++;
+ while (i2 < s2 && isspace(l2[i2]))
+ i2++;
+ if (i1 < s1 && i2 < s2) {
+ if (l1[i1++] != l2[i2++])
+ return 0;
+ continue;
+ }
+ break;
}
- return (i1 >= s1 && i2 >= s2);
+
+ /*
+ * we ran out one side; the remaining side must be all
+ * whitespace to match.
+ */
+ return remainder_all_ws(l1, l2, i1, i2, s1, s2);
} else if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (isspace(l1[i1])) {
- if (!isspace(l2[i2]))
+ while (1) {
+ if (i1 < s1 && i2 < s2) {
+ /* Skip matching spaces */
+ if (isspace(l1[i1]) && isspace(l2[i2])) {
+ while (i1 < s1 && isspace(l1[i1]))
+ i1++;
+ while (i2 < s2 && isspace(l2[i2]))
+ i2++;
+ }
+ }
+ if (i1 < s1 && i2 < s2) {
+ /*
+ * We still have both sides; do they match?
+ */
+ if (l1[i1++] != l2[i2++])
return 0;
- while (isspace(l1[i1]) && i1 < s1)
- i1++;
- while (isspace(l2[i2]) && i2 < s2)
- i2++;
- } else if (l1[i1++] != l2[i2++])
- return 0;
+ continue;
+ }
+ break;
}
- return (i1 >= s1 && i2 >= s2);
+
+ /*
+ * If we do not want -b to imply --ignore-space-at-eol
+ * then you would need to add this:
+ *
+ * if (!(flags & XDF_IGNORE_WHITESPACE_AT_EOL))
+ * return (s1 <= i1 && s2 <= i2);
+ *
+ */
+
+ /*
+ * we ran out one side; the remaining side must be all
+ * whitespace to match.
+ */
+ return remainder_all_ws(l1, l2, i1, i2, s1, s2);
+
} else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (l1[i1] != l2[i2]) {
- while (i1 < s1 && isspace(l1[i1]))
- i1++;
- while (i2 < s2 && isspace(l2[i2]))
- i2++;
- if (i1 < s1 || i2 < s2)
- return 0;
- return 1;
- }
- i1++;
- i2++;
+ while (1) {
+ if (i1 < s1 && i2 < s2 && l1[i1++] == l2[i2++])
+ continue;
+ break;
}
- return i1 >= s1 && i2 >= s2;
+ /*
+ * we ran out one side; the remaining side must be all
+ * whitespace to match.
+ */
+ return remainder_all_ws(l1, l2, i1, i2, s1, s2);
} else
return s1 == s2 && !memcmp(l1, l2, s1);
}
^ permalink raw reply related
* Re: [PATCH-v2/RFC 2/6] xutils: fix hash with whitespace on incomplete line
From: Junio C Hamano @ 2009-08-23 7:51 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Johannes.Schindelin
In-Reply-To: <1250999357-10827-2-git-send-email-git@tbfowler.name>
Thell Fowler <git@tbfowler.name> writes:
> - Make xdl_hash_record_with_whitespace stop hashing before the
> eof when ignoring space change or space at eol on an incomplete
> line.
>
> Resolves issue with a final trailing space being included in the
> hash on an incomplete line by treating the eof in the same fashion
> as a newline.
Please study the style of existing commit messages and imitate them.
> Signed-off-by: Thell Fowler <git@tbfowler.name>
> ---
> xdiff/xutils.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> index 04ad468..c6512a5 100644
> --- a/xdiff/xutils.c
> +++ b/xdiff/xutils.c
> @@ -248,12 +248,12 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
> if (flags & XDF_IGNORE_WHITESPACE)
> ; /* already handled */
> else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
> - && ptr[1] != '\n') {
> + && ptr[1] != '\n' && ptr + 1 < top) {
> ha += (ha << 5);
> ha ^= (unsigned long) ' ';
> }
> else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
> - && ptr[1] != '\n') {
> + && ptr[1] != '\n' && ptr + 1 < top) {
> while (ptr2 != ptr + 1) {
> ha += (ha << 5);
> ha ^= (unsigned long) *ptr2;
Thanks.
The issue you identified and tried to fix is a worthy one. But before the
pre-context of this hunk, I notice these lines:
if (isspace(*ptr)) {
const char *ptr2 = ptr;
while (ptr + 1 < top && isspace(ptr[1])
&& ptr[1] != '\n')
ptr++;
If you have trailing whitespaces on an incomplete line, ptr initially
points at the first such whitespace, ptr2 points at the same location, and
then the while() loop advances ptr to point at the last byte on the line,
which in turn will be the last byte of the file. And the codepath with
your updates still try to access ptr[1] that is beyond that last byte.
I would write it like this patch instead.
The intent is the same as your patch, but it avoids accessing ptr[1] when
that is beyond the end of the buffer, and the logic is easier to follow as
well.
-- >8 --
Subject: xutils: fix hashing an incomplete line with whitespaces at the end
Upon seeing a whitespace, xdl_hash_record_with_whitespace() first skipped
the run of whitespaces (excluding LF) that begins there, ensuring that the
pointer points the last whitespace character in the run, and assumed that
the next character must be LF at the end of the line. This does not work
when hashing an incomplete line, that lacks the LF at the end.
Introduce "at_eol" variable that is true when either we are at the end of
line (looking at LF) or at the end of an incomplete line, and use that
instead throughout the code.
Noticed by Thell Fowler.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
xdiff/xutils.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 04ad468..9411fa9 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -242,18 +242,20 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
for (; ptr < top && *ptr != '\n'; ptr++) {
if (isspace(*ptr)) {
const char *ptr2 = ptr;
+ int at_eol;
while (ptr + 1 < top && isspace(ptr[1])
&& ptr[1] != '\n')
ptr++;
+ at_eol = (top <= ptr + 1 || ptr[1] == '\n');
if (flags & XDF_IGNORE_WHITESPACE)
; /* already handled */
else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
- && ptr[1] != '\n') {
+ && !at_eol) {
ha += (ha << 5);
ha ^= (unsigned long) ' ';
}
else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
- && ptr[1] != '\n') {
+ && !at_eol) {
while (ptr2 != ptr + 1) {
ha += (ha << 5);
ha ^= (unsigned long) *ptr2;
^ permalink raw reply related
* Re: git-mail-commits (Re: What's a good setup for submitting patches to the list properly?)
From: Christian Couder @ 2009-08-23 7:11 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Thell Fowler, git, Julian Phillips
In-Reply-To: <20090822205656.GA3526@vidovic>
On Saturday 22 August 2009, Nicolas Sebrecht wrote:
> The 22/08/09, Christian Couder wrote:
> > There is "git send-email" that is bundled with git. But I use
> > git-mail-commits from Julian Philips. I am very happy with it. Thanks
> > Julian!
>
> Isn't there any public repo for it?
Not that I know of, but I think it would be a good idea to publish it
(perhaps in contrib/).
Julian?
Regards,
Christian.
^ permalink raw reply
* Re: hitting home directory's parent
From: Daniel Convissor @ 2009-08-23 5:12 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20090822181607.GA25823@coredump.intra.peff.net>
Hi Jeff:
On Sat, Aug 22, 2009 at 02:16:07PM -0400, Jeff King wrote:
>
> Without looking, I would not be surprised if it is a side effect of
> git trying to look up help-related config.
That explains what's happening. cmd_help() calls git_config(). Though
it seems it would be more, uh, helpful, if help produced basic usage
output no matter what, and then produce the more detailed config based
output if possible.
> Probably it is calling "setup_git_directory_gently" and ignoring an
> error return, but there is a die() inside that function. The bug
> then is that the _gently form is calling die().
Yep. setup.c, lines 391 and 392 (master branch):
if (chdir(".."))
die_errno("Cannot change to '%s/..'", cwd);
> As for fixing the setup code, I am sadly way behind on my git queue and
> not likely to catch up to this anytime soon. So if anybody feels like
> taking a stab at it, that would be very welcome.
Is there a bug tracker y'all use where I can enter a ticket?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: hitting home directory's parent
From: Daniel Convissor @ 2009-08-23 4:42 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <fcaeb9bf0908220920g29ec24e9v23d0504d10ca6cfb@mail.gmail.com>
Hi Duy:
On Sat, Aug 22, 2009 at 11:20:39PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sat, Aug 22, 2009 at 10:05 PM, Daniel
> Convissor<danielc@analysisandsolutions.com> wrote:
> > Hi Duy:
> >
> > On Sat, Aug 22, 2009 at 11:10:18AM +0700, Nguyen Thai Ngoc Duy wrote:
> >>
> >> I guess it tried to find .git directory upward. I think you can set
> >> GIT_CEILING_DIRECTORIES to make it stop at /home/danielc. Excerpt from
> >> git.txt
> >
> > That didn't change the situation.
>
> I'd suggest you to degrade Git to a version earlier than 1.6.1, when
> the error was not added. :-D
:) Might be easier to use "svn ci" instead. :)
> But did it at least change the error message? Here is what I got when
> "chmod 000 /tmp/a":
No. It produced the same exact error message:
fatal: Cannot change to /home/danielc/..: Permission denied
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: Commit performance, or lack thereof
From: Junio C Hamano @ 2009-08-23 2:20 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3r5v39zzz.fsf@lugabout.jhcloos.org>
James Cloos <cloos@jhcloos.com> writes:
> Starting in the kernel tree, if one edits and adds a single file and
> then commits it w/o specifying the file name as an argument to commit,
> ...
> OTOH, if one does specify the filename as an argument to commit,...
When you do:
git add something && git commit
the commit step is just "write the index out as a tree, create a commit
object to wrap that tree object". It never has to look at your work tree
and is a very cheap operation.
On the other hand, if you do:
some other random things && git commit pathspec
the commit step involves a lot more operations. It has to do:
- create a temporary index from HEAD (i.e. ignore the modification to
the real index you did so far with your earlier "git add");
- rehash all the paths in the work tree that matches the pathspec and
add them to that temporary index; and finally
- write the temporary index out as a tree, create a commit object to
wrap that tree object.
The second step has to go to your work tree, and if you have a slow disk,
or your buffer cache is cold, you naturally have to pay.
So it is not surprising at all if you observe that the latter takes more
time and resource than the former, although there could be something wrong
in your set-up that you need to spend 300M for it. It is fundamentally a
more expensive operation.
^ permalink raw reply
* Re: [PATCH 2/2 (v3)] reset: make the output more user-friendly.
From: Junio C Hamano @ 2009-08-23 2:33 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq8whc8euu.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Intuitively, I would have thought that "git reset" was reporting what
> it was doing, as it was doing it. So to me (before experimenting a bit
> more and looking at the source code),
>
> M foo.txt
> M bar.txt
>
> would mean "I've just reseted foo.txt and bar.txt, which were locally
> modified", while actually "git reset" can very well show this message
> after reseting only foo.txt, just informing the user that bar.txt is
> also modified. So, at least to me, the semantics was very unclear, and
> while I would have understood immediately with the one-liner message.
>
> In short: no strong objection to remove this message, but to me it is
> usefull.
Thanks for sharing the reasoning.
Two conflicting/competing thoughts come to mind:
1. Perhaps we should add a similar "explanation" for the list of paths
with changes upon switching branches with "git checkout" for
consistency.
2. Such an "explanation" of what the output means would help the first
time people, but would everybody stay "first time" forever? Would the
explanation become just another wasted line in valuable screen real
estate after people gain experience?
I am leaning towards #1 right now.
^ permalink raw reply
* Re: hitting home directory's parent
From: Nguyen Thai Ngoc Duy @ 2009-08-23 4:07 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Convissor, Git Mailing List
In-Reply-To: <20090822181607.GA25823@coredump.intra.peff.net>
On Sun, Aug 23, 2009 at 1:16 AM, Jeff King<peff@peff.net> wrote:
> On Sat, Aug 22, 2009 at 11:20:39PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > I did read a bit farther in the manual and initialized a new repository.
>> > Issuing "git --help" once inside that new repository works. Requiring
>> > the --help command to be called from inside a repository, or even that
>> > it's looking for a repository at all, seems unwise. All it should do is
>> > display the usage information and exit.
>>
>> For simple things like --help, I agree Git should not do extra work
>> such as searching for Git repository, which is the cause. That was on
>> Jeff's plan IIRC.
>
> Without looking, I would not be surprised if it is a side effect of
> git trying to look up help-related config. So I don't think it is a
> problem exactly that it checks to see if it is in a repo (which would
> impact config lookup), but that inability to find a repo is a hard
> error.
>
> Probably it is calling "setup_git_directory_gently" and ignoring an
> error return, but there is a die() inside that function. The bug
> then is that the _gently form is calling die().
It is (and should be worked around with GIT_CEILING_DIRECTORIES).
Unfortunately in my test, it could not chdir() back when it failed to
find gitdir. chdir() was called with an absolute directory, and one
directory in that path was inaccesible, leading another die("Cannot
come back to cwd"). This one is fatal and should not be ignored. I
don't know whether having an inaccesible parent directory is a real
scenario, as lots of tools would break.
--
Duy
^ permalink raw reply
* [PATCH] post-receive-email: allow customizing of subject/intro/footer
From: Mike Frysinger @ 2009-08-23 3:51 UTC (permalink / raw)
To: git
The format of the subject/intro/footer are noise imo, but rather than
debate the issue, let the user customize the output using the existing
git config hooks section. The default output is retained for each part.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
contrib/hooks/post-receive-email | 76 +++++++++++++++++++++++++++++---------
1 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2a66063..a812143 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -38,6 +38,15 @@
# hooks.emailprefix
# All emails have their subjects prefixed with this prefix, or "[SCM]"
# if emailprefix is unset, to aid filtering
+# hooks.emailsubject
+# Allow customizing of the subject. Default is a description of what
+# ref changed and how/why.
+# hooks.emailbodyintro
+# Allow customizing of the body intro. Default is friendly paragraph that
+# explains why the user is receiving this e-mail and what has changed.
+# hooks.emailfooter
+# Allow customizing of the footer. Default is name of the script and the
+# repo description.
# hooks.showrev
# The shell command used to format each revision in the email, with
# "%s" replaced with the commit id. Defaults to "git rev-list -1
@@ -55,6 +64,10 @@
# "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and
# give information for debugging.
#
+# All variables that start with 'email' have substitution performed on them.
+# Patterns like @foo@ are replaced with the contents of the variable foo.
+# See subst_vars() for the specific keywords available for substitution.
+#
# ---------------------------- Functions
@@ -190,36 +203,47 @@ generate_email()
generate_email_footer
}
+subst_vars()
+{
+ sep=$(printf '\001')
+ # let this be used in a pipeline or by itself
+ ( [ "$#" -ne 0 ] && echo "$@" || cat ) | sed \
+ -e "s${sep}@change_type@${sep}${change_type}${sep}g" \
+ -e "s${sep}@describe@${sep}${describe}${sep}g" \
+ -e "s${sep}@newrev@${sep}${newrev}${sep}g" \
+ -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \
+ -e "s${sep}@projectdesc@${sep}${projectdesc}${sep}g" \
+ -e "s${sep}@refname@${sep}${refname}${sep}g" \
+ -e "s${sep}@refname_type@${sep}${refname_type}${sep}g" \
+ -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \
+ -e "s${sep}@short_refname@${sep}${short_refname}${sep}g"
+}
+
generate_email_header()
{
# --- Email (all stdout will be the email)
# Generate header
+ (
cat <<-EOF
To: $recipients
- Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
- X-Git-Refname: $refname
- X-Git-Reftype: $refname_type
- X-Git-Oldrev: $oldrev
- X-Git-Newrev: $newrev
+ Subject: ${emailprefix}${emailsubject}
+ X-Git-Refname: @refname@
+ X-Git-Reftype: @refname_type@
+ X-Git-Oldrev: @oldrev@
+ X-Git-Newrev: @newrev@
+ EOF
- This is an automated email from the git hooks/post-receive script. It was
- generated because a ref change was pushed to the repository containing
- the project "$projectdesc".
+ if [ -n "${emailbodyintro}" ] ; then
+ printf '\n%s\n' "${emailbodyintro}"
+ fi
- The $refname_type, $short_refname has been ${change_type}d
- EOF
+ printf '\n%s\n' "The @refname_type@, @short_refname@ has been @change_type@d"
+ ) | subst_vars
}
generate_email_footer()
{
- SPACE=" "
- cat <<-EOF
-
-
- hooks/post-receive
- --${SPACE}
- $projectdesc
- EOF
+ subst_vars "${emailfooter}"
}
# --------------- Branches
@@ -671,6 +695,22 @@ recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
+emailsubject=$(git config hooks.emailsubject || \
+ echo '@projectdesc@ @refname_type@, @short_refname@, @change_type@d. @describe@')
+emailbodyintro=$(git config hooks.emailbodyintro || cat <<-EOF
+ This is an automated email from the git hooks/post-receive script. It was
+ generated because a ref change was pushed to the repository containing
+ the project "@projectdesc@".
+ EOF
+)
+emailfooter=$(git config hooks.emailfooter || SPACE=" " cat <<-EOF
+
+
+ hooks/post-receive
+ --${SPACE}
+ @projectdesc@
+ EOF
+)
custom_showrev=$(git config hooks.showrev)
# --- Main loop
--
1.6.4
^ permalink raw reply related
* [PATCH-v2/RFC 6/6] t4015: add tests for trailing-space on incomplete line
From: Thell Fowler @ 2009-08-23 3:49 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1250999285-10683-1-git-send-email-git@tbfowler.name>
- Add 7 --no-index tests to t4015-diff-whitespace.sh to check
that ignore options work on incomplete lines.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
t/t4015-diff-whitespace.sh | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 6d13da3..193ddbe 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -395,4 +395,37 @@ test_expect_success 'combined diff with autocrlf conversion' '
'
+# Ignore trailing-space testing on incomplete lines.
+prepare_diff_file () {
+ printf "%s%$2s" foo "" >"$1"
+ if [ $3 = "+nl" ]
+ then
+ printf "\n" >>"$1"
+ fi
+}
+
+diff_trailing () {
+ foo="foo___"
+ prepare_diff_file "left" "$2" "$3"
+ lfoo=$( expr substr $foo 1 $((3+$2)) )
+ lfoo=${lfoo}"$3"
+
+ prepare_diff_file "right" "$4" "$5"
+ rfoo=$( expr substr $foo 1 $((3+$4)) )
+ rfoo=${rfoo}"$5"
+
+ label="-$1 $lfoo $rfoo"
+
+ test_expect_success "$label" \
+ "! git diff --no-index -$1 -- left right | grep -q foo"
+}
+
+diff_trailing w 0 +nl 1 -nl
+diff_trailing w 0 -nl 1 -nl
+diff_trailing b 0 +nl 0 -nl
+diff_trailing b 1 +nl 0 -nl
+diff_trailing b 1 -nl 0 -nl
+diff_trailing -ignore-space-at-eol 0 +nl 0 -nl
+diff_trailing -ignore-space-at-eol 2 +nl 2 -nl
+
test_done
--
1.6.4.176.g556a4
^ permalink raw reply related
* [PATCH-v2/RFC 2/6] xutils: fix hash with whitespace on incomplete line
From: Thell Fowler @ 2009-08-23 3:49 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1250999285-10683-1-git-send-email-git@tbfowler.name>
- Make xdl_hash_record_with_whitespace stop hashing before the
eof when ignoring space change or space at eol on an incomplete
line.
Resolves issue with a final trailing space being included in the
hash on an incomplete line by treating the eof in the same fashion
as a newline.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 04ad468..c6512a5 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -248,12 +248,12 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
if (flags & XDF_IGNORE_WHITESPACE)
; /* already handled */
else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
- && ptr[1] != '\n') {
+ && ptr[1] != '\n' && ptr + 1 < top) {
ha += (ha << 5);
ha ^= (unsigned long) ' ';
}
else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
- && ptr[1] != '\n') {
+ && ptr[1] != '\n' && ptr + 1 < top) {
while (ptr2 != ptr + 1) {
ha += (ha << 5);
ha ^= (unsigned long) *ptr2;
--
1.6.4.176.g556a4
^ permalink raw reply related
* [PATCH-v2/RFC 5/6] xutils: fix ignore-space-at-eol on incomplete line
From: Thell Fowler @ 2009-08-23 3:49 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1250999285-10683-1-git-send-email-git@tbfowler.name>
- Allow xdl_recmatch to process to the eof.
Resolves issue with --ignore-space-at-eol processing where an
incomplete line terminated processing early before a final check
could be done on the other side.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 54bb235..3e26488 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -229,7 +229,7 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
}
return (i1 >= s1 && i2 >= s2);
} else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
+ for (i1 = i2 = 0; i1 <= s1 && i2 <= s2; ) {
if (l1[i1] != l2[i2]) {
while (i1 < s1 && isspace(l1[i1]))
i1++;
--
1.6.4.176.g556a4
^ permalink raw reply related
* [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Thell Fowler @ 2009-08-23 3:49 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1250999285-10683-1-git-send-email-git@tbfowler.name>
- Allow xdl_recmatch to recognize and continue processing when
at the end of an incomplete line.
Resolves issue with --ignore-all-space when either side 1 or 2
has 0 trailing spaces and either (or both) are incomplete by
allowing the processing loop to continue when one side has
reached the end and includes a check for being at eof on an
incomplete line.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index c6512a5..e22b4bb 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -191,12 +191,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
int i1, i2;
if (flags & XDF_IGNORE_WHITESPACE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
+ for (i1 = i2 = 0; i1 < s1 || i2 < s2; ) {
if (isspace(l1[i1]))
- while (isspace(l1[i1]) && i1 < s1)
+ while ((isspace(l1[i1]) && i1 < s1)
+ || (i1 + 1 == s1 && l1[s1] != '\n'))
i1++;
if (isspace(l2[i2]))
- while (isspace(l2[i2]) && i2 < s2)
+ while ((isspace(l2[i2]) && i2 < s2)
+ || (i2 + 1 == s2 && l2[s2] != '\n'))
i2++;
if (i1 < s1 && i2 < s2 && l1[i1++] != l2[i2++])
return 0;
--
1.6.4.176.g556a4
^ permalink raw reply related
* [PATCH-v2/RFC 4/6] xutils: fix ignore-space-change on incomplete line
From: Thell Fowler @ 2009-08-23 3:49 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1250999285-10683-1-git-send-email-git@tbfowler.name>
- Allow xdl_recmatch to recognize and continue processing when at
the end of an incomplete line.
Resolves issue with --ignore-space-change when an incomplete line
terminated before the eol whitespace handling started by allowing
the processing loop to continue when one side has reached the end
and includes a check for being at the eol on an incomplete line.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 25 ++++++++++++++++++-------
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index e22b4bb..54bb235 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -205,16 +205,27 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
}
return (i1 >= s1 && i2 >= s2);
} else if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (isspace(l1[i1])) {
- if (!isspace(l2[i2]))
+ for (i1 = i2 = 0; i1 < s1 || i2 < s2;) {
+ if (isspace(l1[i1]) || i1 == s1) {
+ if (!isspace(l2[i2]) && i2 != s2 && l2[s2] != '\n')
return 0;
- while (isspace(l1[i1]) && i1 < s1)
+ while ((isspace(l1[i1]) && i1 < s1)
+ || (i1 + 1 == s1 && l1[s1] != '\n'))
i1++;
- while (isspace(l2[i2]) && i2 < s2)
+ while ((isspace(l2[i2]) && i2 < s2)
+ || (i2 + 1 == s2 && l2[s2] != '\n'))
i2++;
- } else if (l1[i1++] != l2[i2++])
- return 0;
+ } else {
+ if (l1[i1] != l2[i2] && ((i1 != s1 && l1[s1] != '\n')
+ || (i2 != s2 && l2[s2] != '\n')))
+ return 0;
+ else {
+ if (i1 < s1)
+ i1++;
+ if (i2 < s2)
+ i2++;
+ }
+ }
}
return (i1 >= s1 && i2 >= s2);
} else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
--
1.6.4.176.g556a4
^ permalink raw reply related
* [PATCH-v2/RFC 1/6] Add supplemental test for trailing-whitespace on incomplete lines
From: Thell Fowler @ 2009-08-23 3:49 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1250999285-10683-1-git-send-email-git@tbfowler.name>
*** For illustrative purposes only and not meant for upstream ***
- Adds a stand-alone test that loops through A-side B-side with
and without new-lines from 0 to 3 spaces per side.
This is a draft test meant to expose the issue with xutils.c
handling of incomplete lines and trailing-spaces.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
t/t4015-diff-trailing-whitespace.sh | 95 +++++++++++++++++++++++++++++++++++
1 files changed, 95 insertions(+), 0 deletions(-)
create mode 100755 t/t4015-diff-trailing-whitespace.sh
diff --git a/t/t4015-diff-trailing-whitespace.sh b/t/t4015-diff-trailing-whitespace.sh
new file mode 100755
index 0000000..079fba5
--- /dev/null
+++ b/t/t4015-diff-trailing-whitespace.sh
@@ -0,0 +1,95 @@
+#!/bin/sh
+
+test_description='Test trailing whitespace in diff engine.
+
+'
+. ./test-lib.sh
+. "$TEST_DIRECTORY"/diff-lib.sh
+
+# Trailing-space testing with and without newlines.
+prepare_diff_file () {
+ printf "%s%$2s" foo "" >"$1"
+ if [ $3 = "+nl" ]
+ then
+ printf "\n" >>"$1"
+ fi
+}
+
+diff_trailing () {
+ foo="foo___"
+ prepare_diff_file "left" "$2" "$3"
+ lfoo=$( expr substr $foo 1 $((3+$2)) )
+ lfoo=${lfoo}"$3"
+
+ prepare_diff_file "right" "$4" "$5"
+ rfoo=$( expr substr $foo 1 $((3+$4)) )
+ rfoo=${rfoo}"$5"
+
+ label="-$1 $lfoo $rfoo ($6)"
+
+ if [ "$6" != "should_diff" ]
+ then
+ negate='!'
+ else
+ negate=''
+ fi
+
+ if [ -z "$7" ]
+ then
+ test_expect_success "$label" \
+ "$negate git diff --no-index -$1 -- left right | grep -q foo"
+ else
+ test_expect_failure "$label" \
+ "$negate git diff --no-index -$1 -- left right | grep -q foo"
+ fi
+
+ test_debug "git diff --no-index -$1 -- left right | grep foo"
+}
+
+touch diffout
+for arg in -ignore-all-space -ignore-space-at-eol -ignore-space-change
+do
+ for i1 in 0 1 2 3
+ do
+ for i2 in 0 1 2 3
+ do
+ diff_trailing $arg $i1 +nl $i2 -nl should_not_diff >> diffout
+ diff_trailing $arg $i1 -nl $i2 +nl should_not_diff >> diffout
+
+ if [ $i1 -ne $i2 ]
+ then
+ diff_trailing $arg $i1 +nl $i2 +nl should_not_diff >> diffout
+ diff_trailing $arg $i1 -nl $i2 -nl should_not_diff >> diffout
+ fi
+ done
+ done
+done
+
+test_debug 'grep "FAIL" diffout'
+
+for arg in all eol change
+do
+ grep "FAIL" diffout | \
+ grep "$arg" | \
+ cut -d " " -f 4- | \
+
+ ## Playing with filtering to isolate core issue.
+ #sort -k 2,2 -k 3,3 | \
+ #awk '{ forward = $2 " " $3; reverse = $3 " " $2}
+ # !seen[forward]++ && !seen[reverse]++' | \
+ #sort -k 2,2 | \
+
+ ## Playing with filtering to isolate core issue.
+ ## This seems like the most illustrative output...
+ awk '{ key=$3 ; gsub(/-/, "+", key) ; key=$2 ":" key ; if ( hash[key]++ == 0 ) print ; }'
+
+ ## Playing with filtering to isolate core issue.
+ #awk '{ if ( $3 ~ /.*\-/ )
+ # print $0
+ # else
+ # print $1 " " $3 " " $2 " " $4
+ # ; }' | \
+ #sort -k 2,2 -k 3,3
+done
+
+test_done
--
1.6.4.176.g556a4
^ permalink raw reply related
* [PATCH-v2/RFC 0/6] improvements for trailing-space processing on incomplete lines
From: Thell Fowler @ 2009-08-23 3:47 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Thell Fowler
In-Reply-To: <1249428804.2774.52.camel@GWPortableVCS>
These patches are directly aimed at making it possible to validate the
results of git apply --whitespace=fix which is currently not possible
in files with incomplete lines in various situations (demonstrated in
the test in PATCH 1).
The goal is to be able to validate the application of a patch generated
from a dirty whitespace source to a clean target.
D2 C2
| \/ |
| /\ |
D1 C1
where D1..D2, C1..C2, C1..D2, D1..C2 should all yield the same patch-id
when passed a diff ignoring the applicable whitespace changes.
Applying these patches does nothing to fix the case of differences when
apply --whitespace=fix limits new blank lines at eof as can happen when
foo\r\n\r\n\r\n is fixed to foo\n\n.
Thell Fowler (6):
Add supplemental test for trailing-whitespace on incomplete lines
xutils: fix hash with whitespace on incomplete line
xutils: fix ignore-all-space on incomplete line
xutils: fix ignore-space-change on incomplete line
xutils: fix ignore-space-at-eol on incomplete line
t4015: add tests for trailing-space on incomplete line
t/t4015-diff-trailing-whitespace.sh | 95 +++++++++++++++++++++++++++++++++++
t/t4015-diff-whitespace.sh | 33 ++++++++++++
xdiff/xutils.c | 39 ++++++++++-----
3 files changed, 154 insertions(+), 13 deletions(-)
create mode 100755 t/t4015-diff-trailing-whitespace.sh
^ permalink raw reply
* Re: git svn pointing at svn branch instead of trunk?
From: Eric Wong @ 2009-08-23 2:51 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908221512v7d7af188h28d11a4bc8f092fc@mail.gmail.com>
skillzero@gmail.com wrote:
> On Sat, Aug 22, 2009 at 1:46 PM, Eric Wong<normalperson@yhbt.net> wrote:
>
> > So you have something like this?
> >
> > ----------trunk
> > \
> > \-> tag
> >
> > It looks like it's mixed but that's because trunk is an ancestor of your
> > tag, so the majority of commits (see git-svn-id:) look like they're from
> > trunk except the latest git-svn-id: which should have the URL of the tag
> > in it. So in short, everything here is OK.
>
> Yes, that's what I see: most of the commits have a /trunk URL except
> the last one has a /tags/TagX URL.
>
> When the next commit happens on master (I don't have svn commit access
> on the svn repo to try it myself), will git svn automatically track
> master->trunk again? Or is there something I need to change to tell it
> "master tracks svn's /trunk"? I normally do git svn fetch and git svn
> rebase (while on master, I do all my own commits on a separate
> branch).
You need to reset your master to trunk so it knows to track trunk
instead of tags/TagX
--
Eric Wong
^ permalink raw reply
* Re: [RFC] gitweb.perl t9500 t9501
From: Junio C Hamano @ 2009-08-23 2:09 UTC (permalink / raw)
To: Mark A Rada; +Cc: Jakub Narebski, git
In-Reply-To: <4C812C4E-815B-478D-AEB1-3F1DEC5D3641@mailservices.uwaterloo.ca>
Mark A Rada <marada@uwaterloo.ca> writes:
> I have not been telling git-format-patch to use a specific width for
> the diffstat, is the standard width supposed to be 70?
Perhaps there is some misconception here.
We try to keep our _code_ to fit in standard 80-column terminal. We also
keep lines in the _log message_ shorter than 70-something so that after
indentation by various programs (e.g. shortlog) and a few levels of
quoting in the e-mail are added, the lines will still stay below
80-columns. These are standard practices.
And you may need to find a good place to break lines in your _code_, and
your _log message_, to stay below that limit.
But that all happens inside your editor, before you touch format-patch nor
your MUA.
The patch contents may contain long lines, such as
diff --git a/filename-that-is-long b/filename-that-is-long
or
@@ -old,lines +new,lines @@ original contents that is long
that is neither _code_ nor _log message_. They could easily go beyond
80-column, but that is normal, and they do not have any 70-column limit
for you to worry about. They follow a different rule, namely, if
format-patch (or "diff" in general) outputs something on a single line,
that has to stay on a single line. "patch" expects each of these on a
single line. Do not break them.
So make sure that you do not let your MUA perform any line-wrapping at
random place in the message after you formatted your commits via
format-patch, and you will be Ok.
^ permalink raw reply
* Re: Further 'approxidate' improvements
From: Nicolas Pitre @ 2009-08-23 2:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0908221759420.3158@localhost.localdomain>
On Sat, 22 Aug 2009, Linus Torvalds wrote:
> So trying to date-parse nonsensical crud still gives odd results:
>
> I ate six hot-dogs in June -> Sat Jun 6 18:09:26 2009
>
> because it parses "six" and "June" and then puts it together as a date,
> and then adds the current time (and year) and is happy.
>
> But parsing random things amusingly is a _feature_. Misparsing something
> that makes sense as a date is a bug.
Maybe that would be a good idea to write a test just for this, so known
cases making sense aren't accidentally broken by eventual modifications
to add more such cases.
Nicolas
^ permalink raw reply
* Further 'approxidate' improvements
From: Linus Torvalds @ 2009-08-23 1:11 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0908221438450.3158@localhost.localdomain>
The previous patch to improve approxidate got us to the point that a lot
of the remaining annoyances were due to the 'strict' date handling running
first, and deciding that it got a good enough date that the approximate
date routines were never even invoked.
For example, using a date string like
6AM, June 7, 2009
the strict date logic would be perfectly happy with the "June 7, 2009"
part, and ignore the 6AM part that it didn't understand - resulting in the
information getting dropped on the floor:
6AM, June 7, 2009 -> Sat Jun 6 00:00:00 2009
and the date being calculated as if it was midnight, and the '6AM' having
confused the date routines into thinking about '6 June' rather than 'June
7' at 6AM (ie notice how the _day_ was wrong due to this, not just the
time).
So this makes the strict date routines a bit stricter, and requires that
not just the date, but also the time, has actually been parsed. With that
fix, and trivial extension of the approxidate routines, git now properly
parses the date as
6AM, June 7, 2009 -> Sun Jun 7 06:00:00 2009
without dropping the fuzzy time ("6AM" or "noon" or any of the other
non-strict time formats) on the floor.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
On Sat, 22 Aug 2009, Linus Torvalds wrote:
>
> There are other oddnesses. This does not fix them all, but I think it
> makes for fewer _really_ perplexing cases. At least now we have
>
> Jun 6, 5AM -> Sat Jun 6 05:00:00 2009
> 5AM, Jun 6 -> Sat Jun 6 05:00:00 2009
>
> which makes me happier. I can still point to cases that don't work as
> well, but those are separate issues.
This gets rid of the remaining "obviously bogus" issues with parsing of
fuzzy dates. I'm sure there are other issues still remaining, but now I
can't come up with any trivial cases any more without having clear
garbage in the string.
So trying to date-parse nonsensical crud still gives odd results:
I ate six hot-dogs in June -> Sat Jun 6 18:09:26 2009
because it parses "six" and "June" and then puts it together as a date,
and then adds the current time (and year) and is happy.
But parsing random things amusingly is a _feature_. Misparsing something
that makes sense as a date is a bug.
date.c | 32 +++++++++++++++++++++++++++-----
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/date.c b/date.c
index 51c6461..1de1845 100644
--- a/date.c
+++ b/date.c
@@ -24,6 +24,8 @@ time_t tm_to_time_t(const struct tm *tm)
return -1;
if (month < 2 || (year + 2) % 4)
day--;
+ if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_sec < 0)
+ return -1;
return (year * 365 + (year + 1) / 4 + mdays[month] + day) * 24*60*60UL +
tm->tm_hour * 60*60 + tm->tm_min * 60 + tm->tm_sec;
}
@@ -425,13 +427,19 @@ static int match_multi_number(unsigned long num, char c, const char *date, char
return end - date;
}
-/* Have we filled in any part of the time/date yet? */
+/*
+ * Have we filled in any part of the time/date yet?
+ * We just do a binary 'and' to see if the sign bit
+ * is set in all the values.
+ */
static inline int nodate(struct tm *tm)
{
- return tm->tm_year < 0 &&
- tm->tm_mon < 0 &&
- tm->tm_mday < 0 &&
- !(tm->tm_hour | tm->tm_min | tm->tm_sec);
+ return (tm->tm_year &
+ tm->tm_mon &
+ tm->tm_mday &
+ tm->tm_hour &
+ tm->tm_min &
+ tm->tm_sec) < 0;
}
/*
@@ -580,6 +588,9 @@ int parse_date(const char *date, char *result, int maxlen)
tm.tm_mon = -1;
tm.tm_mday = -1;
tm.tm_isdst = -1;
+ tm.tm_hour = -1;
+ tm.tm_min = -1;
+ tm.tm_sec = -1;
offset = -1;
tm_gmt = 0;
@@ -893,6 +904,17 @@ static void pending_number(struct tm *tm, int *num)
*num = 0;
if (tm->tm_mday < 0 && number < 32)
tm->tm_mday = number;
+ else if (tm->tm_mon < 0 && number < 13)
+ tm->tm_mon = number-1;
+ else if (tm->tm_year < 0) {
+ if (number > 1969 && number < 2100)
+ tm->tm_year = number - 1900;
+ else if (number > 69 && number < 100)
+ tm->tm_year = number;
+ else if (number < 38)
+ tm->tm_year = 100 + number;
+ /* We screw up for number = 00 ? */
+ }
}
}
^ permalink raw reply related
* Commit performance, or lack thereof
From: James Cloos @ 2009-08-22 23:42 UTC (permalink / raw)
To: git
Starting in the kernel tree, if one edits and adds a single file and
then commits it w/o specifying the file name as an argument to commit,
git uses 10 or so Megs of VM and one sees performace akin to this:
,----« gtime -v git commit -m 'make oldconfig' »
| [master 53d6af1] make oldconfig
| 1 files changed, 5 insertions(+), 2 deletions(-)
| Command being timed: "git commit -m make oldconfig"
| User time (seconds): 0.26
| System time (seconds): 1.06
| Percent of CPU this job got: 2%
| Elapsed (wall clock) time (h:mm:ss or m:ss): 0:47.04
| Average shared text size (kbytes): 0
| Average unshared data size (kbytes): 0
| Average stack size (kbytes): 0
| Average total size (kbytes): 0
| Maximum resident set size (kbytes): 0
| Average resident set size (kbytes): 0
| Major (requiring I/O) page faults: 86
| Minor (reclaiming a frame) page faults: 4703
| Voluntary context switches: 4805
| Involuntary context switches: 274
| Swaps: 0
| File system inputs: 48384
| File system outputs: 5680
| Socket messages sent: 0
| Socket messages received: 0
| Signals delivered: 0
| Page size (bytes): 4096
| Exit status: 0
`----
OTOH, if one does specify the filename as an argument to commit, git
uses almost 300 Megs of VM and the numbers look more like:
,----« gtime -v git commit -m 'make oldconfig' .config »
| [master 4db1e8b] make oldconfig
| 1 files changed, 1 insertions(+), 1 deletions(-)
| Command being timed: "git commit -m make oldconfig .config"
| User time (seconds): 1.82
| System time (seconds): 1.80
| Percent of CPU this job got: 3%
| Elapsed (wall clock) time (h:mm:ss or m:ss): 1:45.72
| Average shared text size (kbytes): 0
| Average unshared data size (kbytes): 0
| Average stack size (kbytes): 0
| Average total size (kbytes): 0
| Maximum resident set size (kbytes): 0
| Average resident set size (kbytes): 0
| Major (requiring I/O) page faults: 1609
| Minor (reclaiming a frame) page faults: 21363
| Voluntary context switches: 10707
| Involuntary context switches: 620
| Swaps: 0
| File system inputs: 361192
| File system outputs: 11296
| Socket messages sent: 0
| Socket messages received: 0
| Signals delivered: 0
| Page size (bytes): 4096
| Exit status: 0
`----
Git should be able to do the latter operation as efficiently as it can
do the former operation.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply
* Announcement: cvs2svn 2.3.0 released
From: Michael Haggerty @ 2009-08-22 22:44 UTC (permalink / raw)
To: announce; +Cc: Subversion Users, Git Mailing List, Bazaar
I am happy to announce release 2.3.0 of cvs2svn/cvs2git/cvs2bzr.
cvs2svn is a tool for migrating a CVS repository to Subversion, git,
Bazaar, or Mercurial. The main design goals are robustness and 100% data
preservation. cvs2svn can convert just about any CVS repository we've
ever seen, including gcc, Mozilla, FreeBSD, KDE, and GNOME.
Release 2.3.0 primarily improves the support for converting to git and
Bazaar (including explicit cvs2git and cvs2bzr scripts). This release
also adds a few other minor features and fixes a bug when converting to
git with non-inline blobs.
More detailed information is available in the CHANGES file [1].
Note to packagers: Beginning with this release, the man pages for the
main scripts are generated automatically by running the script with the
"--man" option (e.g., "cvs2svn --man >cvs2svn.1") or by executing "make
man". The tarball does *not* include the man pages anymore.
You can get the tarball here:
http://cvs2svn.tigris.org/files/documents/1462/46528/cvs2svn-2.3.0.tar.gz
The MD5 checksum is 6c412baec974f3ff64b9145944682a15.
Please send any bug reports and comments to users@cvs2svn.tigris.org.
Michael
[1]
http://cvs2svn.tigris.org/source/browse/cvs2svn/tags/2.3.0/CHANGES?view=markup
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1668&dsMessageId=2386391
To unsubscribe from this discussion, e-mail: [announce-unsubscribe@cvs2svn.tigris.org].
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2386392
To unsubscribe from this discussion, e-mail: [users-unsubscribe@cvs2svn.tigris.org].
^ 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