Johannes Schindelin | 1 Nov 01:09 2011
Picon
Picon

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

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
Erik Faye-Lund | 1 Nov 01:36 2011
Picon

Re: [PATCHv2] Compile fix for MSVC

On Mon, Oct 31, 2011 at 9:34 PM, Junio C Hamano <gitster <at> 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 <at> gmail.com>
H. Peter Anvin | 1 Nov 01:42 2011

Re: [git patches] libata updates, GPG signed (but see admin notes)

> 
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pete Wyckoff | 1 Nov 03:08 2011

Re: git-p4: problem with commit 97a21ca50ef8

michaelwookey <at> 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
> 
(Continue reading)

Junio C Hamano | 1 Nov 04:30 2011
Picon
Picon

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

Johannes Schindelin <Johannes.Schindelin <at> 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.
Junio C Hamano | 1 Nov 04:30 2011
Picon
Picon

Re: [PATCHv2] Compile fix for MSVC

Erik Faye-Lund <kusmabite <at> 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 <at> gmail.com>

Thanks.
Junio C Hamano | 1 Nov 04:49 2011
Picon
Picon

Re: [PATCH] Display change history as a diff between two dirs

Roland Kaufmann <rlndkfmn+git <at> 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 "$ <at> ". 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`.
(Continue reading)

Rick Bragg | 1 Nov 04:46 2011
Picon

{Spam?} Electronic Voting could take a lesson from GIT

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

Michael Wookey | 1 Nov 05:50 2011
Picon

Re: git-p4: problem with commit 97a21ca50ef8

> 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.
James Bottomley | 1 Nov 06:39 2011

Re: [git patches] libata updates, GPG signed (but see admin notes)

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 <at> 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
(Continue reading)


Gmane