headers
Johannes Schindelin | 1 Nov 2011 01:09
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
Permalink | Reply | 14 comments |
headers
Erik Faye-Lund | 1 Nov 2011 01:36
Picon
Gravatar

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>
Permalink | Reply | 1 comment |
headers
Pete Wyckoff | 1 Nov 2011 03:08
Favicon

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)

Permalink | Reply | 8 comments |
headers
Junio C Hamano | 1 Nov 2011 04:30
Picon
Picon
Favicon
Gravatar

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.
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Nov 2011 04:30
Picon
Picon
Favicon
Gravatar

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.
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Nov 2011 04:49
Picon
Picon
Favicon
Gravatar

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)

Permalink | Reply | 2 comments |
headers
Rick Bragg | 1 Nov 2011 04:46
Favicon

{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
Permalink | Reply | 0 comments |
headers
Michael Wookey | 1 Nov 2011 05:50
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.
Permalink | Reply | 7 comments |
headers
John Szakmeister | 1 Nov 2011 07:39
Gravatar

Re: Credentials and the Secrets API...

On Thu, Oct 27, 2011 at 1:48 PM, Jeff King <peff <at> 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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane