* Re: Force commit date
From: Sverre Rabbelier @ 2009-01-29 18:37 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233253817209-2240539.post@n2.nabble.com>
On Thu, Jan 29, 2009 at 19:30, Zabre <427@free.fr> wrote:
> There might be an option I am not aware of.
Indeed, try 'import-tars.perl' in the /contrib directory of git.git :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 18:45 UTC (permalink / raw)
To: git
In-Reply-To: <1233253817209-2240539.post@n2.nabble.com>
I'm wondering : maybe the trick is outside git? Maybe is it possible to
specify a "forced date" at which an action (a "git commit" in this case) is
done.
Some command that would wrap around the git commit command and tell the
system "apply this, but do it as if now was 2008-08-23 06:15:34".
What do you think?
This would be very interesting to know.
(btw I'm running Linux obviously)
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240602.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* segfault when cloning over https
From: Jan Kasprzak @ 2009-01-29 18:45 UTC (permalink / raw)
To: git
Hello,
I am trying to use git for accessing the repository over https.
I can run
git clone --bare http://www.fi.muni.cz/~kas/tmp/git.git
without problems, but when I change http to https, it either segfaults
or fails with heap corruption detected:
$ git clone --bare https://www.fi.muni.cz/~kas/tmp/git.git
[...]
got f1a1aac6880f1c8f122c57c2380800ec54d10982
*** glibc detected *** git: double free or corruption (!prev): 0x00007f8455a90fe0 ***
======= Backtrace: =========
/lib64/libc.so.6[0xf8bec8]
/lib64/libc.so.6(cfree+0x76)[0xf8e486]
/lib64/libnsspem.so[0x7f845f3f2a75]
/lib64/libnsspem.so[0x7f845f3e1a56]
/lib64/libnsspem.so[0x7f845f3e71a9]
/lib64/libnsspem.so[0x7f845f3ee9c4]
/lib64/libnss3.so[0x7f846210dc4d]
/lib64/libnss3.so(PK11_CreateGenericObject+0x42)[0x7f846210ded2]
/usr/lib64/libcurl.so.4[0x14b129]
/usr/lib64/libcurl.so.4(Curl_nss_connect+0x622)[0x14b9f2]
/usr/lib64/libcurl.so.4(Curl_protocol_connect+0xd2)[0x12bd72]
/usr/lib64/libcurl.so.4[0x13efd3]
/usr/lib64/libcurl.so.4(curl_multi_perform+0x8b)[0x13f2ab]
git[0x49de9f]
git[0x49df2f]
git[0x4a0499]
git[0x4a081e]
git[0x49aa36]
git[0x494b41]
git[0x4942f3]
git[0x415674]
git[0x4041a3]
git[0x4043bc]
/lib64/libc.so.6(__libc_start_main+0xe6)[0xf32576]
git[0x403c69]
======= Memory map: ========
00110000-00157000 r-xp 00000000 08:01 113025474 /usr/lib64/libcurl.so.4.1.0
00157000-00357000 ---p 00047000 08:01 113025474 /usr/lib64/libcurl.so.4.1.0
[...]
I have tried this against various https servers hosting different
repositories, and from various distributions (including Fedora 7, Fedora 8,
and Fedora 10, all x86_64), and from various git builds (1.6.0.6 from Fedora 10,
1.6.1.2 built from the source, etc.
Does anybody see the same problem? Do you use git over https at all?
It is possible to test against this repository:
http://www.fi.muni.cz/~kas/tmp/git.git
https://www.fi.muni.cz/~kas/tmp/git.git
You will have to add the following certificate to your ca-bundle.crt
to access the repository:
-----BEGIN CERTIFICATE-----
MIICsTCCAhoCAQAwDQYJKoZIhvcNAQEEBQAwgaAxCzAJBgNVBAYTAkNaMRcwFQYD
VQQIEw5DemVjaCBSZXB1YmxpYzENMAsGA1UEBxMEQnJubzEfMB0GA1UEChMWRmFj
dWx0eSBvZiBJbmZvcm1hdGljczEMMAoGA1UECxMDQ1ZUMRowGAYDVQQDExFBZG1p
bmlzdHJhdGl2YSBGSTEeMBwGCSqGSIb3DQEJARYPdW5peEBmaS5tdW5pLmN6MB4X
DTk3MTExMDEyMDQyOVoXDTI1MDMyODEyMDQyOVowgaAxCzAJBgNVBAYTAkNaMRcw
FQYDVQQIEw5DemVjaCBSZXB1YmxpYzENMAsGA1UEBxMEQnJubzEfMB0GA1UEChMW
RmFjdWx0eSBvZiBJbmZvcm1hdGljczEMMAoGA1UECxMDQ1ZUMRowGAYDVQQDExFB
ZG1pbmlzdHJhdGl2YSBGSTEeMBwGCSqGSIb3DQEJARYPdW5peEBmaS5tdW5pLmN6
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMm0dLLgsMSwmYPZdYYDGNsdwK
04k9O5gTYk+S70+ygUsLQNL+VLYqprsfZkDelX2wea8oUkj69R8I+vF6N1E8Ubik
3c4RFqJB6tsnTJT1YplCFd7s1BZlGSEKHC3OzHYp19pnXc0IHgX404pgpmuXaq6R
Xu+D8iboFKi60ZpsVQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAD7842aqJRKlFDzk
LK8SpR8KZ/jYWSdzNrwCQfLAlAzo8wDTcC3hgnaiKHJq4ZvS9h2tnGWm+qEToQwB
oKjKyR87zaFeEWu/tNxBNPkAXfX9jdyJ5ozDTVDpFLoLEZ5ppIuh/ZDbPhjTQZrc
IFfjrlWlrKXmiH9hCSQ5R/lIlrnG
-----END CERTIFICATE-----
Please Cc: me directly, I am not a member of this list.
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
>> If you find yourself arguing with Alan Cox, you’re _probably_ wrong. <<
>> --James Morris in "How and Why You Should Become a Kernel Hacker" <<
^ permalink raw reply
* Re: diff settings
From: Keith Cascio @ 2009-01-29 18:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ted Pavlic, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901291731220.3586@pacific.mpi-cbg.de>
On Thu, 29 Jan 2009, Johannes Schindelin wrote:
> we already have a distinction between what is called from scripts vs from
> humans: plumbing vs porcelain. So you can set the defaults for porcelain as
> much as you want, but please leave plumbing alone.
May we consider "git diff" Porcelain and "git diff-{files,index,tree}" plumbing?
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 18:47 UTC (permalink / raw)
To: git
In-Reply-To: <bd6139dc0901291037h46a75446occ3004d2ff58d889@mail.gmail.com>
Sverre Rabbelier-2 wrote:
>
> Indeed, try 'import-tars.perl' in the /contrib directory of git.git :).
>
Thank you Sverre, I'll have a look at this!
(sorry for my "wondering" post, I had not seen yours)
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240620.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: segfault when cloning over https
From: Daniel Stenberg @ 2009-01-29 18:46 UTC (permalink / raw)
To: Jan Kasprzak; +Cc: git
In-Reply-To: <20090129184523.GI23133@fi.muni.cz>
On Thu, 29 Jan 2009, Jan Kasprzak wrote:
> without problems, but when I change http to https, it either segfaults or
> fails with heap corruption detected:
> /lib64/libnsspem.so[0x7f845f3ee9c4]
> /lib64/libnss3.so[0x7f846210dc4d]
> /lib64/libnss3.so(PK11_CreateGenericObject+0x42)[0x7f846210ded2]
> /usr/lib64/libcurl.so.4[0x14b129]
This is a libcurl built to use a Fedora-patched NSS library for the SSL stuff.
You could try to build your own libcurl with a different SSL library to see if
that works fine, as then we could narrow this down a bit...
--
/ daniel.haxx.se
^ permalink raw reply
* Re: Force commit date
From: Markus Heidelberg @ 2009-01-29 18:55 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233254709681-2240602.post@n2.nabble.com>
Zabre, 29.01.2009:
>
> I'm wondering : maybe the trick is outside git? Maybe is it possible to
> specify a "forced date" at which an action (a "git commit" in this case) is
> done.
> Some command that would wrap around the git commit command and tell the
> system "apply this, but do it as if now was 2008-08-23 06:15:34".
man git-commit-tree
-> GIT_COMMITTER_DATE
Though only in the git-commit-tree docs, it also works with git-commit.
Maybe it should be added there, too.
Markus
^ permalink raw reply
* border-case/general git test repository
From: Johannes Gilger @ 2009-01-29 18:54 UTC (permalink / raw)
To: git
Hi,
partly because of laziness, partly out of curiosity I was wondering if
anyone had a (relatively small) test-repository lying around, that
especially stresses the output (not really the integrity of the data) of
git and all kinds of different combinations of operations.
We could really use it for GitX, as GitX parses the output of git and
everytime we think we have found/fixed a glitch in the display we
discover some new case. For example we just noticed that we didn't
detect file-mode changes, and after we implemented that we thought that,
of course, a file can change its mode and content at the same time...
and so on ;)
So things we're looking for are things that usually don't happen that
often (because of obscureness or because of convention respected by
people) but are still perfectly valid output that our/other programs
could trip over.
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 19:02 UTC (permalink / raw)
To: git
In-Reply-To: <200901291955.10769.markus.heidelberg@web.de>
Markus Heidelberg wrote:
>
> man git-commit-tree
> -> GIT_COMMITTER_DATE
>
> Though only in the git-commit-tree docs, it also works with git-commit.
> Maybe it should be added there, too.
>
Thank you Markus, I'll have a look at this too !
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240702.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Force commit date
From: Daniel Barkalow @ 2009-01-29 19:10 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233255759118-2240702.post@n2.nabble.com>
On Thu, 29 Jan 2009, Zabre wrote:
> Markus Heidelberg wrote:
> >
> > man git-commit-tree
> > -> GIT_COMMITTER_DATE
> >
> > Though only in the git-commit-tree docs, it also works with git-commit.
> > Maybe it should be added there, too.
> >
>
> Thank you Markus, I'll have a look at this too !
You may want to consider whether those dates make most sense as the date
of the commit, or the date the changes were done; git tracks both of
these separately, in part because it's easy to have some work done at one
time, and only make the commit that becomes part of the official project
history much later (and these may be done by different people).
The date for the changes being done is set with GIT_AUTHOR_DATE
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Brian Gernhardt @ 2009-01-29 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git List
In-Reply-To: <7vocxqf2sf.fsf@gitster.siamese.dyndns.org>
On Jan 29, 2009, at 12:19 PM, Junio C Hamano wrote:
> If we really wanted to care about case-folding file systems,
> shouldn't we
> make test_commit shell function a bit more than the downcasing? How
> about
> this patch instead?
That's a good point. Always good to prevent future issues.
> test_commit () {
> - file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
> + file=${2:-$(echo "$1" | tr 'A-Z' 'a-z').t}
> echo "${3-$1}" > "$file" &&
> git add "$file" &&
> test_tick &&
Added this and ran through the tests. Works for me. :-D
Tested-by: Brian Gernhardt <benji@silverinsanity.com> (HFS+ on Mac OS
10.5.6)
^ permalink raw reply
* "git gc" removes ".git/refs/heads/master".
From: Bernd Lommerzheim @ 2009-01-29 19:31 UTC (permalink / raw)
To: git
Hi,
maybe I found a bug in git. When I execute "git gc" in my local repository,
git removes the file ".git/refs/heads/master". Is this an intended behavior
(but why?) or is that a bug?
Some commands to reproduce:
~ $ mkdir tmp; cd tmp
~/tmp $ git init
Initialized empty Git repository in /home/myuser/tmp/.git/
~/tmp $ echo "content" > a
~/tmp $ git add .
~/tmp $ git commit -a -m "first commit"
Created initial commit 0b67f33: first commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
~/tmp $ cat .git/refs/heads/master
0b67f33fff4152a912fdbe8819480b8fc1f2e990
~/tmp $ git gc
Counting objects: 3, done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 0 (delta 0)
~/tmp $ cat .git/refs/heads/master
cat: .git/refs/heads/master: No such file or directory
~/tmp $ cat .git/HEAD
ref: refs/heads/master
~/tmp $
I tested this with git v1.6.0.6, v1.6.1.1 and the current master
(a34a9dbb..).
Best regards,
Bernd Lommerzheim
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0901291406000.19665@iabervon.org>
Daniel Barkalow wrote:
>
> You may want to consider whether those dates make most sense as the date
> of the commit, or the date the changes were done; git tracks both of
> these separately, in part because it's easy to have some work done at one
> time, and only make the commit that becomes part of the official project
> history much later (and these may be done by different people).
>
> The date for the changes being done is set with GIT_AUTHOR_DATE
>
Thank you Daniel, this is very interesting, having a GIT_COMMITTER_DATE and
a GIT_AUTHOR_DATE enables me to have both dates, and no need to trick the
system then.
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240926.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: "git gc" removes ".git/refs/heads/master".
From: Johannes Schindelin @ 2009-01-29 19:50 UTC (permalink / raw)
To: Bernd Lommerzheim; +Cc: git
In-Reply-To: <83c97f59a5a5e59f908f3fc125d26adb@lunox.net>
Hi,
On Thu, 29 Jan 2009, Bernd Lommerzheim wrote:
> maybe I found a bug in git. When I execute "git gc" in my local
> repository, git removes the file ".git/refs/heads/master". Is this an
> intended behavior (but why?) or is that a bug?
No, it packs the refs. You have no business accessing files in .git/
directly :-)
Ciao,
Dscho
^ permalink raw reply
* Re: "git gc" removes ".git/refs/heads/master".
From: Johannes Gilger @ 2009-01-29 19:51 UTC (permalink / raw)
To: git
In-Reply-To: <83c97f59a5a5e59f908f3fc125d26adb@lunox.net>
On 2009-01-29, Bernd Lommerzheim <bernd@lommerzheim.com> wrote:
> maybe I found a bug in git. When I execute "git gc" in my local repository,
> git removes the file ".git/refs/heads/master". Is this an intended behavior
> (but why?) or is that a bug?
Good question, and I just found that one out myself. The ref has been
"packed" (git help pack-refs) and can be found in .git/packed-refs. Hope
that answers your question.
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: "git gc" removes ".git/refs/heads/master".
From: Peter Baumann @ 2009-01-29 19:55 UTC (permalink / raw)
To: Bernd Lommerzheim; +Cc: git
In-Reply-To: <83c97f59a5a5e59f908f3fc125d26adb@lunox.net>
On Thu, Jan 29, 2009 at 08:31:17PM +0100, Bernd Lommerzheim wrote:
> Hi,
>
> maybe I found a bug in git. When I execute "git gc" in my local repository,
> git removes the file ".git/refs/heads/master". Is this an intended behavior
> (but why?) or is that a bug?
>
This is intential, as git gc creates .git/packed-refs in which the
contents of your master branch are stored. The packed-refs help speeding
up the listing of your branches if you have many of them (e.g. many old
historical ones).
Regards,
Peter Baumann
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <1233258537869-2240926.post@n2.nabble.com>
For the record, this thread is similar to :
http://n2.nabble.com/Committing-with-past-date--td795326.html
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2241010.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: "git gc" removes ".git/refs/heads/master".
From: Junio C Hamano @ 2009-01-29 20:07 UTC (permalink / raw)
To: Bernd Lommerzheim; +Cc: git
In-Reply-To: <83c97f59a5a5e59f908f3fc125d26adb@lunox.net>
Bernd Lommerzheim <bernd@lommerzheim.com> writes:
> Hi,
>
> maybe I found a bug in git. When I execute "git gc" in my local repository,
> git removes the file ".git/refs/heads/master". Is this an intended behavior
> (but why?) or is that a bug?
>
> Some commands to reproduce:
> ~ $ mkdir tmp; cd tmp
> ~/tmp $ git init
> Initialized empty Git repository in /home/myuser/tmp/.git/
> ~/tmp $ echo "content" > a
> ~/tmp $ git add .
> ~/tmp $ git commit -a -m "first commit"
> Created initial commit 0b67f33: first commit
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 a
> ~/tmp $ cat .git/refs/heads/master
> 0b67f33fff4152a912fdbe8819480b8fc1f2e990
> ~/tmp $ git gc
> Counting objects: 3, done.
> Writing objects: 100% (3/3), done.
> Total 3 (delta 0), reused 0 (delta 0)
> ~/tmp $ cat .git/refs/heads/master
> cat: .git/refs/heads/master: No such file or directory
> ~/tmp $ cat .git/HEAD
> ref: refs/heads/master
> ~/tmp $
$ grep master .git/packed-refs
^ permalink raw reply
* Security and permissions in git
From: Jay Renbaum @ 2009-01-29 20:34 UTC (permalink / raw)
To: git
When setting up a public repository is there a way to control who has access
to various directories within the repository or is everything equal once you
are in?
^ permalink raw reply
* Re: [EGIT] Blame functionality update
From: Robin Rosenberg @ 2009-01-29 20:56 UTC (permalink / raw)
To: Manuel Woelker; +Cc: Shawn O. Pearce, git
In-Reply-To: <3d045c7e0901290935l3bddac0emcbaee0b4b2c5695f@mail.gmail.com>
torsdag 29 januari 2009 18:35:28 skrev Manuel Woelker:
> Hi folks,
>
> quick update about the state of blame functionality in my egit branch
> at http://github.com/manuel-woelker/egit/tree/blame
> Screen shot here: http://docs.google.com/View?docid=df5rvczr_3f46vd2ds
Impressive!. Someone's been busy :)
I haven't looked at the code yet but did take it for a ride and it was nice.
-- robin
^ permalink raw reply
* Re: [PATCH] Add --ff-only flag to git-merge
From: Yuval Kogman @ 2009-01-29 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk58fm8x2.fsf@gitster.siamese.dyndns.org>
Hi,
I started incorperating your feedback but before I send a new patch I
have several questions about the trickier bits:
2009/1/28 Junio C Hamano <gitster@pobox.com>:
> * The placement of this misses the case where a merge of two unrelated
> histories is attempted. You would need to also have a check at "No
> common ancestors found. We need a real merge." part.
Won't that fall through? The if (!common) is above, and this is
eventually an else if for it (see line 978)
> The octopus
> codepath could also end up with a fast forward or up-to-date.
So this case is obviously more convoluted... If an octopus merge is
chosen should it just pass --ff-only to git-merge-octopus? Or maybe it
should always pass --ff-only and the various different strategies
would just die unconditionally?
^ permalink raw reply
* Re: diff settings
From: Nanako Shiraishi @ 2009-01-29 21:07 UTC (permalink / raw)
To: Keith Cascio; +Cc: Johannes Schindelin, Ted Pavlic, git, Junio C Hamano
In-Reply-To: <alpine.GSO.2.00.0901291044280.23065@kiwi.cs.ucla.edu>
Quoting Keith Cascio <keith@CS.UCLA.EDU>:
> On Thu, 29 Jan 2009, Johannes Schindelin wrote:
>
>> we already have a distinction between what is called from scripts vs from
>> humans: plumbing vs porcelain. So you can set the defaults for porcelain as
>> much as you want, but please leave plumbing alone.
>
> May we consider "git diff" Porcelain and "git diff-{files,index,tree}" plumbing?
Sure we may. To see the list of commands with categories, you can consult
http://www.kernel.org/pub/software/scm/git/docs/
Junio, I think you could have stated this a bit more clearly in your message
http://thread.gmane.org/gmane.comp.version-control.git/107069/focus=107165
to avoid confusion, especially when you know you are talking to somebody new to git.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Something weird is happening...
From: Junio C Hamano @ 2009-01-29 21:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, Ingo Molnar
In-Reply-To: <49814BA4.6030705@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> I was investigating a problem that Ingo Molnar reported on the
> linux-2.6-tip.git repository on kernel.org. Unfortunately I was not
> able to reproduce his problem (which is a problem in itself) but I did
> run into another oddity:
>
> : hera 4 ; git fsck
>
> [lots of dangling commits deleted]
> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36
>
> : hera 5 ; git cat-file blob af0e01d4c663a101f48614e40d006ed6272d5c36
> /*
> * debugfs.h - a tiny little debug file system
> *
> * Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>
> * Copyright (C) 2004 IBM Inc.
> *
> [... rest of blob deleted ...]
>
> Okay, what is going on here?
Is the blob borrowed from one of its alternate object store, and not in a
pack? That would explain (note that I am not saying "justify" here, just
"explain") the symptom.
"git fsck" unlike "git fsck --full" does not validate objects in pack nor
objects you borrow from your neighbour via objects/info/alternates.
But it still does the connectivity check fully from your refs. And if it
finds an object that ought to be reachable from your refs that it hasn't
validated, it gives the "missing" warning above. There is a check to
exclude objects in packs when running "git fsck" without --full from this
warning but I do not see a corresponding exclusion of objects that were
borrowed from your neighbour which we didn't check either.
But that is just a conjecture from a cursory looking at the current code.
I do not remember (or did not know from the beginning) some details of it.
And that is why I asked you if "git fsck --full" reports it missing in my
earlier response to you.
^ permalink raw reply
* [PATCH] git-cvsserver: handle CVS 'noop' command.
From: Stefan Karpinski @ 2009-01-29 21:35 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Stefan Karpinski
In-Reply-To: <1232144521-21947-1-git-send-email-stefan.karpinski@gmail.com>
The implementation is trivial: ignore the 'noop' command
if it is sent. This command is issued by some CVS clients,
notably TortoiseCVS. Without this patch, TortoiseCVS will
choke when git-cvsserver complains about the unsupported
command.
Signed-off-by: Stefan Karpinski <stefan.karpinski@gmail.com>
---
Since this change has no negative impact, is too simple to
be wrong, and improves interaction with some clients, it
seem to me like a no-brainer to apply it.
git-cvsserver.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index fef7faf..c1e09ea 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -188,7 +188,7 @@ while (<STDIN>)
# use the $methods hash to call the appropriate sub for this command
#$log->info("Method : $1");
&{$methods->{$1}}($1,$2);
- } else {
+ } elsif ($1 ne 'noop') {
# log fatal because we don't understand this function. If this happens
# we're fairly screwed because we don't know if the client is expecting
# a response. If it is, the client will hang, we'll hang, and the whole
--
1.6.0.3.3.g08dd8
^ permalink raw reply related
* [PATCH] git-cvsserver: run post-update hook *after* update.
From: Stefan Karpinski @ 2009-01-29 21:58 UTC (permalink / raw)
To: Andy Parkins, Michael Witten, Junio C Hamano, git; +Cc: Stefan Karpinski
In-Reply-To: <7viqo61mfq.fsf@gitster.siamese.dyndns.org>
CVS server was running the hook before the update action was
actually done. This performs the update before the hook is called.
The original commit that introduced the current incorrect behavior
was 394d66d "git-cvsserver runs hooks/post-update". The error in
ordering of the hook call appears to have gone unnoticed, but since
git-cvsserver is supposed to emulate receive-pack, it stands to
reason that the hook should be run *after* the update. Since this
behavior is inconsistent with recieve-pack, users are either:
1) not using post-update hooks with git-cvsserver;
2) using post-update hooks that don't care whether they are
called before or after the actual update occurs;
3) using post-update hooks *only* with git-cvsserver, and
relying on the hook being called just before the update.
This patch would affect only users in case 3. These users are
depending on fairly obviously wrong behavior, and moreover they can
simply change their current post-update into post-recieve hooks,
and their systems will work correctly again.
Signed-off-by: Stefan Karpinski <stefan.karpinski@gmail.com>
---
I'm CCing Andy Parkins, Michael Witten, and Junio Hamano, who
authored the other three commits implementing or affecting hooks in
git-cvsserver (394d66d, cdf6328, b2741f6). If you could please take
a look at this patch and comment on if it's harmful or not, it
would be much appreciated.
git-cvsserver.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index c1e09ea..d2e6003 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1413,14 +1413,14 @@ sub req_ci
close $pipe || die "bad pipe: $! $?";
}
+ $updater->update();
+
### Then hooks/post-update
$hook = $ENV{GIT_DIR}.'hooks/post-update';
if (-x $hook) {
system($hook, "refs/heads/$state->{module}");
}
- $updater->update();
-
# foreach file specified on the command line ...
foreach my $filename ( @committedfiles )
{
--
1.6.0.3.3.g08dd8
^ permalink raw reply related
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