* Re: [PATCH] Fix regression in fast-import.c due to strbufs.
From: Pierre Habouzit @ 2007-10-29 6:29 UTC (permalink / raw)
To: Shun Kei Leung
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Git ML
In-Reply-To: <e66701d40710281959q517eabecm87bcf54c7fe47741@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
On Mon, Oct 29, 2007 at 02:59:02AM +0000, Shun Kei Leung wrote:
> Hi Pierre,
>
> Thanks. You are the man! It works perfectly now.
Actually, I also was the one breaking it in the first place, but
you're welcome :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-29 6:45 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071028111443.GA29183@xp.machine.xx>
On 10/28/07, Peter Baumann <waste.manager@gmx.de> wrote:
>
> Have a look at the subtree merge strategy [1] and at the following
> explanations how git-gui got initally merged.
>
> -Peter
>
> [1]: http://www.gelato.unsw.edu.au/archives/git/0702/40139.html
> [2]: http://www.gelato.unsw.edu.au/archives/git/0702/39661.html
>
>
When i merged git.git into git-gui with subtree strategy, I found all
histories of git.git merged into histories of git-gui (from 584
history entries to 11985). Is it possible that only histories related
to git-gui subdirectory in git.git(i.e. histories displayed by git-log
git-gui) are merged into?
1. my configuration:
~/git-gui$ git-remote show git
* remote git
URL: git://git.kernel.org/pub/scm/git/git.git
Tracked remote branches
master
~/git-gui$ git-remote show origin
* remote origin
URL: git://repo.or.cz/git-gui
Remote branch(es) merged with 'git pull' while on branch master
master
Tracked remote branches
master
~/git-gui$ gtlg --pretty=oneline --topo-order --first-parent | wc -l
584
2. pull with subtree strategy
~/git-gui$ git-pull -s subtree git master:master
3. after pull, all logs of git comes into git-gui (584->11985)
~/git-gui$ gtlg --pretty=oneline --topo-order | wc -l
11985
4. histories of git can be hiden by --first-parent
gtlg --pretty=oneline --topo-order --first-parent | wc -l
585
--
franky
^ permalink raw reply
* [PATCH] Fix a small memory leak in builtin-add
From: Benoit Sigoure @ 2007-10-29 7:00 UTC (permalink / raw)
To: git; +Cc: gitster, Benoit Sigoure
In-Reply-To: <1193641233-3880-1-git-send-email-tsuna@lrde.epita.fr>
prune_directory and fill_directory allocated one byte per pathspec and never
freed it.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
I don't know whether this was intentionnal or not (since it's only a matter of
having small chunks of memory not being reclaimed and I don't think we can
enter these functions twice, so these are not leaks in the sense that the
program will consume more and more memory). But if it was intentionnal,
wouldn't it be better to put a small comment in the code saying so (so that
casual readers like me won't get surprised).
builtin-add.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index f9a6580..b8e6094 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -44,6 +44,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
die("pathspec '%s' did not match any files",
pathspec[i]);
}
+ free(seen);
}
static void fill_directory(struct dir_struct *dir, const char **pathspec,
@@ -135,6 +136,7 @@ static void refresh(int verbose, const char **pathspec)
if (!seen[i])
die("pathspec '%s' did not match any files", pathspec[i]);
}
+ free(seen);
}
static int git_add_config(const char *var, const char *value)
--
1.5.3.4.398.g859b
^ permalink raw reply related
* [PATCH] core-tutorial: Catch up with current Git
From: Benoit Sigoure @ 2007-10-29 7:00 UTC (permalink / raw)
To: git; +Cc: gitster, Benoit Sigoure
No longer talk about Cogito since it's deprecated. Some scripts (such as
git-reset or git-branch) have undergone builtinification so adjust the text
to reflect this.
Fix a typo in the description of git-show-branch (merges are indicated by a
`-', not by a `.').
git-pull/git-push do not seem to use the dumb git-ssh-fetch/git-ssh-upload
(the text was probably missing a word).
Adjust a link that wasn't rendered properly because it was wrapped.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
I intentionally modified the text the least possible.
Documentation/core-tutorial.txt | 26 ++++++++++----------------
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 6b2590d..d8e78ac 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -553,13 +553,8 @@ can explore on your own.
[NOTE]
Most likely, you are not directly using the core
-git Plumbing commands, but using Porcelain like Cogito on top
-of it. Cogito works a bit differently and you usually do not
-have to run `git-update-index` yourself for changed files (you
-do tell underlying git about additions and removals via
-`cg-add` and `cg-rm` commands). Just before you make a commit
-with `cg-commit`, Cogito figures out which files you modified,
-and runs `git-update-index` on them for you.
+git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
+and `git-commit'.
Tagging a version
@@ -686,8 +681,8 @@ $ git reset
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
-at what the various git scripts do. For example, `git reset` is the
-above two lines implemented in `git-reset`, but some things like
+at what the various git scripts do. For example, `git reset` used to be
+the above two lines implemented in `git-reset`, but some things like
`git status` and `git commit` are slightly more complex scripts around
the basic git commands.
@@ -805,8 +800,8 @@ you have, you can say
$ git branch
------------
-which is nothing more than a simple script around `ls .git/refs/heads`.
-There will be asterisk in front of the branch you are currently on.
+which used to be nothing more than a simple script around `ls .git/refs/heads`.
+There will be an asterisk in front of the branch you are currently on.
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
@@ -952,7 +947,7 @@ the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. Three commits are shown along with their log messages.
All of them have non blank characters in the first column (`*`
-shows an ordinary commit on the current branch, `.` is a merge commit), which
+shows an ordinary commit on the current branch, `-` is a merge commit), which
means they are now part of the `master` branch. Only the "Some
work" commit has the plus `+` character in the second column,
because `mybranch` has not been merged to incorporate these
@@ -1086,7 +1081,7 @@ to help dumb transport downloaders.
There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
programs, which are 'commit walkers'; they outlived their
usefulness when git Native and SSH transports were introduced,
-and not used by `git pull` or `git push` scripts.
+and are not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
@@ -1193,7 +1188,7 @@ $ mb=$(git-merge-base HEAD mybranch)
The command writes the commit object name of the common ancestor
to the standard output, so we captured its output to a variable,
-because we will be using it in the next step. BTW, the common
+because we will be using it in the next step. By the way, the common
ancestor commit is the "New day." commit in this case. You can
tell it by:
@@ -1459,8 +1454,7 @@ Although git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
-link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf
-[Randy Dunlap's presentation].
+link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
It should be stressed that this hierarchy is purely *informal*.
There is nothing fundamental in git that enforces the "chain of
--
1.5.3.4.398.g859b
^ permalink raw reply related
* Re: How to remove a specific hunk
From: Miles Bader @ 2007-10-29 7:03 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Pascal Obry, git
In-Reply-To: <20071026164926.GA21160@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> BTW, since this is inherently a non-git operation, there are other tools
> that some may find friendlier than an editor. Kompare will let you
> unapply differences, for example, and I would be shocked if emacs didn't
> have some tool for this.
M-x diff-mode
<move to bad hunk>
C-u C-c C-a
-Miles
--
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page
^ permalink raw reply
* Re: [BUG?] git-pull and git-merge don't support option --ff as the document says
From: Lars Hjemli @ 2007-10-29 7:14 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710280936g4b1022fcpab02e72b99afa0f@mail.gmail.com>
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).
--
larsh
^ permalink raw reply
* [PATCH] Speedup scanning for excluded files.
From: Lars Knoll @ 2007-10-29 7:45 UTC (permalink / raw)
To: git
Try to avoid a lot of work while 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.
---
I did a short timing measurement on the git repository itself, the timings
without and with the patch give:
[lars@dahab git (speedup)]$ time git runstatus > /dev/null
real 0m0.098s
user 0m0.068s
sys 0m0.020s
[lars@dahab git (speedup)]$ time ./git runstatus > /dev/null
real 0m0.033s
user 0m0.012s
sys 0m0.016s
Cheers,
Lars
dir.c | 58 ++++++++++++++++++++++++++++++++++++++++++----------------
dir.h | 7 +++++++
2 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/dir.c b/dir.c
index 4c17d36..7bb5add 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 !strchr(string, '*') && !strchr(string, '?')
&& !strchr(string, '[') && !strchr(string, '{');
+}
+
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,10 +265,15 @@ static int excluded_1(const char *pathname,
strncmp(pathname, x->base, baselen))
continue;
- if (fnmatch(exclude, pathname+baselen,
- FNM_PATHNAME) == 0)
+ 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;
- }
+ }
+ }
}
}
return -1; /* undecided */
@@ -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..4dc3c6e 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
* Re: [PATCH] Speedup scanning for excluded files.
From: Pierre Habouzit @ 2007-10-29 8:02 UTC (permalink / raw)
To: Lars Knoll; +Cc: git
In-Reply-To: <200710290845.26727.lars@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Mon, Oct 29, 2007 at 07:45:26AM +0000, Lars Knoll wrote:
> +static int no_wildcard(const char *string)
> +{
> + return !strchr(string, '*') && !strchr(string, '?')
> && !strchr(string, '[') && !strchr(string, '{');
return string[strcspn(string, "*?[{")] == '\0';
is faster as it doesn't scan the string 4 time in the case where there
is no wildcard.
> +}
> +
> 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;
You used spaces in here, and in many places of your patch.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 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
* [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: [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
* 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 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: [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
* 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 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
* 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: 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: 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: 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: 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: 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: 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: 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: [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
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