* Re: [RFC/PATCH] cherry-pick/revert: add support for -X/--strategy-option
From: Jonathan Nieder @ 2010-12-28 19:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Christian Couder, Justin Frankel, Bert Wesarg,
Eyvind Bernhardsen, Kevin Ballard
In-Reply-To: <7v7hetyeom.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Pong, if you are pinging me. I thought you wanted to only discuss it
> first with RFC and meant to follow up on a real-for-inclusion patch.
You thought correctly. In this case I can't think of any change this
needs on top to make this real for inclusion so I just bumped the
thread.
There were two hints at improvements in this thread (separate topic):
the "git merge" manual could use some discussion of the distinction
between --renormalize and --ignore-whitespace-at-eol, and am, rebase,
stash, and "checkout -m <tree>" ought to have -X plumbed, too.
^ permalink raw reply
* Re: [PATCH] setup: translate symlinks in filename when using absolute paths
From: Junio C Hamano @ 2010-12-28 19:47 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belon; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <1293447277-30598-1-git-send-email-carenas@sajinet.com.pe>
Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
> otherwise, comparison to validate against work tree will fail when
> the path includes a symlink and the name passed is not canonical.
>
> Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
I take that "path" and "name passed" refer to the same thing (i.e. "path"
parameter) in the above.
I think you are trying to handle the case where:
- you give "/home/carenas/one" from the command line;
- $PWD is "/home/carenas"; and
- "/home/carenas" is a symlink to "/net/host/home/carenas"
and the scan-from-the-beginning-of-string check done between
"/home/carenas/one" and the return value of get_git_work_tree() which
presumably is "/net/host/home/carenas" disagrees. I wonder if a more
correct solution might be to help get_git_work_tree() to match the notion
of where the repository and its worktree are to the idea of where the user
thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
bit better?
That would involve tweaking make_absolute_path() I guess?
Note that your patch is the right thing to do either case, i.e. with or
without such a change to make_absolute_path(), as the function is used to
set up the return value from get_git_work_tree(). Anything we compare
with it should have passed make_absolute_path() at least once.
Nguyễn?
> ---
> setup.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index 91887a4..e7c0d4d 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -7,10 +7,13 @@ static int inside_work_tree = -1;
> char *prefix_path(const char *prefix, int len, const char *path)
> {
> const char *orig = path;
> - char *sanitized = xmalloc(len + strlen(path) + 1);
> - if (is_absolute_path(orig))
> - strcpy(sanitized, path);
> - else {
> + char *sanitized;
> + if (is_absolute_path(orig)) {
> + const char *temp = make_absolute_path(path);
> + sanitized = xmalloc(len + strlen(temp) + 1);
> + strcpy(sanitized, temp);
> + } else {
> + sanitized = xmalloc(len + strlen(path) + 1);
> if (len)
> memcpy(sanitized, prefix, len);
> strcpy(sanitized + len, path);
> --
> 1.7.3.4.626.g73e7b.dirty
^ permalink raw reply
* Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Junio C Hamano @ 2010-12-28 19:58 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: git
In-Reply-To: <20101227080343.GA15026@orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> If the user's shell in NSS passwd is /bin/false (eg as found during Gentoo's
> package building), the git-rebase exec tests will fail, because they call
> $SHELL around the command, and in the existing testcase, $SHELL was not being
> cleared sufficently.
> ---
> t/t3404-rebase-interactive.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index d3a3bd2..7d8147b 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -71,8 +71,9 @@ test_expect_success 'setup' '
> # "exec" commands are ran with the user shell by default, but this may
> # be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
> # to create a file. Unseting SHELL avoids such non-portable behavior
> -# in tests.
> +# in tests. It must be exported for it to take effect where needed.
> SHELL=
> +export SHELL
Thanks; will queue this version to 'maint'.
I have this nagging suspicion that we may want to revisit this to assign
$SHELL_PATH to it before exporting, and that this might be better done in
t/test-lib.sh at the beginning. Note that unlike my earlier "your v1
might be less portable than desired", these two points are only
speculations and RFCs.
^ permalink raw reply
* Re: [RFC/PATCH] Re: git submodule -b ... of current HEAD fails
From: Junio C Hamano @ 2010-12-28 21:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Klaus Ethgen, Sven Verdoolaege, Jens Lehmann
In-Reply-To: <20101201185046.GB27024@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> git submodule add -b $branch $repository
>
> fails when HEAD already points to $branch in $repository.
I was reviewing the overall picture before tagging 1.7.4-rc0 and started
wondering if this was a good change. If repository already had branch
checked out, and if it was pointing at a commit that was different from
whatever was taken from origin, shouldn't the command _fail_ to prevent
the divergent commits from getting lost?
^ permalink raw reply
* Re: cherry-pick / pre-commit hook?
From: Jakub Narebski @ 2010-12-28 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Dave Abrahams, git
In-Reply-To: <7vy679wynd.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think the basic direction could be (I haven't thought things through,
> just a strawman):
>
> - Allow --verify/--no-verify to all commands that possibly create a new
> commit, and run pre-commit hook where an updated index is about to be
> made into a commit (for some commands this may not be very easy);
>
> - The guideline of picking the default would probably look like this:
>
> (1) for existing commands, keep the current behaviour;
>
> (2) for a new command, --verify should be the default if the command is
> primarily about letting the user do what s/he would/could/should
> have done as "git commit" in the first place (e.g. cherry-picking
> one's own commit from a separate branch or rebasing one's own
> unpublished branch on top of updated upstream), and --no-verify
> otherwise (i.e. taking other's work and using it in a context
> different from the original).
Does it mean that for now (and perhaps also for later) it means that
"git commit" by default runs pre-commit hook, unless one use
--no-verify, and that all comands that create a new commit (rebase,
cherry-pick, revert, merge/pull) can request for pre-commit hook to be
run (if they create commit) with --verify?
I think it is a very good idea, though I don't know how difficult it
would be to make all commands that can create commit accept --verify..
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* is there a roadmap for git... and
From: Marlene Cote @ 2010-12-28 22:50 UTC (permalink / raw)
To: git@vger.kernel.org
Are there any plans to pull in the submodule patches into the main git distribution?
--------------------------
Regards,
Marlene Cote
Affirmed Networks
978-268-0821
^ permalink raw reply
* (unknown),
From: COCA COLA @ 2010-12-28 22:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
KINDLY DOWNLOAD ATTACHMENT AS YOUR EMAIL WAS SELECTED AND YOU HAVE WON ONE MILLION POUNDS
[-- Attachment #2: COCA COLA NOTIFICATION.doc --]
[-- Type: application/msword, Size: 42496 bytes --]
^ permalink raw reply
* Re: [PATCH 05/31] rebase: improve detection of rebase in progress
From: Junio C Hamano @ 2010-12-28 23:08 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Johannes Schindelin, Johannes Sixt, Christian Couder
In-Reply-To: <1293528648-21873-6-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> Currently, the existence of rebase-merge/ is tested with 'test -d',
> while the existence of rebase-apply/ is tested by creating the
> directory and then deleting it again. Any good reason for this?
I don't recall how the merge side reached the current shape of the code,
but I think the rebase-apply one was that we wanted to make sure not only
we don't have a directory but also we actually _can_ create one. If
somebody had a bad permission set, "test -d" wouldn't help us much. We
would fail later and error diagnosis codepath should do the right thing
anyway, so it is not a correctness issue, but is more about attempting to
notice an error early rather than late.
^ permalink raw reply
* Re: [PATCH 02/31] rebase: refactor reading of state
From: Junio C Hamano @ 2010-12-28 23:08 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Johannes Schindelin, Johannes Sixt, Christian Couder
In-Reply-To: <1293528648-21873-3-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> +read_state () {
> + if test -d "$merge_dir"
> + then
> + state_dir="$merge_dir"
> + prev_head=$(cat "$merge_dir"/prev_head) &&
> + end=$(cat "$merge_dir"/end) &&
> + msgnum=$(cat "$merge_dir"/msgnum)
> + else
> + state_dir="$apply_dir"
> + fi &&
> + head_name=$(cat "$state_dir"/head-name) &&
> + onto=$(cat "$state_dir"/onto) &&
> + orig_head=$(cat "$state_dir"/orig-head) &&
> + GIT_QUIET=$(cat "$state_dir"/quiet)
> +}
> +
> continue_merge () {
> test -n "$prev_head" || die "prev_head must be defined"
> test -d "$merge_dir" || die "$merge_dir directory does not exist"
> @@ -138,10 +154,6 @@ call_merge () {
> }
>
> move_to_original_branch () {
> - test -z "$head_name" &&
> - head_name="$(cat "$merge_dir"/head-name)" &&
> - onto="$(cat "$merge_dir"/onto)" &&
> - orig_head="$(cat "$merge_dir"/orig-head)"
It used to be safe to call this without head_name and friends set, because
the function took care of reading these itself. Nobody calls this without
head_name set anymore?
I am not complaining nor suggesting to add an unnecessary "read_state"
here only to slow things down---I am making sure that you removed this
because you know it is unnecessary.
> @@ -220,13 +232,9 @@ do
> echo "mark them as resolved using git add"
> exit 1
> }
> + read_state
> if test -d "$merge_dir"
> then
> - prev_head=$(cat "$merge_dir/prev_head")
> - end=$(cat "$merge_dir/end")
> - msgnum=$(cat "$merge_dir/msgnum")
> - onto=$(cat "$merge_dir/onto")
> - GIT_QUIET=$(cat "$merge_dir/quiet")
Even though this patch may make the code shorter, it starts to read
head_name and orig_head that we previously did not open and change the
values of variables with what are read from them. Does this change affect
the behaviour in any way (either in performance or in correctness)?
> @@ -236,10 +244,6 @@ do
> finish_rb_merge
> exit
> fi
> - head_name=$(cat "$apply_dir"/head-name) &&
> - onto=$(cat "$apply_dir"/onto) &&
> - orig_head=$(cat "$apply_dir"/orig-head) &&
> - GIT_QUIET=$(cat "$apply_dir"/quiet)
> git am --resolved --3way --resolvemsg="$RESOLVEMSG" &&
> move_to_original_branch
Earlier move-to-original-branch was Ok to be called without head_name, and
the old code here read from the file anyway, so it didn't matter, but now
it seems that the first check and assignment you removed from the function
may matter because this caller does not even read from head_name. Are you
sure about this change?
> @@ -279,18 +275,15 @@ do
> die "No rebase in progress?"
>
> git rerere clear
> -
> - test -d "$merge_dir" || merge_dir="$apply_dir"
My heartbeat skipped when I first saw this. Thanks to the previous
commit, it was exposed that somebody reused $dotest that was only to be
used when using merge machinery because the things left to be done in this
codepath are common between the merge and apply, which is kind of sloppy,
but that sloppiness is now gone ;-).
Are there places that read from individual files for states left after
this patch, or read_state is the only interface to get to the states? If
the latter that would be a great news, and also would suggest that we may
want to have a corresponding write_state function (and we may even want to
make the state into a single file to reduce I/O---but that is a separate
issue that can be done at the very end of the series if it turns out to be
beneficial).
Of course it is fine if introduction of read_state is an attempt to catch
most common cases, but it would reduce chances of mistake if the coverage
were 100% (as opposed to 99.9%) hence this question.
^ permalink raw reply
* Re: [PATCH 01/31] rebase: clearer names for directory variables
From: Junio C Hamano @ 2010-12-28 23:08 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Johannes Schindelin, Johannes Sixt, Christian Couder
In-Reply-To: <1293528648-21873-2-git-send-email-martin.von.zweigbergk@gmail.com>
If this were just "s/dotest/merge_dir/g" and the same for rebase-apply, I
would have to say it is long overdue ;-)
I read the patch and didn't spot any glaring mistake, but I wasn't being
as careful as I usually am.
Thanks.
^ permalink raw reply
* Re: [PATCH 16/31] rebase -i: support --stat
From: Junio C Hamano @ 2010-12-28 23:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Martin von Zweigbergk, git, Johannes Sixt, Christian Couder
In-Reply-To: <alpine.DEB.1.00.1012281858300.1794@bonsai2>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 28 Dec 2010, Martin von Zweigbergk wrote:
>
>> diff --git a/git-rebase.sh b/git-rebase.sh
>> index 229e8d2..0fc580a 100755
>
> Hmpf... After a rebasing merge to junio/next:
The series applied cleanly near the tip of my 'master'. I've been
preparing to push out 1.7.4-rc0 so the commit I applied the series was
probably a few commits ahead of the public 'master', but I don't think
there is anything that may conflict with or may be required for this
series to make any difference.
Please check tonight's 'pu' where the series is parked.
Thanks.
^ permalink raw reply
* Re: [PATCH 16/31] rebase -i: support --stat
From: Johannes Schindelin @ 2010-12-28 23:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, git, Johannes Sixt, Christian Couder
In-Reply-To: <7vpqsltqpd.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 28 Dec 2010, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 28 Dec 2010, Martin von Zweigbergk wrote:
> >
> >> diff --git a/git-rebase.sh b/git-rebase.sh
> >> index 229e8d2..0fc580a 100755
> >
> > Hmpf... After a rebasing merge to junio/next:
>
> The series applied cleanly near the tip of my 'master'.
Sorry, I should have been more specific. I updated to current 'next'
(a2bc419) of git://repo.or.cz/git.git/.
> Please check tonight's 'pu' where the series is parked.
Thanks, but unfortunately I have to tend to other things now.
Ciao,
Johannes
^ permalink raw reply
* Re: [RFC/PATCH] Re: git submodule -b ... of current HEAD fails
From: Jens Lehmann @ 2010-12-29 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Klaus Ethgen, Sven Verdoolaege
In-Reply-To: <7vipydwp50.fsf@alter.siamese.dyndns.org>
Am 28.12.2010 22:42, schrieb Junio C Hamano:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> git submodule add -b $branch $repository
>>
>> fails when HEAD already points to $branch in $repository.
>
> I was reviewing the overall picture before tagging 1.7.4-rc0 and started
> wondering if this was a good change. If repository already had branch
> checked out, and if it was pointing at a commit that was different from
> whatever was taken from origin, shouldn't the command _fail_ to prevent
> the divergent commits from getting lost?
But doesn't this change only affect the case where the submodule is
freshly cloned, so there is no chance of losing local changes?
(But AFAIK the patch doesn't really fix the issue, please see [1] and
Jonathan's followup)
[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/772659/focus=163242
^ permalink raw reply
* Re: [RFC/PATCH] Re: git submodule -b ... of current HEAD fails
From: Junio C Hamano @ 2010-12-29 0:34 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Jonathan Nieder, git, Klaus Ethgen,
Sven Verdoolaege
In-Reply-To: <4D1A7B42.1050907@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> But doesn't this change only affect the case where the submodule is
> freshly cloned, so there is no chance of losing local changes?
My fault, for not looking at the surrounding context.
> (But AFAIK the patch doesn't really fix the issue, please see [1] and
> Jonathan's followup)
>
> [1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/772659/focus=163242
I think we queued the later round just uses "checkout -B"; shouldn't that
work?
^ permalink raw reply
* Re: cherry-pick / pre-commit hook?
From: Dave Abrahams @ 2010-12-29 1:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <m3vd2djzhp.fsf@localhost.localdomain>
At Tue, 28 Dec 2010 14:38:20 -0800 (PST),
Jakub Narebski wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I think the basic direction could be (I haven't thought things through,
> > just a strawman):
> >
> > - Allow --verify/--no-verify to all commands that possibly create a new
> > commit, and run pre-commit hook where an updated index is about to be
> > made into a commit (for some commands this may not be very easy);
> >
> > - The guideline of picking the default would probably look like this:
> >
> > (1) for existing commands, keep the current behaviour;
> >
> > (2) for a new command, --verify should be the default if the command is
> > primarily about letting the user do what s/he would/could/should
> > have done as "git commit" in the first place (e.g. cherry-picking
> > one's own commit from a separate branch or rebasing one's own
> > unpublished branch on top of updated upstream), and --no-verify
> > otherwise (i.e. taking other's work and using it in a context
> > different from the original).
>
> Does it mean that for now (and perhaps also for later) it means that
> "git commit" by default runs pre-commit hook, unless one use
> --no-verify, and that all comands that create a new commit (rebase,
> cherry-pick, revert, merge/pull) can request for pre-commit hook to be
> run (if they create commit) with --verify?
>
> I think it is a very good idea
+1!
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: [PATCH 05/31] rebase: improve detection of rebase in progress
From: Martin von Zweigbergk @ 2010-12-28 20:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, git, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <7vaajpv6lh.fsf@alter.siamese.dyndns.org>
On Tue, 28 Dec 2010, Junio C Hamano wrote:
> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
>
> > Currently, the existence of rebase-merge/ is tested with 'test -d',
> > while the existence of rebase-apply/ is tested by creating the
> > directory and then deleting it again. Any good reason for this?
>
> I don't recall how the merge side reached the current shape of the code,
> but I think the rebase-apply one was that we wanted to make sure not only
> we don't have a directory but also we actually _can_ create one. If
> somebody had a bad permission set, "test -d" wouldn't help us much. We
> would fail later and error diagnosis codepath should do the right thing
> anyway, so it is not a correctness issue, but is more about attempting to
> notice an error early rather than late.
Yeah, I was wondering if that might have been the reason. Why would
anyone set such permissions on .git (keep in mind that I am no
Linux/Unix expert)?
I saw that the code was introduced [1] when the directory was called
.dotest and I believe this directory was created at the top level
(i.e. a sibling to .git). Could it be that it was reasonable for the
user to set such permissions back then (on the top level dir), but not
any longer (on the .git dir)?
Either way, if it is good to have the that check for rebase-apply/,
wouldn't it be good to have for rebase-merge/ as well?
/Martin
[1] 7f4bd5d (rebase: one safety net, one bugfix and one optimization.,
2005-11-28)
^ permalink raw reply
* Re: [PATCH 01/31] rebase: clearer names for directory variables
From: Martin von Zweigbergk @ 2010-12-28 20:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, git, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <7vtyhxts0a.fsf@alter.siamese.dyndns.org>
On Tue, 28 Dec 2010, Junio C Hamano wrote:
> If this were just "s/dotest/merge_dir/g" and the same for rebase-apply, I
> would have to say it is long overdue ;-)
Yes, that should be all!
Well, to be precise, in the "@@ -560,35 +561,35 @@ then" hunk, I also
moved the quotes to contain the file name as was done for
rebase-merge. I redid the search/replace just to double check.
^ permalink raw reply
* Re: Git Architecture Question
From: Maaartin @ 2010-12-29 3:58 UTC (permalink / raw)
To: git
In-Reply-To: <20FFFEFA-5808-4673-B876-C5F76B52D12E@gmail.com>
Anuj Gakhar <anuj.gakhar <at> gmail.com> writes:
>
> Hi all,
>
> I am new to Git and learning this powerful tool these days.
>
> I have a simple question :-
>
> I work on a project that has 3 different environments. dev, staging
> and production. dev is obviously the local git repo that all dev's
> work on. staging is where most of the development takes places on a
> daily basis. and production is where least development happens but we
> still do it because sometimes we have to fix things quickly directly
> on the production server.
>
> So how should I set this up ?
>
> 2 branches staging and master (default) ?
I wouldn't use "master" for the production branch, I'd call it simply
"production" (there's nothing special about master, except that it's the
default when you start). However, it's quite easy to change it anytime.
Especially, each developer may create their own private branches at will. When
working on multiple topics concurrently you'll probably create multiple shared
"staging" branches. It's all very fast and very easy to do.
> How can I make it so that the staging branch gets deployed to a
> different folder on the server and the master branch gets deployed on
> a different folder ?
You can control both the working tree directory and the git directory using
environment variables (GIT_WORK_TREE and GIT_DIR), so it's easy, e.g.
cd stagingFolder; GIT_DIR=..../.git git checkout staging
You can use options like --git-dir instead, s. http://www.kernel.org/pub/
software/scm/git/docs/
> Once a week, we would merge all the staging work into production and
> make a release.
>
> Any ideas ?
It may be useful to have a single person responsible for this merging.
^ permalink raw reply
* What's cooking in git.git (Dec 2010, #07; Tue, 28)
From: Junio C Hamano @ 2010-12-29 5:22 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
We are finally at 1.7.4-rc0 as of tonight ;-).
--------------------------------------------------
[New Topics]
* ae/better-template-failure-report (2010-12-18) 1 commit
- Improve error messages when temporary file creation fails
* jc/unpack-trees (2010-12-22) 2 commits
- unpack_trees(): skip trees that are the same in all input
- unpack-trees.c: cosmetic fix
* jn/cherry-pick-strategy-option (2010-12-10) 1 commit
- cherry-pick/revert: add support for -X/--strategy-option
* jn/perl-funcname (2010-12-27) 2 commits
- userdiff/perl: catch BEGIN/END/... and POD as headers
- diff: funcname and word patterns for perl
* pw/convert-pathname-substitution (2010-12-22) 2 commits
- t0021: avoid getting filter killed with SIGPIPE
- convert filter: supply path to external driver
--------------------------------------------------
[Graduated to "master"]
* jc/maint-am-abort-safely (2010-12-21) 1 commit
(merged to 'next' on 2010-12-21 at 81602bc)
+ am --abort: keep unrelated commits since the last failure and warn
* jk/commit-die-on-bogus-ident (2010-12-20) 2 commits
(merged to 'next' on 2010-12-21 at 7785c31)
+ commit: die before asking to edit the log message
+ ident: die on bogus date format
* nd/maint-fix-add-typo-detection (2010-11-27) 5 commits
(merged to 'next' on 2010-12-21 at 87c702b)
+ Revert "excluded_1(): support exclude files in index"
+ unpack-trees: fix sparse checkout's "unable to match directories"
+ unpack-trees: move all skip-worktree checks back to unpack_trees()
+ dir.c: add free_excludes()
+ cache.h: realign and use (1 << x) form for CE_* constants
* nd/setup (2010-11-26) 47 commits
(merged to 'next' on 2010-12-23 at a2bc4196)
+ setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd
+ git.txt: correct where --work-tree path is relative to
+ Revert "Documentation: always respect core.worktree if set"
+ t0001: test git init when run via an alias
+ Remove all logic from get_git_work_tree()
+ setup: rework setup_explicit_git_dir()
+ setup: clean up setup_discovered_git_dir()
+ t1020-subdirectory: test alias expansion in a subdirectory
+ setup: clean up setup_bare_git_dir()
+ setup: limit get_git_work_tree()'s to explicit setup case only
+ Use git_config_early() instead of git_config() during repo setup
+ Add git_config_early()
+ git-rev-parse.txt: clarify --git-dir
+ t1510: setup case #31
+ t1510: setup case #30
+ t1510: setup case #29
+ t1510: setup case #28
+ t1510: setup case #27
+ t1510: setup case #26
+ t1510: setup case #25
+ t1510: setup case #24
+ t1510: setup case #23
+ t1510: setup case #22
+ t1510: setup case #21
+ t1510: setup case #20
+ t1510: setup case #19
+ t1510: setup case #18
+ t1510: setup case #17
+ t1510: setup case #16
+ t1510: setup case #15
+ t1510: setup case #14
+ t1510: setup case #13
+ t1510: setup case #12
+ t1510: setup case #11
+ t1510: setup case #10
+ t1510: setup case #9
+ t1510: setup case #8
+ t1510: setup case #7
+ t1510: setup case #6
+ t1510: setup case #5
+ t1510: setup case #4
+ t1510: setup case #3
+ t1510: setup case #2
+ t1510: setup case #1
+ t1510: setup case #0
+ Add t1510 and basic rules that run repo setup
+ builtins: print setup info if repo is found
* pd/bash-4-completion (2010-12-15) 3 commits
(merged to 'next' on 2010-12-21 at dbf80ff)
+ Merge branch 'master' (early part) into pd/bash-4-completion
+ bash: simple reimplementation of _get_comp_words_by_ref
+ bash: get --pretty=m<tab> completion to work with bash v4
* rj/maint-difftool-cygwin-workaround (2010-12-14) 1 commit
(merged to 'next' on 2010-12-21 at 74b9069)
+ difftool: Fix failure on Cygwin
* rj/maint-test-fixes (2010-12-14) 5 commits
(merged to 'next' on 2010-12-21 at 8883a0c)
+ t9501-*.sh: Fix a test failure on Cygwin
+ lib-git-svn.sh: Add check for mis-configured web server variables
+ lib-git-svn.sh: Avoid setting web server variables unnecessarily
+ t9142: Move call to start_httpd into the setup test
+ t3600-rm.sh: Don't pass a non-existent prereq to test #15
* tf/commit-list-prefix (2010-11-26) 1 commit
(merged to 'next' on 2010-12-21 at 16e1351)
+ commit: Add commit_list prefix in two function names.
--------------------------------------------------
[Stalled]
* mg/cvsimport (2010-11-28) 3 commits
- cvsimport.txt: document the mapping between config and options
- cvsimport: fix the parsing of uppercase config options
- cvsimport: partial whitespace cleanup
I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other
people injected sanity to the discussion. Weatherbaloon patch sent, but
not queued here.
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
--------------------------------------------------
[Cooking]
* rj/test-fixes (2010-12-14) 4 commits
- t4135-*.sh: Skip the "backslash" tests on cygwin
- t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
- t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
- t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* hv/mingw-fs-funnies (2010-12-14) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Will be rerolled (Heiko, 2010-12-23)
* jn/svn-fe (2010-12-06) 18 commits
- vcs-svn: Allow change nodes for root of tree (/)
- vcs-svn: Implement Prop-delta handling
- vcs-svn: Sharpen parsing of property lines
- vcs-svn: Split off function for handling of individual properties
- vcs-svn: Make source easier to read on small screens
- vcs-svn: More dump format sanity checks
- vcs-svn: Reject path nodes without Node-action
- vcs-svn: Delay read of per-path properties
- vcs-svn: Combine repo_replace and repo_modify functions
- vcs-svn: Replace = Delete + Add
- vcs-svn: handle_node: Handle deletion case early
- vcs-svn: Use mark to indicate nodes with included text
- vcs-svn: Unclutter handle_node by introducing have_props var
- vcs-svn: Eliminate node_ctx.mark global
- vcs-svn: Eliminate node_ctx.srcRev global
- vcs-svn: Check for errors from open()
- vcs-svn: Allow simple v3 dumps (no deltas yet)
- vcs-svn: Error out for v3 dumps
Some RFC patches, to give them early and wider exposure.
* nd/struct-pathspec (2010-12-15) 21 commits
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* tr/merge-unborn-clobber (2010-08-22) 1 commit
- Exhibit merge bug that clobbers index&WT
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
^ permalink raw reply
* Re: [RFC/PATCH] Re: git submodule -b ... of current HEAD fails
From: Jens Lehmann @ 2010-12-29 9:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Klaus Ethgen, Sven Verdoolaege
In-Reply-To: <7vlj39to1t.fsf@alter.siamese.dyndns.org>
Am 29.12.2010 01:34, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> (But AFAIK the patch doesn't really fix the issue, please see [1] and
>> Jonathan's followup)
>>
>> [1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/772659/focus=163242
>
> I think we queued the later round just uses "checkout -B"; shouldn't that
> work?
That's what I thought too (and that is what I based my ack upon, the
patch hit the right spot and used the - according to the documentation
- better suited -B option). But while writing the test you rightfully
requested I noticed that using -B didn't change much. The reason is
that the following commands both fail in a freshly cloned repo:
$ git checkout -f -q -b master origin/master
fatal: git checkout: branch master already exists
$ git checkout -f -q -B master origin/master
fatal: Cannot force update the current branch.
So maybe the real problem here is that "git checkout -B" barfs when it
doesn't have anything to do instead of silently doing nothing?
So we maybe want to fix this issue in "git checkout"? Then the patch
will start working (and the test for it can be added in a later patch).
^ permalink raw reply
* Re: [PATCH] setup: translate symlinks in filename when using absolute paths
From: Carlo Marcelo Arenas Belon @ 2010-12-29 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguy???n Th??i Ng???c Duy
In-Reply-To: <7vr5d1wuh0.fsf@alter.siamese.dyndns.org>
On Tue, Dec 28, 2010 at 11:47:07AM -0800, Junio C Hamano wrote:
> Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
>
> > otherwise, comparison to validate against work tree will fail when
> > the path includes a symlink and the name passed is not canonical.
> >
> > Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
>
> I take that "path" and "name passed" refer to the same thing (i.e. "path"
> parameter) in the above.
yes, and sorry for the cryptic description; you detailed below though this
is triggered by the fact that when using an absolute path filename as a
parameter detection for worktree is failing because it was normalized
through make_absolute_path.
> I think you are trying to handle the case where:
>
> - you give "/home/carenas/one" from the command line;
> - $PWD is "/home/carenas"; and
> - "/home/carenas" is a symlink to "/net/host/home/carenas"
this will be a valid scenario, but the issue (with a different use case)
was reported in (which I missed to refer to when running git send-email):
http://thread.gmane.org/gmane.comp.version-control.git/164212
> and the scan-from-the-beginning-of-string check done between
> "/home/carenas/one" and the return value of get_git_work_tree() which
> presumably is "/net/host/home/carenas" disagrees. I wonder if a more
> correct solution might be to help get_git_work_tree() to match the notion
> of where the repository and its worktree are to the idea of where the user
> thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
> bit better?
are you suggesting symlinks would be left untouched at least during
resolution for work_dir?, why is even necesary to resolve the links for
other users of that function?
Carlo
^ permalink raw reply
* Update index with a pickaxed diff
From: Jeenu V @ 2010-12-29 11:33 UTC (permalink / raw)
To: git
I'd like to know if there's a quick way of updating the index with the
output of 'git diff -S<expr>'. I find this useful if the change set
that I wanted to include results from, for example, a mass identifier
renaming. That would be easier, especially when my working directory
is already dirty with other changes, and I don't have to interactively
filter out change sets, other than those matching <expr>.
Thanks.
--
Jeenu
^ permalink raw reply
* Re: [PATCH] setup: translate symlinks in filename when using absolute paths
From: Nguyen Thai Ngoc Duy @ 2010-12-29 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlo Marcelo Arenas Belon, git
In-Reply-To: <7vr5d1wuh0.fsf@alter.siamese.dyndns.org>
2010/12/29 Junio C Hamano <gitster@pobox.com>:
> Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
>
>> otherwise, comparison to validate against work tree will fail when
>> the path includes a symlink and the name passed is not canonical.
>>
>> Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
>
> I take that "path" and "name passed" refer to the same thing (i.e. "path"
> parameter) in the above.
>
> I think you are trying to handle the case where:
>
> - you give "/home/carenas/one" from the command line;
> - $PWD is "/home/carenas"; and
> - "/home/carenas" is a symlink to "/net/host/home/carenas"
>
> and the scan-from-the-beginning-of-string check done between
> "/home/carenas/one" and the return value of get_git_work_tree() which
> presumably is "/net/host/home/carenas" disagrees. I wonder if a more
> correct solution might be to help get_git_work_tree() to match the notion
> of where the repository and its worktree are to the idea of where the user
> thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
> bit better?
I tend to agree. Will cause less surprises (such as this one).
> That would involve tweaking make_absolute_path() I guess?
Hm.. can we avoid converting work_tree to absolute path unless people
explicitly set it (via --work-tree and GIT_WORK_TREE)? Basically
worktree will be relative to cwd. Usually it's just ".". When people
run commands outside worktree, it's the relative "cwd/to/worktree".
I'm wondering if we can just avoid the use of make_absolute_path()
completely in get_git_work_tree()..
> Note that your patch is the right thing to do either case, i.e. with or
> without such a change to make_absolute_path(), as the function is used to
> set up the return value from get_git_work_tree(). Anything we compare
> with it should have passed make_absolute_path() at least once.
Yes, I think that should that be done inside normalize_path_copy(),
not prefix_path().
>> setup.c | 11 +++++++----
>> 1 files changed, 7 insertions(+), 4 deletions(-)
Also Carlo, tests should be good for illustration and regression
purposes. I know you described in detail in another mail. But mails
tend to get lost.
--
Duy
^ permalink raw reply
* Re: Update index with a pickaxed diff
From: Thomas Rast @ 2010-12-29 13:54 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <AANLkTi=BJ-8FaN+rk6_74mgM0PVzVP5uhV3aO1A3jUS3@mail.gmail.com>
Jeenu V wrote:
> I'd like to know if there's a quick way of updating the index with the
> output of 'git diff -S<expr>'.
git diff <whatever> | git apply --cached
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 13/14] t4135-*.sh: Skip the "backslash" tests on cygwin
From: Nguyen Thai Ngoc Duy @ 2010-12-29 13:56 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Johannes Sixt, Junio C Hamano, GIT Mailing-list, jrnieder
In-Reply-To: <4D1A2827.6070503@ramsay1.demon.co.uk>
On Wed, Dec 29, 2010 at 1:10 AM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
> Nguyen Thai Ngoc Duy wrote:
>> On Wed, Dec 22, 2010 at 2:31 AM, Ramsay Jones
>> <ramsay@ramsay1.demon.co.uk> wrote:
>>> The problem boils down to the call to strncmp_icase() suppressing the call to
>>> fnmatch() when the pattern contains glob chars, but the (remaining) string is
>>> equal to the name; thus returning an exact match (MATCHED_EXACTLY) rather than
>>> calling fnmatch (and returning either no-match or MATCHED_FNMATCH).
>>
>> I think that's expected behavior. Wildcard pathspecs are fixed
>> pathspecs will additional wildcard matching support and can match both
>> ways. See 186d604 (glossary: define pathspec)
>
> Really? Hmm, that seems ... odd! (To be clear: you are saying that an exact
> match, *even if the pattern contains glob chars*, takes precedence over the
> glob match! - again *odd*)
not exactly taking precedence. I would say it's "normal pathspecs with
extra capability", so it can match more
> Well, if you are happy with that ...
Well, we have two options here: either that, or declare it a day
(near) zero bug [1] with potentially massive impact. Personally I'd go
with which ever way that is less work :) as long as it does not annoy
me (much).
[1] Exerpt from 56fc510 ([PATCH] git-ls-files: generalized pathspecs -
2005-08-21): "the "matching" criteria is a combination of "exact path
component match" (the same as the git-diff-* family), and
"fnmatch()"." Git makes digging history fun.
--
Duy
^ 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