* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Mika Fischer @ 2011-01-26 9:54 UTC (permalink / raw)
To: kusmabite; +Cc: msysGit, Git Mailing List
In-Reply-To: <AANLkTinGLMcRJ9EuZY_k4GoKyg+r7hxcgnq3z0=qOemA@mail.gmail.com>
On Wed, Jan 26, 2011 at 10:15, Mika Fischer
<mika.a.fischer@googlemail.com> wrote:
> I'll see if I can get a more current version of curl to compile under Windows.
I did not manage to do do this.
But I noticed that the same problem occurs on OpenSuSE 11.2. So I
compiled the latest version of curl on OpenSuSE 11.2 and the problem
is still present...
Best,
Mika
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Christian Couder @ 2011-01-26 9:44 UTC (permalink / raw)
To: Shuang He
Cc: git@vger.kernel.org, apenwarr@gmail.com, Junio C Hamano,
Johannes Sixt
In-Reply-To: <4D3FCBB3.2090508@intel.com>
On Wed, Jan 26, 2011 at 8:22 AM, Shuang He <shuang.he@intel.com> wrote:
> On 2011/1/25 17:20, Christian Couder wrote:
>>
>>>
>>> Yeah, I agree that the issue I addressed above will not be a problem if
>>> all
>>> those branches are maintained very well.
>>> Actually we've implemented a automated bisect system for Intel Linux
>>> Graphics Driver Project, and so we'd like the system
>>> helps us to locate issue in an more automatic way when branches are not
>>> maintained as good as expected.
>>
>> I think there is always a price to pay when you bisect if the branches
>> are not well maintained.
>> Maybe your algorithm could help in some cases, but my opinion is that
>> there will probably still be many problems and a human will often have
>> to take a look.
>>
>
> Yes, I agree. What we trying to do is just make the machine to do more help
> for human.
Yeah, this is the way to go. And by the way I am happy to know that
you have implemented an automated bisect system. That's great and I
hope it already helps.
>>>> - the name "bisectbadbranchfirst" seems wrong to me, because git
>>>> branches are just some special tags; "firstparentsonly" would be a
>>>> better name,
>>>
>>> It's recursively applying bad branch first algorithm, not just constantly
>>> stick to first parent.
>>> Given this condition:
>>> A -> B -> C -> D -> E -> F -> G -> H (master)
>>> \ a -> b -> c -> d -> e / (feature 1)
>>> \ x -> y -> z/ (feature 2)
>>> start with H as bad commit, and A as good commit, if y is the target bad
>>> commit. bad-branch-first algorithm will do it like this:
>>> 1. In first round stick to master branch, so it will locate G as first
>>> bad commit
>>> 2. In second round stick to feature1 branch, then it will locate d as
>>> first bad commit
>>> 3. In third round stick to feature2 branch, then it will finally
>>> locate y
>>> as first bad commit
>>> So you could see, it's always sticking to branch where current bad commit
>>> sit
>>
>> I see. It is interesting, but why not develop a "firstparentsonly"
>> algorithm first?
>>
>> As Avery explains in his email, it is already interesting to have a
>> "firstparentsonly" algorithm because some people are only interested
>> to know from which branch the bug comes from.
>> When they know that, they can just contact the relevant people and be
>> done with it.
>>
>> And when we have a "firstparentsonly" algorithm, then your algorithm
>> could be just a script that repeatedly uses git bisect with the
>> "firstparentsonly" algorithm. And this script might be integrated in
>> the "contrib" directory if it not considered important to be
>> integrated as an algorithm into git bisect.
>
> Sorry to reply so late, since I was on a long journey home for Chinese New
> Year vacation ;)
No problem. I am not in a hurry at all. In fact I don't have much time
these days so I reply very late too.
> I agree that's also an good option.
> Is it acceptable to add option to git-bisect stuff, so user could choose
> which algorithm to use at every step at will.
Are you sure it is needed to be able to change the algorithm at every step?
This means that you would like a new "git bisect strategy <strategy>"
subcommand ?
First I thought that we could just add a "--strategy <strategy>"
option to "git bisect start".
But anyway, I think it should be easy to add afterward, and it can be
done in a separated patch that can be discussed on its own.
> And we have tested previous attached patch with t6002-rev-list-bisect.sh and
> t6030-bisect-porcelain.sh, and we get:
> with bad-branch-first disabled (which is the default setting):
> t6002-rev-list-bisect.sh: # passed all 45 test(s)
> t6030-bisect-porcelain.sh: # passed all 40 test(s)
> and with bad-branch-first enabled:
> t6002-rev-list-bisect.sh: # passed all 45 test(s)
> t6030-bisect-porcelain.sh: # failed 5 among 40 test(s), and I have
> spent some time digging into those failures ,and it seems they're all false
> negative since they're using hard-coded bisect path to validate specific
> case
Yes, there are some hard coded commits that depend on the algorithm.
Anyway I did not look in depth at your patch yet, and as I said it
would be better if you could split it into a patch series where a
"firstparentsonly" algorithm is implemented first.
This way it will be easier to review, and we can start to integrate
some non controversial features, and then discuss the other ones on
their own merit.
Thanks in advance,
Christian.
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Mika Fischer @ 2011-01-26 9:15 UTC (permalink / raw)
To: kusmabite; +Cc: msysGit, Git Mailing List
In-Reply-To: <AANLkTi=UQR3cEbTj4N0W_4CLG9T1F+rmkLEew+WO4w5f@mail.gmail.com>
Hi Erik,
many thanks for your comments!
On Tue, Jan 25, 2011 at 20:05, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> with the latest msysGit (1.7.3.1-preview20101002.exe), I cannot access
>> git repositories via https, if they are served by an apache using
>> OpenSSL 1.0.0
>>
>> The error is:
>> ----
>> error: error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
>> while accessing https://server/repository/info/refs
>>
>> fatal: HTTP request failed
>> ----
>>
>> An apache using OpenSSL 0.9.8 works fine.
>>
>> There seem to be some SSL handshake issues, when curl and apache use
>> different versions of OpenSSL:
>> http://bugs.gentoo.org/332661
>
> This issue is listed as an issue with Gentoo's OpenSSL 1.0.0 builds,
> and seems to be have resolved by adding back SSLv2 support.
>
>> http://comments.gmane.org/gmane.comp.web.curl.general/11154
>
> This seems to be an issue with Fedora's OpenSSL 1.0.0 builds.
I found something else, which seems to be more related to my exact issue:
http://www.mentby.com/Group/curl/curl-outputs-ssl23getserverhello.html
I've also tried doing "openssl s_client -connect <server>:443" with
the openssl command line tool that's included in the current msysgit,
and that works just fine.
> Git for Windows currently use OpenSSL 0.9.8k, so this sounds to me
> like an issue in your server-end. Your server seems to simply be
> incompatible with OpenSSL 0.9.8-clients, which is the vast majority of
> SSL-clients out there.
I find it hard to believe that something like this would have gone
unnoticed for such a long time. Most Linux distributions nowadays come
with OpenSSL 1.0.0 and that would mean that any webserver set up on
them could not communicate with any client using OpenSSL 0.9.8. Since
the openssl command line tool works fine, I think it must be something
much more specific and it must have something to do with curl.
I'll see if I can get a more current version of curl to compile under Windows.
I also wanted to try compiling a more current version of OpenSSL but
the build hangs at "Generating DLL definition files". Any idea what
might be the problem?
> AFAICT, Git does not run curl, but use libcurl instead. It doesn't set
> CURLOPT_SSLVERSION, and Git for Windows use libcurl 7.21.1 where
> either SSLv3 or TLSv1 seems to be the default. So I don't know if
> there's anything we can do about this on the Git side. You could try
> to set CURLOPT_SSLVERSION to work around the issue, but I don't think
> this is something we'd want to do in a Git for Windows release.
This environment variable has no effect for me, neither with git nor
with the command line client.
Best,
Mika
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Francis Moreau @ 2011-01-26 9:01 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D3EF650.20407@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
[...]
> Hmm, seems like the function is gone since d847059. Does all of this help
> you in any way?
Sigh... one more try, one more failure...
This time I tried to use git-bisect(1) to see if I couldn't track the
change more easily.
So, here's what I did:
$ cat ./bisect.sh
#! /bin/sh
if ! git grep -q -e blacklist_iommu -- drivers/pci/intel-iommu.c
then
exit 1
fi
$ git bisect start v2.6.28 v2.6.27 -- drivers/pci
Bisecting: 70 revisions left to test after this (roughly 6 steps)
[a0bfb673dca8a2b4324fe11e678ec6d6a9ad67e0] Merge branch 'linux-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
$ git bisect run ./bisect.sh
running /dev/shm/bisect.sh
Bisecting: 42 revisions left to test after this (roughly 5 steps)
[0235c4fc7fc6f621dc0dd89eba102ad5aa373390] PCI PM: Introduce function
pci_wake_from_d3
running /dev/shm/bisect.sh
error: The following untracked working tree files would be overwritten
by checkout:
arch/x86/es7000/Makefile
arch/x86/es7000/es7000.h
arch/x86/es7000/es7000plat.c
drivers/pci/dma_remapping.h
Please move or remove them before you can switch branches.
Bisecting: 18 revisions left to test after this (roughly 4 steps)
Aborting
bisect run failed:
'bisect_state bad' exited with error code 1
Do you know what's going wrong ?
Thanks
--
Francis
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Francis Moreau @ 2011-01-26 8:36 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <m2ipxc27zi.fsf@gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Am 25.01.2011 10:01, schrieb Francis Moreau:
>>>
>>> The project is the Linux kernel, and I'm trying to look for changes
>>> which happened between v2.6.27 and v2.6.28. The changes happened in the
>>> following file: drivers/pci/intel-iommu.c where a function has been
>>> removed:
>>>
>>> $ git --version
>>> git version 1.7.4.rc3
>>>
>>> $ cd ~/linux-2.6/drivers/pci/
>>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c
>>> $
>>>
>>> No ouput... hmm, I know it's in... oh maybe the path is incorrect
>>>
>>> $ git git grep blacklist v2.6.27 -- intel-iommu.c
>>> v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)
>>> v2.6.27:intel-iommu.c: .callback = blacklist_iommu,
>>>
>>> ah, so Git failed previously without any comments on the wrong
>>> path... maybe it should ?
>>
>> Good idea.
>>
>
> Actually I _think_ I encoutered this behaviour for other commands as well,
> like git-show or git-log, I don't remember.
>
>>
>>> So at that point I know that in the revision v2.6.27, there's a function
>>> called "blacklist_iommu" in drivers/pci/intel-iommu.c
>>>
>>> Now take a look if it's still there in v2.6.28:
>>>
>>> $ git git grep blacklist v2.6.28 -- intel-iommu.c
>>> $
>>>
>>> This time nothing is printed but I know that the command is correct.
>>>
>>> So now I'm interested in looking for the commit which removed this
>>> function. Fo this I'm trying to use git-log(1):
>>>
>>> $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c
>>> $ echo $?
>>> 0
>>>
>>> I tried different options but it fails.
>>>
>>> Also I found that passing the exact string to '-S' is annoying, are
>>> there any way to just pass a part of the string such as
>>> "-Sblacklist_iommu" ?
>>
>> This (-Sblacklist_iommu) works for me.
>>
>
> Hmm, I thought I tried this and it didn't work, but that's obviously
> wrong.
>
>>
>>> Sorry if I miss the revelant git-log's option, but there're so many...
>>
>> Try -m (show full diff for merge commits), as the change you're looking
>> for seems to have been introduced by a merge, not a regular commit.
>>
>> $ opts="--stat -Sblacklist_iommu -m --oneline"
>> $ revs="v2.6.27..v2.6.28"
>>
>> $ git log $opts $revs -- drivers/pci/intel-iommu.c
>>
>> This returns nothing. Hmm. Let's try this instead:
>>
>> $ git log $opts $revs -- drivers/pci/
>> 057316c (from 3e2dab9) Merge branch 'linus' into test
>> drivers/pci/intel-iommu.c | 307 ++++++++++++++++++++------------------------
>> 1 files changed, 140 insertions(+), 167 deletions(-)
>> 6b2ada8 (from 3b7ecb5) Merge branches 'core/softlockup', 'core/softirq', 'core/resources', 'core/printk' and 'core/misc' into core-v28-for-linus
>> drivers/pci/intel-iommu.c | 187 ++++++--------------------------------------
>> 1 files changed, 26 insertions(+), 161 deletions(-)
>> d847059 (from 725c258) Merge branch 'x86/apic' into x86-v28-for-linus-phase4-B
>> drivers/pci/intel-iommu.c | 185 ++++++---------------------------------------
>> 1 files changed, 25 insertions(+), 160 deletions(-)
>> 725c258 (from 129d6ab) Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B
>> drivers/pci/intel-iommu.c | 25 ++++++++++++++++++++++++-
>> 1 files changed, 24 insertions(+), 1 deletions(-)
>> 6e03f99 (from 9821626) Merge branch 'linus' into x86/iommu
>> drivers/pci/intel-iommu.c | 23 +++++++++++++++++++++++
>> 1 files changed, 23 insertions(+), 0 deletions(-)
>>
>> Strange, why did we need to remove the last path component to get these
>> results which say that exactly the file we previously specified was changed?
>
> ah... I think I've been hit by this, since I tried '-m' too but see
> nothing and was not smart enough to remove the filename from the path.
>
>> Also interesting, and matching the above results in that we see the need for
>> the -m flag confirmed:
BTW, couldn't '-m' automatically set when '-S' is given ?
>>
>>
>> $ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99
>> do
>> a=$(git show $merge | grep -c blacklist_iommu)
>> b=$(git show -m $merge | grep -c blacklist_iommu)
>> echo $merge $a $b
>> done
>> 057316c 0 2
>> 6b2ada8 0 2
>> d847059 0 2
>> 725c258 0 2
>> 6e03f99 0 2
>>
>> IAW: the combined diff for the five found merges doesn't show any changes to
>> a line containing the string "blacklist_iommu", but the full diffs do.
>>
>> Let's check for the presence of the string in the merge results and their
>> parents:
>>
>> $ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99
>> do
>> for rev in $(git show $merge | grep ^Merge:)
>> do
>> t=parent
>> case $rev in
>> Merge:)
>> echo
>> rev=$merge
>> t=merge
>> ;;
>> esac
>> if git grep -q blacklist_iommu $rev -- drivers/pci/
>> then
>> echo "$t $rev: found"
>> else
>> echo "$t $rev: not found"
>> fi
>> done
>> done
>>
>> merge 057316c: not found
>> parent 3e2dab9: found
>> parent 2515ddc: not found
>>
>> merge 6b2ada8: not found
>> parent 278429c: not found
>> parent 3b7ecb5: found
>> parent 77af7e3: not found
>> parent 1516071: not found
>> parent 1fa63a8: not found
>> parent 8546232: not found
>>
>> merge d847059: not found
>> parent 725c258: found
>> parent 11494547: not found
>>
>> merge 725c258: found
>> parent 3dd392a: found
>> parent 72d3105: found
>> parent 129d6ab: not found
>> parent 1e19b16: found
>>
>> merge 6e03f99: found
>> parent 9821626: not found
>> parent 6bfb09a: found
>>
>> Hmm, seems like the function is gone since d847059. Does all of this help
>> you in any way?
>
> Yes it does, but one question I'm wondering is: is it possible to do
> this more user friendly ? ;)
I tried to reproduce something similar but with a far more simple repo:
<v2.6.28> 1.f o
|
1.e o (merge)
| \
1.d o o 2.c (merge)
| | \
1.c o o o 3.a "Remove blacklist_iommu()"
| | /
| o 2.a
| /
1.b o
|
<v2.6.27> 1.a o "Introduce blacklist_iommu()"
|
o Init
Basically this repo 3 branches: master, 2, 3. Master branch introduces
the "blacklist_iommu()" function with commit 1.a, and branch "3" removes
it at commit 3.a.
So now:
$ git log --oneline -S"blacklist_iommu"
ea1ddb0 3.a
8053460 1.a
$ git show :/3.a
commit ea1ddb023833470be173363a71a3a055ae8acb85
Author: Francis Moreau <fmoreau@spoutnik.(none)>
Date: Wed Jan 26 09:17:58 2011 +0100
3.a
Remove blacklist_iommy()
diff --git a/intel-iommu.c b/intel-iommu.c
index 2c9539d..f19c1cc 100644
--- a/intel-iommu.c
+++ b/intel-iommu.c
@@ -2,12 +2,4 @@ Wed Jan 26 09:10:15 CET 2011
Wed Jan 26 09:16:23 CET 2011
-static int blacklist_iommu(const struct dmi_system_id *id)
-{
- printk(KERN_INFO "%s detected; disabling IOMMU\n",
- id->ident);
- dmar_disabled = 1;
- return 0;
-}
-
Wed Jan 26 09:14:40 CET 2011
So in this case there's no need to pass the '-m' flag and git-log(1), by
default walks through all the commits:
$ git log --oneline v2.6.27..v2.6.28
e2a5af3 1.e
c9fbd3a Merge branch '2'
a8207d9 Merge branch '3' into 2
ea1ddb0 3.a
3a86ada 2.b
767186a 2.a
45beaac 1.d
1af781c 1.c
4f9b5c1 1.b
8053460 1.a
whereas in my previous example, it doesn't seem to be true.
Could you shed some light ?
Thanks
--
Francis
^ permalink raw reply
* Re: [PATCH 2/2] Re: rebase -i: explain how to discard all commits
From: Jay Soffian @ 2011-01-26 7:33 UTC (permalink / raw)
To: Joshua Jensen
Cc: Matthieu Moy, Junio C Hamano, Johannes Schindelin, Thomas Rast,
Nicolas Sebrecht, Jonathan Nieder, git, Kevin Ballard,
Yann Dirson, Eric Raible
In-Reply-To: <4D39C923.20202@workspacewhiz.com>
On Fri, Jan 21, 2011 at 12:57 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> I've always wished "git reset --hard" would tell me there are modified files
> and force me to type "git reset --hard --force" to overwrite them. It is a
> dangerous command, and I stupidly run it sometimes without running "git
> status" first.
Something analogous to clean.requireForce?
j.
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Shuang He @ 2011-01-26 7:22 UTC (permalink / raw)
To: Christian Couder
Cc: git@vger.kernel.org, apenwarr@gmail.com, Junio C Hamano,
Johannes Sixt
In-Reply-To: <AANLkTin1rS-ZBDx4j-UNFH4z9tnTiv5LBodLO-G2U2UF@mail.gmail.com>
On 2011/1/25 17:20, Christian Couder wrote:
> On Mon, Jan 24, 2011 at 11:30 AM, Shuang He<shuang.he@intel.com> wrote:
>> On 2011/1/24 17:53, Christian Couder wrote:
>>> Hi,
>>>
>>> On Mon, Jan 24, 2011 at 3:03 AM, Shuang He<shuang.he@intel.com> wrote:
>>>> Hi
>>>> The default git-bisect algorithm will jump around the commit tree,
>>>> on the purpose of taking least steps to find the first culprit commit.
>>>> We may find it sometime would locate a old culprit commit that we're not
>>>> concerned about anymore.
>>> Yes, it can be a problem.
>> I'm honored to be given so much comment :)
>> Thank you
> I am honored by your interest in git bisect and the fact that you
> provided a patch :-)
> Thanks!
I'm glad to see that git community is so hot.
>
>>> If the quality of these branches is too bad, I think they should not
>>> have been merged in the first place.
>>> If they are not merged (and not marked as good), then git bisect will
>>> not look at them, since it will look only at commits that are
>>> ancestors of the bad commit it is given.
>>>
>>> Or if one is merged but it causes too many problems, then perhaps a
>>> replacement commit could be used to unmerge the branch.
>>>
>>> Another possibility is to have in a file a list of commits that are
>>> the last commits on these branches before the merge commits, and do a:
>>>
>>> git bisect good $(cat good_commits_file.txt)
>>>
>>> at the beginning of each bisection.
>>>
>>> So I think the long term solution in this case is not what your are
>>> suggesting.
>> Yeah, I agree that the issue I addressed above will not be a problem if all
>> those branches are maintained very well.
>> Actually we've implemented a automated bisect system for Intel Linux
>> Graphics Driver Project, and so we'd like the system
>> helps us to locate issue in an more automatic way when branches are not
>> maintained as good as expected.
> I think there is always a price to pay when you bisect if the branches
> are not well maintained.
> Maybe your algorithm could help in some cases, but my opinion is that
> there will probably still be many problems and a human will often have
> to take a look.
>
Yes, I agree. What we trying to do is just make the machine to do more
help for human.
>>>> 2. Some of those branches may not synchronized with main
>>>> branch in time. Say feature1 is broken when feature2 branch is created,
>>>> and
>>>> feature1 is fixed just a moment later after feature2 branch is created,
>>>> and when feature2's development is done, and developer want to merge
>>>> feature2 branch back to master branch, feature2 will be firstly
>>>> synchronized to master branch tip, then merge into master. For the same
>>>> reason addressed in issue 1, this will also lead git-bisect into wrong
>>>> direction.
>>> I am not sure what you mean by " feature2 will be firstly synchronized
>>> to master branch tip", and I think this should mean a rebase that
>>> would fix the bug if feature1 has already been merged into the master
>>> branch.
>>>
>>> But anyway in this case, I think that git bisect will find that the
>>> first bad commit is the last commit in the branch, just before it was
>>> merged. And by looking at the branch graph it should be quite easy to
>>> understand what happened.
> Now I think I was wrong here, as git bisect will probably find that
> the first commit in the branch (not the last one) is the first bad
> commit.
>
> [...]
>
>>> - the name "bisectbadbranchfirst" seems wrong to me, because git
>>> branches are just some special tags; "firstparentsonly" would be a
>>> better name,
>> It's recursively applying bad branch first algorithm, not just constantly
>> stick to first parent.
>> Given this condition:
>> A -> B -> C -> D -> E -> F -> G -> H (master)
>> \ a -> b -> c -> d -> e / (feature 1)
>> \ x -> y -> z/ (feature 2)
>> start with H as bad commit, and A as good commit, if y is the target bad
>> commit. bad-branch-first algorithm will do it like this:
>> 1. In first round stick to master branch, so it will locate G as first
>> bad commit
>> 2. In second round stick to feature1 branch, then it will locate d as
>> first bad commit
>> 3. In third round stick to feature2 branch, then it will finally locate y
>> as first bad commit
>> So you could see, it's always sticking to branch where current bad commit
>> sit
> I see. It is interesting, but why not develop a "firstparentsonly"
> algorithm first?
>
> As Avery explains in his email, it is already interesting to have a
> "firstparentsonly" algorithm because some people are only interested
> to know from which branch the bug comes from.
> When they know that, they can just contact the relevant people and be
> done with it.
>
> And when we have a "firstparentsonly" algorithm, then your algorithm
> could be just a script that repeatedly uses git bisect with the
> "firstparentsonly" algorithm. And this script might be integrated in
> the "contrib" directory if it not considered important to be
> integrated as an algorithm into git bisect.
Sorry to reply so late, since I was on a long journey home for Chinese
New Year vacation ;)
I agree that's also an good option.
Is it acceptable to add option to git-bisect stuff, so user could choose
which algorithm to use at every step at will.
And we have tested previous attached patch with t6002-rev-list-bisect.sh
and t6030-bisect-porcelain.sh, and we get:
with bad-branch-first disabled (which is the default setting):
t6002-rev-list-bisect.sh: # passed all 45 test(s)
t6030-bisect-porcelain.sh: # passed all 40 test(s)
and with bad-branch-first enabled:
t6002-rev-list-bisect.sh: # passed all 45 test(s)
t6030-bisect-porcelain.sh: # failed 5 among 40 test(s), and I
have spent some time digging into those failures ,and it seems they're
all false negative since they're using hard-coded bisect path to
validate specific case
Thanks
--Shuang
> Thanks,
> Christian.
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Shuang He @ 2011-01-26 7:11 UTC (permalink / raw)
To: Avery Pennarun
Cc: Christian Couder, git@vger.kernel.org, Johannes Sixt,
Junio C Hamano
In-Reply-To: <AANLkTinwbm9gcZhGeQCbOEPov0_xV7uJyQvC7J13qO15@mail.gmail.com>
On 2011/1/25 4:28, Avery Pennarun wrote:
> On Mon, Jan 24, 2011 at 1:53 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> I am not opposed to an option to bisect on the first parents of the
>> bad commit only. And after a very fast look at your patch it seems to
>> be what it does. By the way Avery Pennarun's gitbuilder
>> (https://github.com/apenwarr/gitbuilder) does the same thing. So I
>> know some people are interested in such a feature.
> Just some notes on gitbuilder's algorithm, since I haven't spent the
> time to fully understand Shuang's proposal.
>
> I do understand at least one of his concerns, that is, that people
> like to do a lot of "messy" development on a branch, and when the
> branch is done, merge the whole messy branch into the "mainline". The
> messy branch would then have a lot of commits that break a lot of
> things before fixing them again later.
>
> In a corporate environment, this method allows people to work all day,
> make frequent commits, pull from other branches at will, and never
> risk their lives by doing poorly-educated rebases. It works pretty
> well *until* you try to bisect, at which time all these messy commits
> start to bite you.
>
> gitbuilder's bisection is a total hack around this situation, although
> it happens to work perfectly in the workflow it was designed for, thus
> making me feel clever.
>
> Basically, we push/fetch *all* the branches from *everybody* into a
> single repo, and build all of them as frequently as we can. If you
> think about it, if you have all the branches that someone might have
> pulled/merged from, then you don't have to think of the git history as
> a whole complicated DAG; you can just think of it as a whole bunch of
> separate chunks of linear history. Moreover, as long as people are
> careful to only pull from a branch when that branch is passing all
> tests - which you can easily see by looking at the gitbuilder console
> - then playing inside each of these chunks of linear history can help
> you figure out where particular bugs were introduced during "messy"
> branches.
>
> It also allows you a nice separation of concerns. The owner of the
> mainline branch (the "integration manager" person) only really cares
> about which branch they merged that caused a problem, because that
> person doesn't want to fix bugs, he/she simply wants to know who owns
> the failing branch, so that person can fix *their* bug and their
> branch will merge without breaking things.
>
> So this is why gitbuilder uses "git rev-list --first-parent" during
> its "fake bisection" operation: because a different person is
> responsible for each "linear chunk" of history.
>
> Note that you have to use --no-ff when merging if you want this to
> work reliably. But the build manager person can just remember to do
> that. Combining --no-ff and --ff-only (which sound mutually exclusive
> but aren't) is a way to be extra specially sure.
>
> Now, if you aren't using gitbuilder, what we want from "bisection" is
> not quite the same, but let's imagine that you at least have a similar
> setup, where people *only* ever merge into the mainline by using
> --no-ff. In that case, you'd like a bisect operation that *starts* by
> using --first-parent, which will tell you which merge caused the
> problem. After that, you might want to bisect into the branch.
>
> (I don't actually remember if 'git bisect' understands --first-parent
> correctly. gitbuilder doesn't exactly bisect either, but that's
> another story and not relevant right now.)
>
> I can actually imagine that there are many more projects that do what
> I'm talking about - "messy" branches that get broken and fixed over
> time, then merge into a "clean" mainline - than projects (like the
> kernel and git.git) that try to keep all branches clean at all times.
> Thus, I could see some argument that a "--first-parents first"
> bisection would actually help out a lot of people, and maybe even
> deserves to be the default.
>
> I don't really care though, I just use gitbuilder :)
>
> Have fun,
>
> Avery
Thanks for helping explaining those stuff, and also glad to learn more
about gitbuilder :)
Thanks
--Shuang
^ permalink raw reply
* Re: fatal: protocol error: bad line length character: GET <<<<<
From: Alan Sargent @ 2011-01-26 6:40 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20110126055955.GA13304@LK-Perkele-VI.localdomain>
Ah! Thank you very much.
:)
On Wed, Jan 26, 2011 at 1:59 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 26, 2011 at 12:53:11PM +0800, Alan Sargent wrote:
>> Hello,
>>
>> The "fatal: protocol error: bad line length character" seems fairly
>> common, but in the archive and the faq there isn't reference to this
>> particular instances - GET.
>>
>> alan@toaster:~$ git init myrepo
>> Initialized empty Git repository in /home/nev/myrepo/.git/
>> alan@toaster:~$ cd myrepo
>> alan@toaster:~/myrepo$ git daemon
>> fatal: protocol error: bad line length character: GET << just hitting
>> F5 in the browser
>> fatal: protocol error: bad line length character: GET
> [...]
>
> Git daemon serves git:// protocol, not HTTP, you can't access it from
> web browser.
>
> If you are looking for Git repository web interface, look at gitweb
> or cgit.
>
> The error is because HTTP begins the request with "GET " and git
> daemon is trying to interpret that as length of packet, failing
> and spitting out a fatal error.
>
> -Ilari
>
^ permalink raw reply
* Re: fatal: protocol error: bad line length character: GET <<<<<
From: Ilari Liusvaara @ 2011-01-26 5:59 UTC (permalink / raw)
To: Alan Sargent; +Cc: git
In-Reply-To: <AANLkTimDbHdOwkPu6qihdgJFY0bS0XTVatLCriCmM1nX@mail.gmail.com>
On Wed, Jan 26, 2011 at 12:53:11PM +0800, Alan Sargent wrote:
> Hello,
>
> The "fatal: protocol error: bad line length character" seems fairly
> common, but in the archive and the faq there isn't reference to this
> particular instances - GET.
>
> alan@toaster:~$ git init myrepo
> Initialized empty Git repository in /home/nev/myrepo/.git/
> alan@toaster:~$ cd myrepo
> alan@toaster:~/myrepo$ git daemon
> fatal: protocol error: bad line length character: GET << just hitting
> F5 in the browser
> fatal: protocol error: bad line length character: GET
[...]
Git daemon serves git:// protocol, not HTTP, you can't access it from
web browser.
If you are looking for Git repository web interface, look at gitweb
or cgit.
The error is because HTTP begins the request with "GET " and git
daemon is trying to interpret that as length of packet, failing
and spitting out a fatal error.
-Ilari
^ permalink raw reply
* Re: [PATCH/RFC 0/3] trace: omit noisy repository discovery report
From: Jeff King @ 2011-01-26 5:07 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jonathan Nieder, git, Junio C Hamano
In-Reply-To: <AANLkTimB0rJPLkwyrQEibngeRjgHLxhrntG5sMdQ9CW0@mail.gmail.com>
On Wed, Jan 26, 2011 at 08:45:12AM +0700, Nguyen Thai Ngoc Duy wrote:
> > A few days ago I was tracing something or other and decided that these
> > extra lines are annoying.
> >
> > Patch 1 moves this code from trace.c to git.c, to contain its impact
> > to a single translation unit (that is, it let me experiment without
> > touching cache.h after that).
> >
> > Patch 2 removes the repo-setup tracing code, introducing a
> > test-repo-setup helper to take its place in the repo setup tests.
> >
> > Patch 3 does some cleaning up made possible by patch 2.
> >
> > Thoughts?
>
> I'm fine with this. Although long term maybe we should support pattern
> matching or category selection in GIT_TRACE.
Yeah. I recently was peeking at the git protocol, and I wrote some
nice-ish packet-tracing support. I triggered it via:
GIT_TRACE=$whatever GIT_TRACE_PACKET=1 git push ...
So you have to turn on tracing (to whatever destination you want) and
then turn on packet tracing with a bool. In retrospect, probably
GIT_TRACE_* should take the same type of location parameter as
GIT_TRACE, so you can get whatever subset of trace going to wherever you
like. And then the repo setup code can just go into GIT_TRACE_SETUP or
something.
-Peff
^ permalink raw reply
* fatal: protocol error: bad line length character: GET <<<<<
From: Alan Sargent @ 2011-01-26 4:53 UTC (permalink / raw)
To: git
Hello,
The "fatal: protocol error: bad line length character" seems fairly
common, but in the archive and the faq there isn't reference to this
particular instances - GET.
alan@toaster:~$ git init myrepo
Initialized empty Git repository in /home/nev/myrepo/.git/
alan@toaster:~$ cd myrepo
alan@toaster:~/myrepo$ git daemon
fatal: protocol error: bad line length character: GET << just hitting
F5 in the browser
fatal: protocol error: bad line length character: GET
browser showing Error 101 (net::ERR_CONNECTION_RESET): Unknown error.
fatal: protocol error: bad line length character: GET
fatal: protocol error: bad line length character: GET
fatal: protocol error: bad line length character: GET
fatal: protocol error: bad line length character: GET
fatal: protocol error: bad line length character: GET
This is on Ubuntu, git installed fresh or built it from latest stable
source. Same on a repo that has stuff in it.
Anyone know why?
Cheers.
^ permalink raw reply
* Re: Fwd: Git and Large Binaries: A Proposed Solution
From: Scott Chacon @ 2011-01-26 3:42 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Eric Montellese, Jeff King, git list
In-Reply-To: <20110123141417.GA6133@mew.padd.com>
Hey,
Sorry to come in a bit late to this, but in addition to git-annex, I
wrote something called 'git-media' a long time ago that works in a
similar manner to what you both are discussing.
Much like what peff was talking about, it uses the smudge and clean
filters to automatically redirect content into a .git/media directory
instead of into Git itself while keeping the SHA in Git. One of the
cool thing is that it can use S3, scp or a local directory to transfer
the big files to and from.
Check it out if interested:
https://github.com/schacon/git-media
On Sun, Jan 23, 2011 at 6:14 AM, Pete Wyckoff <pw@padd.com> wrote:
> peff@peff.net wrote on Fri, 21 Jan 2011 17:24 -0500:
>
> Just a quick aside. Since (a2b665d, 2011-01-05) you can provide
> the filename as an argument to the filter script:
>
> git config --global filter.huge.clean huge-clean %f
>
This is amazing. I absolutely did not know you could do this, and it
would make parts of git-media way better if I re-implemented it using
this. Thanks for pointing this out.
Scott
^ permalink raw reply
* Re: [PATCH 2/3] trace: omit repository discovery report
From: Nguyen Thai Ngoc Duy @ 2011-01-26 1:53 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano
In-Reply-To: <20110126005916.GC11230@burratino>
2011/1/26 Jonathan Nieder <jrnieder@gmail.com>:
> +int main(int argc, char **argv)
> +{
> + static struct startup_info test_startup_info;
> +
> + startup_info = &test_startup_info;
> + setup_git_directory();
I think you should do _gently() here (in future maybe, because t1510
does not use it yet).
Note to self, support for testing setup_work_tree() behavior.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/3] trace: omit repository discovery report
From: Jonathan Nieder @ 2011-01-26 1:46 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Nguyễn Thái Ngọc, git, Junio C Hamano
In-Reply-To: <AANLkTinyVKQOVHgdVhB3PhQOp9FbdNNHLqYny6i=_qKw@mail.gmail.com>
Sverre Rabbelier wrote:
> 2011/1/26 Jonathan Nieder <jrnieder@gmail.com>:
>> In practice, four extra lines of trace output per git process is too
>> much noise. So stop printing repository discovery info except when
>> running tests.
>
> Doesn't this disable _all_ discovery debugging aids? So doesn't this
> make it more difficult to figure out what's going on in the
> not-many-child case?
Let's take the 0-child case. With v1.7.4-rc3:
$ GIT_TRACE=1; export GIT_TRACE
$ git symbolic-ref confused
setup: git_dir: .git
setup: worktree: /home/jrn/src/git
setup: cwd: /home/jrn/src/git
setup: prefix: (null)
trace: built-in: git 'symbolic-ref' 'confused'
fatal: ref confused is not a symbolic ref
$ git rev-parse confused >/dev/null
trace: built-in: git 'rev-parse' 'confused'
fatal: ambiguous argument 'confused': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Observations:
- Orthogonal to the useful quantity of information is that it would be
nice if the setup info dump were consistent. Currently non-builtins
and commands like rev-parse without RUN_SETUP|RUN_SETUP_GENTLY skip
it.
- Except for "cwd", the setup lines write information that is easy to
retrieve with git rev-parse. In my limited experience, it is not
the information I need when debugging.
- The cwd, on the other hand, could be very useful. Maybe git should
make sense to always follow "trace: run_command", "trace: exec", and
"trace: built-in" lines with "trace: cwd".
^ permalink raw reply
* Re: [PATCH/RFC 0/3] trace: omit noisy repository discovery report
From: Nguyen Thai Ngoc Duy @ 2011-01-26 1:45 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano
In-Reply-To: <20110126004915.GA11230@burratino>
2011/1/26 Jonathan Nieder <jrnieder@gmail.com>:
> Nguyễn Thái Ngọc Duy wrote:
>
>> +++ b/trace.c
> [...]
>> + trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
>> + trace_printf("setup: worktree: %s\n", quote_crnl(get_git_work_tree()));
>> + trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
>> + trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
>> +}
>
> A few days ago I was tracing something or other and decided that these
> extra lines are annoying.
>
> Patch 1 moves this code from trace.c to git.c, to contain its impact
> to a single translation unit (that is, it let me experiment without
> touching cache.h after that).
>
> Patch 2 removes the repo-setup tracing code, introducing a
> test-repo-setup helper to take its place in the repo setup tests.
>
> Patch 3 does some cleaning up made possible by patch 2.
>
> Thoughts?
I'm fine with this. Although long term maybe we should support pattern
matching or category selection in GIT_TRACE.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/3] trace: omit repository discovery report
From: Sverre Rabbelier @ 2011-01-26 1:19 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Nguyễn Thái Ngọc, git, Junio C Hamano
In-Reply-To: <20110126005916.GC11230@burratino>
Heya,
2011/1/26 Jonathan Nieder <jrnieder@gmail.com>:
> In practice, four extra lines of trace output per git process is too
> much noise. So stop printing repository discovery info except when
> running tests.
Doesn't this disable _all_ discovery debugging aids? So doesn't this
make it more difficult to figure out what's going on in the
not-many-child case?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 3/3] tests: avoid unnecessary use of GIT_TRACE in repo-setup tests
From: Jonathan Nieder @ 2011-01-26 1:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20110126004915.GA11230@burratino>
Now that the startup info is printed by a separate helper, there
is no need to mark that output with "setup: " or use an environment
variable to request it.
While we're changing the test-repo-setup output format, stop quoting
newlines to give the tests a chance of passing when $TEST_DIRECTORY
contains a newline or backslash.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Thanks for reading.
t/t1510-repo-setup.sh | 12 +++++-------
test-repo-setup.c | 40 ++++++----------------------------------
2 files changed, 11 insertions(+), 41 deletions(-)
diff --git a/t/t1510-repo-setup.sh b/t/t1510-repo-setup.sh
index c2edf6f..a8cb445 100755
--- a/t/t1510-repo-setup.sh
+++ b/t/t1510-repo-setup.sh
@@ -56,9 +56,7 @@ test_repo () {
GIT_WORK_TREE="$3" &&
export GIT_WORK_TREE
fi &&
- rm -f trace &&
- GIT_TRACE="$(pwd)/trace" test-repo-setup &&
- grep '^setup: ' trace >result &&
+ test-repo-setup >result &&
test_cmp expected result
)
}
@@ -105,10 +103,10 @@ setup_env () {
expect () {
cat >"$1/expected" <<-EOF
- setup: git_dir: $2
- setup: worktree: $3
- setup: cwd: $4
- setup: prefix: $5
+ git_dir: $2
+ worktree: $3
+ cwd: $4
+ prefix: $5
EOF
}
diff --git a/test-repo-setup.c b/test-repo-setup.c
index 3b66237..72d35fe 100644
--- a/test-repo-setup.c
+++ b/test-repo-setup.c
@@ -1,52 +1,24 @@
#include "cache.h"
-static const char *quote_crnl(const char *path)
-{
- static char new_path[PATH_MAX];
- const char *p2 = path;
- char *p1 = new_path;
-
- if (!path)
- return NULL;
-
- while (*p2) {
- switch (*p2) {
- case '\\': *p1++ = '\\'; *p1++ = '\\'; break;
- case '\n': *p1++ = '\\'; *p1++ = 'n'; break;
- case '\r': *p1++ = '\\'; *p1++ = 'r'; break;
- default:
- *p1++ = *p2;
- }
- p2++;
- }
- *p1 = '\0';
- return new_path;
-}
-
static void trace_repo_setup(void)
{
- const char *git_work_tree;
+ const char *git_work_tree = get_git_work_tree();
const char *prefix = startup_info->prefix;
char cwd[PATH_MAX];
- char *trace = getenv("GIT_TRACE");
-
- if (!trace || !strcmp(trace, "") ||
- !strcmp(trace, "0") || !strcasecmp(trace, "false"))
- return;
if (!getcwd(cwd, PATH_MAX))
die("Unable to get current working directory");
- if (!(git_work_tree = get_git_work_tree()))
+ if (!git_work_tree)
git_work_tree = "(null)";
if (!prefix)
prefix = "(null)";
- trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
- trace_printf("setup: worktree: %s\n", quote_crnl(git_work_tree));
- trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
- trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
+ printf("git_dir: %s\n", get_git_dir());
+ printf("worktree: %s\n", git_work_tree);
+ printf("cwd: %s\n", cwd);
+ printf("prefix: %s\n", prefix);
}
int main(int argc, char **argv)
--
1.7.4.rc3
^ permalink raw reply related
* [PATCH 2/3] trace: omit repository discovery report
From: Jonathan Nieder @ 2011-01-26 0:59 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20110126004915.GA11230@burratino>
The run-command library advertises what process it is running through
the GIT_TRACE stream (see 575ba9d6, 2006-06-25) to provide context
during debugging for error messages that might come from the child
process. In the same spirit, since v1.7.4-rc0~4^2~46 (builtins: print
setup info if repo is found, 2010-11-26) the repo-setup library prints
its result to GIT_TRACE, so the cwd, location of the git directory,
and so on are readily available during debug.
In practice, four extra lines of trace output per git process is too
much noise. So stop printing repository discovery info except when
running tests.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
.gitignore | 1 +
Makefile | 1 +
git.c | 53 -------------------------------------------
t/t1510-repo-setup.sh | 2 +-
test-repo-setup.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 63 insertions(+), 54 deletions(-)
create mode 100644 test-repo-setup.c
diff --git a/.gitignore b/.gitignore
index 3dd6ef7..e1fc557 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,6 +173,7 @@
/test-obj-pool
/test-parse-options
/test-path-utils
+/test-repo-setup
/test-run-command
/test-sha1
/test-sigchain
diff --git a/Makefile b/Makefile
index 775ee83..01cc5c0 100644
--- a/Makefile
+++ b/Makefile
@@ -427,6 +427,7 @@ TEST_PROGRAMS_NEED_X += test-match-trees
TEST_PROGRAMS_NEED_X += test-obj-pool
TEST_PROGRAMS_NEED_X += test-parse-options
TEST_PROGRAMS_NEED_X += test-path-utils
+TEST_PROGRAMS_NEED_X += test-repo-setup
TEST_PROGRAMS_NEED_X += test-run-command
TEST_PROGRAMS_NEED_X += test-sha1
TEST_PROGRAMS_NEED_X += test-sigchain
diff --git a/git.c b/git.c
index d1b15f1..d532576 100644
--- a/git.c
+++ b/git.c
@@ -238,55 +238,6 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
-static const char *quote_crnl(const char *path)
-{
- static char new_path[PATH_MAX];
- const char *p2 = path;
- char *p1 = new_path;
-
- if (!path)
- return NULL;
-
- while (*p2) {
- switch (*p2) {
- case '\\': *p1++ = '\\'; *p1++ = '\\'; break;
- case '\n': *p1++ = '\\'; *p1++ = 'n'; break;
- case '\r': *p1++ = '\\'; *p1++ = 'r'; break;
- default:
- *p1++ = *p2;
- }
- p2++;
- }
- *p1 = '\0';
- return new_path;
-}
-
-static void trace_repo_setup(void)
-{
- const char *git_work_tree;
- const char *prefix = startup_info->prefix;
- char cwd[PATH_MAX];
- char *trace = getenv("GIT_TRACE");
-
- if (!trace || !strcmp(trace, "") ||
- !strcmp(trace, "0") || !strcasecmp(trace, "false"))
- return;
-
- if (!getcwd(cwd, PATH_MAX))
- die("Unable to get current working directory");
-
- if (!(git_work_tree = get_git_work_tree()))
- git_work_tree = "(null)";
-
- if (!prefix)
- prefix = "(null)";
-
- trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
- trace_printf("setup: worktree: %s\n", quote_crnl(git_work_tree));
- trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
- trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
-}
-
const char git_version_string[] = GIT_VERSION;
#define RUN_SETUP (1<<0)
@@ -324,10 +275,6 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
use_pager = check_pager_config(p->cmd);
if (use_pager == -1 && p->option & USE_PAGER)
use_pager = 1;
-
- if ((p->option & (RUN_SETUP | RUN_SETUP_GENTLY)) &&
- startup_info->have_repository) /* get_git_dir() may set up repo, avoid that */
- trace_repo_setup();
}
commit_pager_choice();
diff --git a/t/t1510-repo-setup.sh b/t/t1510-repo-setup.sh
index 15101d5..c2edf6f 100755
--- a/t/t1510-repo-setup.sh
+++ b/t/t1510-repo-setup.sh
@@ -57,7 +57,7 @@ test_repo () {
export GIT_WORK_TREE
fi &&
rm -f trace &&
- GIT_TRACE="$(pwd)/trace" git symbolic-ref HEAD >/dev/null &&
+ GIT_TRACE="$(pwd)/trace" test-repo-setup &&
grep '^setup: ' trace >result &&
test_cmp expected result
)
diff --git a/test-repo-setup.c b/test-repo-setup.c
new file mode 100644
index 0000000..3b66237
--- /dev/null
+++ b/test-repo-setup.c
@@ -0,0 +1,60 @@
+#include "cache.h"
+
+static const char *quote_crnl(const char *path)
+{
+ static char new_path[PATH_MAX];
+ const char *p2 = path;
+ char *p1 = new_path;
+
+ if (!path)
+ return NULL;
+
+ while (*p2) {
+ switch (*p2) {
+ case '\\': *p1++ = '\\'; *p1++ = '\\'; break;
+ case '\n': *p1++ = '\\'; *p1++ = 'n'; break;
+ case '\r': *p1++ = '\\'; *p1++ = 'r'; break;
+ default:
+ *p1++ = *p2;
+ }
+ p2++;
+ }
+ *p1 = '\0';
+ return new_path;
+}
+
+static void trace_repo_setup(void)
+{
+ const char *git_work_tree;
+ const char *prefix = startup_info->prefix;
+ char cwd[PATH_MAX];
+ char *trace = getenv("GIT_TRACE");
+
+ if (!trace || !strcmp(trace, "") ||
+ !strcmp(trace, "0") || !strcasecmp(trace, "false"))
+ return;
+
+ if (!getcwd(cwd, PATH_MAX))
+ die("Unable to get current working directory");
+
+ if (!(git_work_tree = get_git_work_tree()))
+ git_work_tree = "(null)";
+
+ if (!prefix)
+ prefix = "(null)";
+
+ trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
+ trace_printf("setup: worktree: %s\n", quote_crnl(git_work_tree));
+ trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
+ trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
+}
+
+int main(int argc, char **argv)
+{
+ static struct startup_info test_startup_info;
+
+ startup_info = &test_startup_info;
+ setup_git_directory();
+ trace_repo_setup();
+ return 0;
+}
--
1.7.4.rc3
^ permalink raw reply related
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Erik Faye-Lund @ 2011-01-26 0:58 UTC (permalink / raw)
To: smaxein; +Cc: Johannes Sixt, git
In-Reply-To: <4D3F69D2.800@googlemail.com>
On Wed, Jan 26, 2011 at 1:24 AM, Simeon Maxein <smaxein@googlemail.com> wrote:
> Am 26.01.2011 00:31, schrieb Erik Faye-Lund:
>> On Wed, Jan 26, 2011 at 12:26 AM, Simeon Maxein <smaxein@googlemail.com> wrote:
>>> Am 25.01.2011 22:56, schrieb Johannes Sixt:
>>>> On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
>>>>> In my opinion this is a quite serious issue, because files are lost
>>>>> without any indication to the user. As of git 1.7.3.1 (tested on
>>>>> Windows/NTFS with msysGit this time), the problem still exists. Please
>>>>> give it a look. Fullquote of the problem description / steps to
>>>>> reproduce follows.
>>>>>> mkdir testdir
>>>>>> echo 'abc' >testdir/testfile
>>>>>> git add testdir
>>>>>> git commit -m foo
>>>>>> git rm -r testdir
>>>>>> mkdir testDir
>>>>>> echo 'abc' >testDir/testfile
>>>>>> git add testDir
>>>>>> git commit -m bar
>>>> Please retry with current release condidate of 1.7.4; it has some
>>>> core.ignorecase improvements w.r.t. directories. It could well be that your
>>>> problem is fixed.
>>>>
>>>> -- Hannes
>>> Thanks for the suggestion. The directory doesn't vanish anymore with
>>> 1.7.4, so a big Thank You to the developers for improving this. When
>>> rewriting the second commit ls still prints testdir as lowercase though.
>>> More of a nitpick, but it would still be neat to have it right.
>>>
>> This part is correct behavior - git's internal representation is case
>> sensitive. So git's record of the file is still 'testdir', even i
>> you've deleted it and created a new called 'testDir'.
> A normal checkout for those commits results in "testdir" for the first
> one and "testDir" for the second one, so git does store the name
> difference. I would intuitively expect the trees prepared during
> filter-branch to be consistent with the result of a checkout.
>
I'm sorry, I misread what you wrote (I read the 'git rm testDir' as
'rm testDir').
The reason the old folder name is output appears to be that "git
checkout-index -f -u -a" (called from git-filter-branch) doesn't
change the directory name when the directory is already there. But to
be honest, I'm not really sure if it should or not. I'm too tired to
think it through right now ;)
^ permalink raw reply
* [PATCH 1/3] setup: do not expose tracing code
From: Jonathan Nieder @ 2011-01-26 0:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20110126004915.GA11230@burratino>
The trace_repo_setup function has only one caller (run_builtin)
which lives in git.c. Move the code there and stop advertising
it in cache.h.
This means it is likely to remain safe to use startup_info within
trace_repo_setup, since the trace_repo_setup function is only used
when running builtins. Do so and drop the "prefix" parameter.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
cache.h | 1 -
git.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
trace.c | 49 -------------------------------------------------
3 files changed, 50 insertions(+), 51 deletions(-)
diff --git a/cache.h b/cache.h
index d83d68c..2eb3ccc 100644
--- a/cache.h
+++ b/cache.h
@@ -1067,7 +1067,6 @@ __attribute__((format (printf, 1, 2)))
extern void trace_printf(const char *format, ...);
__attribute__((format (printf, 2, 3)))
extern void trace_argv_printf(const char **argv, const char *format, ...);
-extern void trace_repo_setup(const char *prefix);
/* convert.c */
/* returns 1 if *dst was used */
diff --git a/git.c b/git.c
index 68334f6..d1b15f1 100644
--- a/git.c
+++ b/git.c
@@ -238,6 +238,55 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
+static const char *quote_crnl(const char *path)
+{
+ static char new_path[PATH_MAX];
+ const char *p2 = path;
+ char *p1 = new_path;
+
+ if (!path)
+ return NULL;
+
+ while (*p2) {
+ switch (*p2) {
+ case '\\': *p1++ = '\\'; *p1++ = '\\'; break;
+ case '\n': *p1++ = '\\'; *p1++ = 'n'; break;
+ case '\r': *p1++ = '\\'; *p1++ = 'r'; break;
+ default:
+ *p1++ = *p2;
+ }
+ p2++;
+ }
+ *p1 = '\0';
+ return new_path;
+}
+
+static void trace_repo_setup(void)
+{
+ const char *git_work_tree;
+ const char *prefix = startup_info->prefix;
+ char cwd[PATH_MAX];
+ char *trace = getenv("GIT_TRACE");
+
+ if (!trace || !strcmp(trace, "") ||
+ !strcmp(trace, "0") || !strcasecmp(trace, "false"))
+ return;
+
+ if (!getcwd(cwd, PATH_MAX))
+ die("Unable to get current working directory");
+
+ if (!(git_work_tree = get_git_work_tree()))
+ git_work_tree = "(null)";
+
+ if (!prefix)
+ prefix = "(null)";
+
+ trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
+ trace_printf("setup: worktree: %s\n", quote_crnl(git_work_tree));
+ trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
+ trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
+}
+
const char git_version_string[] = GIT_VERSION;
#define RUN_SETUP (1<<0)
@@ -278,7 +327,7 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
if ((p->option & (RUN_SETUP | RUN_SETUP_GENTLY)) &&
startup_info->have_repository) /* get_git_dir() may set up repo, avoid that */
- trace_repo_setup(prefix);
+ trace_repo_setup();
}
commit_pager_choice();
diff --git a/trace.c b/trace.c
index 35d388d..0fb2a2c 100644
--- a/trace.c
+++ b/trace.c
@@ -127,52 +127,3 @@ void trace_argv_printf(const char **argv, const char *fmt, ...)
if (need_close)
close(fd);
}
-
-static const char *quote_crnl(const char *path)
-{
- static char new_path[PATH_MAX];
- const char *p2 = path;
- char *p1 = new_path;
-
- if (!path)
- return NULL;
-
- while (*p2) {
- switch (*p2) {
- case '\\': *p1++ = '\\'; *p1++ = '\\'; break;
- case '\n': *p1++ = '\\'; *p1++ = 'n'; break;
- case '\r': *p1++ = '\\'; *p1++ = 'r'; break;
- default:
- *p1++ = *p2;
- }
- p2++;
- }
- *p1 = '\0';
- return new_path;
-}
-
-/* FIXME: move prefix to startup_info struct and get rid of this arg */
-void trace_repo_setup(const char *prefix)
-{
- const char *git_work_tree;
- char cwd[PATH_MAX];
- char *trace = getenv("GIT_TRACE");
-
- if (!trace || !strcmp(trace, "") ||
- !strcmp(trace, "0") || !strcasecmp(trace, "false"))
- return;
-
- if (!getcwd(cwd, PATH_MAX))
- die("Unable to get current working directory");
-
- if (!(git_work_tree = get_git_work_tree()))
- git_work_tree = "(null)";
-
- if (!prefix)
- prefix = "(null)";
-
- trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
- trace_printf("setup: worktree: %s\n", quote_crnl(git_work_tree));
- trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
- trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
-}
--
1.7.4.rc3
^ permalink raw reply related
* [PATCH/RFC 0/3] trace: omit noisy repository discovery report
From: Jonathan Nieder @ 2011-01-26 0:49 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1290785563-15339-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> +++ b/trace.c
[...]
> + trace_printf("setup: git_dir: %s\n", quote_crnl(get_git_dir()));
> + trace_printf("setup: worktree: %s\n", quote_crnl(get_git_work_tree()));
> + trace_printf("setup: cwd: %s\n", quote_crnl(cwd));
> + trace_printf("setup: prefix: %s\n", quote_crnl(prefix));
> +}
A few days ago I was tracing something or other and decided that these
extra lines are annoying.
Patch 1 moves this code from trace.c to git.c, to contain its impact
to a single translation unit (that is, it let me experiment without
touching cache.h after that).
Patch 2 removes the repo-setup tracing code, introducing a
test-repo-setup helper to take its place in the repo setup tests.
Patch 3 does some cleaning up made possible by patch 2.
Thoughts?
Jonathan Nieder (3):
setup: do not expose tracing code
setup: move debugging code to test-repo-setup helper
setup: stop using GIT_TRACE in tests
.gitignore | 1 +
Makefile | 1 +
cache.h | 1 -
git.c | 4 ----
t/t1510-repo-setup.sh | 12 +++++-------
test-repo-setup.c | 32 ++++++++++++++++++++++++++++++++
trace.c | 49 -------------------------------------------------
7 files changed, 39 insertions(+), 61 deletions(-)
create mode 100644 test-repo-setup.c
--
1.7.4.rc3
^ permalink raw reply
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Simeon Maxein @ 2011-01-26 0:24 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Sixt, git
In-Reply-To: <AANLkTimvwNs9EkV1GweT7VCdzvcz5J5_0pCUA44urQYH@mail.gmail.com>
Am 26.01.2011 00:31, schrieb Erik Faye-Lund:
> On Wed, Jan 26, 2011 at 12:26 AM, Simeon Maxein <smaxein@googlemail.com> wrote:
>> Am 25.01.2011 22:56, schrieb Johannes Sixt:
>>> On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
>>>> In my opinion this is a quite serious issue, because files are lost
>>>> without any indication to the user. As of git 1.7.3.1 (tested on
>>>> Windows/NTFS with msysGit this time), the problem still exists. Please
>>>> give it a look. Fullquote of the problem description / steps to
>>>> reproduce follows.
>>>>> mkdir testdir
>>>>> echo 'abc' >testdir/testfile
>>>>> git add testdir
>>>>> git commit -m foo
>>>>> git rm -r testdir
>>>>> mkdir testDir
>>>>> echo 'abc' >testDir/testfile
>>>>> git add testDir
>>>>> git commit -m bar
>>> Please retry with current release condidate of 1.7.4; it has some
>>> core.ignorecase improvements w.r.t. directories. It could well be that your
>>> problem is fixed.
>>>
>>> -- Hannes
>> Thanks for the suggestion. The directory doesn't vanish anymore with
>> 1.7.4, so a big Thank You to the developers for improving this. When
>> rewriting the second commit ls still prints testdir as lowercase though.
>> More of a nitpick, but it would still be neat to have it right.
>>
> This part is correct behavior - git's internal representation is case
> sensitive. So git's record of the file is still 'testdir', even i
> you've deleted it and created a new called 'testDir'.
A normal checkout for those commits results in "testdir" for the first
one and "testDir" for the second one, so git does store the name
difference. I would intuitively expect the trees prepared during
filter-branch to be consistent with the result of a checkout.
Simeon
^ permalink raw reply
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Erik Faye-Lund @ 2011-01-25 23:31 UTC (permalink / raw)
To: smaxein; +Cc: Johannes Sixt, git
In-Reply-To: <4D3F5C42.4040300@googlemail.com>
On Wed, Jan 26, 2011 at 12:26 AM, Simeon Maxein <smaxein@googlemail.com> wrote:
> Am 25.01.2011 22:56, schrieb Johannes Sixt:
>> On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
>>> In my opinion this is a quite serious issue, because files are lost
>>> without any indication to the user. As of git 1.7.3.1 (tested on
>>> Windows/NTFS with msysGit this time), the problem still exists. Please
>>> give it a look. Fullquote of the problem description / steps to
>>> reproduce follows.
>>>> mkdir testdir
>>>> echo 'abc' >testdir/testfile
>>>> git add testdir
>>>> git commit -m foo
>>>> git rm -r testdir
>>>> mkdir testDir
>>>> echo 'abc' >testDir/testfile
>>>> git add testDir
>>>> git commit -m bar
>> Please retry with current release condidate of 1.7.4; it has some
>> core.ignorecase improvements w.r.t. directories. It could well be that your
>> problem is fixed.
>>
>> -- Hannes
> Thanks for the suggestion. The directory doesn't vanish anymore with
> 1.7.4, so a big Thank You to the developers for improving this. When
> rewriting the second commit ls still prints testdir as lowercase though.
> More of a nitpick, but it would still be neat to have it right.
>
This part is correct behavior - git's internal representation is case
sensitive. So git's record of the file is still 'testdir', even i
you've deleted it and created a new called 'testDir'.
^ permalink raw reply
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Simeon Maxein @ 2011-01-25 23:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201101252256.03644.j6t@kdbg.org>
Am 25.01.2011 22:56, schrieb Johannes Sixt:
> On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
>> In my opinion this is a quite serious issue, because files are lost
>> without any indication to the user. As of git 1.7.3.1 (tested on
>> Windows/NTFS with msysGit this time), the problem still exists. Please
>> give it a look. Fullquote of the problem description / steps to
>> reproduce follows.
>>> mkdir testdir
>>> echo 'abc' >testdir/testfile
>>> git add testdir
>>> git commit -m foo
>>> git rm -r testdir
>>> mkdir testDir
>>> echo 'abc' >testDir/testfile
>>> git add testDir
>>> git commit -m bar
> Please retry with current release condidate of 1.7.4; it has some
> core.ignorecase improvements w.r.t. directories. It could well be that your
> problem is fixed.
>
> -- Hannes
Thanks for the suggestion. The directory doesn't vanish anymore with
1.7.4, so a big Thank You to the developers for improving this. When
rewriting the second commit ls still prints testdir as lowercase though.
More of a nitpick, but it would still be neat to have it right.
The issue of extra files appearing during filter-branch (
http://article.gmane.org/gmane.comp.version-control.git/154662 ) is
still present.
Simeon
^ 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