* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Jonathan Nieder @ 2012-11-21 4:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, git, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vd2z7rj3y.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> Of course, transport-helper shouldn't even be specifying the negative
>> (^) refs, but that's another story.
>
> Hrm, I am not sure I understand what you mean by this.
>
> How should it be telling the fast-export up to what commit the
> receiving end should already have the history for (hence they do not
> need to be sent)? Or are you advocating to re-send the entire
> history down to the root commit every time?
I think Felipe has mentioned before that he considers it the remote
helper's responsibility to keep track of what commits have already
been imported, for example using a marks file.
Never mind that others have said that that's not the current interface
(I don't yet see why it would be a good interface after a transition,
but maybe it would be). Still, hopefully that clarifies the intended
meaning.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Felipe Contreras @ 2012-11-21 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 1:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Here is a list of stalled topics I am having trouble deciding what
> to do (the default is to dismiss them around feature freeze).
>
> * fc/fast-export-fixes (2012-11-08) 14 commits
>
> Renaming of remote-testgit feels to be a mistake. It probably
> should keep its source in remote-testgit.bash and generate it,
Why generate it? There's nothing to generate. python's source code
needs regeneration, bash's code doesn't.
> and
> moreover, if it wants to rename remote-testgit.py to remote-testpy,
> the new one should be called remote-testbash.
No, remote-testbash is not testing anything that is specific to bash,
it's testing the remote helper framework itself. It could be written
in Ruby, or Python, or C, or anything.
remote-testgit.py is *not* testing the remote helper framework, it's
testing the Python-specific remote helper framework.
IOW. remote-testgit tests this:
transport-helper.c
remote-testpy tests this:
git_remote_helpers/Makefile
git_remote_helpers/__init__.py
git_remote_helpers/git/__init__.py
git_remote_helpers/git/exporter.py
git_remote_helpers/git/git.py
git_remote_helpers/git/importer.py
git_remote_helpers/git/non_local.py
git_remote_helpers/git/repo.py
git_remote_helpers/setup.cfg
git_remote_helpers/setup.py
git_remote_helpers/util.py
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-21 3:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vd2z7rj3y.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Of course, transport-helper shouldn't even be specifying the negative
>> (^) refs, but that's another story.
>
> Hrm, I am not sure I understand what you mean by this.
>
> How should it be telling the fast-export up to what commit the
> receiving end should already have the history for (hence they do not
> need to be sent)? Or are you advocating to re-send the entire
> history down to the root commit every time?
No, it would not re-send the whole history, that's what marks are for.
And right now it doesn't exactly which was the last commit. Let's
suppose the remote helper has a refspec like this:
refs/heads/*:refs/hg/origin/heads/*
1) What happens the first time you push?
5203a268546295ebd895fd87522217ef53bd3313 refs/heads/master
5203a268546295ebd895fd87522217ef53bd3313 refs/remotes/tmp/master
Notice how the remote ref is updated correctly, but it's not the
remote helper refspec, so the next time you push, you will from root.
It's only when you fetch that you get the refspec'ed refs:
5203a268546295ebd895fd87522217ef53bd3313 refs/heads/master
5203a268546295ebd895fd87522217ef53bd3313 refs/hg/tmp/heads/master
5203a268546295ebd895fd87522217ef53bd3313 refs/remotes/tmp/master
So, there's already a mismatch.
2) What happens when you have no marks?
You get something like:
reset refs/heads/heads
from :0
Which is totally useless. Somebody proposed a patch that would replace
the :0 with a git sha-1, but that is equally useless for a remote
helper: we need a hg ref id, or a bzr id, or whatever, and no, there's
mapping between git sha-1's and hg ref ids, there's only git->mark
mark->hg, without marks, there's no way to map the git id to the hg
id.
3) What happens when you have a refspec like this?
*:*
Now nothing works, because we would be requesting ^refs/heads/master
refs/heads/master.
And according to the documentation, this is the default when no
refspec is used, which is not true.
4) What happens when there's no refspec at all.
Now it's even worst; nothing gets done at all:
if (!data->refspecs)
continue;
I documented all this breakages in this patch:
http://article.gmane.org/gmane.comp.version-control.git/209365
not ok 10 - push new branch with old:new refspec # TODO known breakage
ok 11 - cloning without refspec
ok 12 - pulling without refspecs
not ok 13 - pushing without refspecs # TODO known breakage
not ok 14 - pulling with straight refspec # TODO known breakage
not ok 15 - pushing with straight refspec # TODO known breakage
not ok 16 - pulling without marks # TODO known breakage
not ok 17 - pushing without marks # TODO known breakage
And if you apply this patch:
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -750,6 +750,7 @@ static int push_refs_with_export(struct transport
*transport,
struct helper_data *data = transport->data;
struct string_list revlist_args = STRING_LIST_INIT_NODUP;
struct strbuf buf = STRBUF_INIT;
+ struct remote *remote = transport->remote;
helper = get_helper(transport);
@@ -761,22 +762,23 @@ static int push_refs_with_export(struct
transport *transport,
char *private;
unsigned char sha1[20];
- if (!data->refspecs)
+ if (ref->deletion)
+ die("remote-helpers do not support ref deletion");
+
+ if (!ref->peer_ref)
+ continue;
+
+ string_list_append(&revlist_args, ref->peer_ref->name);
+
+ if (!data->import_marks)
continue;
- private = apply_refspecs(data->refspecs,
data->refspec_nr, ref->name);
+
+ private = apply_refspecs(remote->fetch,
remote->fetch_refspec_nr, ref->name);
if (private && !get_sha1(private, sha1)) {
strbuf_addf(&buf, "^%s", private);
string_list_append(&revlist_args,
strbuf_detach(&buf, NULL));
}
free(private);
-
- if (ref->deletion) {
- die("remote-helpers do not support ref deletion");
- }
-
- if (ref->peer_ref)
- string_list_append(&revlist_args, ref->peer_ref->name);
-
}
if (get_exporter(transport, &exporter, &revlist_args))
ok 13 - pushing without refspecs # TODO known breakage
ok 14 - pulling with straight refspec # TODO known breakage
ok 15 - pushing with straight refspec # TODO known breakage
ok 16 - pulling without marks # TODO known breakage
ok 17 - pushing without marks # TODO known breakage
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Paul Fox @ 2012-11-21 2:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-reply-to: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org> (sfid-20121120_190548_379327_D3EE7D14)
References: <7vpq39up0m.fsf@alter.siamese.dyndns.org> <7vy5hvq1ey.fsf@alter.siamese.dyndns.org> <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org> (sfid-20121120_190548_379327_D3EE7D14)
Fcc: outbox
--------
junio c hamano wrote:
> Here is a list of stalled topics I am having trouble deciding what
> to do (the default is to dismiss them around feature freeze).
...
> * pf/editor-ignore-sigint (2012-11-11) 5 commits
>
> Avoid confusing cases where the user hits Ctrl-C while in the editor
> session, not realizing git will receive the signal. Since most editors
> will take over the terminal and will block SIGINT, this is not likely
> to confuse anyone.
>
> Some people raised issues with emacsclient, which are addressed by this
> re-roll. It should probably also handle SIGQUIT, and there were a
> handful of other review comments.
>
> Anybody interested in moving this forward?
i started this, but then jeff took it and ran with it and made it
right. i think the remaining changes are small -- if jeff would
prefer, i can probably finish it. (but i won't guarantee not to
mess up the "From:" lines. :-)
paul
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 36.0 degrees)
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Andrew Ardill @ 2012-11-21 1:54 UTC (permalink / raw)
To: Lisandro Damián Nicanor Pérez Meyer; +Cc: git@vger.kernel.org
In-Reply-To: <201211202113.44459.perezmeyer@gmail.com>
On 21 November 2012 11:13, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com> wrote:
> ...
> Well, two ideas come to my mind:
>
> - detect when using git flow (.git/config contains [gitflow "some_branch"]
> entries).
I guess this part is just so the next part can be done automatically?
> - Show "swim-lane"-like graphs, including branches that may not be present,
> but where there (release branches often are created and merged back, for
> example)
I think this could be useful in general, however it might struggle
with already merged branches. I may be mistaken here, however I think
in general there is no way to specify which commits belonged to a
certain branch after they have been merged, as branch information is
not kept in the commit object. There may be some exceptions that make
it feasible at times, but a general solution would be to show any
merged branches as part of the same swim-lane, as per current
behaviour, but to have separate branch heads in different swim-lanes.
This would be a nice feature, and is similar to the behaviour in, for
example, Atlassian's Fisheye repository viewer and the GitHub network
view.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Lisandro Damián Nicanor Pérez Meyer @ 2012-11-21 0:13 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451nrcEo3Uxm0x6b39Hq1k-J4=OZPi-Cao7osaiS-w_Z1+Q@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1974 bytes --]
On Tue 20 Nov 2012 20:56:26 Andrew Ardill escribió:
> On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer
>
> <perezmeyer@gmail.com> wrote:
> > Hi! I am not suscribed to the list, so please CC-me.
>
> That is the default etiquette on this list :)
Great :-)
> > I think this may have been proposed before, but I could not find anything
> > in the web, so I better try myself :)
> >
> > The idea would be to gitk to show a "git flow-like"[0] view when it
> > detects git flow (or the user ask for it or...)
>
> What does it mean to 'show a "git flow-like" view'? Show multiple
> branches? Place commits on each branch in 'swim-lanes', rather than
> moving them around on the horizontal to fit the space available? Some
> more detail, or even a mock-up would help a lot here.
I think the best mock-up would be:
<http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png>
Yes, I'm referring to "swim-lanes" like view. Which may be already there and
I'm miserably failing to see :-/
> > Basiccaly, you can show the main two branches: master and develop. Of
> > course, having the possibility to show feature/release/hotfixes branches
> > would be ideal.
>
> It is already possible to show multiple branches in gitk at the same
> time. You probably have some more specific needs beyond simply showing
> the different branches. Maybe you can be more specific?
Well, two ideas come to my mind:
- detect when using git flow (.git/config contains [gitflow "some_branch"]
entries).
- Show "swim-lane"-like graphs, including branches that may not be present,
but where there (release branches often are created and merged back, for
example)
Maybe some of this is already there and/or it's too much trouble to do so, in
those cases, please accept my apologies :-)
Kinds regards, Lisandro.
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [BUG] git clean does not remove certain directories
From: Soren Brinkmann @ 2012-11-21 0:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]
Hi,
this use case may be a little awkward but this is the behavior I see:
I have a repository which has a couple of untracked directories which can also
include git repositories. No submodules, though.
I used 'git clean -xdf' on the top level of this repo to remove everything
untracked in it - including the git repositories in sub-directories.
Since using git 1.8.0 the clean operation seems to be 'broken', as output
indicates all those questionable sub directories are removed - just as in prior
git versions - but in fact they remain untouched and are _not_ removed.
I attached a shell script creating a hierarchy to reproduce the issue.
Executing the script creates the git repo 'repo.git' with a couple of tracked
and untracked dirs/files and two more git repositories within the first one.
If you cd into repo.git and execute 'git clean -xdf' I see the following output:
Removing repo2.git/
Removing untracked_dir/
But the directories remain intact when using git 1.8.0.
With git 1.6.3.2 it works as I expected and removes the directories. I'm pretty
sure the 1.7.x versions did the same, but it's no longer installed here.
I can see that this behavior may partially be intended, but the tool output
should match its actions. So, either the directories should be removed, or the
output should state, that they are not removed for what reason whatsoever, IMHO
Thanks,
Soren
[-- Attachment #2: reproduce.sh --]
[-- Type: text/plain, Size: 547 bytes --]
#!/bin/sh
mkdir repo.git
cd repo.git
git init
echo foo > tracked_file1
git add tracked_file1
mkdir tracked_dir
echo foo > tracked_dir/tracked_file2
git add tracked_dir/tracked_file2
git commit -m "Adding tracked files"
mkdir repo2.git
echo foo > repo2.git/tracked_file3
mkdir -p untracked_dir/repo3.git
echo foo > untracked_dir/repo3.git/tracked_file4
cd repo2.git
git init
git add tracked_file3
git commit -m "Adding file to subrepo1"
cd ../untracked_dir/repo3.git
git init
git add tracked_file4
git commit -m "Adding file to subrepo2"
cd ../..
^ permalink raw reply
* Topics currently in the Stalled category
From: Junio C Hamano @ 2012-11-21 0:05 UTC (permalink / raw)
To: git
In-Reply-To: <7vy5hvq1ey.fsf@alter.siamese.dyndns.org>
Here is a list of stalled topics I am having trouble deciding what
to do (the default is to dismiss them around feature freeze).
* fc/fast-export-fixes (2012-11-08) 14 commits
Renaming of remote-testgit feels to be a mistake. It probably
should keep its source in remote-testgit.bash and generate it, and
moreover, if it wants to rename remote-testgit.py to remote-testpy,
the new one should be called remote-testbash. There was one reroll
after what used to be queued, but nobody seemed to be interested in
reviewing the series.
This mostly happened while I was away, and judging from the
discussion around this topic (and earlier iterations), I do not
feel comfortable merging this series (or v5 reroll) as-is.
Help?
* pf/editor-ignore-sigint (2012-11-11) 5 commits
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Anybody interested in moving this forward?
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs may be
desirable.
Should we merge this as-is and build on top? What are the chances
of potential regressions?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this, but it seems that there weren't any
activity since then during my absense.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Is this still in "Needs review" state? Are people involved in the
remote interface happy with this change?
* jk/send-email-sender-prompt (2012-11-15) 8 commits
- send-email: do not prompt for explicit repo ident
- Git.pm: teach "ident" to query explicitness
- var: provide explicit/implicit ident information
- var: accept multiple variables on the command line
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given static
- t7502: factor out autoident prerequisite
- test-lib: allow negation of prerequisites
Avoid annoying sender prompt in git-send-email, but only when it is
safe to do so.
Perhaps keep only the first three patches, and replace the rest
with the one from Felipe that takes a much simpler approach (the
rationale of that patch needs to be cleaned up first, along the
lines Jeff outlined, though). Frozen until that happens.
* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
- Unify appending signoff in format-patch, commit and sequencer
I am not sure if the logic to refrain from adding a sign-off based
on the existing run of sign-offs is done correctly in this change.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
I think the fear that this would regress the intended use case of
the environment variable turned out to be unfounded during the
discussion.
Should we merge this as-is to 'next', cook for a while to make sure
nobody screams?
Thanks.
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Andrew Ardill @ 2012-11-20 23:56 UTC (permalink / raw)
To: Lisandro Damián Nicanor Pérez Meyer; +Cc: git@vger.kernel.org
In-Reply-To: <201211202043.00293.perezmeyer@gmail.com>
On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com> wrote:
>
> Hi! I am not suscribed to the list, so please CC-me.
That is the default etiquette on this list :)
> I think this may have been proposed before, but I could not find anything in
> the web, so I better try myself :)
>
> The idea would be to gitk to show a "git flow-like"[0] view when it detects
> git flow (or the user ask for it or...)
What does it mean to 'show a "git flow-like" view'? Show multiple
branches? Place commits on each branch in 'swim-lanes', rather than
moving them around on the horizontal to fit the space available? Some
more detail, or even a mock-up would help a lot here.
> Basiccaly, you can show the main two branches: master and develop. Of course,
> having the possibility to show feature/release/hotfixes branches would be
> ideal.
It is already possible to show multiple branches in gitk at the same
time. You probably have some more specific needs beyond simply showing
the different branches. Maybe you can be more specific?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #06; Mon, 19)
From: Junio C Hamano @ 2012-11-20 23:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vpq39up0m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
> Bunch of topics have been merged to 'next'.
>
> We are at the beginning of the 5th week of this release cycle
> (cf. http://tinyurl.com/gitcal), and I've moved many topics to the
> Stalled category, which will be discarded without prejudice soonish
> unless there are some updates. I am still a bit behind on some
> topics and already posted rerolls may have to be pulled in.
It feels a bit too busy/loud to issue two "What's cooking" in a row,
so here is an informal update.
- The following have graduated to 'master'.
cn/config-missing-path
jk/checkout-out-of-unborn
jk/maint-gitweb-xss
jk/maint-http-half-auth-fetch
jl/submodule-rm
kb/preload-index-more
mg/replace-resolve-delete
mh/alt-odb-string-list-cleanup
ml/cygwin-mingw-headers
pw/maint-p4-rcs-expansion-newline
rh/maint-gitweb-highlight-ext
ta/doc-cleanup
- Many topics have been merged to 'maint' in preparation for 1.8.0.1.
mg/maint-pull-suggest-upstream-to
mm/maint-doc-commit-edit
as/maint-doc-fix-no-post-rewrite
rs/lock-correct-ref-during-delete
rf/maint-mailmap-off-by-one
jk/maint-diff-grep-textconv
js/format-2047
sz/maint-curl-multi-timeout
po/maint-refs-replace-docs
ph/pull-rebase-detached
mm/maint-doc-remote-tracking
rs/branch-del-symref
nd/grep-true-path
jc/grep-pcre-loose-ends (early part)
da/mergetools-p4
jc/test-say-color-avoid-echo-escape
bw/config-lift-variable-name-length-limit
- A few topics have been resurrected from the stalled category to
cooking:
pp/gitweb-config-underscore
jc/apply-trailing-blank-removal
^ permalink raw reply
* [wishlist] support git flow-like view
From: Lisandro Damián Nicanor Pérez Meyer @ 2012-11-20 23:42 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 865 bytes --]
Hi! I am not suscribed to the list, so please CC-me.
I think this may have been proposed before, but I could not find anything in
the web, so I better try myself :)
The idea would be to gitk to show a "git flow-like"[0] view when it detects
git flow (or the user ask for it or...)
Basiccaly, you can show the main two branches: master and develop. Of course,
having the possibility to show feature/release/hotfixes branches would be
ideal.
Kinds regards, Lisandro.
[0] <http://nvie.com/posts/a-successful-git-branching-model/>
--
Esperando confirmación de ingredientes necesarios
que serán expuestos a la radiación...
Manera geek de expresar que se espera la compra
de carne para un típico asado argentino.
Silvio Rikemberg.
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Junio C Hamano @ 2012-11-20 23:43 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: Felipe Contreras, Andreas Schwab, Felipe Balbi, git,
Tomi Valkeinen
In-Reply-To: <20121120230955.GA9686@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> On Tue, Nov 20, 2012 at 02:30:02PM -0800, Junio C Hamano wrote:
>
>> We should probably fix the tools that generate these bogus
>> non-addresses first. What's wrong with
>>
>> Cc: stable kernel (v3.5 v3.6 v3.7) <stable@vger.kernel.org>
>>
>> which should be OK?
>>
>> Also I suspect that this should be also deemed valid:
>>
>> Cc: stable@vger.kernel.org (Stable kernel - v3.5 v3.6 v3.7)
>
> So maybe we should just use the original regex:
>
> $recipient =~ s/(.*>).*$/$1/
>
> which does not add regression for valid addresses, and just fails
> in some rare cases when '>' is used in garbage. It was sufficient
> for original issue reported by, and tested by Felipe.
>
> The problem with '>' would be fixed in separate patch. The same
> problem exits for invalid address generated by --cc-cmd
> (see [PATCH] git-send-email: don't return undefined value in
> extract_valid_address()). We would report an error in both cases,
> as suggested by Junio.
OK, sounds like a plan.
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-20 23:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, Andreas Schwab, Felipe Balbi, git,
Tomi Valkeinen
In-Reply-To: <7vhaojrjpx.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 02:30:02PM -0800, Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > On Tue, Nov 20, 2012 at 10:21 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> >
> >> --- a/git-send-email.perl
> >> +++ b/git-send-email.perl
> >> @@ -924,6 +924,10 @@ sub quote_subject {
> >> # use the simplest quoting being able to handle the recipient
> >> sub sanitize_address {
> >> my ($recipient) = @_;
> >> +
> >> + # remove garbage after email address
> >> + $recipient =~ s/(.*?<[^>]*>).*$/$1/;
> >
> > That won't work for 'foo@bar.com # test'. I think we should abandon
> > hopes of properly parsing an email address and just do:
> >
> > $recipient =~ s/(.*?) #.*$/$1/;
>
> We should probably fix the tools that generate these bogus
> non-addresses first. What's wrong with
>
> Cc: stable kernel (v3.5 v3.6 v3.7) <stable@vger.kernel.org>
>
> which should be OK?
>
> Also I suspect that this should be also deemed valid:
>
> Cc: stable@vger.kernel.org (Stable kernel - v3.5 v3.6 v3.7)
So maybe we should just use the original regex:
$recipient =~ s/(.*>).*$/$1/
which does not add regression for valid addresses, and just fails
in some rare cases when '>' is used in garbage. It was sufficient
for original issue reported by, and tested by Felipe.
The problem with '>' would be fixed in separate patch. The same
problem exits for invalid address generated by --cc-cmd
(see [PATCH] git-send-email: don't return undefined value in
extract_valid_address()). We would report an error in both cases,
as suggested by Junio.
Krzysiek
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-11-20 22:43 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <CAMP44s0WH-P7WY4UqhMX3WdrrSCYXUR9yCgsUV+mzLOCK5LkHQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Of course, transport-helper shouldn't even be specifying the negative
> (^) refs, but that's another story.
Hrm, I am not sure I understand what you mean by this.
How should it be telling the fast-export up to what commit the
receiving end should already have the history for (hence they do not
need to be sent)? Or are you advocating to re-send the entire
history down to the root commit every time?
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Junio C Hamano @ 2012-11-20 22:30 UTC (permalink / raw)
To: Felipe Contreras
Cc: Krzysztof Mazur, Andreas Schwab, Felipe Balbi, git,
Tomi Valkeinen
In-Reply-To: <CAMP44s3+vnKfhhh=qqU2vuKvWwhii4CQ7=YAuhFiceX1EDaVKQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Tue, Nov 20, 2012 at 10:21 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
>
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -924,6 +924,10 @@ sub quote_subject {
>> # use the simplest quoting being able to handle the recipient
>> sub sanitize_address {
>> my ($recipient) = @_;
>> +
>> + # remove garbage after email address
>> + $recipient =~ s/(.*?<[^>]*>).*$/$1/;
>
> That won't work for 'foo@bar.com # test'. I think we should abandon
> hopes of properly parsing an email address and just do:
>
> $recipient =~ s/(.*?) #.*$/$1/;
We should probably fix the tools that generate these bogus
non-addresses first. What's wrong with
Cc: stable kernel (v3.5 v3.6 v3.7) <stable@vger.kernel.org>
which should be OK?
Also I suspect that this should be also deemed valid:
Cc: stable@vger.kernel.org (Stable kernel - v3.5 v3.6 v3.7)
^ permalink raw reply
* git-fetch does not work from .git subdirectory
From: Timur Tabi @ 2012-11-20 22:24 UTC (permalink / raw)
To: git
I was under the impression that git commands which affect repository (as
opposed to the local file system) work from any subdirectory inside the
repository. For example:
[b04825@efes linux.cq-test]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi <timur@freescale.com>
Date: Wed Oct 31 15:56:20 2012 +0200
...
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi <timur@freescale.com>
Date: Wed Oct 31 15:56:20 2012 +0200
...
It appears, however, that git-fetch does not work this way:
[b04825@efes linux.cq-test]$ git fetch upstream master
From ../linux-2.6
* branch master -> FETCH_HEAD
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git fetch upstream master
fatal: '../linux-2.6.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
This makes it complicated because git hooks run from the .git directory on
normal repositories, but they run from the top-level directory on bare
repositories. Apparently, you need to be in the top-level directory for
git-fetch to run in any kind of repository.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re* [PATCH] gitweb: make remote_heads config setting work.
From: Junio C Hamano @ 2012-11-20 22:21 UTC (permalink / raw)
To: Jeff King; +Cc: Phil Pennock, git
In-Reply-To: <20121109163710.GD19725@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Nov 08, 2012 at 08:40:11PM -0800, Junio C Hamano wrote:
>
>> Looking at the code before this part:
>>
>> if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
>> $key = join(".", lc($hi), $mi, lc($lo));
>> } else {
>> $key = lc($key);
>> }
>> $key =~ s/^gitweb\.//;
>> return if ($key =~ m/\W/);
>>
>> the new code is munding the $hi and $mi parts, while the mistaken
>> configuration this patch is trying to correct is about the $lo part,
>> and possibly the $hi part, but never the $mi part.
>
> Good catch. I think the "return" in the existing code suffers from the
> same problem: it will bail on non-word characters in the $mi part, but
> that part should allow arbitrary characters.
I am tired of keeping the "expecting reroll" entries and having to
worry about them, so let's do this
-- >8 --
Subject: [squash] gitweb: make remote_heads config setting work
Only the top-level and bottom-level names are case insensitive and
spelled without "_". Protect future support of subsection names
from name mangling.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git c/gitweb/gitweb.perl w/gitweb/gitweb.perl
index f2144c8..c421fa4 100755
--- c/gitweb/gitweb.perl
+++ w/gitweb/gitweb.perl
@@ -2697,13 +2697,15 @@ sub git_get_project_config {
# only subsection, if exists, is case sensitive,
# and not lowercased by 'git config -z -l'
if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
+ $lo =~ s/_//g;
$key = join(".", lc($hi), $mi, lc($lo));
+ return if ($lo =~ /\W/ || $hi =~ /\W/);
} else {
$key = lc($key);
+ $key =~ s/_//g;
+ return if ($key =~ /\W/);
}
$key =~ s/^gitweb\.//;
- $key =~ s/_//g;
- return if ($key =~ m/\W/);
# type sanity check
if (defined $type) {
^ permalink raw reply related
* Re: [PATCH] git-send-email: don't return undefined value in extract_valid_address()
From: Junio C Hamano @ 2012-11-20 22:14 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: git
In-Reply-To: <20121120204736.GA7039@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> Yes, it's just to hide the warning, the error (warning in this case) it's
> already correctly generated:
>
> W: unable to extract a valid address from: x a.patch
But it is of no use if the message is sent out without the intended
recipient, no? It is too late when you notice it.
> Maybe we should change it to an error?
At least, when we are not giving the "final sanity check [Y/n]?"
prompt, I think the code should error out.
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Felipe Contreras @ 2012-11-20 22:06 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: Andreas Schwab, Junio C Hamano, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <20121120212126.GA12656@shrek.podlesie.net>
On Tue, Nov 20, 2012 at 10:21 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -924,6 +924,10 @@ sub quote_subject {
> # use the simplest quoting being able to handle the recipient
> sub sanitize_address {
> my ($recipient) = @_;
> +
> + # remove garbage after email address
> + $recipient =~ s/(.*?<[^>]*>).*$/$1/;
That won't work for 'foo@bar.com # test'. I think we should abandon
hopes of properly parsing an email address and just do:
$recipient =~ s/(.*?) #.*$/$1/;
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-20 21:21 UTC (permalink / raw)
To: Andreas Schwab
Cc: Felipe Contreras, Junio C Hamano, Felipe Balbi, git,
Tomi Valkeinen
In-Reply-To: <m2lidw11yb.fsf@igel.home>
On Tue, Nov 20, 2012 at 08:58:20PM +0100, Andreas Schwab wrote:
> How about "s/(.*?<[^>]*>).*$/$1/"? That will still fail on "<foo@bar>"
> <foo@bar>, but you'll need a full rfc822 parser to handle the general
> case anyway.
That will fail also on "<something>" <foo@bar>.
I think it's good compromise between complexity and correctness.
Felipe, may you check, it again? This time the change is trivial.
Andreas, may I add you in Thanks-to?
Thanks,
Krzysiek
-- >8 --
Subject: [PATCH] git-send-email: remove garbage after email address
In some cases it's very useful to add some additional information
after email in Cc-list, for instance:
"Cc: Stable kernel <stable@vger.kernel.org> #v3.4 v3.5 v3.6"
Currently the git refuses to add such invalid email to Cc-list,
when the Email::Valid perl module is available or just uses whole line
as the email address.
Now in sanitize_address() everything after the email address is
removed, so the resulting line is correct email address and Email::Valid
validates it correctly.
To avoid unnecessary complexity this code assumes that in phrase before
email address '<something>' never exists.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
git-send-email.perl | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..157eabc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -924,6 +924,10 @@ sub quote_subject {
# use the simplest quoting being able to handle the recipient
sub sanitize_address {
my ($recipient) = @_;
+
+ # remove garbage after email address
+ $recipient =~ s/(.*?<[^>]*>).*$/$1/;
+
my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
if (not $recipient_name) {
--
1.8.0.283.gc57d856
^ permalink raw reply related
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Junio C Hamano @ 2012-11-20 21:07 UTC (permalink / raw)
To: Marc Khouzam; +Cc: Felipe Contreras, SZEDER Gábor, git
In-Reply-To: <CAFj1UpFTu7GnpKSvs6qGH6XjAT16RAk4rmdX0sPFOo9ABg8BKg@mail.gmail.com>
Marc Khouzam <marc.khouzam@gmail.com> writes:
>> This one is already merged to 'next'.
>
> Awesome! I didn't notice.
>
> If I want to suggest an improvement (like checking if the bash
> script is available), do I just post a patch here?
Yes, as a follow-up patch (or two).
Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: don't return undefined value in extract_valid_address()
From: Krzysztof Mazur @ 2012-11-20 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8v9wrpdz.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 12:27:36PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
> > In the fallback check, when Email::Valid is not available, the
> > extract_valid_address() does not check for success of matching regex,
> > and $1, which can be undefined, is always returned. Now if match
> > fails an empty string is returned.
Maybe the last line of comment should be changed to:
fails an empty string is returned to indicate failure.
>
> That much we can read from the code, but a bigger question is why
> would it be a good thing for the callers? Wouldn't they want to
> be able to distinguish a failure from an empty string?
In this case returning empty string does not make sense, so it's
really used to indicate failure.
>
> > Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
> > ---
> > This fixes following warnings:
> > Use of uninitialized value in string eq at ./git-send-email.perl line 1017.
> > Use of uninitialized value in quotemeta at ./git-send-email.perl line 1017.
> > W: unable to extract a valid address from: x a.patch
> >
> > when invalid email address was added by --cc-cmd,
> > ./git-send-email.perl --dry-run --to a@podlesie.net --cc-cmd=echo x a.patch
>
> In other words, would we want to *hide* (not "fix") the warning?
> Shouldn't we be barfing loudly and possibly erroring it out until
> the user fixes her --cc-cmd?
>
Yes, it's just to hide the warning, the error (warning in this case) it's
already correctly generated:
W: unable to extract a valid address from: x a.patch
Maybe we should change it to an error?
Krzysiek
^ permalink raw reply
* Re: git merge commits are non-deterministic? what changed?
From: Junio C Hamano @ 2012-11-20 20:39 UTC (permalink / raw)
To: Ulrich Spörlein
Cc: Michael J Gruber, Jeff King, Matthieu Moy, Andreas Schwab, git
In-Reply-To: <20121120162226.GK69724@acme.spoerlein.net>
Ulrich Spörlein <uqs@spoerlein.net> writes:
> But this will never be changed, it would break the fundamental git
> storage model as it is in place now.
It doesn't just break "storage model", but more importantly, it
breaks the semantics.
Imagine that things started breaking after merging your topic branch
'foo' to the integration branch 'master', and how people would
perceive the situation. Everybody would say your topic 'foo' broke
the build. Nobody except you would say, even if the tip of your
topic 'foo' alone works perfectly, merging the 'master' to your
topic 'foo' broke that topic. The topic should have been adjusted
to the updated baseline, that is the 'master' branch before this
merge since your topic 'foo' forked off of it, before or during the
merge.
To express what was merged into what, the order of parents in the
commit is fundamentally a part of what a commit is.
^ permalink raw reply
* Re: [PATCH] git-send-email: don't return undefined value in extract_valid_address()
From: Junio C Hamano @ 2012-11-20 20:27 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: git
In-Reply-To: <1353414053-25261-1-git-send-email-krzysiek@podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> In the fallback check, when Email::Valid is not available, the
> extract_valid_address() does not check for success of matching regex,
> and $1, which can be undefined, is always returned. Now if match
> fails an empty string is returned.
That much we can read from the code, but a bigger question is why
would it be a good thing for the callers? Wouldn't they want to
be able to distinguish a failure from an empty string?
> Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
> ---
> This fixes following warnings:
> Use of uninitialized value in string eq at ./git-send-email.perl line 1017.
> Use of uninitialized value in quotemeta at ./git-send-email.perl line 1017.
> W: unable to extract a valid address from: x a.patch
>
> when invalid email address was added by --cc-cmd,
> ./git-send-email.perl --dry-run --to a@podlesie.net --cc-cmd=echo x a.patch
In other words, would we want to *hide* (not "fix") the warning?
Shouldn't we be barfing loudly and possibly erroring it out until
the user fixes her --cc-cmd?
> git-send-email.perl | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 5a7c29d..045f25f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -831,12 +831,12 @@ sub extract_valid_address {
> $address =~ s/^\s*<(.*)>\s*$/$1/;
> if ($have_email_valid) {
> return scalar Email::Valid->address($address);
> - } else {
> - # less robust/correct than the monster regexp in Email::Valid,
> - # but still does a 99% job, and one less dependency
> - $address =~ /($local_part_regexp\@$domain_regexp)/;
> - return $1;
> }
> +
> + # less robust/correct than the monster regexp in Email::Valid,
> + # but still does a 99% job, and one less dependency
> + return $1 if $address =~ /($local_part_regexp\@$domain_regexp)/;
> + return "";
> }
>
> # Usually don't need to change anything below here.
^ permalink raw reply
* Re: [PATCH 14/13] test-wildmatch: avoid Windows path mangling
From: Junio C Hamano @ 2012-11-20 20:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Jeff King, Nguyễn Thái Ngọc Duy
In-Reply-To: <50AB2B0F.8090808@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
> The MSYS bash mangles arguments that begin with a forward slash
> when they are passed to test-wildmatch. This causes tests to fail.
> Avoid mangling by prepending "XXX", which is removed by
> test-wildmatch before further processing.
>
> [J6t: reworded commit message]
>
> Reported-by: Johannes Sixt <j6t@kdbg.org>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Works well, and I'm fine with this work-around.
>
> -- Hannes
Thanks, but you need to fix your format-patch somehow.
> @@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
> match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
> match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
> match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
> -match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
> -match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
> +match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
> +match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
> match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
> match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
> diff --git a/test-wildmatch.c b/test-wildmatch.c
This hunk claims that there are 8 lines in preimage and postimage,
but it is not the case. It has only 7 lines each.
You also have the first line of the next patch "diff --git" somehow
indented. How did this happen?
> index 74c0864..e384c8e 100644
> --- a/test-wildmatch.c
> +++ b/test-wildmatch.c
> @@ -3,6 +3,14 @@
> int main(int argc, char **argv)
> {
> + int i;
> + for (i = 2; i < argc; i++) {
> + if (argv[i][0] == '/')
> + die("Forward slash is not allowed at the beginning of the\n"
> + "pattern because Windows does not like it. Use `XXX/' instead.");
> + else if (!strncmp(argv[i], "XXX/", 4))
> + argv[i] += 3;
> + }
> if (!strcmp(argv[1], "wildmatch"))
> return !!wildmatch(argv[3], argv[2], 0);
> else if (!strcmp(argv[1], "iwildmatch"))
And again this claims that the preimage has 6 lines while the
postimage has 14. Somebody is overcounting, or perhaps you removed
the first pre-context by hand without adjusting the line number?
^ 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