* [PATCH] Fix t5516-fetch for systems where `wc -l` outputs whitespace.
From: Brian Gernhardt @ 2007-07-01 15:48 UTC (permalink / raw)
To: git
When wc outputs whitespace, the test "$(command | wc -l)" = 1 is
broken because " 1" != "1". Let the shell eat the whitespace by
using test 1 = $(command | wc -l) instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
As per the previous discussion on the list.
t/t5516-fetch-push.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 08d58e1..c0fa2ba 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -226,7 +226,7 @@ test_expect_success 'push with colon-less refspec (3)' '
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
- test "$( cd testrepo && git show-ref | wc -l )" = 1
+ test 1 = $( cd testrepo && git show-ref | wc -l )
'
test_expect_success 'push with colon-less refspec (4)' '
@@ -239,7 +239,7 @@ test_expect_success 'push with colon-less refspec (4)' '
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
- test "$( cd testrepo && git show-ref | wc -l )" = 1
+ test 1 = $( cd testrepo && git show-ref | wc -l )
'
--
1.5.2.2.590.gf578-dirty
^ permalink raw reply related
* Re: t7004-tag.sh fails (old gpg?)
From: Carlos Rica @ 2007-07-01 16:06 UTC (permalink / raw)
To: skimo; +Cc: Johannes Schindelin, git
In-Reply-To: <20070701153443.GI7969MdfPADPa@greensroom.kotnet.org>
> > On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
> >
> > > gpg: Warning: using insecure memory!
> > > gpg: [don't know]: invalid packet (ctb=00)
> > > gpg: read_keyblock: read error: invalid packet
> > > gpg: enum_keyblocks failed: invalid keyring
> > > gpg: skipped `C O Mitter <committer@example.com>': invalid keyring
> > > gpg: signing failed: invalid keyring
I don't know if it could be due to the deleted t/t7004/trustdb.gpg file,
you can check the same including it (if you didn't get it already):
http://article.gmane.org/gmane.comp.version-control.git/51271
Can you verify the other tags, like those from Junio on each version?
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-07-01 16:09 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070701122625.GC26243@efreet.light.src>
On 7/1/07, Jan Hudec <bulb@ucw.cz> wrote:
> On Mon, Jun 11, 2007 at 07:45:51 +0200, Marco Costalba wrote:
> > On 6/11/07, Jan Hudec <bulb@ucw.cz> wrote:
> > >
>
> However, I am currently not sure how to handle errors. If the current commit
> fails, it will show a message box with it's output, but I can't see where it
> is generated. It seems it's somewhere inside MyProcess, so I don't have to do
> anything special though, right?
>
You have 2 ways to start a git command:
QGit::run() and QGit::runAsync()
The first starts the command and wait for completion, a bool is
returned to indicate success as example
if (!run("git read-tree --reset HEAD"))
return false;
The second one is use to start a command and return immediately, so
it's used for long commands that should be non-blocking, as example:
if (!runAsync("git diff-index -r -m --patch-with-stat HEAD"))
return false;
In the latter case success it means the command has been _started_ successfully.
A bool is the only flag returned, because error detect is done at
lower level, in MyProcess::sendErrorMsg() in file myprocess.cpp that
handles the low level of running an external process and is called by
run().
In case of an error MyProcess::sendErrorMsg() is called to inform the
GUI (a popup dialog box) about the error and the stderr output
received.
What is an error ? :-)
It's not so trivial due to different OS and git commands behaviours
regarding stderr and exiting codes, check the comment at the beginning
of MyProcess::on_finished() in myprocess.cpp to see *how* qgit detects
an error has occurred and informs upstream.
So the bottom line is: no, you don't have to do anything special. The
returned 'false' value from run() call is for your use only, if
needed, you don't have to propagate upstream to let user be informed.
Hope this helps.
Marco
P.S: Why 'git-commit --amend -F' it's explicitely forbidden?
^ permalink raw reply
* Re: [PATCH] cvstrack: work on imported cvs and other git branches
From: Johannes Schindelin @ 2007-07-01 16:11 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <4880FDC4-BAD5-49B4-871B-98259D691449@zib.de>
Hi,
On Sun, 1 Jul 2007, Steffen Prohaska wrote:
> On Jul 1, 2007, at 4:35 PM, Johannes Schindelin wrote:
>
> > On Sun, 1 Jul 2007, Steffen Prohaska wrote:
> >
> > > The idea is to import a cvs repository using git cvsimport; build a
> > > perfect history in git by cherry picking commits that are only in
> > > cvs but not in git; and export only summaries back to cvs. Cvs
> > > imports are organized on a separate git branch. git is used for
> > > merging. The differences can be sent back to cvs as a squashed
> > > commit together with a shortlog. Sent git commits are noted in the
> > > cvs commit message and will be ignored in subsequent cvs imports.
> >
> > Wouldn't it be more intuitive to add a --squash option to
> > git-cvsexportcommit?
>
> Maybe.
>
> But how to handle commits that are sent to cvs and come back
> through git-cvsimport?
Probably I do not really understand what you are doing... If the commits
come from cvs, then they are already there, no? So where do you want to
commit the squashed commits?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-clone: fetch possibly detached HEAD over dumb http
From: Alex Riesen @ 2007-07-01 16:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, git, Louis-Noel Pouchet
In-Reply-To: <7vy7i0amnn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, Jul 01, 2007 04:22:04 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > The check for .git validity includes checking if HEAD contains
> > something sane, and this check is very simple: the HEAD is read
> > (readlink(2) or plain read(2)) and tested if it contains a
> > reference starting with "refs/", which maybe inconsistent with
> > resolve_gitlink_ref, but probably ok.
>
> Ah, I was not paying close attention to resolve_gitlink_ref();
> if it does not require HEAD to point at refs/ I would say it is
> a bug.
yes, thats why I think its ok.
> Come to think of it, I would further say that we probably should
> tighten it up a bit: HEAD must be either a valid commit object
> name (i.e. detached)
That (HEAD must point to a _valid_ commit) will make accidentally
corrupted repositories harder to fix. The tool which require a valid
repository (cat-file, update-ref, read-tree) are the same tools which
you need to fix small problems which can happen, like the commit
pointed by HEAD is accidentally pruned from parent repo.
^ permalink raw reply
* Re: [PATCH] cvstrack: work on imported cvs and other git branches
From: Steffen Prohaska @ 2007-07-01 16:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707011710480.4438@racer.site>
On Jul 1, 2007, at 6:11 PM, Johannes Schindelin wrote:
> On Sun, 1 Jul 2007, Steffen Prohaska wrote:
>
>> On Jul 1, 2007, at 4:35 PM, Johannes Schindelin wrote:
>>
>>> On Sun, 1 Jul 2007, Steffen Prohaska wrote:
>>>
>>>> The idea is to import a cvs repository using git cvsimport; build a
>>>> perfect history in git by cherry picking commits that are only in
>>>> cvs but not in git; and export only summaries back to cvs. Cvs
>>>> imports are organized on a separate git branch. git is used for
>>>> merging. The differences can be sent back to cvs as a squashed
>>>> commit together with a shortlog. Sent git commits are noted in the
>>>> cvs commit message and will be ignored in subsequent cvs imports.
>>>
>>> Wouldn't it be more intuitive to add a --squash option to
>>> git-cvsexportcommit?
>>
>> Maybe.
>>
>> But how to handle commits that are sent to cvs and come back
>> through git-cvsimport?
>
> Probably I do not really understand what you are doing... If the
> commits
> come from cvs, then they are already there, no? So where do you
> want to
> commit the squashed commits?
I do some work in git and want to send this work to cvs. I squash all
_git_ commits into a single _cvs_ commit. In the next incremental
import from cvs the squashed commit comes back to git (at least after
cvsps time fuzz passed). If I just merged from the cvsimport branch
I'd build a history in git that contains the changes twice; once in
a sane way from the original git history and a second time because it
was sent to cvs and came back through git-cvsimport.
What I try to achieve is to build a history in git that has
- every commit that was initially committed to cvs only once.
- every commit that was initially committed to git only once.
- provides a stable git branch that can be cloned by others.
In addition I need a way to send changes from git to cvs such that cvs
has all changes that are available in git.
Some examples of what I may want to do in git:
- just work as if cvs wasn't there and create topic branches. Only
after work is finished the change should be sent to cvs. But changes
from cvs should be continuously integrated.
- track cvs topic branches for a longer period of time and merge
them several times using git and after a final merge, send the
changes
back to cvs.
The background is, I plan to convince approximately 60 developers
to migrate from CVS to git and I'm searching for a way to start the
transition with some beta testers, while maintaining full cvs
infrastructure in place for the remaining users.
Currently, I think that I can handle this with the scripts I sent in
the patch.
Steffen
^ permalink raw reply
* Re: most commonly used git commands?
From: Alex Riesen @ 2007-07-01 16:49 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20070701091645.GA26243@efreet.light.src>
Jan Hudec, Sun, Jul 01, 2007 11:16:46 +0200:
> On Sun, Jul 01, 2007 at 00:35:04 +0200, Alex Riesen wrote:
> > Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200:
> > > On Sat, 30 Jun 2007, Alex Riesen wrote:
> > > > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:
> > > > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> > > > > > "chmod a+x blub".
> > > > >
> > > > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
> > > > > begin with.
> > > > >
> > > >
> > > > But it is necessary on Windows (Cygwin):
> > >
> > > I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems
> > > with chmod under my fingers.
> > >
> >
> > Try doing stat(2) on file.txt which contains "#!/bin/sh" in its first
> > line and for which you have issued a chmod yet. Like a new file, or
> > like every file in a git-tracked directory after you did a fresh
> > checkout. Cygwin actually opens the files when doing stat(2), looks
> > inside and tries to guess if they are executable.
> >
> > You should have said: "Cygwin _never_ had problems with chmod because
> > it cannot and didn't make it work". It is not just chmod, the other
> > side, stat, matters as well.
>
> I always had the impression, that cygwin actually *implements* chmod and does
> so using windows ACLs. And in ACL windows *do* support executable bit (I
Windows ACLs don't have exec bit in the UNIX sense.
> copied some DLL with cygwin copy and it was NOT executable then). Of course
> this only works on filesystems (NTFS, NTFS exported over CIFS) that support
> ACLs. On FAT it might be doing something like you describe. Though it is
> mostly irrelevant for git, because git does not work on FAT (Cygwin only
> supports posix rename on NTFS).
It does not work on NTFS either. For all the same reason I described
above: Cygwin tries to be clever (and annoying) and looks into files.
And no Windows program (like, for example, your editor of preference)
will call Cygwin's chmod just to set the permissions how Cygwin likes
them.
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Sven Verdoolaege @ 2007-07-01 16:53 UTC (permalink / raw)
To: Carlos Rica; +Cc: Johannes Schindelin, git
In-Reply-To: <1b46aba20707010906s5b515419q48247801efe80515@mail.gmail.com>
On Sun, Jul 01, 2007 at 06:06:06PM +0200, Carlos Rica wrote:
> >> On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
> >>
> >> > gpg: Warning: using insecure memory!
> >> > gpg: [don't know]: invalid packet (ctb=00)
> >> > gpg: read_keyblock: read error: invalid packet
> >> > gpg: enum_keyblocks failed: invalid keyring
> >> > gpg: skipped `C O Mitter <committer@example.com>': invalid keyring
> >> > gpg: signing failed: invalid keyring
>
> I don't know if it could be due to the deleted t/t7004/trustdb.gpg file,
> you can check the same including it (if you didn't get it already):
> http://article.gmane.org/gmane.comp.version-control.git/51271
Doesn't seem to have any effect.
> Can you verify the other tags, like those from Junio on each version?
Apparently...
bash-3.00$ git-cat-file blob junio-gpg-pub | gpg --import
gpg: Warning: using insecure memory!
gpg: key F3119B9A: public key imported
gpg: Total number processed: 1
gpg: imported: 1
bash-3.00$ git-verify-tag v1.5.2-rc2
gpg: Warning: using insecure memory!
gpg: Signature made Sun 06 May 2007 10:08:26 AM CEST using DSA key ID F3119B9A
gpg: Good signature from "[image of size 1532]"
gpg: aka "Junio C Hamano <junkio@cox.net>"
Could not find a valid trust path to the key. Let's see whether we
can assign some missing owner trust values.
No path leading to one of our keys found.
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
gpg: Fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
bash-3.00$
skimo
^ permalink raw reply
* Re: [PATCH] cvstrack: work on imported cvs and other git branches
From: Johannes Schindelin @ 2007-07-01 17:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <4ED65855-7B87-43C6-B5F1-162FC9A1CBF0@zib.de>
Hi,
On Sun, 1 Jul 2007, Steffen Prohaska wrote:
> The background is, I plan to convince approximately 60 developers
> to migrate from CVS to git and I'm searching for a way to start the
> transition with some beta testers, while maintaining full cvs
> infrastructure in place for the remaining users.
Why not just cvsimporting into git, and then replace the CVS server with
git-cvsserver? That's what I did.
Ciao,
Dscho
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Johannes Schindelin @ 2007-07-01 18:06 UTC (permalink / raw)
To: skimo; +Cc: Carlos Rica, git
In-Reply-To: <20070701165301.GJ7969MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 556 bytes --]
Hi,
On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
> On Sun, Jul 01, 2007 at 06:06:06PM +0200, Carlos Rica wrote:
>
> > Can you verify the other tags, like those from Junio on each version?
>
> Apparently...
Could you please try to import the attached keys into a new keyring? IOW
$ mkdir test-gpg
$ chown go-rwx test-gpg
$ export GNUPGHOME=$(pwd)/test-gpg
$ gpg --import pubkeys.asc
And send me the resulting pubring.gpg and secring.gpg?
If you have a little more time, you could also put them in t/t7004/, and
check t7004-tag.sh...
Ciao,
Dscho
[-- Attachment #2: Type: TEXT/plain, Size: 1712 bytes --]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.5 (GNU/Linux)
mQGiBEZnyykRBACzCPjIpTYNL7Y2tQqlEGTTDlvZcWNLjF5f7ZzuyOqNOidLUgFD
36qch1LZLSZkShdR3Gae+bsolyjxrlFuFP0eXRPMtqK20aLw7WZvPFpEV1ThMne+
PRJjYrvghWw3L0VVIAIZ8GXwrVBuU99uEjHEI0ojYloOvFc2jVPgSaoBvwCg48Tj
fol2foSoJa7XUu9yAL8szg8D/RUsTzNF+I9hSRHl7MYKFMYoKEY9BDgrgAujp7YY
8qdGsiUb0Ggyzp2kRjZFt4lpcvKhGfHn5GEjmtk+fRbD5qPfMqKFW+T0NPfYlYmL
JJ4fs4qZ8Lx7x6iG6X51u+YNwsQuIGjMCC3CeNi3F7or651kkNYASbaQ1NROkCIN
NudyA/0aasvoZUoNJAc2cP5Ifs6WhXMWLfMR2p2XbfKwKNYneec60usnSComcKqh
sJVk0Gytvr3FOYVhRkXnKAbx+0W2urFP8OFVBTEKO6Ts2VygWGgneQYoHnqzwlUE
yjOjlr+lyf7u2s/KAxpKA6jnttEdRZAmzWkhuox1wwAUkr27/bQiQyBPIE1pdHRl
ciA8Y29tbWl0dGVyQGV4YW1wbGUuY29tPoheBBMRAgAeBQJGZ8spAhsDBgsJCAcD
AgMVAgMDFgIBAh4BAheAAAoJEBO29R7N3kMNdB0An0npiVm5p1HoQjKV4PrHPbrp
b0ahAKC/3JbGwl1vs0Wdno7vY+KBKDaUYLkCDQRGZ8tOEAgAzrl5P1Pr6CDR8mf5
DGGzcUUM+PEroA4FLdKJ5ZaZc7qy1lmmW9vuvb6xdinwcwee2c5fdNE+iUjHV2x2
S/dbfDzJTN/0uajZcw+xnf+KxZ0Rs4gDSs7cHXHBtA7u8ShYd4Hu7JggXpiwgfSk
yrGQiZyLAHW2ck8H07Go8eUP8fLIeva+iPqeYQZo9BaPz92R/J6debpeY1lRkv+y
WTq1GE3C/hxbdBAuHf2duLP2uq9kwoVdfzCRjgV1CQmMIbCrMb7vIlzIe96bb3+K
r/+NEtmB2I3wHBXcwJMnIOnz9Zv933KNlxSbVF23BGLB+F9D7OanKymbs7Eg18fr
mt/t/wAEDQgAtGIxGz944Pn2OtheY9JlBRuIAuVskm24/Zz03dZnk6CuEOIBb5IM
g36GAPKcn1vsLZ0TfE1q53jNpcAAXjgngnRsCjZm1mglqPD4ZfBpl+Hhnuc80fAR
xsUPj+5c8KP2M+Rws4moaZRjVpd3KCi3ceflT/OjwnE9DzdhslCGTMA5n8cajAs2
oqAaQssefVf2prLQLGV9NB4Q3lFnKXdvipHMaAYAsW+iF7JkhTDVNuNGlufeSqUm
igRBjTZXBcVd8sj8vDOCWKUfqxJyS+zRYcotn7QvpvcKAkc3ZGxntDHAIGLVp6ay
+vrkV4Ren8BjFobl25Ruy6Abw+CgnTpuwYhJBBgRAgAJBQJGZ8tOAhsMAAoJEBO2
9R7N3kMNwewAoJoZ/yJWSrCXX08A/q8KSX4ZfoBDAJ0Yxei/DHK9m5lXc2MPkMoK
glpIKw==
=XD5b
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-07-01 18:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Carlos Rica
In-Reply-To: <Pine.LNX.4.64.0707011301540.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Carlos had a cute idea on IRC, but was too shy to mention it here. There
> is a central place for Git's shell script, git-sh-setup. Defining an
> environment variable there, GIT_NO_ALIAS, and honouring that in the Git
> wrapper. Something similar is possible in Git.pm for perl scripts.
>
> Note: I am opposed to overriding default parameters via alias. I am only
> stating that it is still possible.
>
> I am in favour of Linus' patch. Here's why: quite some times, I have been
> asked (at a very late stage) "What still confuses me: what is the
> difference between git-xyz and git xyz?" It _is_ confusing for beginners,
> even if it is easy to explain.
Ok, please consider the idea sold.
^ permalink raw reply
* Re: [PATCH] t7004: ship trustdb to avoid gpg warnings
From: Junio C Hamano @ 2007-07-01 18:19 UTC (permalink / raw)
To: Carlos Rica, Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <1b46aba20707010552k3ca46dbfj6ef508440dee6214@mail.gmail.com>
"Carlos Rica" <jasampler@gmail.com> writes:
> We finally supplied every file generated by gpg. I talked a lot with
> Johannes about what files could be safely threw away and I even ask
> that in the #gnupg channel to remove this file. I hadn't seen those
> messages.
>
> The patch worked fine for me. Indeed, I realized that the file is
> equal to that I shipped in the first version of the tests.
>
> Thank you Junio for your effort on this.
>
> 2007/7/1, Junio C Hamano <gitster@pobox.com>:
>> This avoids warning messages from gpg while verifying the tags; without it,
>> the program complains that the key is not certified with a trusted signature.
Thanks for confirmation; I forgot to add "From:" at the
beginning of the message. The patch was from Johannes and I was
merely forwarding it for him after confirming it worked for me.
I am forwarding your thanks (and mine) to him ;-).
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Sven Verdoolaege @ 2007-07-01 18:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carlos Rica, git
In-Reply-To: <Pine.LNX.4.64.0707011903200.4438@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
On Sun, Jul 01, 2007 at 07:06:43PM +0100, Johannes Schindelin wrote:
> And send me the resulting pubring.gpg and secring.gpg?
Attached.
> If you have a little more time, you could also put them in t/t7004/, and
> check t7004-tag.sh...
Different... (assuming I understand your request correctly)
* expecting success:
git-tag -s -m "A signed tag message" signed-tag &&
get_tag_msg signed-tag >actual &&
git-diff expect actual
gpg: Warning: using insecure memory!
gpg: skipped `C O Mitter <committer@example.com>': secret key not available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
* FAIL 49: creating a signed tag with -m message should succeed
git-tag -s -m "A signed tag message" signed-tag &&
get_tag_msg signed-tag >actual &&
git-diff expect actual
bash-3.00$ git diff
diff --git a/t/t7004/pubring.gpg b/t/t7004/pubring.gpg
index 83855fa..20e89c6 100644
Binary files a/t/t7004/pubring.gpg and b/t/t7004/pubring.gpg differ
diff --git a/t/t7004/secring.gpg b/t/t7004/secring.gpg
index d831cd9..e69de29 100644
Binary files a/t/t7004/secring.gpg and b/t/t7004/secring.gpg differ
skimo
[-- Attachment #2: pubring.gpg --]
[-- Type: application/octet-stream, Size: 1172 bytes --]
[-- Attachment #3: secring.gpg --]
[-- Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Johannes Schindelin @ 2007-07-01 18:30 UTC (permalink / raw)
To: skimo; +Cc: Carlos Rica, git
In-Reply-To: <20070701182637.GL7969MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 786 bytes --]
Hi,
On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
> On Sun, Jul 01, 2007 at 07:06:43PM +0100, Johannes Schindelin wrote:
> > And send me the resulting pubring.gpg and secring.gpg?
>
> Attached.
Thanks.
> > If you have a little more time, you could also put them in t/t7004/, and
> > check t7004-tag.sh...
>
> Different... (assuming I understand your request correctly)
>
> * expecting success:
> git-tag -s -m "A signed tag message" signed-tag &&
> get_tag_msg signed-tag >actual &&
> git-diff expect actual
>
> gpg: Warning: using insecure memory!
> gpg: skipped `C O Mitter <committer@example.com>': secret key not available
> gpg: signing failed: secret key not available
Aargh! I am a complete moron. Attached also the private key now.
Ciao,
Dscho
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/plain; charset=utf-8; name=seckeys.asc, Size: 1237 bytes --]
•\x01»\x04FgË)\x11\x04\0³\bøÈ¥6\r/¶6µ
¥\x10dÓ\x0e[ÙqcKŒ^_íœîÈê:'KR\x01Cߪœ‡RÙ-&dJ\x17QÜfžù»(—(ñ®Qn\x14ý\x1e]\x13̶¢¶Ñ¢ðífo<ZDWTá2w¾=\x12cb»à…l7/EU \x02\x19ðeðPnSßn\x121Ä#J#bZ\x0e¼W6SàIª\x01¿\0 ãÄã~‰v~„¨%®×Rïr\0¿,Î\x0f\x03ý\x15,O3EøaI\x11åìÆ
\x14Æ((F=\x048+€\v£§¶\x18ò§F²%^[Ðh2ΤF6E·‰irò¡\x19ñçäa#šÙ>}\x16Ãæ£ß2¢…[äô4÷Ø•‰‹$ž\x1f³Š™ð¼{Ǩ†é~u»æ\rÂÄ. hÌ\b-ÂxØ·\x17º+ëdÖ\0I¶ÔÔN"\r6çr\x03ý\x1ajËèeJ\r$\a6pþH~Ζ…s\x16-ó\x11Ú—mò°(Ö'yç:Òë'H*&pª¡°•dÐl¾½Å9…aFEç(\x06ñûE¶º±OðáU\x051
;¤ìÙ\ Xh'y\x06(\x1ez³ÂU\x04Ê3£–¿¥ÉþîÚÏÊ\x03\x1aJ\x03¨ç¶Ñ\x1dE&Íi!ºŒuÃ\0\x14’½»ý\0\0ŸtÄ̤u§\x1cQù\x1dÝ\x1eáižwÚ´Â\x03\v“´"C O Mitter <committer@example.com>ˆ^\x04\x13\x11\x02\0\x1e\x05\x02FgË)\x02^[\x03\x06\v \b\a\x03\x02\x03\x15\x02\x03\x03\x16\x02\x01\x02\x1e\x01\x02\x17€\0
\x10\x13¶õ\x1eÍÞC\rt\x1d\0 ½Ùÿ°:´äncÄ\x7f뾨\x0fÆ¿ qC\0ŸC]¼%p¢ÜÊL\aËHØ©¨×›X‚y\x02=\x04FgËN\x10\b\0ιy?Sëè Ñògù\fa³qE\føñ+ \x0e\x05-҉喙sº²ÖY¦[Ûî½¾±v)ðs\ažÙÎ_tÑ>‰HÇWlvK÷[|<ÉLßô¹¨Ùs\x0f±ÿŠÅ\x11³ˆ\x03JÎÜ\x1dqÁ´\x0eîñ(Xwîì˜ ^˜°ô¤Ê±‰œ‹\0u¶rO\aÓ±¨ñå\x0fñòÈzö¾ˆúža\x06hô\x16ÏÝ‘üžyº^cYQ’ÿ²Y:µ\x18MÂþ\x1c[t\x10.\x1dý¸³öº¯dÂ…]\x7f0‘Ž\x05u Œ!°«1¾ï"\È{Þ›o\x7fŠ¯ÿ\x12ÙØð\x1c\x15ÜÀ“' éóõ›ýßr—\x14›T]·\x04bÁø_Cìæ§+)›³± ×Çëšßíÿ\0\x04\r\b\0´b1^[?xàùö:Ø^cÒe\x05^[ˆ\x02ål’m¸ýœôÝÖg“ ®\x10â\x01o’\fƒ~†\0òœŸ[ì-\x13|MjçxÍ¥À\0^8'‚tl
6fÖh%¨ðøeði—áážç<Ñð\x11ÆÅ\x0fî\ð£ö3äp³‰¨i”cV—w((·qçåOó£Âq=\x0f7a²P†LÀ9ŸÇ\x1aŒ\v6¢ \x1aBË\x1e}Wö¦²Ð,e}4\x1e\x10ÞQg)woŠ‘Ìh\x06\0±o¢\x17²d…0Õ6ãF–çÞJ¥&Š\x04A6W\x05Å]òÈü¼3‚X¥\x1f«\x12rKìÑaÊ-Ÿ´/¦÷
\x02G7dlg´1À bÕ§¦²úúäW„^ŸÀc\x16†åÛ”nË ^[Ãà :nÁ\0\x01T\r@íÜ]jnˆŸç4²çZãîœ\x12‰R[«\x17_Ø`þ›é®\x17EiÀ7!†ª›Lî\x1e\x16£ˆI\x04\x18\x11\x02\0 \x05\x02FgËN\x02^[\f\0
\x10\x13¶õ\x1eÍÞC\rÁì\0 Ðr€-\rbEº•QªW ìñá\r¤„\0œ
Ï¿.Ñ<-¿a\v휾½î\x1fš|Ø\x02
^ permalink raw reply
* Re: Non-http dumb protocols
From: Daniel Barkalow @ 2007-07-01 18:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707011527590.4438@racer.site>
On Sun, 1 Jul 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 30 Jun 2007, Junio C Hamano wrote:
>
> > Having said that, I have a feeling that many people do not build
> > any of the commit walkers, and especially the http walker,
> > because they have no need for dumb protocols, and libcurl-dev is
> > just another piece of dependency they do not have to have.
>
> Interestingly, I just was involved in a discussion on IRC, where somebody
> (out of quotat concerns) wants to use sftp to push to a bare repository,
> which is served via HTTP.
>
> Unfortunately, it seems that all persons wanting to have some support for
> that, expect others to do the work for them.
>
> However, there is a miniscule non-zero chance that eventually somebody
> might want to realise an sftp push protocol (where you basically need the
> ls-remote part of the fetcher, too, to determine what to pack and send).
> And to complete a dumb sftp fetch protocol, you'd need a commit walker,
> so I'd like to have at least a minimal interface for commit walkers
> waiting for that saviour.
Okay, I think I'll go for ditching ssh-fetch/-push, making the
commit-walker code more modular, and possibly moving more of the smarts of
http-fetch into the common code so that local-fetch is a better test for
it and sftp fetch would be possible.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Sven Verdoolaege @ 2007-07-01 19:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carlos Rica, git
In-Reply-To: <Pine.LNX.4.64.0707011929200.4438@racer.site>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Sun, Jul 01, 2007 at 07:30:09PM +0100, Johannes Schindelin wrote:
> Aargh! I am a complete moron. Attached also the private key now.
Ok... some progress...
* expecting success: git-tag -v signed-tag
object 86e17e4ed4cddf9a4f960da789f8378f6ea1ff2b
type commit
tag signed-tag
tagger C O Mitter <committer@example.com> Thu Apr 7 15:13:13 2005 -0700
A signed tag message
gpg: Warning: using insecure memory!
gpg: Signature made Sun Jul 1 19:08:37 2007 UTC using DSA key ID CDDE430D
gpg: Good signature from "C O Mitter <committer@example.com>"
gpg: NOTE: secret key CDDE430D is NOT protected.
gpg: /home/skimo/src/git/t/trash/gpghome/trustdb.gpg: invalid file version 3
gpg: fatal: /home/skimo/src/git/t/trash/gpghome/trustdb.gpg: invalid trustdb
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/16384
* FAIL 50: verifying a signed tag should succeed
git-tag -v signed-tag
skimo
[-- Attachment #2: secring.gpg --]
[-- Type: application/octet-stream, Size: 1229 bytes --]
^ permalink raw reply
* Re: [PATCH] cvstrack: work on imported cvs and other git branches
From: Steffen Prohaska @ 2007-07-01 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707011852531.4438@racer.site>
On Jul 1, 2007, at 7:53 PM, Johannes Schindelin wrote:
> On Sun, 1 Jul 2007, Steffen Prohaska wrote:
>
>> The background is, I plan to convince approximately 60 developers
>> to migrate from CVS to git and I'm searching for a way to start the
>> transition with some beta testers, while maintaining full cvs
>> infrastructure in place for the remaining users.
>
> Why not just cvsimporting into git, and then replace the CVS server
> with
> git-cvsserver? That's what I did.
I thought about that but I don't know yet how to slice our existing
CVS repository. Most developers use partial checkouts.
But maybe I should reconsider and evaluate git-cvsserver in more detail.
Steffen
^ permalink raw reply
* Re: Non-http dumb protocols
From: Johannes Schindelin @ 2007-07-01 20:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707011444300.14638@iabervon.org>
Hi,
On Sun, 1 Jul 2007, Daniel Barkalow wrote:
> Okay, I think I'll go for ditching ssh-fetch/-push, making the
> commit-walker code more modular, and possibly moving more of the smarts
> of http-fetch into the common code so that local-fetch is a better test
> for it and sftp fetch would be possible.
Thanks,
Dscho
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Josh Triplett @ 2007-07-01 21:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707011313580.4438@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 1 Jul 2007, Jeff King wrote:
>
>> On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:
>>
>>> So I am somewhat negative on this, unless there is a way for
>>> scripts to say "Even though I say 'git foo', I do mean 'git foo'
>>> not whatever the user has aliased".
>> I had submitted GIT_NOALIAS=1 patches a while back, but IIRC, the
>> consensus was that it was a bit too ugly and fragile in concept.
>
> I think it is not GIT_NOALIAS that is ugly and fragile in concept. It is
> the whole notion that you can define default parameters via aliases that
> is ugly and fragile.
>
> The possibility to say
>
> git config alias.log '!rm -rf /home/peff'
>
> on somebody _else's_ machine makes me go shudder.
>
> And there's another thing. On some machines, rm is aliased to 'rm -i'.
> That's good, right? NO! It _forces_ me to either look at the aliases on
> that particular box, or alternatively (which is what I actually do),
> specify _exactly_ what I want (I never do "rm", I always do "rm -i" or "rm
> -f", or "git rm"). That's because the default behaviour is
> _different_ on _different_ boxes. Repeat after me: consistency is good,
> inconsistency is bad.
And to give a git-specific example, I suspect many people would see this
feature and immediately do "git config alias.commit "commit -a".
- Josh Triplett
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: Junio C Hamano @ 2007-07-01 21:39 UTC (permalink / raw)
To: Jeff King
Cc: しらいしななこ, GIT,
Johannes Schindelin
In-Reply-To: <20070701091905.GA13559@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jul 01, 2007 at 06:06:29PM +0900, しらいしななこ wrote:
>
>> I don't understand myself anymore, either (^_^;) I just tried to follow
>> Jnio's earlier suggestion in his message. He said this.
>
> OK, we will wait for Junio to clarify tomorrow. :)
Jeez. I tried to stay lazy and have all the work done by
somebody else (and taking the credit at the end, as I was
mentored by you-know-who ;-), but you guys managed to suck me
into this.
There are a few issues when you replay a stash on a state that
is different from the state the stash was created on.
Stash records the then-current HEAD, index and the working tree
(I'll call them H, I and W for brevity from now on). Ideally,
we would want to have the difference between the resulting index
and working tree to be similar to the difference between I and
W.
Replaying the stash is done on a clean working tree. That is,
we require that at least the index and working tree match (we
could also require that the index and HEAD match, but I do not
think it changes anything in this discussion). And we apply the
change between H and W with three-way merge.
For paths that are cleanly merged with this three-way merge,
merge-recursive updates the working tree and the index. That
means if you do "git diff", you would not see the local changes
that were carried forward would not be visible, and you would
need "git diff HEAD" to view them. I found it confusing, and
that was the suggestion I sent was about. Nana's "3rd try", which
I applied and pushed to 'next', addresses this issue by running
"read-tree --reset $c_tree" (where $c_tree is the contents of
the index before replaying the stash).
This is not ideal. We would want to see "git diff" for such a
path show difference similar to difference between I and W.
There is a little glitch, though. Such an operation can also be
done with a three-way merge (git-merge-file would most likely be
useful), but what would we do when this second merge conflicts?
If we insist on making the "git diff" output to match the diff
between I and W for the path, somebody needs to resolve the
conflict and put the result in the index, but if git-merge-file
couldn't, the user is left to do that. I strongly suspect that
we would not want that aggravation (besides, the working tree
cannot be used anymore as it contains what we would want to
leave there as the result of unstashing). The second best thing
is probably to leave the index as it was before the stash was
applied for such a path (in other words, for such a path, we
discard the difference between I and W, favoring to use W).
We could still attempt to carry the difference between I and W
for paths that the second merge cleanly resolves, but then "git
diff" will show full diff between H and W for some paths (that
is, the ones the second merge did not cleanly resolve) while
diff between I and W for others (the ones that resolved
cleanly). That is not what the current code does, though.
I am hoping that the "best effort" would make it more convenient
to use, but I also suspect that it might make things more
confusing to the end user and certainly more difficult to explain.
So that's about the cleanly-merged case.
What we should do about the paths that the first merge (i.e. the
one that updates the working tree) does not resolve cleanly? We
would want to keep the index the way merge-recursive left, for
conflicting paths at least. We would have higher stages for
them, so that the user will not accidentally commit things that
have not been merged, and can use usual conflict resolution
techniques like "git diff" to view the combined diff between
three versions.
^ permalink raw reply
* [PATCH] Make '!' aliases more useful
From: Johannes Schindelin @ 2007-07-01 21:51 UTC (permalink / raw)
To: git, gitster
When an alias starts with an exclamation mark, the rest is interpreted
as a shell command. However, all arguments passed to git used to be
ignored.
Now you can have an alias like
$ git config alias.e '!echo'
and
$ git e Hello World
does what you expect it to do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I have this in my $HOME/.gitconfig:
[alias]
debug = !GIT_PAGER= gdb --args git
which allows me to debug, say "git log a..b" by saying "git debug
log a..b".
git.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 8ea70da..32e8aa9 100644
--- a/git.c
+++ b/git.c
@@ -205,6 +205,21 @@ static int handle_alias(int *argcp, const char ***argv)
git_config(git_alias_config);
if (alias_string) {
if (alias_string[0] == '!') {
+ if (*argcp > 1) {
+ int i, sz = PATH_MAX;
+ char *s = xmalloc(sz), *new_alias = s;
+
+ add_to_string(&s, &sz, alias_string, 0);
+ free(alias_string);
+ alias_string = new_alias;
+ for (i = 1; i < *argcp &&
+ !add_to_string(&s, &sz, " ", 0) &&
+ !add_to_string(&s, &sz, (*argv)[i], 1)
+ ; i++)
+ ; /* do nothing */
+ if (!sz)
+ die("Too many or long arguments");
+ }
trace_printf("trace: alias to shell cmd: %s => %s\n",
alias_command, alias_string + 1);
ret = system(alias_string + 1);
--
1.5.2.2.3276.gf2524-dirty
^ permalink raw reply related
* Re: [PATCH] Document git-stash
From: Junio C Hamano @ 2007-07-01 21:54 UTC (permalink / raw)
To: Jeff King
Cc: しらいしななこ, GIT,
Johannes Schindelin
In-Reply-To: <20070701080757.GA6093@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> +(no subcommand)::
>> +
>> + Save your local modifications to a new 'stash', and run `git-reset
>> + --hard` to revert them.
>
> For orthogonality's sake, should this be 'git-stash save', aliased to
> just 'git-stash'? It would make this heading a little more intuitive,
> and the very first paragraph (describing all of the modes) a little more
> clear.
I would further suggest that we _require_ 'git stash save' to
create a new one and perhaps make the non-subcommand case run
'git stash list'. While I was trying the code out I
accidentally created a new stash when I did not mean to, which
pushed the stash I wanted to apply down in the list every time I
made such a mistake.
^ permalink raw reply
* Re: [PATCH] contrib/hooks: add post-update hook for updating working copy
From: Sam Vilain @ 2007-07-01 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejjte4wp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> > You can make interesting things happen to a repository
> > > every time you push into it, by setting up 'hooks' there. See
> > > -documentation for gitlink:git-receive-pack[1].
> > > +documentation for gitlink:git-receive-pack[1]. One commonly
> > > +requested feature, updating the working copy of the target
> > > +repository, must be enabled in this way.
>
> That is more like "could be", not "must be", and it is not the
> manpage's job to pass judgement on if a feature is often requested.
Ok, I'll just remove that clause. Or do you think it perhaps belongs in
a NOTES or HINTS section?
>> + if tree_in_revlog $ref $current_tree
>> + then
>
> Why should it behave differently depending on whether the index
> matches one of the arbitrary (i.e. taken from "tail" default)
> number of commits the user happened to be at in the recent past?
> If the check were "does it match with the HEAD", there could be
> a valid justification but this check does not make any sense to
> me.
Ok, well first we check that the index matches the working copy. But if
there are staged changes which have not been committed, then the written
tree will (probably) not exist anywhere in the reflog for the current
branch, and we can stop.
Basically I'm trying to figure out "does the current index have any
uncommitted changes". If it matches the tree from the previous (handful
of) ref(s), then the answer is "no". If we can't find it anywhere then
it's probably got staged changes, and short of trying to move the
changes forward, we should stop.
>> + if git-diff-index -R --name-status HEAD >&2 &&
>> + git-diff-index -z --name-only --diff-filter=A HEAD | xargs -0r rm &&
>> + git-reset --hard HEAD
>
> I do not understand the first two lines at all. Are you trying
> to lose working files for the paths that were added to the index
> since HEAD? "git reset --hard HEAD" should take care of that
> already.
The first one simply displays what is happening to the working copy for
the benefit of the user.
The second is implementing something I for some reason thought git-reset
wasn't doing.
> But more importantly, why is it justified to throw away such
> files to begin with?
Because we've already previously decided that they are safely stowed in
a previous (via time/reflog) revision of the current branch.
>> + echo "E:unexpected error during update" >&2
>> + fi
>> + else
>> + echo "E:uncommitted, staged changes found" >&2
>> + fi
>> + else
>> + echo "E:unstaged changes found" >&2
>> + fi
>
> I think this part is a good demonstration why pushing into a
> live branch should not attempt to update the working tree. It
> sometimes happens, and it sometimes cannot (which is not your
> fault at all), but the indication of what happened (or did not
> happen) goes to the person who pushed the changes, not to the
> person who gets confusing behaviour if the index/worktree
> suddenly goes out of sync with respect to the updated HEAD.
One counter-argument to this is that you indicate that is the behaviour
that you want when you chmod +x the hook. It should gracefully step out
of the way when people who currently set that hook active keep doing it.
But this problem exists without this hook, in fact it is far worse. The
indication of what happened goes nowhere, and the person gets extremely
confusing behaviour when they commit.
Perhaps it would make sense to do this check in the "update" hook as
well, thereby chmod +x refuses to allow a push that touches the
currently checked out branch. The check would then be run twice if both
hooks are enabled, unless the first one can signal success/verification
to the second somehow.
> The longer I look at this patch, the more inclined I become to
> say that the only part that is worth saving is the next hunk.
>
>> -exec git-update-server-info
>> + if [ -z "$success" ]
>> + then
>> + (
>> + echo "Non-bare repository checkout is not clean - not updating it"
>> + echo "However I AM going to update the index. Any half-staged commit"
>> + echo "in that checkout will be thrown away, but on the bright side"
>> + echo "this is probably the least confusing thing for us to do and at"
>> + echo "least we're not throwing any files somebody has changed away"
>> + git-reset --mixed HEAD
>> + echo
>> + echo "This is the new status of the upstream working copy:"
>> + git-status
>> + ) >&2
>> + fi
>> +fi
>> +done
I disagree; I think any half-measure is going to leave new users
horribly surprised by what happens, and if you just reset the index then
the staged commit is lost.
Sam.
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Sam Vilain @ 2007-07-01 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tytso
In-Reply-To: <7vk5tle4wq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I thought Ted said he'll look into clearning this up, so I won't
> apply it yet at this moment to my tree, but have one comment...
Yes, sorry I should have left this one out, it didn't get any changes.
Sam.
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: Johannes Schindelin @ 2007-07-01 22:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King,
しらいしななこ, GIT
In-Reply-To: <7vlkdz4wp3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 1 Jul 2007, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> +(no subcommand)::
> >> +
> >> + Save your local modifications to a new 'stash', and run `git-reset
> >> + --hard` to revert them.
> >
> > For orthogonality's sake, should this be 'git-stash save', aliased to
> > just 'git-stash'? It would make this heading a little more intuitive,
> > and the very first paragraph (describing all of the modes) a little more
> > clear.
>
> I would further suggest that we _require_ 'git stash save' to
> create a new one and perhaps make the non-subcommand case run
> 'git stash list'. While I was trying the code out I
> accidentally created a new stash when I did not mean to, which
> pushed the stash I wanted to apply down in the list every time I
> made such a mistake.
Well, the normal thing you want to do if you say "git stash" is best
described by "Git, stash!".
However, unstash would by a nice feature. Not easy, but nice. Not easy,
because we would be actively outsmarting the reflog machinery we use for
the stash.
Ciao,
Dscho
^ 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