* [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Sitaram Chamarty @ 2011-10-06 12:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phil Hord, Sitaram Chamarty, git
In-Reply-To: <CAMK1S_gssgpy7nF46c1roJUCN5yvQaOYfVE_-ZrvMfHGWKvk0w@mail.gmail.com>
Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
---
(re-rolled according to earlier discussion)
git-difftool--helper.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 8452890..0468446 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -38,15 +38,16 @@ launch_merge_tool () {
# $LOCAL and $REMOTE are temporary files so prompt
# the user with the real $MERGED name before launching $merge_tool.
+ ans=y
if should_prompt
then
printf "\nViewing: '$MERGED'\n"
if use_ext_cmd
then
- printf "Hit return to launch '%s': " \
+ printf "Launch '%s' [Y/n]: " \
"$GIT_DIFFTOOL_EXTCMD"
else
- printf "Hit return to launch '%s': " "$merge_tool"
+ printf "Launch '%s' [Y/n]: " "$merge_tool"
fi
read ans
fi
@@ -54,9 +55,9 @@ launch_merge_tool () {
if use_ext_cmd
then
export BASE
- eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
+ test "$ans" != "n" && eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
else
- run_merge_tool "$merge_tool"
+ test "$ans" != "n" && run_merge_tool "$merge_tool"
fi
}
--
1.7.6
^ permalink raw reply related
* Re: git-cherry-pick and author field in version 1.7.6.4
From: Nicolas Dichtel @ 2011-10-06 12:37 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111006112742.GA4445@sigill.intra.peff.net>
Le 06/10/2011 13:27, Jeff King a écrit :
> On Thu, Oct 06, 2011 at 09:51:06AM +0200, Nicolas Dichtel wrote:
>
>> Here is my sequence. I'm in a linux tree with a remote that point to
>> linus tree and I want to cherry-pick a patch from this remote:
>>
>> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> [dev 87ce387] drivers/net/usb/asix.c: Fix unaligned accesses
>> 1 files changed, 33 insertions(+), 1 deletions(-)
>> # git log -1 --format='%an<%ae>'
>> Nicolas Dichtel<nicolas.dichtel@6wind.com>
>> # git log -1 --format='%an<%ae>' 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> Neil Jones<NeilJay@gmail.com>
>> #
>
> Hmph. Odd:
>
> $ cd linux-2.6
> $ git checkout -b dev 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9^
> Switched to a new branch 'dev'
> $ git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> [dev 78929c2] drivers/net/usb/asix.c: Fix unaligned accesses
> Author: Neil Jones<NeilJay@gmail.com>
> 1 files changed, 33 insertions(+), 1 deletions(-)
> $ git log -1 --format='%an<%ae>'
> Neil Jones<NeilJay@gmail.com>
# git checkout -b dev 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9^
Checking out files: 100% (25721/25721), done.
Switched to a new branch 'dev'
# git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
[dev 693df4c] drivers/net/usb/asix.c: Fix unaligned accesses
1 files changed, 33 insertions(+), 1 deletions(-)
# git log -1 --format='%an<%ae>'
Nicolas Dichtel<nicolas.dichtel@6wind.com>
#
>
>> Maybe it is related to the problem I've reported in another thread:
>> http://comments.gmane.org/gmane.comp.version-control.git/182853
>
> Possibly. That issue is about the commit that comes _after_ the
> cherry-pick, and in this instance, things are already wrong for you by
> the time the cherry-pick has completed.
>
> However, the problem has to do with leaving a stale state file in .git,
> so perhaps a previous partially-completed cherry-pick has left cruft in
> .git that is confusing this cherry-pick (i.e., I can't reproduce because
> it is being affected by something that happened before the commands
> above). So let's see what Jay comes up with for solving the other
> problem, and I suspect it may just fix this issue, too.
I think so too. Will wait.
>
> You might also repeating the commands above. If it still fails, maybe
> try removing ".git/CHERRY_PICK_HEAD" if it exists and see if that helps.
No, it just allow the commit --amend, but this will not change the author.
Regards,
Nicolas
^ permalink raw reply
* Re: git-cherry-pick and author field in version 1.7.6.4
From: Jeff King @ 2011-10-06 11:27 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: git
In-Reply-To: <4E8D5DEA.9010500@6wind.com>
On Thu, Oct 06, 2011 at 09:51:06AM +0200, Nicolas Dichtel wrote:
> Here is my sequence. I'm in a linux tree with a remote that point to
> linus tree and I want to cherry-pick a patch from this remote:
>
> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> [dev 87ce387] drivers/net/usb/asix.c: Fix unaligned accesses
> 1 files changed, 33 insertions(+), 1 deletions(-)
> # git log -1 --format='%an<%ae>'
> Nicolas Dichtel<nicolas.dichtel@6wind.com>
> # git log -1 --format='%an<%ae>' 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> Neil Jones<NeilJay@gmail.com>
> #
Hmph. Odd:
$ cd linux-2.6
$ git checkout -b dev 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9^
Switched to a new branch 'dev'
$ git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
[dev 78929c2] drivers/net/usb/asix.c: Fix unaligned accesses
Author: Neil Jones <NeilJay@gmail.com>
1 files changed, 33 insertions(+), 1 deletions(-)
$ git log -1 --format='%an <%ae>'
Neil Jones <NeilJay@gmail.com>
> Maybe it is related to the problem I've reported in another thread:
> http://comments.gmane.org/gmane.comp.version-control.git/182853
Possibly. That issue is about the commit that comes _after_ the
cherry-pick, and in this instance, things are already wrong for you by
the time the cherry-pick has completed.
However, the problem has to do with leaving a stale state file in .git,
so perhaps a previous partially-completed cherry-pick has left cruft in
.git that is confusing this cherry-pick (i.e., I can't reproduce because
it is being affected by something that happened before the commands
above). So let's see what Jay comes up with for solving the other
problem, and I suspect it may just fix this issue, too.
You might also repeating the commands above. If it still fails, maybe
try removing ".git/CHERRY_PICK_HEAD" if it exists and see if that helps.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Bernhard R. Link @ 2011-10-06 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [111005 20:19]:
> I do not necessarily think that it is a good approach to forbid the same
> branch to be checked out in two different places, by the way. [...]
> [...] The problem arises only when one of the repositories try
> to update or delete the branch while it is checked out in another working
> tree.
I think this is mostly the same problem that also make pushing to a
checked out branch a problem.
Isn't the real problem that a checked out branch / a branch having a
workdir only has information what branch it belongs to?
Wouldn't both problems (multiple workdirs of the same branch, pushing
to a checked out branch) solved if each working directory (including
the default one in a non-bare repository) also stored the commit id
last checked out? (And then giving a warning, error or automatically
creating a detached head setting whenever the branch it followed is
moved behind it's back?)
Bernhard R. Link
^ permalink raw reply
* Re: [BUG] git stash -k show the help message for diff-index
From: Matthieu Moy @ 2011-10-06 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nzn8hcp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Hmm, does not reproduce.
>
> : alter victim-2.git/master; git status
> # On branch master
> nothing to commit (working directory clean)
> : alter victim-2.git/master; git stash -k
> No local changes to save
> : alter victim-2.git/master; git version
> git version 1.7.7
Sorry, I should have mentionned that: I had the bug with next.
I've tried bisecting it down, but the bug mysteriously disappeared
during the bisect (I did have bad and good commits during bisect, but at
the end, I had only good commits, and the bad ones weren't
reproducible).
I can't reproduce anymore.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 0/9] i18n: add PO files to po/
From: Peter Krefting @ 2011-10-06 9:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Jonathan Nieder,
Git Mailing List, Ramkumar Ramachandra, Marcin Cieślak,
Sam Reed, Jan Engelhardt, Jan Krüger,
Nguyễn Thái Ngọc
In-Reply-To: <7vaa9gbdyc.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> These two are somewhat mutually exclusive. I _suspect_ that Jonathan might
> have been hinting me to eject everything under the current po/ directory,
> and bind that part of the tree as a submodule from another repository,
> which would give us "git log -p" cleanliness automatically.
That sounds like a good idea, actually. That way you can also chose which
version of the po/ tree to include without having to do crazy cherry-picking
and stuff, and it makes it easier to maintain externally and such.
I have experience working with Translation Project, both as a software
maintainer requesting translation, and as a translator doing translations,
and I am interested in setting up a po repository for Git and use TP to
maintain translations (or directly, for those that would prefer that).
--
\\// Peter - volunteered, because localization is a good thing
^ permalink raw reply
* git-svn: ignore-paths not enough (not ignoring refs?)
From: Piotr Krukowiecki @ 2011-10-06 8:43 UTC (permalink / raw)
To: Michael Olson; +Cc: Eric Wong, Git Mailing List
Hi,
I'm using --ignore-paths options but some paths which should be
ignored (they math the regexp) are not ignored. I suspect this is
because of http://thread.gmane.org/gmane.comp.version-control.git/145398
It seems the patch from that url was never accepted to git. It does
not apply anymore too. Is it possible to update the patch? From the
discussion the patch looked ok (with exception to git-svn dying if a
parent ref didn't exist :) )
Here's my git-svn clone log, with some print lines added to is_path_ignored():
$ git svn clone -s --no-follow-parent --ignore-paths='$REGEXP -r 1230:1240 $URL
[...]
is_path_ignored: 'xtest/tags/rel1' # this matches the regexp and
should be ignored
is_path_ignored: 'xtest/tags/rel1/common' # more paths which should be
ignored follow
[...]
r1237 = c660a7e6ad81cafa0a64a7ec85a3e23f0c02bc09
(refs/remotes/tags/rel1) # but it is not!
# I can see the tag:
$ git branch -a
remotes/tags/rel1
# There are no changes in this change:
$ git show -p c660a7e6ad81cafa0a64a7ec85a3e23f0c02bc09
[...]
git-svn-id: $URL/rel1@1237 3e523551-a86b-4873-bcb6-76fcd93a4c5c
# Under svn the r1237 is following:
$ svn log -r 1237 -v $URL
------------------------------------------------------------------------
r1237 | ...
Changed paths:
A /xtest/tags/rel1/common (from /xtest/branches/xtest44/common:1235)
# The xtest/branches/xtest44/common does not match the ignore-paths
and is not ignored.
--
Piotr Krukowiecki
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Nicolas Dichtel @ 2011-10-06 7:53 UTC (permalink / raw)
To: Jay Soffian, git
In-Reply-To: <4E8D5AD0.2040509@6wind.com>
Le 06/10/2011 09:37, Nicolas Dichtel a écrit :
> Le 05/10/2011 18:50, Jay Soffian a écrit :
>> On Wed, Oct 5, 2011 at 10:52 AM, Nicolas Dichtel
>> <nicolas.dichtel@6wind.com> wrote:
>>> Hi,
>>>
>>> still with version 1.7.6.4, when I do a cherry-pick, that succeeded, I
>>> cannot do a commit --amend after:
>>>
>>> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>>> [dev 1a04a23] drivers/net/usb/asix.c: Fix unaligned accesses
>>> 1 files changed, 33 insertions(+), 1 deletions(-)
>>> # echo $?
>>> 0
>>> # git commit --amend
>>> fatal: You are in the middle of a cherry-pick -- cannot amend.
>>> #
>>>
>>> The same operations (with the same patch), with version 1.7.3.4 is ok.
>>
>> Please do the following with 1.7.6.4:
>>
>> # ls .git
>> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> # ls .git
>> # git cat-file -p 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> # git cat-file -p HEAD
>>
>> And send the transcript.
> Here is:
>
> # ls .git
> branches COMMIT_EDITMSG config description FETCH_HEAD HEAD hooks index info logs
> objects ORIG_HEAD packed-refs refs
> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> [dev 4cca2c2] drivers/net/usb/asix.c: Fix unaligned accesses
> 1 files changed, 33 insertions(+), 1 deletions(-)
> # ls .git
> branches CHERRY_PICK_HEAD COMMIT_EDITMSG config description FETCH_HEAD HEAD
> hooks index info logs objects ORIG_HEAD packed-refs refs
> # git cat-file -p 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> tree f29742a1a73c27a88c7ac701a7a06ac1c2f7973a
> parent e7a3af5d8cd782b84e6ca4e4dcc8613be1a809f0
> author Neil Jones <NeilJay@gmail.com> 1274141908 -0700
> committer David S. Miller <davem@davemloft.net> 1274141908 -0700
>
> drivers/net/usb/asix.c: Fix unaligned accesses
>
> Using this driver can cause unaligned accesses in the IP layer
> This has been fixed by aligning the skb data correctly using the
> spare room left over by the 4 byte header inserted between packets
> by the device.
>
> Signed-off-by: Neil Jones <NeilJay@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> # git cat-file -p HEAD
> tree 282b6492d9d5bcf1c3718420c6f31ca2033ca5cb
> parent c8054f854773e65d8592f2ef35939ec2ae8b01df
> author Nicolas Dichtel <nicolas.dichtel@6wind.com> 1317886553 +0200
> committer Nicolas Dichtel <nicolas.dichtel@6wind.com> 1317886553 +0200
>
> drivers/net/usb/asix.c: Fix unaligned accesses
>
> Using this driver can cause unaligned accesses in the IP layer
> This has been fixed by aligning the skb data correctly using the
> spare room left over by the 4 byte header inserted between packets
> by the device.
>
> Signed-off-by: Neil Jones <NeilJay@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> #
>
There is another symptom, describe in this thread:
http://comments.gmane.org/gmane.comp.version-control.git/182852
Maybe the two problems are related.
Regards,
Nicolas
^ permalink raw reply
* Re: git-cherry-pick and author field in version 1.7.6.4
From: Nicolas Dichtel @ 2011-10-06 7:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111005174138.GA22962@sigill.intra.peff.net>
Le 05/10/2011 19:41, Jeff King a écrit :
> On Wed, Oct 05, 2011 at 04:51:58PM +0200, Nicolas Dichtel wrote:
>
>> in the last stable version (1.7.6.4), when I perform a
>> git-cherry-pick, the initial author of the patch is erased whith my
>> name (it was not the case in version 1.7.3.4 and prior). Is this
>> behavior intended ? Is there an option to keep the initial author of
>> the patch?
>
> I can't reproduce your problem:
>
> git init repo&&
> cd repo&&
> echo content>file&& git add file&& git commit -m base&&
> echo changes>>file&&
> git commit --author='Other Person<other@example.com>' -a -m other&&
> git tag other&&
> git reset --hard HEAD^&&
> git cherry-pick other
>
> gives this output for the cherry-pick:
>
> [master 6eb207f] other
> Author: Other Person<other@example.com>
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> and the resulting commit looks good:
>
> $ git log -1 --format='%an<%ae>'
> Other Person<other@example.com>
>
> Does the script above work for you? If so, then what is different about
> your problematic case?
Here is my sequence. I'm in a linux tree with a remote that point to linus tree
and I want to cherry-pick a patch from this remote:
# git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
[dev 87ce387] drivers/net/usb/asix.c: Fix unaligned accesses
1 files changed, 33 insertions(+), 1 deletions(-)
# git log -1 --format='%an<%ae>'
Nicolas Dichtel<nicolas.dichtel@6wind.com>
# git log -1 --format='%an<%ae>' 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
Neil Jones<NeilJay@gmail.com>
#
Maybe it is related to the problem I've reported in another thread:
http://comments.gmane.org/gmane.comp.version-control.git/182853
Regards,
Nicolas
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Nicolas Dichtel @ 2011-10-06 7:37 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <CAG+J_DynqAK8uXDPtHwWpGhfA5qFZifucs91qL79Pu_DmCxG3g@mail.gmail.com>
Le 05/10/2011 18:50, Jay Soffian a écrit :
> On Wed, Oct 5, 2011 at 10:52 AM, Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
>> Hi,
>>
>> still with version 1.7.6.4, when I do a cherry-pick, that succeeded, I
>> cannot do a commit --amend after:
>>
>> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> [dev 1a04a23] drivers/net/usb/asix.c: Fix unaligned accesses
>> 1 files changed, 33 insertions(+), 1 deletions(-)
>> # echo $?
>> 0
>> # git commit --amend
>> fatal: You are in the middle of a cherry-pick -- cannot amend.
>> #
>>
>> The same operations (with the same patch), with version 1.7.3.4 is ok.
>
> Please do the following with 1.7.6.4:
>
> # ls .git
> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> # ls .git
> # git cat-file -p 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> # git cat-file -p HEAD
>
> And send the transcript.
Here is:
# ls .git
branches COMMIT_EDITMSG config description FETCH_HEAD HEAD hooks index
info logs objects ORIG_HEAD packed-refs refs
# git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
[dev 4cca2c2] drivers/net/usb/asix.c: Fix unaligned accesses
1 files changed, 33 insertions(+), 1 deletions(-)
# ls .git
branches CHERRY_PICK_HEAD COMMIT_EDITMSG config description FETCH_HEAD
HEAD hooks index info logs objects ORIG_HEAD packed-refs refs
# git cat-file -p 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
tree f29742a1a73c27a88c7ac701a7a06ac1c2f7973a
parent e7a3af5d8cd782b84e6ca4e4dcc8613be1a809f0
author Neil Jones <NeilJay@gmail.com> 1274141908 -0700
committer David S. Miller <davem@davemloft.net> 1274141908 -0700
drivers/net/usb/asix.c: Fix unaligned accesses
Using this driver can cause unaligned accesses in the IP layer
This has been fixed by aligning the skb data correctly using the
spare room left over by the 4 byte header inserted between packets
by the device.
Signed-off-by: Neil Jones <NeilJay@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
# git cat-file -p HEAD
tree 282b6492d9d5bcf1c3718420c6f31ca2033ca5cb
parent c8054f854773e65d8592f2ef35939ec2ae8b01df
author Nicolas Dichtel <nicolas.dichtel@6wind.com> 1317886553 +0200
committer Nicolas Dichtel <nicolas.dichtel@6wind.com> 1317886553 +0200
drivers/net/usb/asix.c: Fix unaligned accesses
Using this driver can cause unaligned accesses in the IP layer
This has been fixed by aligning the skb data correctly using the
spare room left over by the 4 byte header inserted between packets
by the device.
Signed-off-by: Neil Jones <NeilJay@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
#
Regards,
Nicolas
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Junio C Hamano @ 2011-10-06 7:06 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel
In-Reply-To: <CAG+J_Dysix9fOCuvm5+aU7-AC4wmsxH4-MOX+yhaHEqzeN1cPg@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Something like this?
>
> diff --git i/builtin/revert.c w/builtin/revert.c
> index 3117776c2c..f7fcc88871 100644
> --- i/builtin/revert.c
> +++ w/builtin/revert.c
> @@ -384,6 +384,7 @@ static int do_pick_commit(void)
> char *defmsg = NULL;
> struct strbuf msgbuf = STRBUF_INIT;
> int res;
> + int record_cherry_pick_head = 0;
>
> if (no_commit) {
> /*
> @@ -477,7 +478,7 @@ static int do_pick_commit(void)
> strbuf_addstr(&msgbuf, ")\n");
> }
> if (!no_commit)
> - write_cherry_pick_head();
> + record_cherry_pick_head = 1;
> }
>
> if (!strategy || !strcmp(strategy, "recursive") || action == REVERT) {
> @@ -514,6 +515,9 @@ static int do_pick_commit(void)
> free_message(&msg);
> free(defmsg);
>
> + if (record_cherry_pick_head)
> + write_cherry_pick_head();
> +
> return res;
> }
I switched to "maint" to look at this patch in context without the
sequencer complication.
The basic idea to delay writing the file feels sound, but when a conflict
happens, print_advice() runs and tries to clear CHERRY_PICK_HEAD, but you
are then writing the file out much later than that at the end of the
function.
This patch seems to break a few tests. t3404, t3506 and t3507 are among
them.
Also, if you are using the recursive strategy, a cherry-pick that did not
start would die() in do_recursive_merge(), and your hunk at -477,7 to
remove call to write_cherry_head() would be sufficient, but if you are
using another strategy, then try_merge_command() would return with 2 and I
think you would want to skip it for the same reason in that case.
^ permalink raw reply
* Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
From: Alexey Shumkin @ 2011-10-06 7:01 UTC (permalink / raw)
To: Johannes Sixt
Cc: Brandon Casey, peff@peff.net, git@vger.kernel.org,
gitster@pobox.com, sunshine@sunshineco.com, bharrosh@panasas.com,
trast@student.ethz.ch
In-Reply-To: <4E8D4812.9090102@viscovery.net>
Offtopic:
Excuse me, guys
May I ask you to exclude me from CC-list for this topic,
it seems to me I got in it for a mistake somehow,
I have no relation to this topic
thanks in advance :)
> Am 10/6/2011 4:00, schrieb Brandon Casey:
> > [resend without html bits added by "gmail offline"]
> > On Wed, Oct 5, 2011 at 7:53 PM, Brandon Casey <drafnel@gmail.com>
> > wrote:
> >> On Thursday, September 15, 2011, Brandon Casey wrote:
> >>>
> >>> On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt
> >>> <j.sixt@viscovery.net>
> >>>> There is a danger that the high-level die() routine (which is
> >>>> used by the
> >>>> x-wrappers) uses one of the low-level compat/ routines. IOW, in
> >>>> the case of errors, recursion might occur. Therefore, I would
> >>>> prefer that the compat/ routines do their own error reporting
> >>>> (preferably via return values and errno).
> >>>
> >>> Thanks. Will do.
> >>
> >> Hi Johannes,
> >> I have taken a closer look at the possibility of recursion with
> >> respect to die() and the functions in compat/. It appears the
> >> risk is only related to vsnprintf/snprintf at the moment. So as
> >> long as we avoid calling xmalloc et al from within snprintf.c, I
> >> think we should be safe from recursion. I'm inclined to keep the
> >> additions to mingw.c and win32/syslog.c since they both already
> >> use the x-wrappers or strbuf, even though they could easily be
> >> worked around. The other file that was touched is compat/qsort,
> >> which returns void and doesn't have a good alternative error
> >> handling path. So, I'm inclined to keep that one too.
>
> I'm fine with keeping the change to mingw.c (getaddrinfo related) and
> qsort: both are unlikely to be called from die().
>
> But syslog() *is* called from die() in git-daemon, and it would be
> better to back out the other offenders instead of adding to them.
>
> -- Hannes
>
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-06 6:33 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20111005180125.GC22962@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 05.10.2011 20:01:
> On Wed, Oct 05, 2011 at 01:55:36PM -0400, Jeff King wrote:
>
>> On Tue, Oct 04, 2011 at 08:49:55PM +0200, Michael J Gruber wrote:
>>
>>> We seem to mean something different:
>>>
>>> git config --get remote.bitbucket.pushurl
>>> https://grubix@bitbucket.org/grubix/git.git
>>> SSH_ASKPASS= git push -n bitbucket
>>> Username for 'bitbucket.org':
>>>
>>> I mean that git should not need to ask for the username here.
>>
>> No, we are in agreement about the intended behavior. I think you are
>> seeing a bug. What version of git produced it?
>>
>> With my http-auth series, I get:
>>
>> $ git push https://github.com/peff/git.git
>> Username for 'github.com':
>>
>> $ git push https://peff@github.com/peff/git.git
>> Password for 'github.com':
>>
>> Using v1.7.7 produces similar results.
>
> Hrm. I do get this, with the same version of git:
>
> $ git config remote.foo.url https://github.com/peff/git.git
> $ git push foo
> Username for 'github.com':
>
> $ git config remote.foo.url https://peff@github.com/peff/git.git
> $ git push foo
> Password for 'github.com':
>
> So far so good. Now how about this:
>
> $ git config remote.foo.url https://github.com/peff/git.git
> $ git config remote.foo.pushurl https://peff@github.com/peff/git.git
> $ git push foo
> Username for 'github.com':
>
> So I think the problem is with pushurl, not with the auth code. Oddly,
> though, running GIT_TRACE reveals:
Yep, I have a pushurl in config.
>
> $ GIT_TRACE=1 git push foo
> trace: built-in: git 'push' 'foo'
> trace: run_command: 'git-remote-https' 'foo' 'https://peff@github.com/peff/git.git'
>
> which is the right URL. So it's almost as if we are throwing away the
> passed URL in favor of the configuration, and then looking up the
> configuration wrong. I'm about to go get on a plane, so I don't have
> more time to look at it now, but I suspect it's something simple and
> stupid.
Thanks for confirming what it should be like. I never expected pushurl
and url to behave differently (I had used GIT_TRACE myself).
Good flight :)
Michael
^ permalink raw reply
* Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
From: Johannes Sixt @ 2011-10-06 6:17 UTC (permalink / raw)
To: Brandon Casey
Cc: peff@peff.net, git@vger.kernel.org, gitster@pobox.com,
sunshine@sunshineco.com, bharrosh@panasas.com,
trast@student.ethz.ch, zapped@mail.ru
In-Reply-To: <CA+sFfMdHpvdMU==a2sUR9sZZCcgqPfGF7+dy6yi8RVoMZ+uZVA@mail.gmail.com>
Am 10/6/2011 4:00, schrieb Brandon Casey:
> [resend without html bits added by "gmail offline"]
> On Wed, Oct 5, 2011 at 7:53 PM, Brandon Casey <drafnel@gmail.com> wrote:
>> On Thursday, September 15, 2011, Brandon Casey wrote:
>>>
>>> On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt <j.sixt@viscovery.net>
>>>> There is a danger that the high-level die() routine (which is used by
>>>> the
>>>> x-wrappers) uses one of the low-level compat/ routines. IOW, in the case
>>>> of errors, recursion might occur. Therefore, I would prefer that the
>>>> compat/ routines do their own error reporting (preferably via return
>>>> values and errno).
>>>
>>> Thanks. Will do.
>>
>> Hi Johannes,
>> I have taken a closer look at the possibility of recursion with respect to
>> die() and the functions in compat/. It appears the risk is only related to
>> vsnprintf/snprintf at the moment. So as long as we avoid calling xmalloc et
>> al from within snprintf.c, I think we should be safe from recursion.
>> I'm inclined to keep the additions to mingw.c and win32/syslog.c since they
>> both already use the x-wrappers or strbuf, even though they could easily be
>> worked around. The other file that was touched is compat/qsort, which
>> returns void and doesn't have a good alternative error handling path. So,
>> I'm inclined to keep that one too.
I'm fine with keeping the change to mingw.c (getaddrinfo related) and
qsort: both are unlikely to be called from die().
But syslog() *is* called from die() in git-daemon, and it would be better
to back out the other offenders instead of adding to them.
-- Hannes
^ permalink raw reply
* [PATCH] strbuf.c: remove unnecessary strbuf_grow() from strbuf_getwholeline()
From: Brandon Casey @ 2011-10-06 4:21 UTC (permalink / raw)
To: git; +Cc: Brandon Casey
This use of strbuf_grow() is a historical artifact that was once used to
ensure that strbuf.buf was allocated and properly nul-terminated. This
was added before the introduction of the slopbuf in b315c5c0, which
guarantees that strbuf.buf always points to a usable nul-terminated string.
So let's remove it.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
strbuf.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 9ff1b59..3ad2cc0 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -357,7 +357,6 @@ int strbuf_getwholeline(struct strbuf *sb, FILE *fp, int term)
{
int ch;
- strbuf_grow(sb, 0);
if (feof(fp))
return EOF;
--
1.7.7.1.ge3b6f
^ permalink raw reply related
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-06 4:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v1uuq51c3.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 9:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> Now they do what? Either commit --force or create a new branch?
>> Wouldn't it have been better to create the new branch before they
>> started editing?
>
> If they are going to commit, and if they knew that they are going to
> commit, yes.
Committing is obviously the common case for a checked-out branch.
> But why do you want to forbid people from just checking things out if they
> are not interested in committing? That is where I think you are going
> backwards.
Because if they do decide to commit, it's now harder for them to do so.
It would be great if git could intervene after the checkout, but
before they edit any files, so that they don't have uncommitted work.
Obviously that's not possible, so git should prevent them from getting
to that point.
Let's consider the various situations:
1. master is checked out w/edits in workdir1, user wants to work on
topic in workdir2.
There's nothing to warn about in workdir2 neither at checkout nor commit time.
2. master is checked out w/edits in workdir1, user wants examine
unedited master in workdir2
At checkout time in workdir2:
My preference: checkout advices user to use --detach or --force.
Your preference: checkout is silent.
Now user decides they want to commit to master in workdir2 (which is
insane, they've got uncommitted changes to it in workdir1). What
happens?
In my scenario, the commit happens on a detached HEAD. When they
eventually switch back to a branch, git tells them how to move their
commit to a branch.
In your scenario, commit complains. User now has to --force, stash, or
create a new branch.
It's just seems insane to me putting in obstacles to the user
committing their work. That's where I think you are going backwards.
You have a use case where using a detached HEAD doesn't work because
you've scripted around the same branch multiply checked out. I think
that's probably an exceedingly rare use case, and justifies "checkout
--force".
>> I guess it depends what you mostly use your workdirs for. For me, it's
>> to have different branches checked out, not to have the same branch
>> checked out in multiple locations.
>
> Then you wouldn't have any problem if commit refused to make commit on the
> branch that is checked out elsewhere, no?
Yes, I would, because by that point, I've already made the mistake of
checking out the same branch twice. I want git to prevent me from
doing that by accident. Because I don't want to ever be in the
situation which comes next, which is that I've got uncommitted work
for the same branch in two places!
> I am not saying we should never have an option to _warn_ checking out the
> same branch in multiple places. I am saying it is wrong to forbid doing so
> by default.
I am not saying we should never have an option to allow checking out
the same branch in multiple places. I am saying it is wrong to allow
doing so by default.
j.
^ permalink raw reply
* [PATCH v2 2/2] attr.c: respect core.ignorecase when matching attribute patterns
From: Brandon Casey @ 2011-10-06 4:00 UTC (permalink / raw)
To: gitster; +Cc: git, peff, Brandon Casey
In-Reply-To: <1317873614-3057-1-git-send-email-drafnel@gmail.com>
When core.ignorecase is true, the file globs configured in the
.gitattributes file should be matched case-insensitively against the paths
in the working directory. Let's do so.
Plus, add some tests.
The last set of tests is performed only on a case-insensitive filesystem.
Those tests make sure that git handles the case where the .gitignore file
resides in a subdirectory and the user supplies a path that does not match
the case in the filesystem. In that case^H^H^H^Hsituation, part of the
path supplied by the user is effectively interpreted case-insensitively,
and part of it is dependent on the setting of core.ignorecase. git should
only match the portion of the path below the directory holding the
.gitignore file according to the setting of core.ignorecase.
This is also partly future-proofing. Currently, git builds the attr stack
based on the path supplied by the user, so we don't have to do anything
special (like use strcmp_icase) to handle the parts of that path that don't
match the filesystem with respect to case. If git instead built the attr
stack by scanning the repository, then the paths in the origin field would
not necessarily match the paths supplied by the user. If someone makes a
change like that in the future, these tests will notice.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
attr.c | 5 ++-
t/t0003-attributes.sh | 60 ++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/attr.c b/attr.c
index 124337d..76b079f 100644
--- a/attr.c
+++ b/attr.c
@@ -11,6 +11,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";
@@ -631,7 +632,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
@@ -645,7 +646,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);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index ae2f1da..47a70c4 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -9,7 +9,7 @@ attr_check () {
path="$1"
expect="$2"
- git check-attr test -- "$path" >actual 2>err &&
+ git $3 check-attr test -- "$path" >actual 2>err &&
echo "$path: test: $2" >expect &&
test_cmp expect actual &&
test_line_count = 0 err
@@ -27,6 +27,7 @@ test_expect_success 'setup' '
echo "onoff test -test"
echo "offon -test test"
echo "no notest"
+ echo "A/e/F test=A/e/F"
) >.gitattributes &&
(
echo "g test=a/g" &&
@@ -93,6 +94,63 @@ test_expect_success 'attribute test' '
'
+test_expect_success 'attribute matching is case sensitive when core.ignorecase=0' '
+
+ test_must_fail attr_check F f "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/F f "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/c/F f "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/G a/g "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/B/g a/b/g "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/b/G a/b/g "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/b/H a/b/h "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/b/D/g "a/b/d/*" "-c core.ignorecase=0" &&
+ test_must_fail attr_check oNoFf unset "-c core.ignorecase=0" &&
+ test_must_fail attr_check oFfOn set "-c core.ignorecase=0" &&
+ attr_check NO unspecified "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/b/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check a/b/d/YES a/b/d/* "-c core.ignorecase=0" &&
+ test_must_fail attr_check a/E/f "A/e/F" "-c core.ignorecase=0"
+
+'
+
+test_expect_success 'attribute matching is case insensitive when core.ignorecase=1' '
+
+ attr_check F f "-c core.ignorecase=1" &&
+ attr_check a/F f "-c core.ignorecase=1" &&
+ attr_check a/c/F f "-c core.ignorecase=1" &&
+ attr_check a/G a/g "-c core.ignorecase=1" &&
+ attr_check a/B/g a/b/g "-c core.ignorecase=1" &&
+ attr_check a/b/G a/b/g "-c core.ignorecase=1" &&
+ attr_check a/b/H a/b/h "-c core.ignorecase=1" &&
+ attr_check a/b/D/g "a/b/d/*" "-c core.ignorecase=1" &&
+ attr_check oNoFf unset "-c core.ignorecase=1" &&
+ attr_check oFfOn set "-c core.ignorecase=1" &&
+ attr_check NO unspecified "-c core.ignorecase=1" &&
+ attr_check a/b/D/NO "a/b/d/*" "-c core.ignorecase=1" &&
+ attr_check a/b/d/YES unspecified "-c core.ignorecase=1" &&
+ attr_check a/E/f "A/e/F" "-c core.ignorecase=1"
+
+'
+
+test_expect_success 'check whether FS is case-insensitive' '
+ mkdir junk &&
+ echo good >junk/CamelCase &&
+ echo bad >junk/camelcase &&
+ if test "$(cat junk/CamelCase)" != good
+ then
+ test_set_prereq CASE_INSENSITIVE_FS
+ fi
+'
+
+test_expect_success CASE_INSENSITIVE_FS 'additional case insensitivity tests' '
+ test_must_fail attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=0" &&
+ test_must_fail attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=0" &&
+ attr_check A/b/h a/b/h "-c core.ignorecase=0" &&
+ attr_check A/b/h a/b/h "-c core.ignorecase=1" &&
+ attr_check a/B/D/g "a/b/d/*" "-c core.ignorecase=1" &&
+ attr_check A/B/D/NO "a/b/d/*" "-c core.ignorecase=1"
+'
+
test_expect_success 'unnormalized paths' '
attr_check ./f f &&
--
1.7.7.1.ge3b6f
^ permalink raw reply related
* [PATCH v2 1/2] attr: read core.attributesfile from git_default_core_config
From: Brandon Casey @ 2011-10-06 4:00 UTC (permalink / raw)
To: gitster; +Cc: git, peff, Brandon Casey
In-Reply-To: <1317873614-3057-1-git-send-email-drafnel@gmail.com>
From: Junio C Hamano <gitster@pobox.com>
This code calls git_config from a helper function to parse the config entry
it is interested in. Calling git_config in this way may cause a problem if
the helper function can be called after a previous call to git_config by
another function since the second call to git_config may reset some
variable to the value in the config file which was previously overridden.
The above is not a problem in this case since the function passed to
git_config only parses one config entry and the variable it sets is not
assigned outside of the parsing function. But a programmer who desires
all of the standard config options to be parsed may be tempted to modify
git_attr_config() so that it falls back to git_default_config() and then it
_would_ be vulnerable to the above described behavior.
So, move the call to git_config up into the top-level cmd_* function and
move the responsibility for parsing core.attributesfile into the main
config file parser.
Which is only the logical thing to do ;-)
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
attr.c | 15 ++-------------
builtin/check-attr.c | 2 ++
cache.h | 1 +
config.c | 3 +++
environment.c | 1 +
5 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/attr.c b/attr.c
index 0793859..124337d 100644
--- a/attr.c
+++ b/attr.c
@@ -20,8 +20,6 @@ static const char git_attr__unknown[] = "(builtin)unknown";
#define ATTR__UNSET NULL
#define ATTR__UNKNOWN git_attr__unknown
-static const char *attributes_file;
-
/* This is a randomly chosen prime. */
#define HASHSIZE 257
@@ -494,14 +492,6 @@ static int git_attr_system(void)
return !git_env_bool("GIT_ATTR_NOSYSTEM", 0);
}
-static int git_attr_config(const char *var, const char *value, void *dummy)
-{
- if (!strcmp(var, "core.attributesfile"))
- return git_config_pathname(&attributes_file, var, value);
-
- return 0;
-}
-
static void bootstrap_attr_stack(void)
{
if (!attr_stack) {
@@ -521,9 +511,8 @@ static void bootstrap_attr_stack(void)
}
}
- git_config(git_attr_config, NULL);
- if (attributes_file) {
- elem = read_attr_from_file(attributes_file, 1);
+ if (git_attributes_file) {
+ elem = read_attr_from_file(git_attributes_file, 1);
if (elem) {
elem->origin = NULL;
elem->prev = attr_stack;
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 708988a..abb1165 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -92,6 +92,8 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
struct git_attr_check *check;
int cnt, i, doubledash, filei;
+ git_config(git_default_config, NULL);
+
argc = parse_options(argc, argv, prefix, check_attr_options,
check_attr_usage, PARSE_OPT_KEEP_DASHDASH);
diff --git a/cache.h b/cache.h
index 607c2ea..8d95fb2 100644
--- a/cache.h
+++ b/cache.h
@@ -589,6 +589,7 @@ extern int warn_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
extern const char *apply_default_ignorewhitespace;
+extern const char *git_attributes_file;
extern int zlib_compression_level;
extern int core_compression_level;
extern int core_compression_seen;
diff --git a/config.c b/config.c
index 4183f80..d3bcaa0 100644
--- a/config.c
+++ b/config.c
@@ -491,6 +491,9 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.attributesfile"))
+ return git_config_pathname(&git_attributes_file, var, value);
+
if (!strcmp(var, "core.bare")) {
is_bare_repository_cfg = git_config_bool(var, value);
return 0;
diff --git a/environment.c b/environment.c
index e96edcf..d60b73f 100644
--- a/environment.c
+++ b/environment.c
@@ -29,6 +29,7 @@ const char *git_log_output_encoding;
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace;
const char *apply_default_ignorewhitespace;
+const char *git_attributes_file;
int zlib_compression_level = Z_BEST_SPEED;
int core_compression_level;
int core_compression_seen;
--
1.7.7.1.ge3b6f
^ permalink raw reply related
* [PATCH v2 0/2] reroll bc/attr-ignore-case (top two commits)
From: Brandon Casey @ 2011-10-06 4:00 UTC (permalink / raw)
To: gitster; +Cc: git, peff, Brandon Casey
This is the re-roll of this series that I said I would do.
This just swaps the order of the top two patches around and *hopefully*
improves the commit messages.
My original "attr.c: respect core.ignorecase.." patch was broken and I
intended to mark it as WIP. Your patch fixes it, but it's nicer if your
patch comes first, that way the test suite (and git) is never broken.
This is built on top of aae0befee293ebdf9aa6391a074eb0e7c10cdf75 in
bc/attr-ignore-case, which hopefully makes it easy to replace the top two
commits in that branch with these two commits.
I know this is already in next, and you seem poised to merge to master,
so feel free to drop these if you want.
Brandon Casey (1):
attr.c: respect core.ignorecase when matching attribute patterns
Junio C Hamano (1):
attr: read core.attributesfile from git_default_core_config
attr.c | 20 ++++------------
builtin/check-attr.c | 2 +
cache.h | 1 +
config.c | 3 ++
environment.c | 1 +
t/t0003-attributes.sh | 60 ++++++++++++++++++++++++++++++++++++++++++++++++-
6 files changed, 71 insertions(+), 16 deletions(-)
--
1.7.7.1.ge3b6f
^ permalink raw reply
* Re: [PATCHv3 5/5] Add test showing git-fetch groks gitfiles
From: Nguyen Thai Ngoc Duy @ 2011-10-06 3:13 UTC (permalink / raw)
To: Phil Hord; +Cc: git@vger.kernel.org, Phil Hord, Junio C Hamano, Erik Faye-Lund
In-Reply-To: <4E8C5D31.2000406@cisco.com>
On Thu, Oct 6, 2011 at 12:35 AM, Phil Hord <hordp@cisco.com> wrote:
> Add a test for two subtly different cases: 'git fetch path/.git'
> and 'git fetch path' to confirm that transport recognizes both
> paths as git repositories when using the gitfile mechanism.
It'd be interesting to test failed cases too. I can think of two: .git
file is not a valid file and .git points to an invalid repo.
--
Duy
^ permalink raw reply
* Re: [PATCHv3 2/5] Learn to handle gitfiles in enter_repo
From: Nguyen Thai Ngoc Duy @ 2011-10-06 3:11 UTC (permalink / raw)
To: Phil Hord; +Cc: git@vger.kernel.org, Phil Hord, Junio C Hamano, Erik Faye-Lund
In-Reply-To: <4E8C5C2E.50309@cisco.com>
On Thu, Oct 6, 2011 at 12:31 AM, Phil Hord <hordp@cisco.com> wrote:
> - if (!suffix[i] || chdir(used_path))
> + if (!suffix[i])
> + return NULL;
> + gitfile = read_gitfile(used_path) ;
> + if (gitfile)
> + strcpy(used_path, gitfile);
> + if (chdir(used_path))
> return NULL;
> path = validated_path;
> }
This is room for improvement, the patch is fine as it is now. We could
improve error reporting here. If .git file points to nowhere, we get
"not a repository-kind of message. Except daemon.c, enter_repo()
callers always die() if enter_repo() returns NULL. We could move the
die() part (with improved error message) into enter_repo().
We could update enter_repo(const char *, int) to enter_repo(const char
*, int, int gently). If gently is 1, we never die() nor report
anything (ie. what we're doing now). daemon.c will need this, the rest
of callers will be happy with gently = 0.
--
Duy
^ permalink raw reply
* Re: [PATCHv3 3/5] Add a common is_gitfile function
From: Nguyen Thai Ngoc Duy @ 2011-10-06 2:59 UTC (permalink / raw)
To: Phil Hord; +Cc: git@vger.kernel.org, Phil Hord, Junio C Hamano, Erik Faye-Lund
In-Reply-To: <4E8C5CC2.4030505@cisco.com>
On Thu, Oct 6, 2011 at 12:33 AM, Phil Hord <hordp@cisco.com> wrote:
> diff --git a/setup.c b/setup.c
> index 61c22e6..a3d5a41 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -358,7 +358,7 @@ const char *read_gitfile(const char *path)
>
> if (stat(path, &st))
> return NULL;
> - if (!S_ISREG(st.st_mode))
> + if (!is_gitfile(path))
> return NULL;
> fd = open(path, O_RDONLY);
> if (fd < 0)
> @@ -368,9 +368,6 @@ const char *read_gitfile(const char *path)
> close(fd);
> if (len != st.st_size)
> die("Error reading %s", path);
> - buf[len] = '\0';
> - if (prefixcmp(buf, "gitdir: "))
> - die("Invalid gitfile format: %s", path);
> while (buf[len - 1] == '\n' || buf[len - 1] == '\r')
> len--;
> if (len < 9)
I think you are changing the behavior here. Currently if .git is a
file and not a valid gitfile, die() will be called and repo discovery
process stops. With your patch, it skips invalid .git files and moves
on.
I'm not saying it's good or bad, just pointing out.
--
Duy
^ permalink raw reply
* Re: How do I investigate apparently random git clone reports of "error: File ... has bad hash"?
From: Thorkil Naur @ 2011-10-06 2:34 UTC (permalink / raw)
To: Andreas Schwab; +Cc: cvs-ghc, git
In-Reply-To: <m2r53metpo.fsf@igel.home>
Hello Andreas,
Thank you very much for your response. I have separately received the
advice of upgrading my curl installation:
> Date: Fri, 30 Sep 2011 09:08:56 +0200
> From: Karel Gardas <karel.gardas@centrum.cz>
> To: cvs-ghc <cvs-ghc@haskell.org>
> Subject: Re: tn23 (x86 OSX HEAD), build 442, Failure
> ...
> Hello,
>
> my opensolaris builder machine also suffered from the same issue like
> tn23 and sometimes even mbolingbroke and others. Symptoms are you are
> not able to grab the ghc code or subrepos code. The solution is
> simple: (1) either remove curl from your path or (2) update curl to
> the latest version (7.21.7 works for me) and make sure it is really
> using its latest libcurl. Once I did (2) here I've never seen the
> issue again.
> ...
Additional details:
> http://www.haskell.org/pipermail/cvs-ghc/2011-October/066434.html
So it appears that upgrading curl has removed the problem.
Best regards
Thorkil
On Sun, Sep 11, 2011 at 09:59:15PM +0200, Andreas Schwab wrote:
> Thorkil Naur <naur@post11.tele.dk> writes:
>
> >> $ git clone http://darcs.haskell.org/ghc.git/ build8
> >> Cloning into build8...
> >> error: File 42988feeeb76f5cb92b541e9dac277e073bcb3ef has bad hash
> >> error: Unable to find 42988feeeb76f5cb92b541e9dac277e073bcb3ef under
> > http://darcs.haskell.org/ghc.git
> >> Cannot obtain needed blob 42988feeeb76f5cb92b541e9dac277e073bcb3ef
> >> while processing commit ffb2e81c03a01e74825b3a0223e214df59241fab.
> >> error: Fetch failed.
>
> I just tried to clone it and got this error:
>
> $ git clone http://darcs.haskell.org/ghc.git
> Cloning into ghc...
> error: Recv failure: Connection reset by peer (curl_result = 56, http_code = 0, sha1 = be6810bb027643bf0697b3d237426110f064aba1)
> error: Unable to find be6810bb027643bf0697b3d237426110f064aba1 under http://darcs.haskell.org/ghc.git
> Cannot obtain needed commit be6810bb027643bf0697b3d237426110f064aba1
> while processing commit 6942b112082fbcdff5c66f06f56fdd336861da47.
> error: Fetch failed.
>
> It looks like this is just a network problem.
>
> Btw, the repo is rather strange. It's not a bare repo, but does not
> contain a .git directory. Instead the files that are normally under
> .git are placed directly in the working tree.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Nguyen Thai Ngoc Duy @ 2011-10-06 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrcj3sow.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 10:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Thu, Oct 6, 2011 at 9:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> I think of two options:
>>>> ...
>>> Sorry, what problem are you trying to solve? Does that "checkout -f" meant
>>> to nuke the local changes that are not yet at a good "stop point"?
>>
>> I meant "git checkout" on the already locked branch is refused, but
>> "git checkout -f" in that case will act just like "git checkout"
>> ignoring all locks. But I forgot that "git checkout -f" also discards
>> worktree changes. Maybe "git checkout --ignore-locks" instead of "git
>> checkout -f".
>
> I see what you mean, but doesn't it feel as if it is working around a
> problem that is introduced only because of a wrong policy (i.e. "you
> cannot check out the same branch at two places", as opposed to "viewing
> them in multiple places is perfectly fine, but no touching")?
Well, we could do change the default so "git checkout" == "git
checkout --ignore-locks".
"git commit --ignore-locks" would commit without checking locks. "git
commit" could either:
- reject because it does not hold the lock (to hostile?)
- detach automatically then commit
The latter has a benefit that we can now checkout tags without
detaching from the beginning. "git branch" would show tag name until
you commit.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
From: Brandon Casey @ 2011-10-06 2:00 UTC (permalink / raw)
To: Johannes Sixt
Cc: peff@peff.net, git@vger.kernel.org, gitster@pobox.com,
sunshine@sunshineco.com, bharrosh@panasas.com,
trast@student.ethz.ch, zapped@mail.ru
In-Reply-To: <CA+sFfMf73K3yv_5K633DKOsVufMV6rTjd+SSunq4sBikt4jCsg@mail.gmail.com>
[resend without html bits added by "gmail offline"]
So, it seems that of all of Google's email clients, only full desktop
gmail allows you to send plain text email (if you're careful to make
sure "Rich formatting" has not been clicked). The new offline gmail
sends html, gmail android app sends html, gmail mobile web sends html.
Google's war on plain text continues...
Or have I overlooked the switch that makes gmail send plain text and
only plain text?
On Wed, Oct 5, 2011 at 7:53 PM, Brandon Casey <drafnel@gmail.com> wrote:
> On Thursday, September 15, 2011, Brandon Casey wrote:
>>
>> On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt <j.sixt@viscovery.net>
>> wrote:
>> > Am 9/15/2011 3:59, schrieb Brandon Casey:
>> >> The "x"-prefixed versions of strdup, malloc, etc. will check whether
>> >> the
>> >> allocation was successful and terminate the process otherwise.
>> >>
>> >> A few uses of malloc were left alone since they already implemented a
>> >> graceful path of failure or were in a quasi external library like
>> >> xdiff.
>> >>
>> >> Signed-off-by: Brandon Casey <drafnel@gmail.com>
>> >> ---
>> >> ...
>> >> compat/mingw.c | 2 +-
>> >> compat/qsort.c | 2 +-
>> >> compat/win32/syslog.c | 2 +-
>> >
>> > There is a danger that the high-level die() routine (which is used by
>> > the
>> > x-wrappers) uses one of the low-level compat/ routines. IOW, in the case
>> > of errors, recursion might occur. Therefore, I would prefer that the
>> > compat/ routines do their own error reporting (preferably via return
>> > values and errno).
>>
>> Thanks. Will do.
>
> Hi Johannes,
> I have taken a closer look at the possibility of recursion with respect to
> die() and the functions in compat/. It appears the risk is only related to
> vsnprintf/snprintf at the moment. So as long as we avoid calling xmalloc et
> al from within snprintf.c, I think we should be safe from recursion.
> I'm inclined to keep the additions to mingw.c and win32/syslog.c since they
> both already use the x-wrappers or strbuf, even though they could easily be
> worked around. The other file that was touched is compat/qsort, which
> returns void and doesn't have a good alternative error handling path. So,
> I'm inclined to keep that one too.
> Sound reasonable?
> -Brandon
>
^ 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