* Re: [PATCH] Speedup scanning for excluded files.
From: Junio C Hamano @ 2007-10-30 0:00 UTC (permalink / raw)
To: Morten Welinder; +Cc: Lars Knoll, git, Pierre Habouzit, Junio C Hamano
In-Reply-To: <118833cc0710291559kbd874a8o8111b9495090ef27@mail.gmail.com>
"Morten Welinder" <mwelinder@gmail.com> writes:
>> + } else if (x->flags & EXC_FLAG_ENDSWITH) {
>> + if (!strcmp(exclude + 1, pathname + pathlen -x->patternlen + 1))
>
> Is there some guarantee that the result of that subtraction is still within
> the string?
Good eyes.
If pattern is "*.exe", patternlen is 5, and strcmp wants to
compare 4 chars, so pathlen is better be at least that long, and
we do allow that pattern to match a hidden file ".exe".
Like this?
if (x->patternlen - 1 <= pathlen &&
!strcmp(exclude + 1, pathname + pathlen - x->patternlen + 1))
return to_exclude;
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-29 23:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Jan Hudec, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710291545250.30120@woody.linux-foundation.org>
Hi,
On Mon, 29 Oct 2007, Linus Torvalds wrote:
> And "standards" are only as good as they are useful. XML is a piece of
> crap despite being a standard because it makes no sense.
To be fair, there are uses for XML. On Halloween, for example.
Sorry, could not resist,
Dscho
^ permalink raw reply
* [PATCH 2/2] add throughput display to index-pack
From: Nicolas Pitre @ 2007-10-29 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
... and call it "Receiving objects" when over stdin to look clearer
to end users.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/index-pack.c b/index-pack.c
index 2f149a4..d32c7b9 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -87,6 +87,8 @@ static void *fill(int min)
die("early EOF");
die("read error on input: %s", strerror(errno));
}
+ if (verbose && from_stdin)
+ display_throughput(&progress, ret);
input_len += ret;
} while (input_len < min);
return input_buffer;
@@ -406,7 +408,9 @@ static void parse_pack_objects(unsigned char *sha1)
* - remember base (SHA1 or offset) for all deltas.
*/
if (verbose)
- start_progress(&progress, "Indexing objects", nr_objects);
+ start_progress(&progress,
+ from_stdin ? "Receiving objects" : "Indexing objects",
+ nr_objects);
for (i = 0; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
data = unpack_raw_entry(obj, &delta->base);
^ permalink raw reply related
* [PATCH 1/2] add throughput to progress display
From: Nicolas Pitre @ 2007-10-29 23:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This adds the ability for the progress code to also display throughput
when that makes sense.
The math was inspired by commit c548cf4ee0737a321ffe94f6a97c65baf87281be
from Linus.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/progress.c b/progress.c
index 7629e05..275579b 100644
--- a/progress.c
+++ b/progress.c
@@ -37,7 +37,7 @@ static void clear_progress_signal(void)
static int display(struct progress *progress, unsigned n, int done)
{
- char *eol;
+ char *eol, *tp;
if (progress->delay) {
if (!progress_update || --progress->delay)
@@ -55,18 +55,20 @@ static int display(struct progress *progress, unsigned n, int done)
}
progress->last_value = n;
+ tp = (progress->throughput) ? progress->throughput->display : "";
eol = done ? ", done. \n" : " \r";
if (progress->total) {
unsigned percent = n * 100 / progress->total;
if (percent != progress->last_percent || progress_update) {
progress->last_percent = percent;
- fprintf(stderr, "%s: %3u%% (%u/%u)%s", progress->title,
- percent, n, progress->total, eol);
+ fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
+ progress->title, percent, n,
+ progress->total, tp, eol);
progress_update = 0;
return 1;
}
} else if (progress_update) {
- fprintf(stderr, "%s: %u%s", progress->title, n, eol);
+ fprintf(stderr, "%s: %u%s%s", progress->title, n, tp, eol);
progress_update = 0;
return 1;
}
@@ -74,6 +76,59 @@ static int display(struct progress *progress, unsigned n, int done)
return 0;
}
+void display_throughput(struct progress *progress, unsigned long n)
+{
+ struct throughput *tp = progress->throughput;
+ struct timeval tv;
+ unsigned int misecs;
+
+ gettimeofday(&tv, NULL);
+
+ if (!tp) {
+ progress->throughput = tp = calloc(1, sizeof(*tp));
+ if (tp)
+ tp->prev_tv = tv;
+ return;
+ }
+
+ tp->count += n;
+
+ /*
+ * We have x = bytes and y = microsecs. We want z = KiB/s:
+ *
+ * z = (x / 1024) / (y / 1000000)
+ * z = x / y * 1000000 / 1024
+ * z = x / (y * 1024 / 1000000)
+ * z = x / y'
+ *
+ * To simplify things we'll keep track of misecs, or 1024th of a sec
+ * obtained with:
+ *
+ * y' = y * 1024 / 1000000
+ *
+ * Taking care not to overflow y' we get:
+ *
+ * y' = y / (1000000 / 1024)
+ * y' = y / 977
+ */
+ misecs = (tv.tv_sec - tp->prev_tv.tv_sec) * 1024;
+ misecs += (int)(tv.tv_usec - tp->prev_tv.tv_usec) / 977;
+
+ if (misecs > 512) {
+ tp->prev_tv = tv;
+ tp->avg_bytes += tp->count;
+ tp->avg_misecs += misecs;
+ snprintf(tp->display, sizeof(tp->display),
+ ", %lu KiB/s", tp->avg_bytes / tp->avg_misecs);
+ tp->avg_bytes -= tp->last_bytes[tp->idx];
+ tp->avg_misecs -= tp->last_misecs[tp->idx];
+ tp->last_bytes[tp->idx] = tp->count;
+ tp->last_misecs[tp->idx] = misecs;
+ tp->idx = (tp->idx + 1) % TP_IDX_MAX;
+ tp->count = 0;
+ }
+}
+
int display_progress(struct progress *progress, unsigned n)
{
return display(progress, n, 0);
@@ -104,4 +159,6 @@ void stop_progress(struct progress *progress)
display(progress, progress->last_value, 1);
}
clear_progress_signal();
+ free(progress->throughput);
+ progress->throughput = NULL;
}
diff --git a/progress.h b/progress.h
index 07b56bd..eba457f 100644
--- a/progress.h
+++ b/progress.h
@@ -1,6 +1,21 @@
#ifndef PROGRESS_H
#define PROGRESS_H
+#include <sys/time.h>
+
+#define TP_IDX_MAX 8
+
+struct throughput {
+ struct timeval prev_tv;
+ unsigned long count;
+ unsigned long avg_bytes;
+ unsigned long last_bytes[TP_IDX_MAX];
+ unsigned int avg_misecs;
+ unsigned int last_misecs[TP_IDX_MAX];
+ unsigned int idx;
+ char display[20];
+};
+
struct progress {
const char *title;
int last_value;
@@ -8,8 +23,10 @@ struct progress {
unsigned last_percent;
unsigned delay;
unsigned delayed_percent_treshold;
+ struct throughput *throughput;
};
+void display_throughput(struct progress *progress, unsigned long n);
int display_progress(struct progress *progress, unsigned n);
void start_progress(struct progress *progress, const char *title,
unsigned total);
^ permalink raw reply related
* Re: [PATCH] Speedup scanning for excluded files.
From: Morten Welinder @ 2007-10-29 22:59 UTC (permalink / raw)
To: Lars Knoll; +Cc: git, Pierre Habouzit, Junio C Hamano
In-Reply-To: <200710290959.32538.lars@trolltech.com>
> + } else if (x->flags & EXC_FLAG_ENDSWITH) {
> + if (!strcmp(exclude + 1, pathname + pathlen -x->patternlen + 1))
Is there some guarantee that the result of that subtraction is still within
the string?
Morten
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-29 22:57 UTC (permalink / raw)
To: Theodore Tso
Cc: Jan Hudec, Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi,
git
In-Reply-To: <20071029214925.GH21133@thunk.org>
On Mon, 29 Oct 2007, Theodore Tso wrote:
>
> Well, the confusion is that we refer to things that look like
> "git://git.kernel.org/pub/scm/git/git.git" as if it were a URL.
Sure, but "URL" in human-speak has nothing to do with an RFC.
I dislike language-lawyerese. Why the hell do people think that human
language should follow the RFC's?
Git addresses look like URL's, and they act like URL's, but dammit, git
isn't a web browser, and it's not interested in acting like one.
And "standards" are only as good as they are useful. XML is a piece of
crap despite being a standard because it makes no sense. Similarly, "URL
quoting" is a piece of crap when _it_ makes no sense. Having a RFC or an
ISO standard doesn't change anything, and doesn't imply that human
communication (or indeed, even machine communication) should care.
Linus
^ permalink raw reply
* Re: [PATCH] Speedup scanning for excluded files.
From: Junio C Hamano @ 2007-10-29 22:17 UTC (permalink / raw)
To: Lars Knoll; +Cc: git, Pierre Habouzit
In-Reply-To: <200710290959.32538.lars@trolltech.com>
Thanks. This looks obviously correct and tempts me to apply
directly to 'master'.
There are similar logic on the gitattributes side (attr.c) which
might benefit from such an optimization as well. In the longer
run, we might even want to introduce 'ignored' attribute to the
gitattributes mechanism and make the unified result to supersede
gitignore.
^ permalink raw reply
* Re: remote#branch
From: Theodore Tso @ 2007-10-29 21:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Hudec, Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi,
git
In-Reply-To: <alpine.LFD.0.999.0710291112590.30120@woody.linux-foundation.org>
On Mon, Oct 29, 2007 at 11:17:12AM -0700, Linus Torvalds wrote:
> Git remote names already aren't "url"s in the http sense.
>
> We say "master:some.host/file/goes here/without/any/stupid/web-escapes"
> for the ssh names, and the same goes for "file:///name here" etc.
>
> People who think that git URL's are web-pages had better wake up and smell
> the coffee. They aren't. They never were. They never *should* be.
Well, the confusion is that we refer to things that look like
"git://git.kernel.org/pub/scm/git/git.git" as if it were a URL. In
fact, you did so yourself in the last paragraph above. "People who
think that git URL's".... but in fact, whether or not Universal
Resource Locators (URL's) in the RFC 3986 sense requires quoting
doesn't matter whether or not they are web pages or not. If they are
formal URL's in the sense of RFC 3986, it doesn't matter whether they
are http URL's, or ldap URL's, or telephone URL's, etc. they are
supposed to be quoted whether or not they appear in a web form or not.
The whole point of URL's is that they are *uniform*.
So what that means is the much more correct statement is:
"People who think the names that people specify that to git, which
sometimes include names that look very much like URL's, especially
when they begin 'git://' or 'http://', and they think they are really
RFC 3986 URL's had better wake up and smell the coffee. They aren't.
They never were. The they never *should* be.
The best that we can say given existing usage is that what git accepts
is a superset of what is allowable by RFC 3986 syntactically, and that
git in general doesn't do any URL-style quoting, even when given a
name that looks syntactically like a http-style URL that begins
'http://'."
What this means in practice though is that people would be well
advised not to pick locator names (NOT URL's) that contain characters
that normally would require escaping by RFC 3986 rules, since the
inconsistency of whether tools that expect URL-style quoting rules
will probably cause user and tools confusion. Hence, it would
probably be a bad idea to place a directory pathname that included the
'#' character on a web server and expect that resulting git:// and
http:// names generated by an Apache web server and gitweb scripts to
do sane things, not to mention direct access via git:// names used
when you do a "git push" to said respository. Sometimes the name will
require RFC 3968 quoting, and sometimes it may not be quoted using RFC
3968 rules, depending on which tool you are using.
I do agree that the Cogito '#' notation makes things worse, not
better, because it encourages a bigger separation between the RFC 3986
rules, and what the git tool accepts in practice --- which are not
URL's, no matter how much some of our git-style names superficially
look like URL's.
- Ted
^ permalink raw reply
* Re: [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Junio C Hamano @ 2007-10-29 21:17 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193628652-15647-1-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> Git had previously been using the $PATH for scripts--a previous
> patch moved exec'ed commands to also use the $PATH. For consistency
> "help -a" should also list commands in the $PATH.
>
> The main commands are still listed from the git_exec_path(), but
> the $PATH is walked and other git commands (probably extensions) are
> listed.
>
> Signed-off-by: Scott R Parish <srp@srparish.net>
> ---
> help.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++---------------
> 1 files changed, 120 insertions(+), 37 deletions(-)
Thanks.
It's easier to read if you briefly describe the differences
between the replacement patch and the previous version of the
patch below the three-dash lines. See for example Lars Knoll's
patch from today <200710290959.32538.lars@trolltech.com>.
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-29 18:32 UTC (permalink / raw)
To: Jan Hudec; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071029174000.GA4449@efreet.light.src>
Hi,
On Mon, 29 Oct 2007, Jan Hudec wrote:
> On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:
>
> > On Sat, 27 Oct 2007, Jan Hudec wrote:
> >
> > > On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
> > >
> > > > ',' is allowed in ref names, so ',' is out.
> > >
> > > Actually since many characters that are allowed in ref name are not
> > > allowed in URL at all, the ref-name has to be url-escaped. Which
> > > brings all characters back in, because they can always be specified
> > > escaped.
> >
> > No. The URL part of it has to be encoded. But the ref names do
> > _not_. (If we really want to have a way to specify the remote URL and
> > the branch(es) we want to fetch _at the same time_.)
>
> If the branch names are not url-escaped, than the result is not an URL.
> Which is just ugly and confusing. If it looks like an URL, it should
> better be one.
So all you're saying is: it is not possible.
Well, discussion ended, I guess.
Ciao,
Dscho
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-29 18:17 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071029174000.GA4449@efreet.light.src>
On Mon, 29 Oct 2007, Jan Hudec wrote:
>
> If the branch names are not url-escaped, than the result is not an URL. Which
> is just ugly and confusing. If it looks like an URL, it should better be one.
Git remote names already aren't "url"s in the http sense.
We say "master:some.host/file/goes here/without/any/stupid/web-escapes"
for the ssh names, and the same goes for "file:///name here" etc.
People who think that git URL's are web-pages had better wake up and smell
the coffee. They aren't. They never were. They never *should* be.
This whole argument is idiotic. The #branch format was a mistake of
cogito. Cogito is dead. Get over it already.
We have a format already, and it has nothing to do with '#' or any idiotic
web escape, or anything else.
Linus
^ permalink raw reply
* Re: remote#branch
From: Jan Hudec @ 2007-10-29 17:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710280000240.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
On Sun, Oct 28, 2007 at 00:01:57 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 27 Oct 2007, Jan Hudec wrote:
>
> > On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
> >
> > > ',' is allowed in ref names, so ',' is out.
> >
> > Actually since many characters that are allowed in ref name are not
> > allowed in URL at all, the ref-name has to be url-escaped. Which brings
> > all characters back in, because they can always be specified escaped.
>
> No. The URL part of it has to be encoded. But the ref names do _not_.
> (If we really want to have a way to specify the remote URL and the
> branch(es) we want to fetch _at the same time_.)
If the branch names are not url-escaped, than the result is not an URL. Which
is just ugly and confusing. If it looks like an URL, it should better be one.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: stg branch --create test v2.6.24-rc1 doesn't work
From: Catalin Marinas @ 2007-10-29 17:11 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: kha, Git Mailing List
In-Reply-To: <cc723f590710260342t5fd0bdc3nc1ea5198cea1a604@mail.gmail.com>
On 26/10/2007, Aneesh Kumar <aneesh.kumar@gmail.com> wrote:
> $ stg branch --create test v2.6.24-rc1
> Checking for changes in the working directory ... done
> Don't know how to determine parent branch from "v2.6.24-rc1"
> Branch "test" created
> [test@linux-review-ext]$ git log
>
>
> Throws an error/warning in the above command.
>
> Also import then gives
>
> [test@linux-review-ext]$ stg import
> /home/opensource/patches/ext4-patch-queue/ext4_mballoc_freespace_accounting_fix.patch
> Checking for changes in the working directory ... done
> fatal: cebdeed27b068dcc3e7c311d7ec0d9c33b5138c2 is not a valid 'commit' object
> stg import: git-commit-tree failed with code 128
What version of StGIT are you using?
You could try 'stg branch --create test v2.6.24-rc1^{commit} but I
thought latest StGIT adds this by default.
--
Catalin
^ permalink raw reply
* Re: stgit restrictions on patch names
From: Catalin Marinas @ 2007-10-29 16:14 UTC (permalink / raw)
To: Yann Dirson; +Cc: Karl Hasselström, GIT list
In-Reply-To: <20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net>
On 25/10/2007, Yann Dirson <ydirson@altern.org> wrote:
> Looks like stgit is now more picky on patch names than in used to be:
It's not that we explicitly disallows "+" but I think I tried to avoid
some wrong patch names but was too lazy to create a better regexp.
As a quick fix, we could re-generate a patch name if it is invalid.
> => the result of the cloning operation is a partial clone. Do we want to:
>
> - implement a mechanism for checking beforehand that the operation
> will not fail ? Seems awkward to duplicate checks already found
> elsewhere.
>
> - wait for proper transactions so we can rollback on error ?
>
> - on clone error, delete the newly-created stack ? I'd vote for this
> one, until the previous one gets done.
I think the last one is the simplest to implement, while the second is
nicer, I've never found the time to investigate it properly.
--
Catalin
^ permalink raw reply
* Re: Bug in git-show with "%ai" and "%ci" formats?
From: Wincent Colaiuta @ 2007-10-29 14:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710291331310.4362@racer.site>
El 29/10/2007, a las 14:32, Johannes Schindelin escribió:
> On Mon, 29 Oct 2007, Wincent Colaiuta wrote:
>
>> Can anybody reproduce the following behaviour? Basically all the
>> author and
>> committer date formats documented in the git-show man page work
>> except for
>> "%ai" and "%ci". This is with Git 1.5.2.4 running on Darwin 9.0.0:
>
> It was added in v1.5.3-rc2~17.
>
> Usually, it is a good idea to use the documentation which
> corresponds with
> the git version you are using ;-)
Doh... funny... This was only yesterday; I installed 1.5.2.4
(stupidly, a typo) and the 1.5.3.4 man pages. If I'd just done a "git
stash" or something I would've realized that I was using an older
version...
Cheers,
Wincent
^ permalink raw reply
* Re: New features in gitk
From: Michele Ballabio @ 2007-10-29 14:04 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <18211.59478.188419.397886@cargo.ozlabs.ibm.com>
On Sunday 28 October 2007, Paul Mackerras wrote:
> * Gitk now uses a new graph layout algorithm, which means it doesn't
> have to generate the whole layout from top to bottom at startup
> time, making startup faster.
This is probably causing gitk to eat my (admittedly old) CPU, sometimes.
For example, a
gitk --all v1.5.2..v1.5.3
gives me problems when I scroll down to about half of the shown history:
that is when I reach the sequence of hundreds of "merge topic branch
into next" commits, and gitk tries hard to display the graph as best
as it can.
It can become unresponsive for one second at every PgDown.
Otherwise, gitk is way faster in other (non-pathological)
circumstances.
^ permalink raw reply
* Re: New features in gitk
From: Han-Wen Nienhuys @ 2007-10-29 13:30 UTC (permalink / raw)
To: git
In-Reply-To: <18211.59478.188419.397886@cargo.ozlabs.ibm.com>
Paul Mackerras escreveu:
> I just pulled the dev branch of gitk into the master branch, so the
> master branch now has the new features and improvements that I have
> been working on, namely:
>
> * The find and highlight functions have been combined into a single
sound extremely cool; I didn't know someone was working on it actively.
Can I misuse this thread to bring a ancient bug under your attention?
It is affecting me regularly; see here for the report:
http://article.gmane.org/gmane.comp.version-control.git/48789
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Bug in git-show with "%ai" and "%ci" formats?
From: Johannes Schindelin @ 2007-10-29 13:32 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <4A647262-B69A-4DB6-942C-18C45458B169@wincent.com>
Hi,
On Mon, 29 Oct 2007, Wincent Colaiuta wrote:
> Can anybody reproduce the following behaviour? Basically all the author and
> committer date formats documented in the git-show man page work except for
> "%ai" and "%ci". This is with Git 1.5.2.4 running on Darwin 9.0.0:
It was added in v1.5.3-rc2~17.
Usually, it is a good idea to use the documentation which corresponds with
the git version you are using ;-)
Hth,
Dscho
^ permalink raw reply
* Bug in git-show with "%ai" and "%ci" formats?
From: Wincent Colaiuta @ 2007-10-29 13:18 UTC (permalink / raw)
To: Git Mailing List
Can anybody reproduce the following behaviour? Basically all the
author and committer date formats documented in the git-show man page
work except for "%ai" and "%ci". This is with Git 1.5.2.4 running on
Darwin 9.0.0:
$ git show -s --pretty=format:"%ad"
Sun Oct 28 20:58:39 2007 +0100
$ git show -s --pretty=format:"%aD"
Sun, 28 Oct 2007 20:58:39 +0100
$ git show -s --pretty=format:"%ar"
17 hours ago
$ git show -s --pretty=format:"%at"
1193601519
$ git show -s --pretty=format:"%ai"
%ai
$ git show -s --pretty=format:"%cd"
Sun Oct 28 20:58:39 2007 +0100
$ git show -s --pretty=format:"%cD"
Sun, 28 Oct 2007 20:58:39 +0100
$ git show -s --pretty=format:"%cr"
17 hours ago
$ git show -s --pretty=format:"%ct"
1193601519
$ git show -s --pretty=format:"%ci"
%ci
Cheers,
Wincent
^ permalink raw reply
* Re: [BUG?] git-pull and git-merge don't support option --ff as the document says
From: Yin Ping @ 2007-10-29 13:05 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580710290014o5750214te5b20eaf6127de9c@mail.gmail.com>
On 10/29/07, Lars Hjemli <hjemli@gmail.com> wrote:
> On 10/28/07, Yin Ping <pkufranky@gmail.com> wrote:
> > Released git version 1.5.3.4
>
> --ff/--no-ff is not part of any released git version; you'll need to
> build the 'master' branch of git.git. And they're currently only
> supported by git-merge, not git-pull (the same goes for --no-squash).
see, 3x
--
franky
^ permalink raw reply
* Re: [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: David Symonds @ 2007-10-29 11:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, git
In-Reply-To: <Pine.LNX.4.64.0710291129250.4362@racer.site>
On 10/29/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sun, 28 Oct 2007, Scott Parish wrote:
>
> > I was thinking set operations when i named this (hense "a" and "b"),
> > but i'll try this out.
>
> Yes, I guessed that. But in that case, "subtract" is actively wrong,
> since you cannot guarantee (and indeed do not want to assume) that one is
> the subset of the other.
The nearest set theory operation would be "difference" (or
"complement"); that does not require that the subtrahend is a subset
of the minuend.
Dave.
^ permalink raw reply
* Re: [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Johannes Schindelin @ 2007-10-29 11:30 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071029024431.GA12459@srparish.net>
Hi,
On Sun, 28 Oct 2007, Scott Parish wrote:
> On Sun, Oct 28, 2007 at 04:51:00PM +0000, Johannes Schindelin wrote:
>
> > > +static void subtract_cmds(struct cmdnames *a, struct cmdnames *b) {
> >
> > Maybe "exclude_cmds()", and choose more suggestive names for the
> > parameters?
>
> I was thinking set operations when i named this (hense "a" and "b"),
> but i'll try this out.
Yes, I guessed that. But in that case, "subtract" is actively wrong,
since you cannot guarantee (and indeed do not want to assume) that one is
the subset of the other.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Speedup scanning for excluded files.
From: Lars Knoll @ 2007-10-29 8:59 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Junio C Hamano
In-Reply-To: <20071029080234.GA22826@artemis.corp>
>From 51b364c9c87bec89556a2089cc5363c588ea2ff5 Mon Sep 17 00:00:00 2001
From: Lars Knoll <lars@trolltech.com>
Date: Sun, 28 Oct 2007 21:27:13 +0100
Subject: [PATCH] Speedup scanning for excluded files.
Try to avoid a lot of work scanning for excluded files,
by caching some more information when setting up the exclusion
data structure.
Speeds up 'git runstatus' on a repository containing the Qt sources by 30% and
reduces the amount of instructions executed (as measured by valgrind) by a
factor of 2.
---
Fixed both the indentation and the no_wildcard method as Pierre pointed out.
Lars
dir.c | 60 +++++++++++++++++++++++++++++++++++++++++++-----------------
dir.h | 7 +++++++
2 files changed, 50 insertions(+), 17 deletions(-)
diff --git a/dir.c b/dir.c
index 4c17d36..f4e130c 100644
--- a/dir.c
+++ b/dir.c
@@ -118,14 +118,32 @@ int match_pathspec(const char **pathspec, const char *name, int namelen, int pre
return retval;
}
+static int no_wildcard(const char *string)
+{
+ return string[strcspn(string, "*?[{")] == '\0';
+}
+
void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which)
{
struct exclude *x = xmalloc(sizeof (*x));
+ x->to_exclude = 1;
+ if (*string == '!') {
+ x->to_exclude = 0;
+ string++;
+ }
x->pattern = string;
+ x->patternlen = strlen(string);
x->base = base;
x->baselen = baselen;
+ x->flags = 0;
+ if (!strchr(string, '/'))
+ x->flags |= EXC_FLAG_NODIR;
+ if (no_wildcard(string))
+ x->flags |= EXC_FLAG_NOWILDCARD;
+ if (*string == '*' && no_wildcard(string+1))
+ x->flags |= EXC_FLAG_ENDSWITH;
if (which->nr == which->alloc) {
which->alloc = alloc_nr(which->alloc);
which->excludes = xrealloc(which->excludes,
@@ -209,7 +227,7 @@ void pop_exclude_per_directory(struct dir_struct *dir, int stk)
* Return 1 for exclude, 0 for include and -1 for undecided.
*/
static int excluded_1(const char *pathname,
- int pathlen,
+ int pathlen, const char *basename,
struct exclude_list *el)
{
int i;
@@ -218,19 +236,20 @@ static int excluded_1(const char *pathname,
for (i = el->nr - 1; 0 <= i; i--) {
struct exclude *x = el->excludes[i];
const char *exclude = x->pattern;
- int to_exclude = 1;
+ int to_exclude = x->to_exclude;
- if (*exclude == '!') {
- to_exclude = 0;
- exclude++;
- }
-
- if (!strchr(exclude, '/')) {
+ if (x->flags & EXC_FLAG_NODIR) {
/* match basename */
- const char *basename = strrchr(pathname, '/');
- basename = (basename) ? basename+1 : pathname;
- if (fnmatch(exclude, basename, 0) == 0)
- return to_exclude;
+ if (x->flags & EXC_FLAG_NOWILDCARD) {
+ if (!strcmp(exclude, basename))
+ return to_exclude;
+ } else if (x->flags & EXC_FLAG_ENDSWITH) {
+ if (!strcmp(exclude + 1, pathname + pathlen -x->patternlen + 1))
+ return to_exclude;
+ } else {
+ if (fnmatch(exclude, basename, 0) == 0)
+ return to_exclude;
+ }
}
else {
/* match with FNM_PATHNAME:
@@ -246,9 +265,14 @@ static int excluded_1(const char *pathname,
strncmp(pathname, x->base, baselen))
continue;
- if (fnmatch(exclude, pathname+baselen,
- FNM_PATHNAME) == 0)
- return to_exclude;
+ if (x->flags & EXC_FLAG_NOWILDCARD) {
+ if (!strcmp(exclude, pathname + baselen))
+ return to_exclude;
+ } else {
+ if (fnmatch(exclude, pathname+baselen,
+ FNM_PATHNAME) == 0)
+ return to_exclude;
+ }
}
}
}
@@ -259,9 +283,11 @@ int excluded(struct dir_struct *dir, const char *pathname)
{
int pathlen = strlen(pathname);
int st;
-
+ const char *basename = strrchr(pathname, '/');
+ basename = (basename) ? basename+1 : pathname;
+
for (st = EXC_CMDL; st <= EXC_FILE; st++) {
- switch (excluded_1(pathname, pathlen, &dir->exclude_list[st])) {
+ switch (excluded_1(pathname, pathlen, basename, &dir->exclude_list[st])) {
case 0:
return 0;
case 1:
diff --git a/dir.h b/dir.h
index a248a23..3ce8dbe 100644
--- a/dir.h
+++ b/dir.h
@@ -17,13 +17,20 @@ struct dir_entry {
char name[FLEX_ARRAY]; /* more */
};
+#define EXC_FLAG_NODIR 1
+#define EXC_FLAG_NOWILDCARD 2
+#define EXC_FLAG_ENDSWITH 4
+
struct exclude_list {
int nr;
int alloc;
struct exclude {
const char *pattern;
+ int patternlen;
const char *base;
int baselen;
+ int to_exclude;
+ int flags;
} **excludes;
};
--
1.5.3.4.383.gd90a7
^ permalink raw reply related
* [PATCH] Teach git-pull about --[no-]ff, --no-squash and --commit
From: Lars Hjemli @ 2007-10-29 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These options are supported by git-merge, but git-pull didn't know about
them.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-pull.sh | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 74bfc16..39e5222 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -4,7 +4,7 @@
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
-USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
+USAGE='[-n | --no-summary] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s strategy]... [<fetch-options>] <repo> <head>...'
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -27,8 +27,16 @@ do
;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=--no-commit ;;
+ --c|--co|--com|--comm|--commi|--commit)
+ no_commit=--commit ;;
--sq|--squ|--squa|--squas|--squash)
squash=--squash ;;
+ --no-sq|--no-squ|--no-squa|--no-squas|--no-squash)
+ squash=--no-squash ;;
+ --ff)
+ no_ff=--ff ;;
+ --no-ff)
+ no_ff=--no-ff ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -133,5 +141,5 @@ then
fi
merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-exec git-merge $no_summary $no_commit $squash $strategy_args \
+exec git-merge $no_summary $no_commit $squash $no_ff $strategy_args \
"$merge_name" HEAD $merge_head
--
1.5.3.4.1404.g65af
^ permalink raw reply related
* Re: New features in gitk
From: Jonathan del Strother @ 2007-10-29 8:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Paul Mackerras, git
In-Reply-To: <20071029062000.GB4310@artemis.corp>
On 29 Oct 2007, at 06:20, Pierre Habouzit wrote:
> On Sun, Oct 28, 2007 at 11:13:43PM +0000, Paul Mackerras wrote:
>>> * the 'sha1' input field is a major pain in the UI: the cut&paste
>>> interaction is very poor. I don't know why, but it's often
>>> very very
>>> hard to really copy the sha id, probably because it's
>>> selected by
>>> default.
>>
>> It's selected so that the contents are in the cut buffer and you can
>> paste them in an xterm with middle-button. Possibly I need to check
>> that control-C (or command-C under macos) is properly bound to copy.
>
> Well, doing ^C doesn't always copy it (probably a glitch wrt which
> input has the focus), and it certainly doesn't synchronize with the
> cut
> buffer for me. And it doesn't work for anyone at work either. I use
> ion
> with the KDE clipboard manager (klipper -- because I never managed to
> find a clipboard manager that is as good yet, not depending upon KDE),
> and at work most people use KDE, with the same klipper. Maybe it's
> a bad
> interaction, I should try to use it under gnome or so to see if it is.
>
FWIW, I have exactly the same problem under OS X. I've never figured
out a pattern that gives a guaranteed copy - I'll try playing around
today and see what I can find.
Actually, while I'm here, gitk semi-regularly ignores ⌘Q, which
ought to quit on OS X.
^ 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