* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-10-30 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxztm2dx.fsf@gitster.siamese.dyndns.org>
On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> git push now allows you pushing a couple of branches that have
>> advanced, while ignoring all branches that have no local changes,
>> but are lagging behind their matching remote refs. This is done
>> without reporting errors.
>>
>> Thanks to Junio C. Hamano <gitster@pobox.com> for suggesting to
>> report in the summary that refs have been ignored.
>
> I do not think this is a good idea at all. Furthermore, I never
> suggested anything about summary.
Yeah, sorry. You only asked if the summary does mention
something; not suggesting it should do so.
> You are robbing the
> information from the pusher which ones are pushed and which ones
> are left behind.
Absolutely; because the branches left behind are not
interesting. The remote already is ahead of the local
branches. The local branches are just left were they are. They
have no new information on them. Forcing an push would _rewind_
the remote without adding anything to it.
If you really intended to do a rewind you should have passed
'--force' in the first place and my report would never be
printed.
> It simply is insane to make this strange rule 10/10 introduces
> the default behaviour. It is too specific to a particular
> workflow (that is, working with a shared central repository,
> having many locally tracking branches that are not often used
> and become stale, and working on only things to completion
> between pushes).
I don't think its very strange behaviour if you see it in the
light of what the user wants to achieve. We are talking about
the case were only fast forward pushes are allowed. So, we
only talk about a push that has the goal of adding new local
changes to the remote. The user says "git push" and means
push my new local changes to the remote.
Unfortunately, the remote may have advanced differently from
the local branch, and the push must fail because someone needs
to merge first. git push recommends to do a pull and retry, which
is the right thing to do.
My strange rule 10/10 adds a check that verifies if the local
side has something interesting to push. Only in this case a
pull make sense. If you do not have something new, a pull will
be a fast-forward, and just a waste of time.
In this light I think the current behaviour is insane, because
it asks the user to spend time on things that do not add any
value. No new commits, no new information, no need to merge, no
need to push again, no need to report errors ...
> I think we could live with an optional behaviour, in addition to
> the current "matching refs" behaviour, that is "matching refs,
> ignoring strict ancestors", though, but I doubt it is worth the
> addition.
... just ignore strict ancestors by default.
Steffen
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-30 10:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org>
Hi,
On Mon, 29 Oct 2007, Linus Torvalds wrote:
> On Tue, 30 Oct 2007, Theodore Tso wrote:
>
> > Quick! Which of the URL-like strings follow the URL quoting rules,
> > and which ones don't?
>
> Quick! WHO THE F*CK CARES?
I second this.
Should we -- ever -- encounter problems with the way we do things, we can
still fix it. So far, our "inconsistent" behaviour has not given me
grief.
Ciao,
Dscho
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Johannes Schindelin @ 2007-10-30 9:58 UTC (permalink / raw)
To: Peter Karlsson
Cc: Alex Riesen, Steffen Prohaska, Shawn O. Pearce, Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0710291357420.23695@perkele.intern.softwolves.pp.se>
Hi,
On Mon, 29 Oct 2007, Peter Karlsson wrote:
> Alex Riesen:
>
> > Because you do not send changes to a _server_. There is no server. There is
> > just another repo. Hence just "push"
>
> Fine. "Send to repository", then. My point is that if "push" is a technical
> term, then it doesn't belong in the GUI, and if it isn't, then it should be
> translated like any other UI element.
Come on. "Byte" is a technical term, too, and only the French translate
it. Same goes for "Computer". There is a point where hiding the truth
from the user becomes silly. This is it.
Ciao,
Dscho
^ permalink raw reply
* Missing MIME-headers in git-email-tool ..
From: Matti Aarnio @ 2007-10-30 9:53 UTC (permalink / raw)
To: git
The git-send-email does send posts without any sort of MIME labeling:
From: / To: removed
Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates
Date: Tue, 30 Oct 2007 17:33:15 +0800
Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@analog.com>
X-Mailer: git-send-email 1.5.3.4
Precedence: bulk
which per MIME rules means that the message in question is equivalent
to one with header labels:
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
What would be a problem ? Some of us have names that are encoded
in 8-bit form, and some receiving systems get all mighty upset when
they receive unlabelled email carry 8-bit encoded texts.
(Thanks to chinese and russian spammers..)
Now if the git-send-email would add following three lines in all
outgoing email headers, things would be 99% correct for a long time..
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
The potential incorrectness is with UTF-8 encoded names.
Even then it probably is merely nuisance and not real delivery
preventing detail.
/Matti Aarnio -- one of <postmaster @ vger.kernel.org>
^ permalink raw reply
* Re: [PATCH 01/10] push: change push to fail if short refname does not exist
From: Junio C Hamano @ 2007-10-30 9:22 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <AD10F15D-0F77-42BB-86CA-6404063C784B@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
> ...
>> Will drop 1/10 and 2/10 for now.
>
> Then they'll be dropped and I'll rely on the the --dry-run flag.
>
> Or someone else needs to step in and support my point.
Yup, you exactly got what I meant by "for now". I reserve the
right to be convinced and converted later ;-).
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Junio C Hamano @ 2007-10-30 8:56 UTC (permalink / raw)
To: Peter Karlsson
Cc: Alex Riesen, Steffen Prohaska, Shawn O. Pearce, Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0710291357420.23695@perkele.intern.softwolves.pp.se>
Peter Karlsson <peter@softwolves.pp.se> writes:
> Alex Riesen:
>
>> Because you do not send changes to a _server_. There is no
>> server. There is just another repo. Hence just "push"
>
> Fine. "Send to repository", then. My point is that if "push" is a
> technical term, then it doesn't belong in the GUI, and if it isn't,
> then it should be translated like any other UI element.
Why doesn't a "technical term" belong in the GUI in the first
place?
If majority of people who use git know and use the term "push"
to describe that concept, certainly they will be the people from
whom the new people who start to use git (either from command
line or from GUI) get help. Why do you want to have them use
different language to make the communication more difficult?
^ permalink raw reply
* Re: [PATCH 01/10] push: change push to fail if short refname does not exist
From: Steffen Prohaska @ 2007-10-30 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwst5m2eq.fsf@gitster.siamese.dyndns.org>
On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Pushing a short refname used to create a new ref on on the
>> remote side if it did not yet exist. If you specified the wrong
>> branch accidentally it was created. A safety valve that pushes
>> only existing branches may help to avoid errors.
>
> On the other hand, if you specified a wrong branch that exists
> on the remote end accidentally, it still was pushed. Do we want
> to have a new "--i-really-want-to-push" option to make it safer?
Maybe not a bad idea ;)
But not as a command line flag but after printing the results
of a '--dry-run' and than asking the user for confirmation:
"do you want to push this?".
> I do not think so. Why should a new branch be treated any
> differently?
Because "updating an existing branch" and "creating a new branch"
are two slightly different tasks.
If git provides a way to make this difference explicit, it
would be safer to use.
> Will drop 1/10 and 2/10 for now.
Then they'll be dropped and I'll rely on the the --dry-run flag.
Or someone else needs to step in and support my point.
Steffen
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-30 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Peter Baumann, git
In-Reply-To: <7vmyu1s1qt.fsf@gitster.siamese.dyndns.org>
>
> Actually, subtree strategy was designed to allow merging back
> and forth. But the result, as it _is_ a merge, will not omit
> any commit from the history from both branches.
>
>
Can git-log be more clever so that it can recognize a subtree merge
and show only logs related to the subtree?
Another suggestion is that the commit msg for subtree merge should be
more accurate such as " Merge branch master of <repos> into direcotry
<dir> of branch <branch>"
--
franky
^ permalink raw reply
* Re: [PATCH 07/10] push: use same rules as git-rev-parse to resolve refspecs
From: Steffen Prohaska @ 2007-10-30 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3avtngzc.fsf@gitster.siamese.dyndns.org>
On Oct 30, 2007, at 9:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> This commit changes the rules for resolving refspecs to match the
>> rules for resolving refs in rev-parse. git-rev-parse uses clear rules
>> to resolve a short ref to its full name, which are well documented.
>> The rules for resolving refspecs documented in git-send-pack were
>> less strict and harder to understand. This commit replaces them by
>> the rules of git-rev-parse.
>>
>> The unified rules are easier to understand and better resolve
>> ambiguous
>> cases. You can now push from a repository containing several branches
>> ending on the same short name.
>
> As you introduced long names around 5/10 to have two different
> ones for clarity with the goal of unifying them, so once you
> unified the rules, it probably is a good idea to rename the long
> "do_this_with_X_rule()" and "do_this_with_Y_rule()" functions
> back to "do_this()", isn't it?
Absolutely.
But I'm not sure if I'm the one who unifies them.
Steffen
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-10-30 8:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935935821192-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> git push now allows you pushing a couple of branches that have
> advanced, while ignoring all branches that have no local changes,
> but are lagging behind their matching remote refs. This is done
> without reporting errors.
>
> Thanks to Junio C. Hamano <gitster@pobox.com> for suggesting to
> report in the summary that refs have been ignored.
I do not think this is a good idea at all. Furthermore, I never
suggested anything about summary. You are robbing the
information from the pusher which ones are pushed and which ones
are left behind.
It simply is insane to make this strange rule 10/10 introduces
the default behaviour. It is too specific to a particular
workflow (that is, working with a shared central repository,
having many locally tracking branches that are not often used
and become stale, and working on only things to completion
between pushes).
I think we could live with an optional behaviour, in addition to
the current "matching refs" behaviour, that is "matching refs,
ignoring strict ancestors", though, but I doubt it is worth the
addition.
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Junio C Hamano @ 2007-10-30 8:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, git, Andy C
In-Reply-To: <alpine.LFD.0.999.0710292156580.30120@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 30 Oct 2007, Jeff King wrote:
>>
>> - no improvement on smaller datasets. Running "git-whatchanged -M
>> --raw -l0" on the linux-2.6 repo takes about the same time with the
>> old and new code (presumably the algorithmic savings of the new code
>> are lost in a higher constant factor, so when n is small, it is a
>> wash).
>
> Have you compared the results? IOW, does it find the *same* renames?
>
> I'm a bit worried about the fact that you just pick a single (arbitrary)
> src/dst per fingerprint. Yes, it should be limited, but that seems to be a
> bit too *extremely* limited. But if it gives the same results in practice,
> maybe nobody cares?
If it always gives the same results in practice, obviously
nobody can even notice.
However, merging this series to 'pu' breaks rebase-merge test
t3402 among other things.
^ permalink raw reply
* Re: [PATCH 1/2] add throughput to progress display
From: Junio C Hamano @ 2007-10-30 8:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710291904190.22100@xanadu.home>
Very nice.
I however wonder why this breaks t1004 when applied on top of
lt/rename topic.
^ permalink raw reply
* Re: [PATCH 01/10] push: change push to fail if short refname does not exist
From: Junio C Hamano @ 2007-10-30 8:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935935812741-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Pushing a short refname used to create a new ref on on the
> remote side if it did not yet exist. If you specified the wrong
> branch accidentally it was created. A safety valve that pushes
> only existing branches may help to avoid errors.
On the other hand, if you specified a wrong branch that exists
on the remote end accidentally, it still was pushed. Do we want
to have a new "--i-really-want-to-push" option to make it safer?
I do not think so. Why should a new branch be treated any
differently?
Will drop 1/10 and 2/10 for now.
^ permalink raw reply
* Re: [PATCH 07/10] push: use same rules as git-rev-parse to resolve refspecs
From: Junio C Hamano @ 2007-10-30 8:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935935823045-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> This commit changes the rules for resolving refspecs to match the
> rules for resolving refs in rev-parse. git-rev-parse uses clear rules
> to resolve a short ref to its full name, which are well documented.
> The rules for resolving refspecs documented in git-send-pack were
> less strict and harder to understand. This commit replaces them by
> the rules of git-rev-parse.
>
> The unified rules are easier to understand and better resolve ambiguous
> cases. You can now push from a repository containing several branches
> ending on the same short name.
As you introduced long names around 5/10 to have two different
ones for clarity with the goal of unifying them, so once you
unified the rules, it probably is a good idea to rename the long
"do_this_with_X_rule()" and "do_this_with_Y_rule()" functions
back to "do_this()", isn't it?
^ permalink raw reply
* Re: [PATCH 04/10] push: add "git push HEAD" shorthand for 'push current branch to default repo'
From: Junio C Hamano @ 2007-10-30 8:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935935812185-git-send-email-prohaska@zib.de>
Will drop this as you already know why.
^ permalink raw reply
* Re: [PATCH 03/10] push: support pushing HEAD to real branch name
From: Junio C Hamano @ 2007-10-30 8:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1193593581486-git-send-email-prohaska@zib.de>
Nice.
^ permalink raw reply
* Re: [PATCH] Fix a small memory leak in builtin-add
From: Junio C Hamano @ 2007-10-30 8:28 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git, gitster
In-Reply-To: <1193641233-3880-2-git-send-email-tsuna@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> 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).
I think it was just a slop. Thanks for catching it.
^ permalink raw reply
* Re: [PATCH 0/4] Build in some more things
From: Junio C Hamano @ 2007-10-30 8:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710292049450.7357@iabervon.org>
I've merged this to 'pu', but honestly speaking, the conflicts
are geting a bit more "interesting" than I care to keep
repeating even with help from rerere, with four people
simultaneously touching the neighbouring code in their topics.
Topics involved are:
** db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
. Use built-in send-pack.
. Build-in send-pack, with an API for other programs to call.
. Build-in peek-remote, using transport infrastructure.
. Miscellaneous const changes and utilities
* jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
+ t5516: test update of local refs on push
+ send-pack: don't update tracking refs on error
* js/forkexec (Fri Oct 19 21:48:06 2007 +0200)
+ Use start_command() in git_connect() instead of explicit
fork/exec.
+ Change git_connect() to return a struct child_process instead of a
pid_t.
** sp/push-refspec (Sun Oct 28 18:46:21 2007 +0100)
. push: teach push to pass --verbose option to transport layer
. push: use same rules as git-rev-parse to resolve refspecs
. add ref_abbrev_matches_full_with_rev_parse_rules() comparing
abbrev with full ref name
. rename ref_matches_abbrev() to
ref_abbrev_matches_full_with_fetch_rules()
Could you please check the result after I push it out?
^ permalink raw reply
* Possible bug: git-svn leaves broken tree in case of error
From: Anton Korobeynikov @ 2007-10-30 7:30 UTC (permalink / raw)
To: git
Hello, Everyone.
I noticed this bug several times. Consider the following conditions are
met:
- We're syncing from svn using git-svn :)
- We have authors file provided
- We have a changeset with author unlisted in the authors file.
git-svn dies due to the following code:
sub check_author {
my ($author) = @_;
if (!defined $author || length $author == 0) {
$author = '(no author)';
}
if (defined $::_authors && ! defined $::users{$author}) {
die "Author: $author not defined in $::_authors file\n";
}
$author;
}
Unfortunately it leaves repository in some middle state: git-svn itself
thinks, that it synced with everything, but git itself doesn't "see" any
changesets anymore. I found no way to repair tree after such situation,
so I had to repull from scratch.
I found myself, that this should be warning (and fix in this case is
trivial), not error (maybe some commandline switch to control behaviour,
etc). It can be even error, but breaking tree is definitely bug in this
case.
Any thoughts?
--
With best regards, Anton Korobeynikov.
Faculty of Mathematics & Mechanics, Saint Petersburg State University.
^ permalink raw reply
* [PATCH v3] Speedup scanning for excluded files.
From: Lars Knoll @ 2007-10-30 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, git, Pierre Habouzit
In-Reply-To: <200710300828.49840.lars@trolltech.com>
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. A 'git runstatus' on the git repository goes from 100M instructions
down to about 22M.
Signed-off-by: Lars Knoll <lars@trolltech.com>
---
Included an out of bounds check for the issue Morten found.
dir.c | 61 ++++++++++++++++++++++++++++++++++++++++++++-----------------
dir.h | 7 +++++++
2 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/dir.c b/dir.c
index 4c17d36..b3d7462 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,21 @@ 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 (x->patternlen - 1 <= pathlen &&
+ !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 +266,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 +284,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] Speedup scanning for excluded files.
From: Lars Knoll @ 2007-10-30 7:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, git, Pierre Habouzit
In-Reply-To: <7vzly1sc7p.fsf@gitster.siamese.dyndns.org>
On Tuesday 30 October 2007, Junio C Hamano wrote:
> "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;
Yes, that looks right. Thanks for catching that one.
Lars
^ permalink raw reply
* Re: [PATCH 0/4] Build in some more things
From: Johannes Sixt @ 2007-10-30 7:24 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710292049450.7357@iabervon.org>
Daniel Barkalow schrieb:
> The main effect of this series is removing the fork/exec from pushing via
> the git protocol (aside from the later fork/exec in connect.c of course).
>
> It also heads off some tempting transport-related fetch bugs, which I will
> not introduce in a later patch.
>
> * Miscellaneous const changes and utilities
> Adds two small utility functions, and marks a bunch of stuff as const;
> the const stuff is to keep builtin-fetch from getting messed up without
> a warning, because it wants some lists not to change.
>
> * Build-in peek-remote, using transport infrastructure.
> * Build-in send-pack, with an API for other programs to call.
> * Use built-in send-pack.
I assume this goes on top of current master or db/fetch-pack. The patches
have some conflicts with js/forkexec (nothing serious, though). Maybe it
makes sense to rebase on top of that.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/2] add throughput to progress display
From: Johannes Sixt @ 2007-10-30 7:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.9999.0710291904190.22100@xanadu.home>
Nicolas Pitre schrieb:
> 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>
System headers should be taken care of by git-compat-util.h. In fact, it
already pulls in <sys/time.h>, hence, it shouldn't be necessary here.
-- Hannes
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Peter Karlsson @ 2007-10-29 12:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: Steffen Prohaska, Shawn O. Pearce, Git Mailing List
In-Reply-To: <20071026214124.GB3062@steel.home>
Alex Riesen:
> Because you do not send changes to a _server_. There is no server. There
> is just another repo. Hence just "push"
Fine. "Send to repository", then. My point is that if "push" is a technical
term, then it doesn't belong in the GUI, and if it isn't, then it should be
translated like any other UI element.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: remote#branch
From: Tom Prince @ 2007-10-30 5:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710292150400.30120@woody.linux-foundation.org>
On Mon, Oct 29, 2007 at 09:51:47PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 30 Oct 2007, Theodore Tso wrote:
> >
> > Mirror URL git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> > Push URL git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
>
> No.
>
> The push url is generally written as
>
> repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
>
> Tough.
But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.
>
> > Quick! Which of the URL-like strings follow the URL quoting rules,
> > and which ones don't?
>
> Quick! WHO THE F*CK CARES?
>
So, how should git deal with
git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
compared to
http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
Note: this doesn't have anything to do with server:/path/to/repo
Not that I care, but git should probably handle things consistently.
Tom
^ 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