* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Jens Lehmann @ 2011-09-13 19:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, git-dev
In-Reply-To: <20110912224934.GA28994@sigill.intra.peff.net>
Am 13.09.2011 00:49, schrieb Jeff King:
> So with a set of changes like:
>
> [assume submodule at commit A, superproject at commit B]
>
> 1. Make commit C in submodule repo.
>
> 2. Make commit D in superproject repo.
>
> 3. Make commit E in submodule repo.
>
> 4. Make commit F in superproject repo.
>
> what does it buy us to find out that the submodule changed from "A" to
> "C"? We can't actually fetch it. We can only fetch the tips of the
> submodule and hope that they include everything we wanted (i.e., both C
> and E; which might not be the case of E rewound and is not a descendant
> of C).
Yes. But working with submodules in my experience only then works well
when you never drop a submodule commit recorded in any superproject. At
my dayjob we have the convention: You may only record commits that are
on the submodule's master - or another never to be rewound integration
branch - in the superproject. That gives us all needed commits in a
simple fetch.
> So since we must accept that we can't necessarily get every intermediate
> step, I wonder if we are simply better off diffing the "before" and
> "after" state of a particular ref, rather than traversing. It's way
> cheaper, and is just as likely to give us the same information (i.e.,
> which submodule paths had changed commits).
The real world use case I have for that is that when a bug introduced by
a new submodule commit is detected later on, the superproject's fix
records an older submodule commit to remove the problematic change from
the superproject. But the submodule's branch isn't rewound (as that is
most probably master) but a fix is applied on top of it. Then that one
gets tested and - if it was found ok - recorded in the superproject.
Changes like this could be overlooked if you only compare "before" and
"after" instead of traversing, leading to not fetching a submodule which
does have new commits that are used in the newly fetched superproject's
commits. I'd like to have on-demand fetch keep the correct solution of
traversing unless we have good reasons against it, especially as teaching
checkout & friends to recursively update submodules too depends on all
needed commits being present.
^ permalink raw reply
* git checkout --orphan skips reflogging
From: Dmitry Ivankov @ 2011-09-13 18:28 UTC (permalink / raw)
To: Git List
In short, git checkout --orphan doesn't write
HEAD_sha1 -> 00000
entry to logs/HEAD, while git-comit will write
00000 -> new_orphan_HEAD_sha1
entry. And then reflog backward walk will stop on 000 -> entry and
won't see earlier history.
How to reproduce:
$ git init test && cd test
$ git commit -m A --allow-empty
$ git checkout --orphan topic
$ git commit -m B --allow-empty
$ git log -g --oneline HEAD
some_sha1 HEAD@{0}: commit (initial): B
# oops, where are my old HEADs?
$ cat .git/logs/HEAD
000.. another_sha1 ... commit (initial): A
000.. some_sha1 ... commit (initial): B
# phew, at least I can find them by hand
Isn't it also a bug in reflog walking that we rely on each old_sha1
being new_sha1 of a previous entry?
^ permalink raw reply
* Re: [PATCH v2 0/7] Improved infrastructure for refname normalization
From: Junio C Hamano @ 2011-09-13 17:43 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, cmn, A Large Angry SCM
In-Reply-To: <4E6ED90D.1090704@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Consistency of the UI should be the goal. Supporting unnormalized
> refnames some places, but not others, will just confuse and frustrate
> users.
> ...
> So I propose the following:
>
> * Institute a policy that refnames in the UI must always be normalized
>
> * On a best-effort basis, emit errors whenever unnormalized refnames are
> encountered
>
> * Continue to support "git check-ref-format --print", which script
> writers can use to normalize refnames if they need to.
>
> The only disadvantage of a stricter policy is that some of today's
> sloppy scripts, which today might sometimes work (but not reliably),
> break in a pretty obvious way that can be fixed with a single call to
> "git check-ref-format --print".
>
> I'd rather get beyond this swamp and start working on the hierarchical
> reference cache, which will bring some real benefits. (The hierarchical
> reference cache requires some sanity in refname handling, which is why I
> got into this mess in the first place.)
Both the analysis and theproposal I find very sane and sensible. Thanks.
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Junio C Hamano @ 2011-09-13 17:34 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Couder, Jens Lehmann, Junio C Hamano, git, git-dev
In-Reply-To: <20110913171506.GA32251@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Will do. Junio, do you want me to re-roll the quadratic fix, or just
> build the refactoring on top?
The latter would be fine and it probably is not even urgent.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jeff King @ 2011-09-13 17:20 UTC (permalink / raw)
To: Eric Sunshine
Cc: John Szakmeister, Junio C Hamano, git, Boaz Harrosh,
Brandon Casey, Thomas Rast, Alexey Shumkin
In-Reply-To: <4E6F70E6.2070602@sunshineco.com>
On Tue, Sep 13, 2011 at 11:04:06AM -0400, Eric Sunshine wrote:
> >Or maybe not there at all? We tend to do quite a bit with Matlab, and
> >Matlab scripts also end in ".m". Unfortunately, it bears little
> >resemblance to Objective-C.
>
> This default mapping is provided as a convenience only. Users can
> edit .gitattributes as needed. If we assume that the number of
> Macintosh and iOS (iPhone, iPad, iPod Touch) programmers heavily
> outweighs the number of Matlab users, then the convenience of having
> .m in the default list may be justified.
Yeah, but the cost of being wrong may be much higher than the cost of
just using the default.
> It also is reasonable to ask if the "*.m diff=objc" mapping actually
> produces an inferior diff hunk-header[1] for Matlab files than when
> "diff=objc" is not present.
I think this is the important question. Is it inferior, and how bad does
it look? And then we can weigh that against the convenience of not
having to specify objc files in gitattributes.
-Peff
^ permalink raw reply
* Re: [PATCH v2] Documentation: basic configuration of notes.rewriteRef
From: Jeff King @ 2011-09-13 17:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <95a35723c2ac7e3accfceec2cdededcd213fb59b.1315899036.git.trast@student.ethz.ch>
On Tue, Sep 13, 2011 at 09:32:42AM +0200, Thomas Rast wrote:
> Users had problems finding a working setting for notes.rewriteRef.
> Document how to enable rewriting for notes/commits, which should be a
> safe setting.
Thanks. After our discussion, I am left with the feeling that it is
probably going to be the problem of the individual notes-refs to say "I
am immutable; don't rewrite me" (probably by putting them in some
special part of the ref namespace). But until we figure out exactly how
that will work, this is a safe and sane step forward.
-Peff
^ permalink raw reply
* Re: [PATCH v2] Documentation: basic configuration of notes.rewriteRef
From: Junio C Hamano @ 2011-09-13 17:16 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jeff King
In-Reply-To: <95a35723c2ac7e3accfceec2cdededcd213fb59b.1315899036.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Users had problems finding a working setting for notes.rewriteRef.
> Document how to enable rewriting for notes/commits, which should be a
> safe setting.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Junio C Hamano wrote:
>> Should we drop this post 1.7.7, or (preferrably) replace it with better
>> instructions?
>
> I'd replace it with this bit. Users who have trouble setting the
> variable to something useful will likely not know how to edit
> non-default notes trees, either.
Ok. Thanks.
> +enable note rewriting. Set it to `refs/notes/commits` to enable
> +rewriting for the default commit notes.
^ permalink raw reply
* Re: [PATCH] t3200: clean up checks for file existence
From: Jeff King @ 2011-09-13 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7v62kwxt4b.fsf@alter.siamese.dyndns.org>
On Tue, Sep 13, 2011 at 10:13:56AM -0700, Junio C Hamano wrote:
> In the longer term, we might want to update these tests further so that
> they do not fail when implementation is updated not to write loose refs,
> e.g.
Yeah, I noticed that, too, but figured to leave it for when such a
change came about (which is probably going to need to fix tests
everywhere, not just here). I'm happy to fix this area now, though, if
you want.
-Peff
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Jeff King @ 2011-09-13 17:15 UTC (permalink / raw)
To: Christian Couder; +Cc: Jens Lehmann, Junio C Hamano, git, git-dev
In-Reply-To: <CAP8UFD3ULs9YLCaaJYGo-_A=KqO4yFy3WHJmO5b_hyRSPzA-Vg@mail.gmail.com>
On Tue, Sep 13, 2011 at 06:40:07PM +0200, Christian Couder wrote:
> > +struct argv_array {
> > + const char **argv;
> > + unsigned int argc;
> > + unsigned int alloc;
> > +};
>
> But there is already such a struct in bisect.c!
Heh. I completely missed that. As I was writing it, I realized it would
be a good thing to factor out, but most of the argv builders I checked
weren't dynamic at all (they knew up front how big argv would need to be
because they were copying).
As it turns out, our implementations are remarkably similar considering
I hadn't read yours. It must mean they're both obviously correct. :)
> So it would be nice if you could refactor this and the argv_array
> functions in bisect.c in the same way you refactored sha1-array.
Will do. Junio, do you want me to re-roll the quadratic fix, or just
build the refactoring on top?
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax
From: Junio C Hamano @ 2011-09-13 17:14 UTC (permalink / raw)
To: Eric Wong
Cc: Ramsay Jones, Sam Vilain, Michael J Gruber, Junio C Hamano,
GIT Mailing-list, mhagger
In-Reply-To: <20110913075726.GA15066@dcvr.yhbt.net>
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH] t3200: clean up checks for file existence
From: Junio C Hamano @ 2011-09-13 17:13 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20110913161358.GB28634@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here it is, on top of mg/branch-list. The "test without -f" bits could
> actually be squashed in to your commits if we really want clean history,
> but I don't think it's a big deal.
Thanks.
In the longer term, we might want to update these tests further so that
they do not fail when implementation is updated not to write loose refs,
e.g.
> test_expect_success \
> 'git branch abc should create a branch' \
> - 'git branch abc && test -f .git/refs/heads/abc'
> + 'git branch abc && test_path_is_file .git/refs/heads/abc'
git branch abc && git show-ref -q --verify refs/heads/abc
But this patch is about correctness first, so I'll queue it as-is.
^ permalink raw reply
* [Survey] Signed push
From: Junio C Hamano @ 2011-09-13 16:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, linux-kernel
[administrivia] This message is also Cc'ed to the kernel mailing list in
order to ask for opinions from members of one of the most important user
communities of Git, but people may want to drop the kernel list when
responding to this message to reduce the noise level over there. Thanks.
In the light of what happened to k.org recently, we've been discussing
things Git can do to help raising confidence levels perceived by the
general public on integrity of the source trees, especially for the kernel
community. As the article by Jonathan Corbet on lwn.net nicely described,
projects managed with Git are already pretty resistant from tampering, and
it is not my (nor anybody in the Git community's) intention to propose any
more unnecessary bureaucracy to the development process without merit.
There are two updates that may change the end user experience I would like
to ask your opinions on, both as the Git designer (emeritus?) and as the
top kernel developer.
1. Improved pull requests.
Currently a typical pull-request begins like this:
The following changes since commit f696543dad6c7ba27b0c4fab167a5687263a9ba0:
Flobar 2.4.3 (2011-09-13 12:34:56 +0900)
are available in the git repository at:
git://git.kernel.org/pub/flobar.git/ master
which is followed by the shortlog and expected diffstat. This tells you
where the requester based his work on in excruciating detail, but does not
tell you what you should expect to fetch, any more than "whatever happened
to be at the named branch when you happened to notice the request."
We have a tentative patch to add an extra line after the "URL branch" line
that is for your cut & paste that looks like:
are available in the git repository at:
git://git.kernel.org/pub/flobar.git/ master
for you to fetch changes up to 5738c9c21e53356ab5020912116e7f82fd2d428f
I often see you respond to a pull request on the kernel mailing list with
"I see nothing new; forgot to push?", and having this extra line may also
help communication.
Would it be just an added and useless noise that you nor your requesters
would not care much about?
An alternative that I am considering is to let the requester say this
instead:
are available in the git repository at:
git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f
without adding the extra line.
That is, to allow fetching the history up to an explicitly named commit
object. This would only involve a change to fetch-pack at the receiving
end; just match the commit object name given from the command line against
the ls-remote response and ask upload-pack to give the history leading to
it. The released versions of Git already will happily oblige, as long as
the commit object named in the request message still sits at the tip of
the intended branch.
Do you think it is worthwhile to pursue this alternative?
2. Signed pushes.
You tag official releases and release candidates with your GPG key, and
everybody who works within the kernel ecosystem trusts the history behind
the commits pointed by them, but there is no easy way to verify that
commits and merges between the last tagged commit and the tip of your
branch(es) are indeed from you, or if an intruder piled fake ones on top
of your commits (until you try to push again and discover that the history
does not fast-forward, that is).
We have been discussing an addition of "git push -s" to let people sign
their pushes (instead of having to sign every commit or add signed
tag). The implementation alternatives were being bikeshed but not of much
interest in this message, but the user experience would go like this:
* You push out your work with "git push -s";
* "git push" prepares a "push certificate" (it is meant to certify "these
are the commits I place at the tips of these refs"), which is a human
and machine readable text file in core, that may look like this:
Push-Certificate-Version: 0
Pusher: Junio C Hamano <gitster@pobox.com>
Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next
and asks you to GPG sign it. You only unlock your GPG key and the
command internally runs GPG, just like "tag -s".
* When "git push" finishes, the receiving end has this record in its
refs/notes/signed-push notes tree, together with your previous pushes
(as this is not a shared repository, it will record only your pushes).
The notes annnotate the commits named on the "Update:" lines above.
* People who want to verify commits that are not yet tagged near the tip
in their clone of your tree can fetch refs/notes/signed-push and run
$ git log --show-notes=signed-push --branches --not --tags
to see your push certificates as annotations on commits that are not
yet tagged. They can verify them using a tool (yet to be written) that
acts like "git tag --verify".
It is hoped that it would help downstream with warm and fuzzy assurances
that all commits including the ones that are not yet tagged are genuine
(disclaimer: my employer is among the "downstream" that wants to have that
warm and fuzzy assurance) if we can see these push certificates published
at your public repository.
A few questions.
* As a user, do you think "signed push" is a good idea, or is it merely
an unnecessary bureaucracy, having to sign all pushes?
* As a user, do you think it is a good thing that you could also verify
the commits you receive from the Git-managed repositories of your
lieutenants using this mechanism, or you wouldn't bother, perhaps
because you are applying many patches sent via unsigned e-mail from
Andrew anyway?
* If the answers to the above points are both "yes", do you think it
would make sense to also propagate the push certificates you obtain
from your lieutenants to your public repository when you make your
"push -s"? It will allow your downstream to follow the chain of trust
in one-go (if you are pulling from public places, they can fetch the
push certificates from your lieutenants themselves and merge them, so
this is merely a convenience feature) by simply fetching from the
refs/notes/signed-push notes tree from your public repository. Do you
think it is a useful and worthwhile thing to do?
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Christian Couder @ 2011-09-13 16:40 UTC (permalink / raw)
To: Jeff King; +Cc: Jens Lehmann, Junio C Hamano, git, git-dev
In-Reply-To: <20110912195652.GA27850@sigill.intra.peff.net>
Hi Peff,
On Mon, Sep 12, 2011 at 9:56 PM, Jeff King <peff@peff.net> wrote:
> diff --git a/submodule.c b/submodule.c
> index 7a76edf..00aeb71 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -8,12 +8,17 @@
> #include "diffcore.h"
> #include "refs.h"
> #include "string-list.h"
> +#include "sha1-array.h"
Nice to see you reuse sha1-array!
[...]
> +struct argv_array {
> + const char **argv;
> + unsigned int argc;
> + unsigned int alloc;
> +};
But there is already such a struct in bisect.c!
> +static void init_argv(struct argv_array *array)
> +{
> + array->argv = NULL;
> + array->argc = 0;
> + array->alloc = 0;
> +}
> +
> +static void push_argv(struct argv_array *array, const char *value)
> +{
> + ALLOC_GROW(array->argv, array->argc + 2, array->alloc);
> + array->argv[array->argc++] = xstrdup(value);
> + array->argv[array->argc] = NULL;
> +}
> +
> +static void clear_argv(struct argv_array *array)
> +{
> + int i;
> + for (i = 0; i < array->argc; i++)
> + free((char **)array->argv[i]);
> + free(array->argv);
> + init_argv(array);
> +}
> +
> +static void add_sha1_to_argv(const unsigned char sha1[20], void *data)
> +{
> + push_argv(data, sha1_to_hex(sha1));
> +}
So it would be nice if you could refactor this and the argv_array
functions in bisect.c in the same way you refactored sha1-array.
Thanks,
Christian.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Brandon Casey @ 2011-09-13 16:22 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Eric Sunshine, git, Boaz Harrosh, Thomas Rast,
Alexey Shumkin
In-Reply-To: <20110913160520.GA28634@sigill.intra.peff.net>
On 09/13/2011 11:05 AM, Jeff King wrote:
> On Tue, Sep 13, 2011 at 10:15:15AM -0500, Brandon Casey wrote:
>
>> ...and I see there is already an fnmatch_icase() in dir.c which adds
>> FNM_CASEFOLD when the global var ignore_case is set. So, maybe it's as
>> easy as:
>> [...]
>> - return (fnmatch(pattern, basename, 0) == 0);
>> + return (fnmatch_icase(pattern, basename, 0) == 0);
>
> OK, wow. That's exactly the level of easy I was hoping for. Do you want
> to roll that up into a patch with some tests?
I haven't even tested that it runs. :) No, I was hoping someone
who was more interested would finish it, and maybe even test on
an affected system.
-Brandon
^ permalink raw reply
* [PATCH] t3200: clean up checks for file existence
From: Jeff King @ 2011-09-13 16:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <4E6F48C4.3030407@drmicha.warpmail.net>
This patch uses test_path_is_file and test_path_is_missing
instead of "test -f / ! test -f" checks. The former are more
verbose in case of failure and more precise (e.g., is_missing
will check that the entry is actually missing, not just not
a regular file).
As a bonus, this also fixes a few buggy tests that used
"test foo" instead of "test -f foo", and consequently always
reported success.
Signed-off-by: Jeff King <peff@peff.net>
---
On Tue, Sep 13, 2011 at 02:12:52PM +0200, Michael J Gruber wrote:
> I'd prefer your style anyway, but also prefer changing t3200 in one go.
Here it is, on top of mg/branch-list. The "test without -f" bits could
actually be squashed in to your commits if we really want clean history,
but I don't think it's a big deal.
t/t3200-branch.sh | 50 +++++++++++++++++++++++++-------------------------
1 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index c466b20..3988ec9 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -23,7 +23,7 @@ test_expect_success \
test_expect_success \
'git branch --help should not have created a bogus branch' '
git branch --help </dev/null >/dev/null 2>/dev/null;
- ! test -f .git/refs/heads/--help
+ test_path_is_missing .git/refs/heads/--help
'
test_expect_success 'branch -h in broken repository' '
@@ -39,11 +39,11 @@ test_expect_success 'branch -h in broken repository' '
test_expect_success \
'git branch abc should create a branch' \
- 'git branch abc && test -f .git/refs/heads/abc'
+ 'git branch abc && test_path_is_file .git/refs/heads/abc'
test_expect_success \
'git branch a/b/c should create a branch' \
- 'git branch a/b/c && test -f .git/refs/heads/a/b/c'
+ 'git branch a/b/c && test_path_is_file .git/refs/heads/a/b/c'
cat >expect <<EOF
$_z40 $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from master
@@ -52,15 +52,15 @@ test_expect_success \
'git branch -l d/e/f should create a branch and a log' \
'GIT_COMMITTER_DATE="2005-05-26 23:30" \
git branch -l d/e/f &&
- test -f .git/refs/heads/d/e/f &&
- test -f .git/logs/refs/heads/d/e/f &&
+ test_path_is_file .git/refs/heads/d/e/f &&
+ test_path_is_file .git/logs/refs/heads/d/e/f &&
test_cmp expect .git/logs/refs/heads/d/e/f'
test_expect_success \
'git branch -d d/e/f should delete a branch and a log' \
'git branch -d d/e/f &&
- test ! -f .git/refs/heads/d/e/f &&
- test ! -f .git/logs/refs/heads/d/e/f'
+ test_path_is_missing .git/refs/heads/d/e/f &&
+ test_path_is_missing .git/logs/refs/heads/d/e/f'
test_expect_success \
'git branch j/k should work after branch j has been deleted' \
@@ -78,13 +78,13 @@ test_expect_success \
'git branch -m m m/m should work' \
'git branch -l m &&
git branch -m m m/m &&
- test -f .git/logs/refs/heads/m/m'
+ test_path_is_file .git/logs/refs/heads/m/m'
test_expect_success \
'git branch -m n/n n should work' \
'git branch -l n/n &&
git branch -m n/n n
- test -f .git/logs/refs/heads/n'
+ test_path_is_file .git/logs/refs/heads/n'
test_expect_success 'git branch -m o/o o should fail when o/p exists' '
git branch o/o &&
@@ -100,34 +100,34 @@ test_expect_success 'git branch -m q r/q should fail when r exists' '
test_expect_success 'git branch -v -d t should work' '
git branch t &&
- test .git/refs/heads/t &&
+ test_path_is_file .git/refs/heads/t &&
git branch -v -d t &&
- test ! -f .git/refs/heads/t
+ test_path_is_missing .git/refs/heads/t
'
test_expect_success 'git branch -v -m t s should work' '
git branch t &&
- test .git/refs/heads/t &&
+ test_path_is_file .git/refs/heads/t &&
git branch -v -m t s &&
- test ! -f .git/refs/heads/t &&
- test -f .git/refs/heads/s &&
+ test_path_is_missing .git/refs/heads/t &&
+ test_path_is_file .git/refs/heads/s &&
git branch -d s
'
test_expect_success 'git branch -m -d t s should fail' '
git branch t &&
- test .git/refs/heads/t &&
+ test_path_is_file .git/refs/heads/t &&
test_must_fail git branch -m -d t s &&
git branch -d t &&
- test ! -f .git/refs/heads/t
+ test_path_is_missing .git/refs/heads/t
'
test_expect_success 'git branch --list -d t should fail' '
git branch t &&
- test .git/refs/heads/t &&
+ test_path_is_file .git/refs/heads/t &&
test_must_fail git branch --list -d t &&
git branch -d t &&
- test ! -f .git/refs/heads/t
+ test_path_is_missing .git/refs/heads/t
'
mv .git/config .git/config-saved
@@ -144,12 +144,12 @@ git config branch.s/s.dummy Hello
test_expect_success \
'git branch -m s/s s should work when s/t is deleted' \
'git branch -l s/s &&
- test -f .git/logs/refs/heads/s/s &&
+ test_path_is_file .git/logs/refs/heads/s/s &&
git branch -l s/t &&
- test -f .git/logs/refs/heads/s/t &&
+ test_path_is_file .git/logs/refs/heads/s/t &&
git branch -d s/t &&
git branch -m s/s s &&
- test -f .git/logs/refs/heads/s'
+ test_path_is_file .git/logs/refs/heads/s'
test_expect_success 'config information was renamed, too' \
"test $(git config branch.s.dummy) = Hello &&
@@ -160,8 +160,8 @@ test_expect_success 'renaming a symref is not allowed' \
git symbolic-ref refs/heads/master2 refs/heads/master &&
test_must_fail git branch -m master2 master3 &&
git symbolic-ref refs/heads/master2 &&
- test -f .git/refs/heads/master &&
- ! test -f .git/refs/heads/master3
+ test_path_is_file .git/refs/heads/master &&
+ test_path_is_missing .git/refs/heads/master3
'
test_expect_success SYMLINKS \
@@ -270,8 +270,8 @@ test_expect_success \
'git checkout -b g/h/i -l should create a branch and a log' \
'GIT_COMMITTER_DATE="2005-05-26 23:30" \
git checkout -b g/h/i -l master &&
- test -f .git/refs/heads/g/h/i &&
- test -f .git/logs/refs/heads/g/h/i &&
+ test_path_is_file .git/refs/heads/g/h/i &&
+ test_path_is_file .git/logs/refs/heads/g/h/i &&
test_cmp expect .git/logs/refs/heads/g/h/i'
test_expect_success 'checkout -b makes reflog by default' '
--
1.7.7.rc1.2.gb2409
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jeff King @ 2011-09-13 16:05 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Eric Sunshine, git, Boaz Harrosh, Thomas Rast,
Alexey Shumkin
In-Reply-To: <DJ8J88If0KG_BPR1BK-feQRQ5yjv1AIYHW3sMosJzbrjCLKCIJABAFuSAH9IrkEl-y3-8mIKsysdqADcV6A7C7f4UuM9aZNpztbz_L9pXXw@cipher.nrlssc.navy.mil>
On Tue, Sep 13, 2011 at 10:15:15AM -0500, Brandon Casey wrote:
> ...and I see there is already an fnmatch_icase() in dir.c which adds
> FNM_CASEFOLD when the global var ignore_case is set. So, maybe it's as
> easy as:
> [...]
> - return (fnmatch(pattern, basename, 0) == 0);
> + return (fnmatch_icase(pattern, basename, 0) == 0);
OK, wow. That's exactly the level of easy I was hoping for. Do you want
to roll that up into a patch with some tests?
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Brandon Casey @ 2011-09-13 15:15 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Eric Sunshine, git, Boaz Harrosh, Thomas Rast,
Alexey Shumkin
In-Reply-To: <20110912233348.GE28994@sigill.intra.peff.net>
On 09/12/2011 06:33 PM, Jeff King wrote:
> On Mon, Sep 12, 2011 at 04:25:31PM -0700, Junio C Hamano wrote:
>
>>> Peff also asked if uppercase extensions are common on Windows. They
>>> are, so one often sees .HTM, .HTML, etc. Should this issue be handled
>>> by jk/default-attr?
>>
>> I do not think we would mind adding .HTM but would people limit themselves
>> to uppercase while not limiting themselves to three letters and use .HTML?
>
> I wonder if they should all be in the style of:
>
> [Hh][Tt][Mm][Ll]
> [Jj][Aa][Vv][Aa]
>
> for case-challenged systems. That feels like the wrong solution, though.
> If you're on a case-insensitive system, shouldn't we perhaps be
> comparing some kind of canonical version of the filename that is
> lowercased? That would help these built-in attributes, as well as ones
> that people write.
Perhaps fnmatch should be using FNM_CASEFOLD when core.ignorecase is
set. We already provide compat/fnmatch/ and have NO_FNMATCH_CASEFOLD in
Makefile, so it should be safe to use.
...and I see there is already an fnmatch_icase() in dir.c which adds
FNM_CASEFOLD when the global var ignore_case is set. So, maybe it's as
easy as:
diff --git a/attr.c b/attr.c
index 09cb4fc..b482262 100644
--- a/attr.c
+++ b/attr.c
@@ -2,6 +2,7 @@
#include "cache.h"
#include "exec_cmd.h"
#include "attr.h"
+#include "dir.h"
const char git_attr__true[] = "(builtin)true";
const char git_attr__false[] = "\0(builtin)false";
@@ -649,7 +650,7 @@ static int path_matches(const char *pathname, int pathlen,
/* match basename */
const char *basename = strrchr(pathname, '/');
basename = basename ? basename + 1 : pathname;
- return (fnmatch(pattern, basename, 0) == 0);
+ return (fnmatch_icase(pattern, basename, 0) == 0);
}
/*
* match with FNM_PATHNAME; the pattern has base implicitly
@@ -663,7 +664,7 @@ static int path_matches(const char *pathname, int pathlen,
return 0;
if (baselen != 0)
baselen++;
- return fnmatch(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+ return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
}
static int macroexpand_one(int attr_nr, int rem);
> Or maybe that is too large a can of worms to open. I sort of assume we
> have those canonicalization routines somewhere already, though.
>
> I think we're missing Brandon's note that ".F" is used (as distinct from
> ".f", even on case-sensitive filesystems, as it has some magic meaning).
> And the pascal ones somebody mentioned.
Yep, that's all that is missing from my perspective.
-Brandon
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Eric Sunshine @ 2011-09-13 15:04 UTC (permalink / raw)
To: John Szakmeister
Cc: Junio C Hamano, Jeff King, git, Boaz Harrosh, Brandon Casey,
Thomas Rast, Alexey Shumkin
In-Reply-To: <CAEBDL5VDsc49wj6GiQ0ZaSZ0eBy_iTd73zhgqhLfOLFhnqC-5A@mail.gmail.com>
On 9/13/2011 3:51 AM, John Szakmeister wrote:
> On Mon, Sep 12, 2011 at 7:15 PM, Eric Sunshine<sunshine@sunshineco.com> wrote:
> [snip]
>> Shouldn't the last entry be?
>>
>> "*.m diff=objc",
>
> Or maybe not there at all? We tend to do quite a bit with Matlab, and
> Matlab scripts also end in ".m". Unfortunately, it bears little
> resemblance to Objective-C.
This default mapping is provided as a convenience only. Users can edit
.gitattributes as needed. If we assume that the number of Macintosh and
iOS (iPhone, iPad, iPod Touch) programmers heavily outweighs the number
of Matlab users, then the convenience of having .m in the default list
may be justified.
It also is reasonable to ask if the "*.m diff=objc" mapping actually
produces an inferior diff hunk-header[1] for Matlab files than when
"diff=objc" is not present.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/180103/
-- ES
^ permalink raw reply
* Re: [PATCH] t3200: test branch creation with -v
From: Michael J Gruber @ 2011-09-13 12:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20110913035724.GA4828@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 13.09.2011 05:57:
> On Sat, Sep 10, 2011 at 03:29:43PM +0200, Michael J Gruber wrote:
>
>> Jeff King venit, vidit, dixit 09.09.2011 21:43:
>>> On Fri, Sep 09, 2011 at 09:40:59PM +0200, Michael J Gruber wrote:
>>>
>>>> +test_expect_success 'git branch -v t should work' ' + git branch
>>>> -v t && + test .git/refs/heads/t &&
>>>
>>> test -f ?
>>>
>>> Also, don't we have test_path_is_file which yields slightly prettier
>>> output (and maybe some portability benefits; I don't remember)?
>>>
>>>> + git branch -d t && + test ! -f .git/refs/heads/t
>>>
>>> Ditto for 'test_path_is_missing' here.
>>>
>>> -Peff
>>
>> Well, I tried to follow the surrounding style. That t3200 could benefit
>> from some attention, though, which I did not want to mix in with the
>> issue at hand.
>
> The "test_path_is_file" thing is style. But not using "test -f" is just
> wrong; you are testing "is .git/refs/heads/t an empty string?" which is
> useless.
>
> You want this on top of what's in mg/branch-list:
Yes, sorry. How did I miss that?
I'd prefer your style anyway, but also prefer changing t3200 in one go.
>
> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
> index c466b20..b513115 100755
> --- a/t/t3200-branch.sh
> +++ b/t/t3200-branch.sh
> @@ -100,14 +100,14 @@ test_expect_success 'git branch -m q r/q should fail when r exists' '
>
> test_expect_success 'git branch -v -d t should work' '
> git branch t &&
> - test .git/refs/heads/t &&
> + test -f .git/refs/heads/t &&
> git branch -v -d t &&
> test ! -f .git/refs/heads/t
> '
>
> test_expect_success 'git branch -v -m t s should work' '
> git branch t &&
> - test .git/refs/heads/t &&
> + test -f .git/refs/heads/t &&
> git branch -v -m t s &&
> test ! -f .git/refs/heads/t &&
> test -f .git/refs/heads/s &&
> @@ -116,7 +116,7 @@ test_expect_success 'git branch -v -m t s should work' '
>
> test_expect_success 'git branch -m -d t s should fail' '
> git branch t &&
> - test .git/refs/heads/t &&
> + test -f .git/refs/heads/t &&
> test_must_fail git branch -m -d t s &&
> git branch -d t &&
> test ! -f .git/refs/heads/t
> @@ -124,7 +124,7 @@ test_expect_success 'git branch -m -d t s should fail' '
>
> test_expect_success 'git branch --list -d t should fail' '
> git branch t &&
> - test .git/refs/heads/t &&
> + test -f .git/refs/heads/t &&
> test_must_fail git branch --list -d t &&
> git branch -d t &&
> test ! -f .git/refs/heads/t
>
> I suspect you didn't notice the bogosity before because those are just
> confirming the precondition that "git branch" actually created the file.
>
> -Peff
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Michael J Gruber @ 2011-09-13 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, Eric Wong, git
In-Reply-To: <7v1uvl2wd1.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 13.09.2011 00:58:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * rj/maint-t9159-svn-rev-notation (2011-09-11) 1 commit
>> - t9159-*.sh: Add an svn version check
>
> Ack/Nack from people involved in git-svn and/or the patch, please?
Not much time due to conference this week. Don't we have a version check
somewhere else in the tests already? (I may be mixing it up with git-svn
proper.) We should not dupe that and anyways libify or define a
prerequisite.
Michael
^ permalink raw reply
* Re: windows git problem
From: Nguyen Thai Ngoc Duy @ 2011-09-13 10:30 UTC (permalink / raw)
To: luis; +Cc: Michael Witten, git
In-Reply-To: <CACsJy8B4RY4Yst9TPhNCOj8AUziFa+O+2Msen9Bt=QHo5SW=sA@mail.gmail.com>
On Tue, Sep 13, 2011 at 8:10 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Tue, Sep 13, 2011 at 4:31 AM, luis <luis@tandvsolns.co.uk> wrote:
>> Exactly!
>>
>> so the next time someone (in windows) does a commit, they remove the file or
>> the folder contents!
>
> May be this commit dc1ae70 (Support case folding for git add when
> core.ignorecase=true).
I take it back. add_to_index() is mostly called by git-add. A checkout
fills the index with unpack-trees, which does not seem to be
case-insensitive to me.
--
Duy
^ permalink raw reply
* Re: windows git problem
From: Nguyen Thai Ngoc Duy @ 2011-09-13 10:10 UTC (permalink / raw)
To: luis; +Cc: Michael Witten, git
In-Reply-To: <4E6E5000.3040203@tandvsolns.co.uk>
On Tue, Sep 13, 2011 at 4:31 AM, luis <luis@tandvsolns.co.uk> wrote:
> Exactly!
>
> so the next time someone (in windows) does a commit, they remove the file or
> the folder contents!
May be this commit dc1ae70 (Support case folding for git add when
core.ignorecase=true). Forcing core.ignorecase to add_to_index() seems
a bit too strong for me. We could have added a new flag,
ADD_CASE_INSENSITIVE, to add_to_index() and enabled it only to
selected commands instead.
Or maybe we can improve the situation a little bit by warning users this case.
--
Duy
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Erik Faye-Lund @ 2011-09-13 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pascal Obry, Ramsay Jones, Johannes Sixt, git
In-Reply-To: <7v7h5d2wd3.fsf@alter.siamese.dyndns.org>
On Tue, Sep 13, 2011 at 12:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> [Stalled]
>>
>> * po/cygwin-backslash (2011-08-05) 2 commits
>> - On Cygwin support both UNIX and DOS style path-names
>> - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
>
> Honestly I lost track of this one. How would we want to proceed on this
> topic after 1.7.7?
>
> Asking help from Windows folks.
I believe Hannes pointed out that there were some work left to be done
on it ("enable backslash processing in setup.c:prefix_filename()"),
and I didn't spot a new version after that. He also pointed out that
enabling backslash processing would cause you to lose the ability to
escape special characters, but it sounds to me like this is something
that simply "comes with the territory" of supporting win32-paths in a
POSIX-ish environment, and is already the governing convention in
Cygwin. But I'm not an expert on this topic; Cygwin is not something I
usually care much about.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Nguyen Thai Ngoc Duy @ 2011-09-13 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vhb4h1ewc.fsf@alter.siamese.dyndns.org>
On Tue, Sep 13, 2011 at 10:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> ... I
>> suspect until then, you could just drop them.
>
> That's a lot simpler than having to worry about it. Thanks.
Yeah. I've been moving and having less time for open source. Plus
gnome is approaching the release date and translation work's coming
up. I'll resubmit when I get around to it.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax
From: John Szakmeister @ 2011-09-13 9:15 UTC (permalink / raw)
To: Eric Wong
Cc: Ramsay Jones, Sam Vilain, Michael J Gruber, Junio C Hamano,
GIT Mailing-list, mhagger
In-Reply-To: <20110913075726.GA15066@dcvr.yhbt.net>
On Tue, Sep 13, 2011 at 3:57 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> Hmm, I was hoping that someone would say something like:
>>
>> "This test does not depend on the difference between the peg revision
>> and the operative revision, because the history represented in the test
>> repo is so simple that there *is* no difference, so Acked By: ... "
>
> Unfortunately, I remain perpetually confused w.r.t peg revisions vs "-r"
> and how it's handled differently between different SVN versions.
I haven't followed this conversation, but I can explain what peg
revisions are. It used to be the only way to talk about a version of
a file or path was to use '-r REVNUM'. IIRC, what would happen is
that the url you provided would refer to the now current name of the
file, and Subversion would walk back in history to look up the
specified version of the file. However, that becomes a problem when
the file no longer exists, or has been renamed. It's compounded if
there is a new file with the same name in HEAD, because it would look
up the wrong history. So peg revisions were introduced to say "start
looking here @PEGREV and search forward or backwards for the version
in REVNUM." So the difference is that old clients always looked at
HEAD to start the search, whereas new clients will use PEGREV if
specified, and HEAD otherwise.
There is a pretty thorough discussion of it in the SVN book:
<http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html>
Hope that helps!
-John
^ 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