* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Jeff Garzik @ 2011-10-31 23:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Linus Torvalds, git, James Bottomley,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On 10/31/2011 06:44 PM, Junio C Hamano wrote:
> "H. Peter Anvin"<hpa@zytor.com> writes:
>
>> On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>>>
>>> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
>>> - which is how things happen as a result of a pull request - you won't
>>> get tags at all - you have to ask for them by name or use "--tags" to
>>> get them all.
>>>
>>
>> Didn't realize that... I guess I'm too used to named remotes.
>>
>> If so, just using a tag should be fine, no?
>
> So nobody is worried about this (quoting from my earlier message)?
>
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine.
>
> A signed emphemeral tag is usable as means to verify authenticity in a
> hop-by-hop fashion, but that does not leave a permanent trail that can be
> used for auditing.
The main worry is Linus ($human_who_pulls) gets
cryptographically-verified data at the time he pulls. Once Linus
republishes his tree (git push), there will be few, if any, wanting to
verify Jeff Garzik's signature.
So no, I don't see that as a _driving_ need in the kernel's case.
And IMO the kernel will be a mix of signed and unsigned content for a
while, possibly forever.
And Linus wrote:
> [ Example gpg-signed small block that the attached patch adds to the
> pull request: ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Commit be3fa9125e708348c7baf04ebe9507a72a9d1800
> from git.kernel.org/pub/git
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iQEcBAEBAgAGBQJOrsILAAoJEHm+PkMAQRiGxZcH/31e0RrBitXUPKxHJajD58yh
> SIEe/7i6E2RUSFva3KybEuFslcR8p8DYzDQTPLejStvnkO8v0lXu9s9R53tvjLMF
> aaQXLOgrOC2RqvzP4F27O972h32YpLBkwIdWQGAhYcUOdKYDZ9RfgEgtdJwSYuL+
> oJ7TjLrtkcILaFmr9nYZC+0Fh7z+84R8kR53v0iBHJQOFfssuMjUWCoj9aEY12t+
> pywXuVk2FsuYvhniCAcyU6Y1K9aXaf6w5iOY2hx/ysXtUBnv92F7lcathxQkvgjO
> fA7/TXEcummOv5KQFc9vckd5Z1gN2ync5jhfnmlT2uiobE6mNdCbOVlCOpsKQkU=
> =l5PG
> -----END PGP SIGNATURE-----
This is my preference for kernel pull requests at the moment. That has
one advantage over Junio's "git pull --require-signature" and signed
commits, notably, the URL is signed.
But in general signed commits would be nice, too. pull-generated merge
requests would need to be signed, potentially introducing an additional
interactive step (GPG passphrase request) into an automated process.
Jeff
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vincent van Ravesteijn, git, kusmabite, ramsay, msysgit
In-Reply-To: <7vd3dcq4s5.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 31 Oct 2011, Junio C Hamano wrote:
> Thanks. The patch looks good from a POSIX person's point of view, and I
> do not immediately see how this would break other variants of Windows
> build at least from the code inspection.
As my virtual machine still ran the test suite after my latest rebasing
merge when I left work, I could not test the MSVC stuff just yet. I wanted
to do that tomorrow and either merge or come back with suggestions.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vincent van Ravesteijn, git, ramsay, msysgit
In-Reply-To: <7vd3dcq4s5.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks. The patch looks good from a POSIX person's point of view, and I do
> not immediately see how this would break other variants of Windows build
> at least from the code inspection.
>
> So I'll queue this, but I'll leave it to you and msysgit folks to decide
> if this topic should be merged to 1.7.8-rc1, as I do not have equipment,
> expertise, nor time to judge it myself (other than the code inspection we
> have already done here).
>
> Please give me an Ack or two by the end of this week. Thanks.
The result of applying this on top of the current master (1.7.8-rc0)
compiles and seem to runs fine for me, both with the MinGW supplied by
msysGit, and MSVC (as outlined by compat/vcbuild/README). Without the
patches, it fails to build with MSVC. In addition, the changes looks
good to me. So:
Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-11-01 0:42 UTC (permalink / raw)
To: Jeff Garzik
Cc: Junio C Hamano, Linus Torvalds, git, James Bottomley,
Andrew Morton, linux-ide, LKML
In-Reply-To: <4EAF3556.3000001@garzik.org>
>
> The main worry is Linus ($human_who_pulls) gets
> cryptographically-verified data at the time he pulls. Once Linus
> republishes his tree (git push), there will be few, if any, wanting to
> verify Jeff Garzik's signature.
>
> So no, I don't see that as a _driving_ need in the kernel's case.
>
> And IMO the kernel will be a mix of signed and unsigned content for a
> while, possibly forever.
>
I think the desire is to be able to deconstruct things if things were to
go wrong.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: git-p4: problem with commit 97a21ca50ef8
From: Pete Wyckoff @ 2011-11-01 2:08 UTC (permalink / raw)
To: Michael Wookey; +Cc: Git Mailing List, Luke Diamand
In-Reply-To: <CAOk9v+-==GwDQaZ=4BW1QfEF7+5SfhNF409Xom0bHdT_qKaiFA@mail.gmail.com>
michaelwookey@gmail.com wrote on Tue, 01 Nov 2011 10:11 +1100:
> [ please CC me as I am not subscribed to the list ]
>
> Hi,
>
> Commit 97a21ca50ef893a171a50c863fe21a924935fd2a "git-p4: stop ignoring
> apple filetype" isn't correct. Without knowing too much about how
> git-p4 works, it appears that the "apple" filetype includes the
> resource fork, and the "p4 print" that is used to obtain the content
> from the perforce server doesn't take this into account, or maybe some
> post processing of the file needs to be done to include the data, but
> not the resource fork, before inclusion into the git repo.
>
> With the above commit, a binary blob that literally contains the
> resource fork and data is included within the git repo. Of course,
> without the above commit, the intended file was never included in the
> git repo at all. Perhaps the resource fork issue was a known problem
> by the original git-p4 author.
>
> A sample file that that demonstrates what the above commit produces is
> here (use curl/wget):
>
> http://dl.dropbox.com/u/1006983/sample_image_fail.png
>
> This is literally a binary blob with about 110 KiB of resource fork
> plus the PNG data. The same image, minus about 110 KiB of resource
> fork is here:
>
> http://dl.dropbox.com/u/1006983/sample_image_correct.png
>
> I'm happy to test patches as we have a perforce repository with files
> of the "apple" filetype.
Thanks so much for taking the time to find this and to narrow it
down.
I found icnsutils that shows the fail.png file has a bunch of
icons glued onto the front of the correct image file.
We can certainly revert this commit, but first I'd like to
understand what the right behavior should be.
I managed to include an apple filetype in a repo from a linux box
by hacking:
$ cp /tmp/sample_image_fail.png fail.png
$ p4 add -t apple fail.png
$ p4 submit -dfail-apple
Submitting change 2.
Locking 1 files ...
add //depot/fail.png#1
Unable to read AppleDouble Header.
open for read: /home/pw/src/perforce/cli/%fail.png: No such
file or directory
Submit aborted -- fix problems then use 'p4 submit -c 2'.
Some file(s) could not be transferred from client.
Hrm. Fake it by copying your example apple file to what it asks
for:
$ cp fail.png %fail.png
$ p4 submit -c 2
Submitting change 2.
add //depot/fail.png#1
Change 2 submitted.
(But later p4 sync -f destroy both files.)
Voila:
$ p4 fstat //depot/fail.png
... depotFile //depot/fail.png
... clientFile /home/pw/src/perforce/cli/fail.png
... isMapped
... headAction add
... headType apple
... headTime 1320111844
... headRev 1
... headChange 2
... headModTime 1320111842
... haveRev 1
And git-p4 checks it out intact:
$ git p4 clone //depot
[..]
$ sha1sum depot/fail.png /tmp/sample_image_fail.png
93d175ad906147f4d75296bd2adb6d706f798c64 depot/fail.png
93d175ad906147f4d75296bd2adb6d706f798c64 /tmp/sample_image_fail.png
Which is what I thought an apple-filetype user would want.
Reverting the patch causes _no_ file to be created. Is
this better? Maybe the single-blob file, since it no longer
appears in AppleDouble format, is just as useless as no file?
The other option is to use "p4 print" without the -G, which
seems to retrieve only the data fork, and leave that in the repo.
Of course, if you change it, and submit it, it makes a mess.
Would it be good if git-p4 understood how to identify and create
AppleDouble files on Mac? If yes, eventually, we can revert the
commit and explain how this feature doesn't quite work yet.
Even if no, it seems like we should revert and complain that
this apple support is broken.
-- Pete
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 3:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Vincent van Ravesteijn, git, kusmabite, ramsay, msysgit
In-Reply-To: <alpine.DEB.1.00.1110311908240.1930@bonsai2>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> As my virtual machine still ran the test suite after my latest rebasing
> merge when I left work, I could not test the MSVC stuff just yet. I wanted
> to do that tomorrow and either merge or come back with suggestions.
Thanks.
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 3:30 UTC (permalink / raw)
To: kusmabite; +Cc: Vincent van Ravesteijn, git, ramsay, msysgit
In-Reply-To: <CABPQNSaW+ciEzAMruYVgK_y2xf=sExYiFfdbS4xonKe=h-APjA@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> The result of applying this on top of the current master (1.7.8-rc0)
> compiles and seem to runs fine for me, both with the MinGW supplied by
> msysGit, and MSVC (as outlined by compat/vcbuild/README). Without the
> patches, it fails to build with MSVC. In addition, the changes looks
> good to me. So:
>
> Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Junio C Hamano @ 2011-11-01 3:49 UTC (permalink / raw)
To: Roland Kaufmann; +Cc: git
In-Reply-To: <4EAE688C.8010502@gmail.com>
Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
>> "git diff" (and possibly even things like "git log -p") populating
>> two temporary directories (your old/ and new/) and running a custom
>> program specified by GIT_EXTERNAL_TREEDIFF environment variable,
>> instead of doing
>
> Would it be better to have yet another configuration available for
> this option instead of reusing the existing infrastructure for `git
> difftool`?
GIT_EXTERNAL_DIFF is designed to drive tools that can take a single pair
of files and compare, so it is entirely possible for people to have such
tool that would _not_ grok (as a tool named by the variable does not have
to) two directories specified by it. So yes, it is essential that the
variable not be reused.
It probably is OK for "git diff --dirdiff" to use GIT_EXTERNAL_TREEDIFF if
and only if GIT_EXTERNAL_DIFF is not defined, and use GIT_EXTERNAL_DIFF
otherwise. People who have GIT_EXTERNAL_DIFF set to a tool capable of
handing directory pair can just add "--dirdiff" to the command line, and
others can find such a tool and set it to GIT_EXTERNAL_TREEDIFF when they
do so.
>> It also is not clear what could be used in "$@". Obviously you would
>> not want things like "-U20" and "--stat" fed to the first "list of
>> paths" phase, but there may be some options you may want to give to
>> the inner "external diff" thing.
>
> Ideally, it should work the same way as `git difftool`.
I am not so sure about that; difftool is another way to drive a tool one
filepair at a time. You want to drive a tool that takes them as two _sets_
of files, one in each directory.
^ permalink raw reply
* {Spam?} Electronic Voting could take a lesson from GIT
From: Rick Bragg @ 2011-11-01 3:46 UTC (permalink / raw)
To: GIT Mailing-list
I don't want to get off topic, but here goes:
I wrote up a very simple idea and put it here:
https://github.com/rbragg/PeerElect
It could start off very small (in-house votes as to what food to buy for
example) and grow as large as a full scale presidential election. It can
also run along side of real paper votes.
Anyway, just an Idea, and I think it's time has come. Seeing the
electronic voting systems out there now, in real use, I shutter!
Rick
^ permalink raw reply
* Re: git-p4: problem with commit 97a21ca50ef8
From: Michael Wookey @ 2011-11-01 4:50 UTC (permalink / raw)
To: Pete Wyckoff, Git Mailing List, Luke Diamand
In-Reply-To: <20111101020841.GA8116@arf.padd.com>
> Would it be good if git-p4 understood how to identify and create
> AppleDouble files on Mac? If yes, eventually, we can revert the
> commit and explain how this feature doesn't quite work yet.
> Even if no, it seems like we should revert and complain that
> this apple support is broken.
I've used git-p4 for many years, and have always had to work around
the limitation of the "apple" filetype and the resulting lack of files
added to the git repo.
Of course, I'd love to have git-p4 work seamlessly for this scenario.
Even Perforce have a KB article on the limitation of the "apple"
filetype with git-p4:
http://kb.perforce.com/article/1417/git-p4
At least with 97a21ca50ef8 reverted, there is a warning that files
will be missing. The current behaviour results in a git repo with
unusable files without any warning whatsoever. I think having unusable
files, and without warnings, is worse as there is no indication that
there is a problem with files in the working tree.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: James Bottomley @ 2011-11-01 5:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, H. Peter Anvin, git, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com>
On Mon, 2011-10-31 at 15:52 -0700, Linus Torvalds wrote:
> On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > So nobody is worried about this (quoting from my earlier message)?
>
> No, because you haven't been reading what we write.
>
> The tag is useless.
It's not useless to people who want to verify the tree after it's been
released by you (say for forensics or something). As Peter said, we can
put it in a normally invisible namespace, but having a flag to make it
visible allows tools like git describe --contains to tell me which
signed tag was used to send a particular commit.
> The information *in* the tag is not. But it shouldn't be saved in the
> tag (or note, or whatever). Because that's just an annoying place for
> it to be, with no upside.
>
> Save it in the commit we generate. BAM! Useful, readable, permanent,
> and independently verifiable.
>
> And the advantage is that we can make that same mechanism add
> "maintainer notes" to the merge message too. Right now some
> maintainers write good notes about what the merge will bring in, but
> they are basically lost, because git is so good at merging and doesn't
> even stop to ask people to edit the merge message.
A signed empty commit containing the merge message as a comment also
looks fine to me. We'd need extra tooling to say which signed merge
corresponds to this patch, but I'd say its workable. The only slightly
counter intuitive thing is that for a non-trivial merge, my signed merge
description will have to be the next commit below rather than in the
actual merge you do (because we can't alter a cryptographically signed
commit).
James
^ permalink raw reply
* Re: Credentials and the Secrets API...
From: John Szakmeister @ 2011-11-01 6:39 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20111027174807.GD1967@sigill.intra.peff.net>
On Thu, Oct 27, 2011 at 1:48 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 27, 2011 at 12:05:03PM -0400, John Szakmeister wrote:
[snip]
>> With that information, I went ahead and created a
>> gnome-credential-keyring that uses Gnome's Keyring facility. I still
>> need to do a few more things (mainly run it against Jeff's tests), but
>> it's generally working. Just wanted to keep folks in the loop.
>> Hopefully, I can get patches out this weekend.
>
> Great, I'm looking forward to reading it.
I've pushed up the work I've done to:
<https://github.com/jszakmeister/git-credential-keyring>
There's not much to it. It also doesn't handle certs and that sort of
thing. I think we need to figure out which protocols need to be
handled differently so that we can use the appropriate api for the
keyring-like api. :-)
I also chose this way instead of a patch to git, because it appears
your work is no longer in pu (I must have missed the fact that it was
removed). Once your work makes it way back in, I can look into
getting it into the contrib area, if that's desired.
>> Jeff: it would be really excellent to break out the various pieces. I
>> think it would also be better to split the asking for passwords from
>> the storing of passwords.
>
> That's my current plan. I just need to stop dragging my feet on
> re-rolling the series.
Sounds good! I'll be happy to update when you do re-roll it. The
test you sent out was very helpful, BTW. I do think the test cases
with no context are a bit broken though. It doesn't seem right to ask
the storage backend to retrieve a password without any context at all,
IMHO. My implementation doesn't pass those two tests. It does pass
the rest of them though.
-John
^ permalink raw reply
* how to undo a merge
From: Hong-Ming Su @ 2011-11-01 7:27 UTC (permalink / raw)
To: git
The commit graph before merging is:
A--B <-master
\ \
\ \
C--D--E--F <- dev
git checkout master
git merge dev
The commit graph after merging is:
A--B
\ \
\ \
C--D--E--F <- dev <-master
master fast-forward to commit F.
I want to "undo" the merge. What shall I do?
Thank you!
Best regards,
Hong-Ming
^ permalink raw reply
* Re: how to undo a merge
From: Vincent van Ravesteijn @ 2011-11-01 7:56 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiEoaxAO3XxJMWEXP-L7C_xkxU0_nyDaor+TsJr-Ch7ARw@mail.gmail.com>
Op 1-11-2011 8:27, Hong-Ming Su schreef:
> The commit graph before merging is:
> A--B<-master
> \ \
> \ \
> C--D--E--F<- dev
>
> git checkout master
> git merge dev
>
> The commit graph after merging is:
> A--B
> \ \
> \ \
> C--D--E--F<- dev<-master
>
> master fast-forward to commit F.
> I want to "undo" the merge. What shall I do?
git checkout master
git reset B
Vincent
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-11-01 9:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v39e8o61s.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 04:49, Junio C Hamano <gitster@pobox.com> wrote:
> Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
>> Would it be better to have yet another configuration available for
>> this option instead of reusing the existing infrastructure for `git
>> difftool`?
> It probably is OK for "git diff --dirdiff" to use GIT_EXTERNAL_TREEDIFF if
> and only if GIT_EXTERNAL_DIFF is not defined, and use GIT_EXTERNAL_DIFF
> otherwise. People who have GIT_EXTERNAL_DIFF set to a tool capable of
> handing directory pair can just add "--dirdiff" to the command line, and
Did you perhaps mean the other way around: GIT_EXTERNAL_TREEDIFF
if set, and GIT_EXTERNAL_DIFF otherwise?
I will revise the patch to incorporate that, and at the same time fix
the isempty
function (it can be done simpler).
>>> It also is not clear what could be used in "$@". Obviously you would
>>> not want things like "-U20" and "--stat" fed to the first "list of
>>> paths" phase, but there may be some options you may want to give to
>>> the inner "external diff" thing.
>> Ideally, it should work the same way as `git difftool`.
> I am not so sure about that; difftool is another way to drive a tool one
> filepair at a time. You want to drive a tool that takes them as two _sets_
> of files, one in each directory.
I was thinking about the behaviour when you send options that are not
applicable to files at all, such as "--stat". In that case, it just stops after
`git diff`. Options that only applies to one file and not to a set
have I admittedly
not thought about (yet).
--
Roland.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Näwe @ 2011-11-01 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Linux Kernel
In-Reply-To: <4EAEAE13.50101@atlas-elektronik.com>
Am 31.10.2011 15:17, schrieb Stefan Näwe:
> Am 31.10.2011 06:00, schrieb Junio C Hamano:
>> A release candidate Git 1.7.8.rc0 is available for testing.
>>
>> [...]
>>
>>
>> Git v1.7.8 Release Notes (draft)
>> ================================
>>
>> Updates since v1.7.7
>> --------------------
>>
>> [...]
>>
>> * HTTP transport did not use pushurl correctly, and also did not tell
>> what host it is trying to authenticate with when asking for
>> credentials.
>> (merge deba493 jk/http-auth later to maint).
>
> This seems to break pushing with https for me.
> It never uses values from my '~/.netrc'.
> I'll come up with a detailed scenario later.
Update:
git push prompts for the password but just pressing return succeeds.
Weird...
Stefan
--
----------------------------------------------------------------
/dev/random says: Budget: A method for going broke methodically.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: Reference has invalid format: check maybe a bit to harsh?
From: Michael Haggerty @ 2011-11-01 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Oberndorfer, git
In-Reply-To: <7vpqhcq5h2.fsf@alter.siamese.dyndns.org>
On 10/31/2011 09:19 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> I agree that we would want to give users an escape hatch. That is, if we
>> can make something like this to work:
>>
>> c=$(git rev-parse --force refs/patches/obd_development/blah:_vari...)
>> git update-ref refs/patches/obd_development/blah--various-improvements $c
>
> Also we would need to be able to say
>
> git update-ref -d refs/patches/obd_development/blah:_vari...
>
> to get rid of the offending one.
>
>> I think we would be in a good shape.
>
> Having said all that, I think we should in general loosen the checks done
> on the reading side a lot more. The "checks" themselves should stay, can
> give loud warnings, and even can error out when appropriate, but in an
> operation that is necessary to recover from _existing_ breakage (like the
> one in this thread, a file with a colon in its name in .git/refs/), the
> ability to read and to remove is essential for recovery.
>
> I vaguely recall we had to apply a fix in the same spirit to loosen
> reading side after the offending topic was merged to 'master' during this
> cycle about $GIT_DIR/config not possibly being a ref getting warned, or
> something.
>
> Michael, what do you think?
Supporting invalid reference names some places, but not others, and this
perhaps (as in the case of ":") platform-dependent would be a big can of
worms (as can be seen by my attempt to summarize the situation, a few
paragraphs below).
I see the situation as a conflict between security and reliability on
the one hand and backwards-compatibility and/or the ability to recover
from old mistakes on the other hand. For example, reference names like
the following are problematic in earlier git releases:
* "refs/heads/foo/../../../../etc/passwd" -- here be dragons
* "refs/heads/foo.lock/bar" -- screws up the locking of a reference
called "refs/heads/foo"
* "refs/heads/prn:/waste/my/paper" -- is questionable on Windows, I believe
* "refs/heads//foo" -- would be normalized to "refs/heads/foo" in
certain circumstances but not others
Perhaps instead of arguing about exactly what command arguments are
treated strictly vs laxly and attempting to half-support invalid
reference names, we could solve 98% of the problem with a couple of
localized measures:
1. Something in the git_snpath() callchain could prevent paths referring
to files outside of $GIT_DIR from being generated (by normalizing the
paths, stripping out "." and "..", etc). I suppose that this change
would remove a lot of potential security issues at a stroke, and make it
less important for refname handling to be paranoid.
2. Invalid references could be detected and fixed via some mode of "git
fsck". This would then be the only codepath that has to handle invalid
reference names, and would take that burden off of the rest of the code.
"git fsck" could sanitize the names of invalid references and move them
to some kind of "lost+found" namespace. (Disadvantage: it could be
impractical to run "git fsck" on a remote repository to which one
doesn't have filesystem access.)
If one would want to plunge in with a complicated solution, things will
get messy. Here is an attempt at an exhaustive summary of the changes
since v1.7.7 that affect how strictly refnames are checked for validity,
and ideas for how one could work around problems of backwards
compatibility in the particular cases.
1. read_packed_refs() -- the old behavior was to accept *anything* found
in the packed-refs file; however, invalid references could not be worked
with reliably. Now checks that packed-refs refnames are valid and
die()s if not.
a. The old behavior could be restored for now.
a'. The old behavior could be restored, except that renames with
leading, trailing, or duplicate slashes could silently be normalized.
This could lead to collisions between unnormalized and normalized names
that were previously distinct. Such a collision is harmless if the two
symbols have the same value, but currently causes a fatal error if they
have distinct values.
b. Invalid references could be silently ignored (this would cause
them to be silently discarded at the next pack-refs).
c. Invalid references could be ignored with a warning (the warning
could include the SHA1). This would cause a lot of warnings to be
output until the next pack-refs or the repository is fixed some other way.
2. get_ref_dir() (reads loose refs) -- the old behavior was to accept
anything that was found as a filesystem path under "$GIT_DIR/refs"
except paths with components starting with "." or ending with ".lock".
Now checks that loose-ref refnames are valid and die()s if not.
a. The old behavior could be restored for now.
b. Invalid references could be silently ignored (this would cause
them to be carried around forever in the local repository, including
after a pack-refs, but omitted when the local repository is cloned).
c. Invalid references could be ignored with a warning (the warning
could include the SHA1). This would cause a lot of warnings to be
output until the repository is fixed somehow.
3. add_extra_ref() -- old behavior was to accept anything. But since
extra refs are generated locally and the names are not used, this
behavior shouldn't be a problem and could be restored for now.
4. check_refname_format() -- now disallows any refname component than
ends with ".lock" (previously only the last component was checked). Now
disallows DEL character in refnames, in agreement with the old
specification.
5. resolve_ref() -- previously passed its argument to git_snpath() and
tried to open the path without any verification whatsoever. Treated the
contents of symbolic refs similarly. Now checks the validity of
refnames at both steps.
a. The old behavior could be restored, but this would be very
questionable given how refs like "foo/../../../etc/passed" might be handled.
b. There could be some laxer level of checking of security-relevant
issues without enforcing all of the refname rules.
6. The infamous change that caused files that looked like loose
references but have invalid *contents* to cause a warning to be emitted
(strictly speaking, this doesn't affect refnames but reference contents).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Git is exploding
From: Matthieu Moy @ 2011-11-01 10:08 UTC (permalink / raw)
To: Øyvind A. Holm; +Cc: git
In-Reply-To: <CAA787r=jeBv9moineaJVY=urYzEX+d7n23ED-txAGhLS+OPbmg@mail.gmail.com>
Øyvind A. Holm <sunny@sunbase.org> writes:
> Found an interesting "Popularity Contest" graph on debian.org (via
> Thomas Bassetto on G+):
>
> http://bit.ly/rNxVN0
>
> Very cool indeed.
The recent rise is essentially due to the git-core package renamed to
git, and people doing updates:
http://qa.debian.org/popcon-graph.php?packages=git%2C+git-core&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Still, Git is now more popular than SVN for Debian users accepting the
popcon data gathering.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 11:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <alpine.DEB.1.00.1110311908240.1930@bonsai2>
On Tue, Nov 1, 2011 at 1:09 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 31 Oct 2011, Junio C Hamano wrote:
>
>> Thanks. The patch looks good from a POSIX person's point of view, and I
>> do not immediately see how this would break other variants of Windows
>> build at least from the code inspection.
>
> As my virtual machine still ran the test suite after my latest rebasing
> merge when I left work, I could not test the MSVC stuff just yet. I wanted
> to do that tomorrow and either merge or come back with suggestions.
I've applied the patches to 'devel', verified that the result builds,
and pushed it out.
However, it still doesn't compile with MSVC on top of our 'devel':
make: *** No rule to make target `compat/win32/sys/poll.h', needed by `daemon.o'
The fix for this problem is the following:
---8<---
diff --git a/Makefile b/Makefile
index 2837e79..70edb11 100644
--- a/Makefile
+++ b/Makefile
@@ -518,7 +518,7 @@ LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
-LIB_H += compat/win32/sys/poll.h
+LIB_H += compat/win32/poll.h
LIB_H += compat/win32/dirent.h
LIB_H += connected.h
LIB_H += csum-file.h
---8<---
This is a slip-up in my patch 0f77dea, but I don't quite understand
why this didn't cause any troubles until now... I guess the MSVC parts
of Makefile are somehow more dependent on LIB_H or something...
Junio, is it too late to squash in a fix-up? If it is, I can send a
fixup-patch instead...
Anyway, with that fix in place, it still breaks here:
compat/win32\poll.h(26) : warning C4005: 'POLLIN' : macro redefinition
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1495) :
see previous definition of 'POLLIN'
compat/win32\poll.h(27) : warning C4005: 'POLLPRI' : macro redefinition
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1496) :
see previous definition of 'POLLPRI'
[...]
compat/win32\poll.h(35) : warning C4005: 'POLLWRBAND' : macro redefinition
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1500) :
see previous definition of 'POLLWRBAND'
compat/win32\poll.h(38) : error C2011: 'pollfd' : 'struct' type redefinition
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1506) :
see declaration of 'pollfd'
Again, this seems to be related to the poll-emulation... I see that
these things are guarded by an "#if(_WIN32_WINNT >= 0x0600)" in
<winsock2.h>, which means it's supported for Windows Vista and
above... We still support Windows XP, so it seems someone has set this
too high :)
And this seems to indeed be the case, as compat/win32/poll.c takes
care to set it to 0x0502 before including. Something like this fixes
that problem for me:
---8<---
diff --git a/compat/mingw.h b/compat/mingw.h
index cdaa7ba..0b8e1aa 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -1,3 +1,4 @@
+#define _WIN32_WINNT 0x0501
#include <winsock2.h>
#include <ws2tcpip.h>
diff --git a/git-compat-util.h b/git-compat-util.h
index 0135dcc..e66c21e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,6 +85,7 @@
#define _SGI_SOURCE 1
#ifdef WIN32 /* Both MinGW and MSVC */
+#define _WIN32_WINNT 0x0501
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
---8<---
I'd prefer to set this from the Makefile, but this generates a warning
in compat/win32/poll.c about redefining a macro (poll.c wants it to be
0x502, which is Windows XP with SP2, rather than 0x501 which is normal
Windows XP):
---8<---
diff --git a/Makefile b/Makefile
index 2837e79..a4aa785 100644
--- a/Makefile
+++ b/Makefile
@@ -1131,7 +1131,10 @@ ifeq ($(uname_S),Windows)
CC = compat/vcbuild/scripts/clink.pl
AR = compat/vcbuild/scripts/lib.pl
CFLAGS =
- BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild
-Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
+ BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild \
+ -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H \
+ -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE \
+ -D_WIN32_WINNT=0x501
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
compat/win32/poll.o compat/win32/dirent.o
---8<---
(this will probably both be line-wrapped and white-space-broken, but
you get the point)
...But now I get a complaint about LF_FACESIZE and TMPF_TRUETYPE:
CC compat/winansi.o
winansi.c
compat/winansi.c(39) : error C2065: 'LF_FACESIZE' : undeclared identifier
compat/winansi.c(39) : error C2057: expected constant expression
compat/winansi.c(56) : warning C4113: 'FARPROC' differs in parameter lists from
'PGETCURRENTCONSOLEFONTEX'
compat/winansi.c(74) : error C2065: 'TMPF_TRUETYPE' : undeclared identifier
make: *** [compat/winansi.o] Error 1
Luckily, Karsten Blees already sent a patch for this:
http://osdir.com/ml/msysgit/2011-10/msg00031.html
...And with that applied, that problem goes away.
Unfortunately, it's not the last error I get:
LINK git-daemon.exe
daemon.o : error LNK2001: unresolved external symbol _inet_pton
daemon.o : error LNK2001: unresolved external symbol _inet_ntop
git-daemon.exe : fatal error LNK1120: 2 unresolved externals
make: *** [git-daemon.exe] Error 1
The following patch makes that go away:
---8<---
diff --git a/Makefile b/Makefile
index 2837e79..c87c7c5 100644
--- a/Makefile
+++ b/Makefile
@@ -1124,6 +1124,8 @@ ifeq ($(uname_S),Windows)
NO_CURL = YesPlease
NO_PYTHON = YesPlease
BLK_SHA1 = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_INET_NTOP = YesPlease
NO_POSIX_GOODIES = UnfortunatelyYes
NATIVE_CRLF = YesPlease
NO_D_INO_IN_DIRENT = YesPlease
---8<---
(again, probably white-space broken, but you get the point)
And THEN it compiles fine from 'devel'.
So there's some more work left to be done. Unfortunately, I don't have
time to polish these changes for at least a week, so unless someone
volunteers it'll take some time...
^ permalink raw reply related
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Dmitry V. Levin @ 2011-11-01 12:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <20111031231320.GA3857@do>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
On Tue, Nov 01, 2011 at 06:13:20AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Mon, Oct 31, 2011 at 08:17:09PM +0400, Dmitry V. Levin wrote:
> >
> > git rev-parse --since=1970-01-01 (and other git commands that take
> > date string arguments like --since) may fail when --since=1970-01-01 is
> > given. Whether it fails or not depends on current time and timezone data.
> > For example, "TZ=Europe/Paris git rev-parse --since=1970-01-01" fails two
> > hours a day (between 00:00 and 02:00 CET), and those who use more eastern
> > timezones are even less lucky. In artificial timezones like UTC-24 it
> > always fails:
> >
> > $ TZ=UTC-24 git rev-parse --since=1970-01-01
> > --max-age=18446744073709523490
>
> Out of curiosity, why do you need to work with a time so close to that
> date?
There is an utility that used to invoke "git log --since='1970-01-01 UTC'"
by default, and I was unlucky enough to use it during these hours of
failure. The utility is now fixed (it no longer calls git log with
--since option unless explicitly instructed to do so), and I hope git
is going to be fixed as well.
BTW, the timezone specifier (UTC) in "git rev-parse --since='1970-01-01 UTC'"
seems to be completely ignored by date string parser.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* checking out later commits from rolled back state
From: photoshop_nerd @ 2011-11-01 14:36 UTC (permalink / raw)
To: git
Hello, I a m relatively new to git, and my question pertains to moving back
and forth through the history of my commits.
Here is how I open a previous commit:
1)$ git log
2) (get sha1 hash of previous commit)
3)$ git checkout <hash of my previous commit>
the problem is that once I am working with that commit, git log only shows
the hash tags up to the time that the commit was made, but not any of the
later commits. Is there a way to get the hash tags of my later commits when
I am in that rolled back state?
--
View this message in context: http://git.661346.n2.nabble.com/checking-out-later-commits-from-rolled-back-state-tp6951892p6951892.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Recovery after interrupted repack
From: Drew Northup @ 2011-11-01 14:49 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <8339egazbf.fsf@kalahari.s2.org>
On Wed, 2011-10-26 at 12:15 +0300, Hannu Koivisto wrote:
> Hi,
>
> I interrupted git repack -a -f -d and now most commands say "fatal:
> bad object HEAD". Additionally an attempt to run git repack again
> says a bunch of "error: refs/heads/foo does not point to a valid
> object!" messages.
>
> git fsck prints a huge list of "missing blob <sha-1>" lines.
>
> I'm using a Cygwin build of git 1.7.5.1 (I also have a build of the
> latest master available).
Was the result any different after running git fsck on it? If all else
fails you can probably still use the contents of the reflog to fix
things, but I'm not the best reference on such matters.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: checking out later commits from rolled back state
From: Alexey Shumkin @ 2011-11-01 14:56 UTC (permalink / raw)
To: photoshop_nerd; +Cc: git
In-Reply-To: <1320158207959-6951892.post@n2.nabble.com>
usually, before you checkout a "past" commit you are on a "current"
named branch
so, do
$ git log <branch_you_were_on_before>
In general, most "history" git commands take a commit hash as an
argument and HEAD as a default one if none was specified
(HEAD is always CURRENT commit (you are on), it is a difference of SVN)
when you ran
$ git log
it was, actually,
$ git log HEAD
Also, you may specify several commits as arguments of git log
It it very usefull to use (in terminal) to see how branches are diverged
(on X/Windows gitk is more pretty)
$ git log --oneline --graph --decorate <branch1> <branch2> <branchN>
There is also "git reflog" command
RTM git-reflog
> Hello, I a m relatively new to git, and my question pertains to
> moving back and forth through the history of my commits.
>
> Here is how I open a previous commit:
>
> 1)$ git log
>
> 2) (get sha1 hash of previous commit)
>
> 3)$ git checkout <hash of my previous commit>
>
> the problem is that once I am working with that commit, git log only
> shows the hash tags up to the time that the commit was made, but not
> any of the later commits. Is there a way to get the hash tags of my
> later commits when I am in that rolled back state?
>
> --
> View this message in context:
> http://git.661346.n2.nabble.com/checking-out-later-commits-from-rolled-back-state-tp6951892p6951892.html
> Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: checking out later commits from rolled back state
From: Vincent van Ravesteijn @ 2011-11-01 14:58 UTC (permalink / raw)
To: photoshop_nerd; +Cc: git
In-Reply-To: <1320158207959-6951892.post@n2.nabble.com>
Op 1-11-2011 15:36, photoshop_nerd schreef:
> Hello, I a m relatively new to git, and my question pertains to moving back
> and forth through the history of my commits.
>
> Here is how I open a previous commit:
>
> 1)$ git log
>
> 2) (get sha1 hash of previous commit)
>
> 3)$ git checkout<hash of my previous commit>
>
> the problem is that once I am working with that commit, git log only shows
> the hash tags up to the time that the commit was made, but not any of the
> later commits. Is there a way to get the hash tags of my later commits when
> I am in that rolled back state?
>
If your are on branch 'master':
git log
git checkout <hash of previous commit>
then
"git log master" will show you the log from the tip of the master branch.
Vincent
^ permalink raw reply
* Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns
From: Jeff King @ 2011-11-01 15:21 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20111029124755.GE2345@goldbirke>
On Sat, Oct 29, 2011 at 02:47:55PM +0200, SZEDER Gábor wrote:
> > Grep only looks in the current subdirectory for matches.
>
> Unless the user explicitly specifies the path(s)... But that comes at
> the end of the command line, so the completion script could have no
> idea about it at the time of 'git grep <TAB>'.
True. But that's a more general problem. You have a 'tags' file that
presumably represents the working tree. But you are not necessarily
grepping there. You might be grepping something related (e.g., what's in
the index), which makes the tags file still a good guess.
But you might also be grepping some totally unrelated branch, in which
case this is not helpful.
I tend to think that we are OK erring on the side of using the 'tags'
file, even if it might be wrong, since otherwise we have nothing to
tab-complete. When the user hits <Tab>, they are asking us to make our
best guess, and if they know there is nothing to complete, they won't
hit <Tab>. So it's not like we're hurting some existing workflow.
And in that sense, maybe we should just do the "search back up the
working tree" thing. Sure, it may be return way more matches than are
accurate, but even that's better than having no tab-completion at all.
> > You don't want __gitdir here, but rather "git rev-parse --show-cdup".
>
> Oh, yes, indeed.
>
> But there was a point in using __gitdir() here: it respects the
> --git-dir= option. Which brings up the question: what
> should 'git --git-dir=/some/where/.git grep <TAB>' offer?
I guess if core.worktree is set, it would look there instead (and ditto
for specifying --work-tree on the command line). Handling those is such
a corner case that I'm not too concerned if we don't. And if somebody
really cares, they can fix the completion later to pick up magic like
that from the early part of the command line. I don't see it as a
blocker for an initial version of the patch.
> _get_comp_words_by_ref() is a general completion function, the purpose
> of which is to provide a bash-version-independent equivalent of
> $COMP_WORDS and $COMP_CWORD by working around the different word
> splitting rules. It doesn't know about git and its commands at all.
>
> But there is the while loop in _git() that looks for the git command
> (among other things) on the command line, which could store the index
> of the command name in $words in a variable. This variable could then
> be used in that case statement (and probably in a couple of other
> places, too).
Yeah, that makes sense. Again, my inclination is to just leave that for
a further patch if somebody really wants to make the completion (for
this and any other positional slots) more accurate.
-Peff
^ 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