Currently we treat "*.c" and "path/to/*.c" the same way. Which means
we check all possible paths in repo against "path/to/*.c". One could
see that "path/elsewhere/foo.c" obviously cannot match "path/to/*.c"
and we only need to check all paths _inside_ "path/to/" against that
pattern.
This patch ch
When a pattern contains only a single asterisk as wildcard,
e.g. "foo*bar", after literally comparing the leading part "foo" with
the string, we can compare the tail of the string and make sure it
matches "bar", instead of running fnmatch() on "*bar" against the
remainder of the string.
-O2 build
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 18 +-
dir.h | 8
tree-walk.c | 6 --
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index c391d46..f81e1d2 100644
--- a/dir.c
+++ b/dir.c
@@ -34,6 +34,21 @@ int fnmatch_icase
We mark pathspec with wildcards with the field use_wildcard. We
could do better by saving the length of the non-wildcard part, which
can be used for optimizations such as f9f6e2c (exclude: do strcmp as
much as possible before fnmatch - 2012-06-07).
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-b
The only change (apart from what Junio's made after I sent the series)
is rename GF_* to GFNM_* and PSF_* to PATHSPEC_* with a brief explanation
for each flag.
.gitignore code does not have "foo*oob" bug that the original series has.
Nguyễn Thái Ngọc Duy (4):
pathspec: save the non-wildcard len
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index d88fa10..bf5c822 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -548,7 +548,6 @@ static void get
There's no need to pass it around everywhere. This would make easier
further refactoring that makes use of this variable.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/builtin/fast-export.c b/
Split into a separate helper function get_commit() so that the part that
finds the relevant commit, and the part that does something with it
(handle tag object, etc.) are in different places.
No functional changes.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 68 +
There's not much to do when marks are not available, except pushing
everything, so let's do so by avoiding the negative refs (e.g.
^refs/testgit/origin/master).
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 2 +-
2 files changed, 2 insertions(+
For example '*:*'.
Obviously '^refs/heads/master refs/heads/master' is not going to work,
so lets check that the ref we are negating is not the same we are
pushing.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 2 +-
2 files changed, 2 inserti
The refspec feature is not mandatory.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 2e027c8..b268cd2 100755
---
Just shuffle the die() part to make it more explicit, and cleanup the
code-style.
Signed-off-by: Felipe Contreras
---
transport-helper.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 32ad877..0c95101 100644
--- a/transpor
They have been marked as UNINTERESTING for a reason, lets respect that.
Currently the first ref is handled properly, but not the rest:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
When pushing, the remote namespace is updated correctly
(e.g. refs/origin/master), but not the remote helper's
(e.g. refs/testgit/origin/master).
This alone should not cause any regressions, but combined with other
patches to handle negative refs correctly (upcoming patch), it might.
However, that
Hi,
Trying to fix the remaining issues with transport-helper I stumbled upon a
problem with the first patch attached. Now that the namespaced refs of the
remote helper are properly tracked, there's a problem when pushing more than
one ref at the same time *and* the last patch on the v5 patch serie
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we ca
Setting 'commit' to 'commit' is a no-op. It might have been there to
avoid a compiler warning, but if so, it was the compiler to blame, and
it's certainly not there any more.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Doesn't make a difference for the tests, but it does for the ones
seeking reference.
Signed-off-by: Felipe Contreras
---
git-remote-testgit | 13 +
1 file changed, 13 insertions(+)
diff --git a/git-remote-testgit b/git-remote-testgit
index e140282..aba3502 100755
--- a/git-remote-te
People who want to write their own remote-helper will find it more
useful to see clearly how they are supposed to advertise and implement
the "done" feature themselves.
Right now we are relying on fast-export to do that by using the
--use-done-feature argument. However, people writing their own
re
Unfortunately a lot of these tests fail.
Signed-off-by: Felipe Contreras
---
git-remote-testgit| 38 +++---
t/t5801-remote-helpers.sh | 52 +++
2 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/git-rem
We don't need a bare 'server' and an intermediary 'public'. The repos
can talk to each other directly; that's what we want to exercise.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 63 ++-
1 file changed, 29 insertions(+), 34 deletio
This was only to cover a bug that was fixed in remote-testpy not to
resurface.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 13 -
1 file changed, 13 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 2f7fc10..6801529 100755
--- a
This only makes sense for the python remote helpers framework. The tests
don't exercise any feature of transport helper. Remove them.
Signed-off-by: Felipe Contreras
---
git-remote-testgit| 3 ---
t/t5801-remote-helpers.sh | 50 ---
2 files ch
This script is not really exercising the remote-helper functionality,
but more the python framework for remote helpers that live in
git_remote_helpers.
It's also not a good example of how to write remote-helpers, unless you
are planning to use python, and even then you might not want to use this
f
Exercising the python remote helper framework is for another tool and
another test. This is about testing the remote-helper interface.
It's way simpler, it exercises the same features of remote helpers, it's
easy to read and understand, and it doesn't depend on python.
For now let's just copy the
This is remote-testgit, not remote-hg.
Signed-off-by: Felipe Contreras
---
t/t5800-remote-helpers.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index e7dc668..d46fa40 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t
Basically this is what we want:
== pull ==
testgit transport-helper
* export -> import
# testgit.marks git.marks
== push ==
testgit transport-helper
* import<- export
# te
We want to be able to import, and then export, using the same marks, so
that we don't push things that the other side already received.
Unfortunately, fast-export doesn't store blobs in the marks, but
fast-import does. This creates a mismatch when fast export is reusing a
mark that was previously
Hi,
I'm rerolling this series with the changes fron Junio, plus a bit more cleanups.
I dropped the last patch, because I found an issue and a separate patch series
would take care of that. Other than that the main changes remain the same.
The old remote-testgit is now remote-testpy (as it's test
Kacper Kornet writes:
> The following patch is an attempt to implement this idea.
I think "revert" is a wrong word (implying you have already done
something and you are trying to defeat the effect of that old
something), and you meant to say "reverse" (i.e. the opposite of
normal) or something.
Nguyễn Thái Ngọc Duy writes:
> This round cherry-pick and commit only skip S-o-b if the last one is
> the same...
That sounds sensible. When the user asks us to add sign-off, we
should honor it, unless it is known that adding one is absolutely
unnecessary, which is "it already exists as the la
It confuses pylint, and is never needed.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 9712082..551aec9 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -3188,7 +3188,6 @@ def main():
printUsage(commands.keys())
Signed-off-by: Pete Wyckoff
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index cb1ec8d..9712082 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2406,7 +2406,7 @@ class P4Sync(Command, P4UserMap):
try:
This test passes already. Make sure p4 diagnostic errors are displayed.
Signed-off-by: Pete Wyckoff
---
t/t9800-git-p4-basic.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 05797c3..8c59796 100755
--- a/t/t9800-git-p4-
Error messages that arise during the "p4 print" phase of
generating commits were silently ignored. Catch them,
abort the fast-import, and exit.
Without this fix, the sync/clone appears to work, but files that
are inaccessible by the p4d server will still be imported to git,
although without the p
Support for the "p4 move" command was added in 8e9497c (git p4:
add support for 'p4 move' in P4Submit, 2012-07-12), which checks
to make sure that the client and server support the command.
But older versions of p4d may not handle the "-k" argument, and
newer p4d allow disabling "p4 move" with a c
Group the two calls to "p4 describe" into a new helper function,
and try to validate the p4 results. The current behavior when p4
describe fails is to die with a python backtrace. The new behavior
will print the full response.
This does not solve any particular problem, but adds more
checking in
These are assorted minor fixes. They should be safe for 1.8.1,
and are not urgent enough for maint.
Four of them deal with handling errors from p4d better. The first two
of these have been seen on the list already. The third showed up in my
own testing. The fourth adds a test to make sure that
There is a discrepancy between the last line of `git diff --stat`
and `git diff --shortstat` in case of a merge.
The unmerged files are actually counted twice, thus doubling the
value of "file changed".
In fact, while stat decrements number of files when seeing an unmerged
file, shortstat doesn't.
On Thu, Nov 22, 2012 at 11:11 PM, Eric S. Raymond wrote:
> Shawn Pearce :
>> [Lots of helpful stuff ended by]
>> > 4. How does "git help" work? That is, how is a subcommand expected
>> > to know when it is being called to export its help text?
>>
>> IIRC "git help foo" runs "man git-foo".
>
> OK,
On Fri, Nov 23, 2012 at 3:02 PM, Marc Khouzam wrote:
> The user can be presented with invalid completion results
> when trying to complete a 'git checkout' command. This can happen
> when using a branch name prefix that matches multiple remote branches.
>
> For example, if available branches are:
Hello everyone,
we recently switched to git and so far it's doing a terriffic job.
Today though, we had a problem that we couldn't figure until now.
We have a master, a develop and a refactor branch. Today we merged
refactor into develop, which dramatically changes some source files. I
needed
On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:
> On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:
> > On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> > > "W. Trevor King" writes:
> > >
> > > > The superproject gitlink should only be updated after
> >
Am Freitag, 23. November 2012, 16:55:21 schrieb Heiko Voigt:
> I am still a little bit undecided about an automatically crafted commit.
>
> At $dayjob we sometimes update submodules to their tip without any
> superproject changes just to make sure we use the newest version. Most
> of the time the
Right clicking on a tag pops up a menu, which allows
tag to be renamed or deleted.
Signed-off-by: Leon KUKOVEC
---
gitk-git/gitk | 154 +
1 file changed, 154 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..38cc233
On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:
> On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote:
> > There is an important question still unanswered here for me: How does
> > the submodule get the configuration what the local branch tracks on the
> > remote side?
>
>
Shawn Pearce :
> Nope, it just has to be executable. We don't have any current Python
> code. IIRC the last Python code was the implementation of
> git-merge-recursive, which was ported to C many years ago.
This turns out not to be quite true. The tree currently includes
two Python scripts, a Pe
On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:
> On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> > "W. Trevor King" writes:
> >
> > > The superproject gitlink should only be updated after
> > >
> > > $ git submodule update --pull
> > >
> > > A plain
> > >
> > >
On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:
> The benefit is that Ævar's
>
> $ git submodule foreach 'git checkout $(git config --file
> $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> becomes
>
> $ git submodule update --pull
There is an important questi
On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
>
> > The superproject gitlink should only be updated after
> >
> > $ git submodule update --pull
> >
> > A plain
> >
> > $ git submodule update
> >
> > would still checkout the previously-recorded SHA,
Michael J Gruber :
> Regarding git-weave, I'm wondering (without having looked at the code)
> how this relates to git-archiv and git-fast-import/export, i.e. how much
> this leverages existing infrastructure rather than reinventing the
> wheel. Do your "trees" correspond to a "git tree"?
The unrav
Hi Heiko,
I have changed the external drive and seen that the new one works. The
issue is, I guess, that the first drive was named "My Passport", with
a space in it, while the second one is "Iomega". Spaces in drive names
are not accepted by Linux, which could explain why they are a problem
also w
Peter Krefting :
> I was just about to say that the import direction of this seems to
> fill the same need as contrib/fast-import/import-directories.perl
> that I submitted a few years back.
Yours was the closest in functionality, yes.
> Your version seems only to be able to import a linear histo
Hi,
On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote:
> I have attached an external disc, which appears on Windows as drive f:
> in Windows Explorer.
> Right-clicking on it displays a context menu showing (among other
> items) Git Init Here, Git Gui and
> Git Bash. The first two wor
The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example, if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remo
> From: Sascha Cunz [mailto:sascha...@babbelbox.org]
> Sent: Friday, November 23, 2012 1:26 PM
> To: Joachim Schmitz
> Cc: 'Marc Khouzam'; git@vger.kernel.org; sze...@ira.uka.de;
> felipe.contre...@gmail.com
> Subject: Re: [PATCH] Completion must sort before using uniq
>
> > I can't see the diffe
> I can't see the difference and in fact don't understand uniq's -u option al
> all Linux man pages say: "only print unique lines", but that is what uniq
> does by default anyway?!?
>From the german translation of uniq's man-page, you can deduct that "only
print unique lines" actually means: "pri
Re-adding git@vger...
> From: Marc Khouzam [mailto:marc.khou...@gmail.com]
> Sent: Friday, November 23, 2012 11:51 AM
> To: Joachim Schmitz
> Cc: sze...@ira.uka.de; felipe.contre...@gmail.com
> Subject: Re: [PATCH] Completion must sort before using uniq
>
> On Fri, Nov 23, 2012 at 3:10 AM, Joachi
Hi,
Mostly cosmetic suggestions, but it looks OK to me.
On Fri, Nov 23, 2012 at 12:17 PM, Marc Khouzam wrote:
> The user can be presented with invalid completion results
> when trying to complete a 'git checkout' command. This can happen
> when using a branch name prefix that matches multiple r
The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remote
I noticed a problem with remote helpers which is mainly about convenience, but
still annoying enough that I wish it could be resolved; but I'd like some input
on what the proper way would be...
Here is the issue: cloning with relative paths is problematic (if not broken)
when using remote-helpe
Junio C Hamano wrote:
Jeff King writes:
...
Not exactly. There are three classes of people:
- wrote scripts using --get; found out that --get barfs if you feed
two or more of the same, and have long learned to accept it as a
limitation and adjusted their configuration files to avoid it
Eric S. Raymond:
git-weave(1)
Yes, there are scripts in contrib that do similar things.
I was just about to say that the import direction of this seems to
fill the same need as contrib/fast-import/import-directories.perl that
I submitted a few years back.
Your version seems only to be a
Eric S. Raymond venit, vidit, dixit 22.11.2012 23:11:
> Shawn Pearce :
>> [Lots of helpful stuff ended by]
>>> 4. How does "git help" work? That is, how is a subcommand expected
>>> to know when it is being called to export its help text?
>>
>> IIRC "git help foo" runs "man git-foo".
>
> OK, that
When the changes are pushed upstream, and in the meantime someone else
updated upstream branch git advises to use git pull. This results in
history:
---A---B---C--
\ /
D---E
where B is my commit. D, E are commits pushed by someone else when I was
working on B. However
On Thu, Nov 22, 2012 at 5:16 AM, Marc Khouzam wrote:
> The uniq program only works with sorted input. The man page states
> "uniq prints the unique lines in a sorted file".
>
> When __git_refs use the guess heuristic employed by checkout for
> tracking branches it wants to consider remote branche
Marc Khouzam wrote:
The uniq program only works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
...
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
67 matches
Mail list logo
