* Re: hitting home directory's parent
From: Daniel Convissor @ 2009-08-22 15:05 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <fcaeb9bf0908212110o5ed1233ek11183fa37b474a06@mail.gmail.com>
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 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.
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: Nguyen Thai Ngoc Duy @ 2009-08-22 16:20 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20090822150542.GA29507@panix.com>
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
But did it at least change the error message? Here is what I got when
"chmod 000 /tmp/a":
/tmp/a/b/c $ cd ../..
bash: cd: ../..: Permission denied
/tmp/a/b/c $ git --help
fatal: Cannot change to '/tmp/a/b/c/..': Permission denied
/tmp/a/b/c $ GIT_CEILING_DIRECTORIES=/tmp/a/b git --help
fatal: Cannot come back to cwd: Permission denied
Looks like absolute path will cause troubles anyway this case.
> 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.
--
Duy
^ permalink raw reply
* Re: hitting home directory's parent
From: Nguyen Thai Ngoc Duy @ 2009-08-22 16:22 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0908220920g29ec24e9v23d0504d10ca6cfb@mail.gmail.com>
On Sat, Aug 22, 2009 at 11:20 PM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> But did it at least change the error message? Here is what I got when
> "chmod 000 /tmp/a":
>
> /tmp/a/b/c $ cd ../..
> bash: cd: ../..: Permission denied
> /tmp/a/b/c $ git --help
> fatal: Cannot change to '/tmp/a/b/c/..': Permission denied
> /tmp/a/b/c $ GIT_CEILING_DIRECTORIES=/tmp/a/b git --help
> fatal: Cannot come back to cwd: Permission denied
Note: I tested it on Linux, not Cygwin so the behavior may differ.
--
Duy
^ permalink raw reply
* Re: hitting home directory's parent
From: Jeff King @ 2009-08-22 18:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Daniel Convissor, Git Mailing List
In-Reply-To: <fcaeb9bf0908220920g29ec24e9v23d0504d10ca6cfb@mail.gmail.com>
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().
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.
-Peff
^ permalink raw reply
* git svn pointing at svn branch instead of trunk?
From: skillzero @ 2009-08-22 18:40 UTC (permalink / raw)
To: git
When I used git svn to clone a repository, it ended up pointing master
at a tag in svn instead of trunk. For example, git svn info shows the
URL for the tag instead of trunk. git log master also shows the most
recent commit is the creation of that tag in svn, but then the next
commit is the most recent commit to trunk. It's like it's mixing
things from the tag with things from trunk. The most recent commit in
svn was to create the tag that master is now pointing to in case that
matters.
Is there something in the svn repository that might cause this? What's
the correct way to reset what git svn thinks master should point to?
And how should I get rid of the commit on master that created the tag
without messing up git svn (e.g. can I just git reset or will that
confuse git svn later?).
^ permalink raw reply
* Re: [PATCH v3 1/9] sequencer: add "do_fast_forward()" to perform a fast forward
From: Junio C Hamano @ 2009-08-22 20:15 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <200908221319.37737.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
>> Hmm, forgot to amend, or perhaps you sent out a wrong series?
>
> Your comments on the v2 series were in a message replying to patch 5/9, so I
> amended only 5/9 and after it, because I thought that you had already
> reviewed those before 5/9 and they were ok.
Sorry, but in general I expect readers of this list to be intelligent
enough and capable of extrapolating, so that I do not have to spell out
the same issue over and over again ;-)
> As you merged the series in pu, I thought that it was ok.
Heh, being queued to 'pu' does not mean any more than just that we do not
want to lose what the author spent efforts to produce, and we want to give
reviewers easier access to the end result. If it is Ok, it would have
been in 'next'.
That's why topics initially queued in 'pu' sometimes move to 'stalled'
state in "What's in" report and then eventually get ejected.
The comment you added only says what it does, namely, that it does two
different things, based on the allow_dirty global variable that is
underdocumented. It does not explain _why_ it is a good thing, in what
circumstance the caller would want "almost" semantics and in what other
circumstance the caller would want a "real" hard reset.
>> I am afraid that the whole cc/sequencer-rebase-i series needs a serious
>> reroll before it gets near 'next'.
>
> Ok, I will reroll everything to try to improve commit messages.
It would be a good idea; it may expose a wrong abstraction or an
insufficient refactoring (e.g. adding yet another function to make a
commit object that runs parallel to what we already have).
Thanks.
^ permalink raw reply
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
From: Nicholas A. Bellinger @ 2009-08-22 20:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, J.H., H. Peter Anvin
In-Reply-To: <m3fxbkn5ot.fsf@localhost.localdomain>
Greetings Jakub,
On Fri, 2009-08-21 at 15:49 -0700, Jakub Narebski wrote:
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
>
> > I have recently been trying to make a tag and branch of the same name
>
> But why? Why do you want to confuse git and yourself?
>
I stumbled the strangeness in k.o gitweb due to my inexperience with git
tagging+branch.. I absoulutely agree that it makes more sense to use
different names for these, and that is what I am doing from now on.. :-)
> > from a previous <COMMIT> on a master branch on a kernel.org tree using
> > the following commands:
> >
> > # Create the tag:
> > git tag -a lio-x.y <COMMIT>
> > # Push the tags:
> > git push --tags origin
> > # Fetch to be sure
> > git fetch origin
> > # Make tagged branch:
> > git checkout -b lio-x.y <COMMIT>
> > # Make <NEW_COMMIT> to lio-x.y and commit
> > git commit frob
> > # Switch back to master branch
> > git checkout master
> > # Push local branch to origin
> > git push origin refs/heads/lio-x.y
> >
> > At this point after pushing to origin, I can do a fresh clone of the
> > tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
> > and the logs and blobs look as expected..
> >
> > However, after checking gitweb log for branch lio-x.y on kernel.org, I
> > only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
> > lio-x.y still reference the original <COMMIT>, et al.
>
> I guess that you meant here gitweb's 'log' / 'shortlog' view linked
> from 'heads' view, don't you?
That is correct..
>
> > John Hawley has been helping to resolve the issue (I am just going to
> > use different tag/branch names instead), and hpa asked me to report this
> > as it is easy to reproduce with the gitweb version on kernel.org..
>
> > 22:42 < warthog9> I would got show this to the git people, it *could*
> > just be an old bug in gitweb (ours is not particularly
> > up to date) but if I can replicate it here easily enough
> > I'm guessing there's still a bug elsewhere
>
> This is an old and long fixed (or rather worked around) issue in
> gitweb, fixed in bf901f8 (gitweb: disambiguate heads and tags withs
> the same name, 2007-12-15)... well if by fixed you can consider
> passing around "fully qualified" refnames, i.e. the 'shortlog' link in
> 'heads' view now uses 'refs/heads/frob', and not only 'frob'.
>
Cool, I am hear it has already been fixed.
--nab
^ permalink raw reply
* Re: What's a good setup for submitting patches to the list properly?
From: Christian Couder @ 2009-08-22 20:20 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Julian Phillips
In-Reply-To: <alpine.DEB.2.00.0908220953460.2012@GWPortableVCS>
On Saturday 22 August 2009, Thell Fowler wrote:
>
> > What could I have done/checked before sending to make sure that these
> > would have posted properly?
Perhaps you could send them to yourself.
> No input on this? Perhaps I should've posted to the git user or alpine
> lists?
It's ok to post this kind of questions on the git mailing list.
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!
Regards,
Christian.
^ permalink raw reply
* Re: git svn pointing at svn branch instead of trunk?
From: Eric Wong @ 2009-08-22 20:46 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908221140p532a3c29k90af7b4cbd25d65e@mail.gmail.com>
skillzero@gmail.com wrote:
> When I used git svn to clone a repository, it ended up pointing master
> at a tag in svn instead of trunk. For example, git svn info shows the
> URL for the tag instead of trunk. git log master also shows the most
> recent commit is the creation of that tag in svn, but then the next
> commit is the most recent commit to trunk. It's like it's mixing
> things from the tag with things from trunk. The most recent commit in
> svn was to create the tag that master is now pointing to in case that
> matters.
Hi,
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.
> Is there something in the svn repository that might cause this? What's
> the correct way to reset what git svn thinks master should point to?
> And how should I get rid of the commit on master that created the tag
> without messing up git svn (e.g. can I just git reset or will that
> confuse git svn later?).
I changed this recently in b186a261b1f7ec1fbda8c5f6d84595f3a7716d92
git svn used to always pick the newest change in the entire SVN repo
to point master to, now it'll attempt to find "trunk" to be master.
You can git reset anything on your master without affecting git svn.
If you have commits on master, just cherry pick them to a new branch
that's based off trunk and then reset master to be that new branch.
--
Eric Wong
^ permalink raw reply
* git-mail-commits (Re: What's a good setup for submitting patches to the list properly?)
From: Nicolas Sebrecht @ 2009-08-22 20:56 UTC (permalink / raw)
To: Christian Couder; +Cc: Thell Fowler, git, Julian Phillips
In-Reply-To: <200908222220.35354.chriscool@tuxfamily.org>
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?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: What's a good setup for submitting patches to the list properly?
From: Thell Fowler @ 2009-08-22 20:58 UTC (permalink / raw)
To: Christian Couder; +Cc: Thell Fowler, git, Julian Phillips
In-Reply-To: <200908222220.35354.chriscool@tuxfamily.org>
Christian Couder (chriscool@tuxfamily.org) wrote on Aug 22, 2009:
> On Saturday 22 August 2009, Thell Fowler wrote:
> >
> > > What could I have done/checked before sending to make sure that these
> > > would have posted properly?
>
> Perhaps you could send them to yourself.
>
Yes, I did. They all showed up under the correct thread, but then I
changed how I did it by adding cover-letter to the format-patch options.
BTW - After looking at the headers it looks like the cover letter header
worked just fine, but that the cover letter msg-id changed between when
format-patch created it and when it was sent out causing the reset of the
msgs to not have anything to reference to.
> > No input on this? Perhaps I should've posted to the git user or alpine
> > lists?
>
> It's ok to post this kind of questions on the git mailing list.
>
> 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!
>
I guess I'll setup smtp and try the send-email route, not sure if that
is going to change anything having to do with the In-Reply-To field
and a cover letter or how it shows in the threading.
If that doesn't work then I'll give Julian's mail-commits a whirl.
Thanks for replying Christian!
--
Thell
^ permalink raw reply
* Improve on 'approxidate'
From: Linus Torvalds @ 2009-08-22 22:10 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
This is not a new failure mode - approxidate has always been kind of
random in the input it accepts, but some of the randomness is more
irritating than others.
For example:
Jun 6, 5AM -> Mon Jun 22 05:00:00 2009
5AM Jun 6 -> Sat Jun 6 05:00:00 2009
Whaa? The reason for the above is that approxidate squirrells away the '6'
from "Jun 6" to see if it's going to be a relative number, and then
forgets about it when it sees a new number (the '5' in '5AM'). So the odd
"June 22" date is because today is July 22nd, and if it doesn't have
another day of the month, it will just pick todays mday - having ignored
the '6' entirely due to getting all excited about seeing a new number (5).
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
date.c | 93 +++++++++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 63 insertions(+), 30 deletions(-)
diff --git a/date.c b/date.c
index 409a17d..51c6461 100644
--- a/date.c
+++ b/date.c
@@ -525,11 +525,8 @@ static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt
}
}
- if (num > 0 && num < 32) {
- tm->tm_mday = num;
- } else if (num > 0 && num < 13) {
+ if (num > 0 && num < 13 && tm->tm_mon < 0)
tm->tm_mon = num-1;
- }
return n;
}
@@ -657,42 +654,59 @@ void datestamp(char *buf, int bufsize)
date_string(now, offset, buf, bufsize);
}
-static void update_tm(struct tm *tm, unsigned long sec)
+/*
+ * Relative time update (eg "2 days ago"). If we haven't set the time
+ * yet, we need to set it from current time.
+ */
+static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)
{
- time_t n = mktime(tm) - sec;
+ time_t n;
+
+ if (tm->tm_mday < 0)
+ tm->tm_mday = now->tm_mday;
+ if (tm->tm_mon < 0)
+ tm->tm_mon = now->tm_mon;
+ if (tm->tm_year < 0) {
+ tm->tm_year = now->tm_year;
+ if (tm->tm_mon > now->tm_mon)
+ tm->tm_year--;
+ }
+
+ n = mktime(tm) - sec;
localtime_r(&n, tm);
+ return n;
}
-static void date_yesterday(struct tm *tm, int *num)
+static void date_yesterday(struct tm *tm, struct tm *now, int *num)
{
- update_tm(tm, 24*60*60);
+ update_tm(tm, now, 24*60*60);
}
-static void date_time(struct tm *tm, int hour)
+static void date_time(struct tm *tm, struct tm *now, int hour)
{
if (tm->tm_hour < hour)
- date_yesterday(tm, NULL);
+ date_yesterday(tm, now, NULL);
tm->tm_hour = hour;
tm->tm_min = 0;
tm->tm_sec = 0;
}
-static void date_midnight(struct tm *tm, int *num)
+static void date_midnight(struct tm *tm, struct tm *now, int *num)
{
- date_time(tm, 0);
+ date_time(tm, now, 0);
}
-static void date_noon(struct tm *tm, int *num)
+static void date_noon(struct tm *tm, struct tm *now, int *num)
{
- date_time(tm, 12);
+ date_time(tm, now, 12);
}
-static void date_tea(struct tm *tm, int *num)
+static void date_tea(struct tm *tm, struct tm *now, int *num)
{
- date_time(tm, 17);
+ date_time(tm, now, 17);
}
-static void date_pm(struct tm *tm, int *num)
+static void date_pm(struct tm *tm, struct tm *now, int *num)
{
int hour, n = *num;
*num = 0;
@@ -706,7 +720,7 @@ static void date_pm(struct tm *tm, int *num)
tm->tm_hour = (hour % 12) + 12;
}
-static void date_am(struct tm *tm, int *num)
+static void date_am(struct tm *tm, struct tm *now, int *num)
{
int hour, n = *num;
*num = 0;
@@ -720,7 +734,7 @@ static void date_am(struct tm *tm, int *num)
tm->tm_hour = (hour % 12);
}
-static void date_never(struct tm *tm, int *num)
+static void date_never(struct tm *tm, struct tm *now, int *num)
{
time_t n = 0;
localtime_r(&n, tm);
@@ -728,7 +742,7 @@ static void date_never(struct tm *tm, int *num)
static const struct special {
const char *name;
- void (*fn)(struct tm *, int *);
+ void (*fn)(struct tm *, struct tm *, int *);
} special[] = {
{ "yesterday", date_yesterday },
{ "noon", date_noon },
@@ -757,7 +771,7 @@ static const struct typelen {
{ NULL }
};
-static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
+static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm *now, int *num)
{
const struct typelen *tl;
const struct special *s;
@@ -778,7 +792,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
for (s = special; s->name; s++) {
int len = strlen(s->name);
if (match_string(date, s->name) == len) {
- s->fn(tm, num);
+ s->fn(tm, now, num);
return end;
}
}
@@ -800,7 +814,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
while (tl->type) {
int len = strlen(tl->type);
if (match_string(date, tl->type) >= len-1) {
- update_tm(tm, tl->length * *num);
+ update_tm(tm, now, tl->length * *num);
*num = 0;
return end;
}
@@ -818,7 +832,7 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
n++;
diff += 7*n;
- update_tm(tm, diff * 24 * 60 * 60);
+ update_tm(tm, now, diff * 24 * 60 * 60);
return end;
}
}
@@ -866,6 +880,22 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
+/*
+ * Do we have a pending number at the end, or when
+ * we see a new one? Let's assume it's a month day,
+ * as in "Dec 6, 1992"
+ */
+static void pending_number(struct tm *tm, int *num)
+{
+ int number = *num;
+
+ if (number) {
+ *num = 0;
+ if (tm->tm_mday < 0 && number < 32)
+ tm->tm_mday = number;
+ }
+}
+
unsigned long approxidate(const char *date)
{
int number = 0;
@@ -881,21 +911,24 @@ unsigned long approxidate(const char *date)
time_sec = tv.tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
+
+ tm.tm_year = -1;
+ tm.tm_mon = -1;
+ tm.tm_mday = -1;
+
for (;;) {
unsigned char c = *date;
if (!c)
break;
date++;
if (isdigit(c)) {
+ pending_number(&tm, &number);
date = approxidate_digit(date-1, &tm, &number);
continue;
}
if (isalpha(c))
- date = approxidate_alpha(date-1, &tm, &number);
+ date = approxidate_alpha(date-1, &tm, &now, &number);
}
- if (number > 0 && number < 32)
- tm.tm_mday = number;
- if (tm.tm_mon > now.tm_mon && tm.tm_year == now.tm_year)
- tm.tm_year--;
- return mktime(&tm);
+ pending_number(&tm, &number);
+ return update_tm(&tm, &now, 0);
}
^ permalink raw reply related
* Re: git svn pointing at svn branch instead of trunk?
From: skillzero @ 2009-08-22 22:12 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090822204627.GA22484@dcvr.yhbt.net>
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).
> I changed this recently in b186a261b1f7ec1fbda8c5f6d84595f3a7716d92
> git svn used to always pick the newest change in the entire SVN repo
> to point master to, now it'll attempt to find "trunk" to be master.
Thanks, I'll build that and try it out. That sounds like what was confusing me.
^ permalink raw reply
* [RFC] gitweb.perl t9500 t9501
From: Mark A Rada @ 2009-08-22 22:42 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <7vfxbldj31.fsf@alter.siamese.dyndns.org>
Ok, I have a few questions, please:
> Word-wrapped.
I have not been telling git-format-patch to use a specific width for
the diffstat, is the
standard width supposed to be 70? Also, you will note a line in the
patch below
that will definitely be broken, it looks like
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-
standalone-no-errors.sh
I don't see an option for git-format-patch to get around that in the
man page,
how would I fix that?
> I do not mind keeping these two lines as belt-and-suspender, though.
That is a vivid analogy...I will have to remember that one for later.
I tried switching the order of the last two checks, and I think it
makes that unused
check more useful, it can inform clients they are trying something
that has been
explicitly disabled as opposed to just notifying them the format is
unsupported.
Do you think making the change is worthwhile? (new commit? rewinding?)
(The patch at the bottom currently assumes you have switched them
already.)
another snippet:
@@ -5175,10 +5175,10 @@ sub git_snapshot {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @snapshot_fmts)) {
- die_error(403, "Unsupported snapshot format");
} elsif ($known_snapshot_formats{$format}{'disabled'}) {
die_error(403, "Snapshot format not allowed");
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
+ die_error(403, "Unsupported snapshot format");
}
if (!defined $hash) {
>> A trick: use '\EOF' and you don't need to escape $ against variable
>> expansion by shell.
> It is not a "trick" but is a basic courtesy for reviewers. Even if
> you do
> not have any $ to worry about, _unless_ you actively know you would
> want
> variable substitution to happen, it is easier for readers if you
> signal
> the fact that the here-doc is verbatim by quoting the \EOF marker
> upfront.
Thanks for the protip, I've taken the liberty of making use of it for
gitweb-lib.sh,
I hope you don't mind, Jakub.
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
---
t/gitweb-lib.sh | 74 +++++++++++++++++++
t/t9500-gitweb-standalone-no-errors.sh | 68 +-----------------
t/t9501-gitweb-standalone-http-status.sh | 78 ++++++++++++++++++++
3 files changed, 153 insertions(+), 67 deletions(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
new file mode 100644
index 0000000..4f4115f
--- /dev/null
+++ b/t/gitweb-lib.sh
@@ -0,0 +1,74 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Jakub Narebski
+#
+
+
+gitweb_init () {
+ safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
+ cat >gitweb_config.perl <<EOF
+#!/usr/bin/perl
+
+# gitweb configuration for tests
+
+our \$version = 'current';
+our \$GIT = 'git';
+our \$projectroot = "$safe_pwd";
+our \$project_maxdepth = 8;
+our \$home_link_str = 'projects';
+our \$site_name = '[localhost]';
+our \$site_header = '';
+our \$site_footer = '';
+our \$home_text = 'indextext.html';
+our @stylesheets = ('file:///$TEST_DIRECTORY/../gitweb/gitweb.css');
+our \$logo = 'file:///$TEST_DIRECTORY/../gitweb/git-logo.png';
+our \$favicon = 'file:///$TEST_DIRECTORY/../gitweb/git-favicon.png';
+our \$projects_list = '';
+our \$export_ok = '';
+our \$strict_export = '';
+
+EOF
+
+ cat >.git/description <<EOF
+$0 test repository
+EOF
+}
+
+gitweb_run () {
+ GATEWAY_INTERFACE='CGI/1.1'
+ HTTP_ACCEPT='*/*'
+ REQUEST_METHOD='GET'
+ SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
+ QUERY_STRING=""$1""
+ PATH_INFO=""$2""
+ export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
+ SCRIPT_NAME QUERY_STRING PATH_INFO
+
+ GITWEB_CONFIG=$(pwd)/gitweb_config.perl
+ export GITWEB_CONFIG
+
+ # some of git commands write to STDERR on error, but this is not
+ # written to web server logs, so we are not interested in that:
+ # we are interested only in properly formatted errors/warnings
+ rm -f gitweb.log &&
+ perl -- "$SCRIPT_NAME" \
+ >gitweb.output 2>gitweb.log &&
+ if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
+
+ # gitweb.log is left for debugging
+ # gitweb.output is used to parse http output
+}
+
+. ./test-lib.sh
+
+if ! test_have_prereq PERL; then
+ say 'skipping gitweb tests, perl not available'
+ test_done
+fi
+
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1
|| {
+ say 'skipping gitweb tests, perl version is too old'
+ test_done
+}
+
+gitweb_init
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-
standalone-no-errors.sh
index 6275181..32e47d3 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -9,73 +9,7 @@ This test runs gitweb (git web interface) as CGI
script from
commandline, and checks that it would not write any errors
or warnings to log.'
-gitweb_init () {
- safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
- cat >gitweb_config.perl <<EOF
-#!/usr/bin/perl
-
-# gitweb configuration for tests
-
-our \$version = "current";
-our \$GIT = "git";
-our \$projectroot = "$safe_pwd";
-our \$project_maxdepth = 8;
-our \$home_link_str = "projects";
-our \$site_name = "[localhost]";
-our \$site_header = "";
-our \$site_footer = "";
-our \$home_text = "indextext.html";
-our @stylesheets = ("file:///$TEST_DIRECTORY/../gitweb/gitweb.css");
-our \$logo = "file:///$TEST_DIRECTORY/../gitweb/git-logo.png";
-our \$favicon = "file:///$TEST_DIRECTORY/../gitweb/git-favicon.png";
-our \$projects_list = "";
-our \$export_ok = "";
-our \$strict_export = "";
-
-EOF
-
- cat >.git/description <<EOF
-$0 test repository
-EOF
-}
-
-gitweb_run () {
- GATEWAY_INTERFACE="CGI/1.1"
- HTTP_ACCEPT="*/*"
- REQUEST_METHOD="GET"
- SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
- QUERY_STRING=""$1""
- PATH_INFO=""$2""
- export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
- SCRIPT_NAME QUERY_STRING PATH_INFO
-
- GITWEB_CONFIG=$(pwd)/gitweb_config.perl
- export GITWEB_CONFIG
-
- # some of git commands write to STDERR on error, but this is not
- # written to web server logs, so we are not interested in that:
- # we are interested only in properly formatted errors/warnings
- rm -f gitweb.log &&
- perl -- "$SCRIPT_NAME" \
- >/dev/null 2>gitweb.log &&
- if grep "^[[]" gitweb.log >/dev/null 2>&1; then false; else true; fi
-
- # gitweb.log is left for debugging
-}
-
-. ./test-lib.sh
-
-if ! test_have_prereq PERL; then
- say 'skipping gitweb tests, perl not available'
- test_done
-fi
-
-perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1
|| {
- say 'skipping gitweb tests, perl version is too old'
- test_done
-}
-
-gitweb_init
+. ./gitweb-lib.sh
#
----------------------------------------------------------------------
# no commits (empty, just initialized repository)
diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-
standalone-http-status.sh
new file mode 100644
index 0000000..be042f0
--- /dev/null
+++ b/t/t9501-gitweb-standalone-http-status.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Mark Rada
+#
+
+
+test_description='gitweb as standalone script (http status tests).
+
+This test runs gitweb (git web interface) as CGI script from the
+commandline, and checks that it returns the appropriate http status
+code and message.'
+
+. ./gitweb-lib.sh
+
+#
----------------------------------------------------------------------
+# snapshot settings
+
+test_commit \
+ 'GITWEB' \
+ 'I CAN HAS SNAPSHOT?'
+
+cat >>gitweb_config.perl <<\EOF
+$feature{'snapshot'}{'override'} = 0;
+EOF
+
+test_expect_success \
+ 'snapshots: tgz only default format enabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
+ grep "403 - Unsupported snapshot format" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
+ grep "403 - Snapshot format not allowed" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "403 - Unsupported snapshot format" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$feature{'snapshot'}{'default'} = ['tgz','tbz2','txz','zip'];
+EOF
+
+test_expect_success \
+ 'snapshots: all enabled in default, use default disabled value' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
+ grep "403 - Snapshot format not allowed" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$known_snapshot_formats{'zip'}{'disabled'} = 1;
+EOF
+
+test_expect_success \
+ 'snapshots: zip explicitly disabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "403 - Snapshot format not allowed" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$known_snapshot_formats{'tgz'}{'disabled'} = 0;
+EOF
+
+test_expect_success \
+ 'snapshots: tgz explicitly enabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+test_done
--
1.6.4
^ permalink raw reply related
* 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
* 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
* 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
* 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
* 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: 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
* [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
* [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 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 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 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
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