* Re: Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 20:43 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.1111011332400.32316@s15462909.onlinehome-server.info>
On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi kusma,
>
> On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
>> I've applied the patches to 'devel', verified that the result builds,
>> and pushed it out.
>
> I've applied your patches and made up commit messages. So far, I only
> tested with MSVCE 9.0 (AKA Express 2008) before running out of time.
> Please have a look at the commits (since I could build a git.exe with the
> correct version, I felt comfortable enough to push out to 'devel').
The commits look good to me. Thanks for following up on it :)
> Maybe if someone donates Jenkins resources, we could make an automatic
> branch in the future that has git.sln in it (similar to the 'html' branch
> in git.git).
CloudBees seems to have some kind of a free Jenkins service. Perhaps
it's sufficient?
http://www.cloudbees.com/dev-pricing.cb
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 20:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <7vy5vzn65u.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> 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...
>
> I can queue this for v1.7.8-rc1 if you want, as it is a fix whether or not
> we define MSVC or not while building.
Yes, please do. This looks good to me, thanks for picking it up :)
>> 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...
>
> It seems, from your description, that msvc update series has some way to
> go and it probably is better to be cooked by Windows-savvy folks for
> another cycle.
I don't think you need to hold these three patches; with them I was
able to build your 'master'. I believe the problems I bumped into only
exist in msysgit's 'devel' (or in your 'next', which msysgit/devel is
based upon).
> Which would mean that your upload-archive series is still
> good to go as long as it works for non-MSVC/mingw people, right?
>
Yes. Apart from the slip-up with LIB_H, my upload-archive series
should be unrelated to the issues I found here.
^ permalink raw reply
* Re: [PATCH] git-svn: add hook to allow modifying the subversion commit message
From: Eric Wong @ 2011-11-01 20:28 UTC (permalink / raw)
To: Michael Lutz; +Cc: git
In-Reply-To: <1319228708-9052-1-git-send-email-michi@icosahedron.de>
Michael Lutz <michi@icosahedron.de> wrote:
> Sometimes modifying the commit message git-svn creates for a subversion
> commit can be useful, for example if the original message contains meta
> information not needed in the git clone or information from svn properties
> should be stored visibly in the commit message.
>
> This change adds a hook 'git-svn-msg' analogue to the 'commit-msg' hook.
> Additionally to the commit message, the hook is passed the git-svn meta
> data by an environment variable.
I'm not convinced this is a good feature to support. We already have
--no-metadata to remove git-svn-id: lines and I hate that feature
because it introduced extra variables for testing/debugging/recovery.
Metadata in the commit message is important, if you want to remove
it after-the-fact, there's git-filter-branch.
When dealing with repositories that have been through several systems
(e.g. (CVS|Perforce) -> SVN -> git), it's useful to be able to refer to
old mailing list archives that only refer to the original system (since
neither SVN nor git existed at the time the email was sent).
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Naewe @ 2011-11-01 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111101T205618-231@post.gmane.org>
Stefan Naewe <stefan.naewe <at> gmail.com> writes:
> Push with https works, if the URL looks e.g. like this:
>
> https://github.com/user/repo.git
>
> rather than this
>
> https://user <at> github.com/user/repo.git
>
> and having a ~/.netrc like this
>
> machine github.com login user password YouDontWantToKnow
>
> If the URL contains 'user@' I get the 'need ENTER' behaviour.
>
Another update:
If I revert deba493 the 'need ENTER' is gone and everything works as above.
Stefan
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Naewe @ 2011-11-01 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <7vmxcfn23i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> [administrivia: dropped the kernel mailing list from and added Peff to Cc]
>
> Stefan Näwe <stefan.naewe <at> atlas-elektronik.com> writes:
>
> >>> * 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...
>
> There are only handful of commits that even remotely touch http related
> codepath between v1.7.7 and v1.7.8-rc0:
>
> [...]
>
> Could you try reverting deba493 and retest, and then if the behaviour is
> the same "need ENTER", further revert 070b4dd and retest?
Did some tests again at my home machine with v1.7.8-rc0.
Push with https works, if the URL looks e.g. like this:
https://github.com/user/repo.git
rather than this
https://user@github.com/user/repo.git
and having a ~/.netrc like this
machine github.com login user password YouDontWantToKnow
If the URL contains 'user@' I get the 'need ENTER' behaviour.
I'll recheck everything at work, where I live behind a very restrictive
firewall (Don't know if that makes any difference).
Regards,
Stefan
^ permalink raw reply
* Re: Git is exploding
From: Junio C Hamano @ 2011-11-01 20:14 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Øyvind A. Holm, git
In-Reply-To: <vpqty6n1ybs.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> http://www.ohloh.net/p/compare?project_0=Git&project_1=Subversion&project_2=mercurial&submit_2=Go
> => Git has 2,659 users on ohloh, Subversion has 7,667 and Mercurial has
> 795.
Git costs $11M (6 years old) while Subversion costs $6.7M (11 years old)?
^ permalink raw reply
* Re: [PATCH] svn: Quote repository root in regex match
From: Eric Wong @ 2011-11-01 20:13 UTC (permalink / raw)
To: Ted Percival; +Cc: git
In-Reply-To: <1320100632-10058-1-git-send-email-ted.percival@quest.com>
Ted Percival <ted.percival@quest.com> wrote:
> Fixes a problem matching repository URLs, especially those with a '+' in
> the URL, such as svn+ssh:// URLs. Parts of the URL were interpreted as
> special characters by the regex matching.
>
> Signed-off-by: Ted Percival <ted.percival@quest.com>
Looks obviously correct to me, thanks
Acked-by: Eric Wong <normalperson@yhbt.net>
And pushed to master of git://bogomips.org/git-svn.git
(commit 0e7e30f5606b48a4c6d34bc99c6d680bb76d3fbc)
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-01 19:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But what would be nice is that "git pull" would fetch the tag (based on
> name) *automatically*, and not actually create a tag in my repository at
> all. Instead, if would use the tag to check the signature, and - if we
> do this right - also use the tag contents to populate the merge commit
> message.
>
> In other words, no actual tag would ever be left around as a turd, it
> would simply be used as an automatic communication channel between the
> "git push -s" of the submitter and my subsequent "git pull". Neither
> side would have to do anything special, and the tag would never show
> up in any relevant tree (it could even be in a totally separate
> namespace like "refs/pullmarker/<branchname>" or something).
While I like the "an ephemeral tag is used only for hop-to-hop
communication to carry information to be recorded in the resulting
history" approach, I see a few downsides.
* The ephemeral tag needs to stay somewhere under refs/ hierarchy of the
lieutenant's tree until you pick it up, even if they are out of the way
in refs/pullmarker/$branchname. The next time the same lieutenant makes
a pull request, either it will be overwritten or multiple versions of
them refs/pullmarker/$branchname/$serial need to be kept.
- If the former, this makes forking of the project harder. Suppose a
pull request is made, you fetch and reject it. The lieutenant reworks
and makes another pull request. At this point the earlier signature
is gone. If somebody disagreed with your rejection and wanted to run
his tree with the initial version you rejected, his tree will not
carry the signature from the lieutenant.
- If the latter, then there needs to be a way to expire these pull
markers when they no longer are useful (i.e. the signature in it is
transcribed to a merge commit you create) [*1*]. But the party who
has power to clean them (i.e. the lieutenant who owns the repository)
is different from the party whose action determines when they no
longer are necessary (i.e. you). In practice this would lead to these
pull markers not cleaned at all [*2*].
* To verify the commit C that was taken from the tip of lieutenant's tree
some time ago, one has to find the merge commit that has C as a parent,
and look at the merge commit. For example "git log --show-signature"
would either show or not show the authenticity of C depending on where
the traversal comes from. You certainly can implement it that way, but
"some child describes an aspect of its parent, but not necessarily all
children do so" feels philosophically less correct than "the commit has
data to describe itself".
In your "ephemeral tag", the workflow for a developer (D) and his
integrator (U) would look like this, I think.
D$ until have something worth sending; do work; done
D$ git push -s
Enter passphrase: ...
- "push" internally creates a pull marker that signs the commit
object name this is pushing, among other things, and sends it
along the primary payload
D$ git pull-request; mail linus
U$ git pull
- "pull" notices the pull marker and fetches it as well;
- "pull" GPG validates the pull marker;
- When preparing a merge commit message, the contents of the
pull marker is included in .git/MERGE_MSG
The "in-commit signature" would give you 100% and your contributors 98% of
that, I think.
D$ until have something worth sending; do work; done
- The final round of reworking is concluded with "commit -S",
which would GPG sign the tip commit itself
D$ git push
- Nothing needs to change in the protocol nor "push" itself
D$ git pull-request; mail linus
U$ git pull
- "pull" GPG validates the tip commit
- Nothing unusual needs to happen to the resulting "merge" commit
And as a bonus, the code is already there ;-).
[Footnote]
*1* The common ancestor discovery in fetch uses as many refs as it can to
reduce the amount of data that needs to be transferred, and it is known to
hurt performance of the initial advertisement exchange when there are too
many useless refs.
*2* Do casual git users even know how to remove refs in a
remote/publishing repository?
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 18:40 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <CABPQNSaCRRRpEQPG1Mb4DovkMdQSBhHTm-i7y5M4iT+ndHX4XA@mail.gmail.com>
Hi kusma,
On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
> On Tue, Nov 1, 2011 at 1:09 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > 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.
I've applied your patches and made up commit messages. So far, I only
tested with MSVCE 9.0 (AKA Express 2008) before running out of time.
Please have a look at the commits (since I could build a git.exe with the
correct version, I felt comfortable enough to push out to 'devel').
Maybe if someone donates Jenkins resources, we could make an automatic
branch in the future that has git.sln in it (similar to the 'html' branch
in git.git).
Ciao,
Dscho
^ permalink raw reply
* Re: Git is exploding
From: Matthieu Moy @ 2011-11-01 18:39 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
Here are a few other interesting metrics:
http://www.ohloh.net/repositories/compare
=> around 1/4 of the repositories found are Git repositories. Subversion
has a bit more than half, and the last 1/4 is essentially CVS.
http://www.ohloh.net/p/compare?project_0=Git&project_1=Subversion&project_2=mercurial&submit_2=Go
=> Git has 2,659 users on ohloh, Subversion has 7,667 and Mercurial has
795.
From those numbers, centralized VCS are still dominant, but Git really
emerges among DVCS, and is not that far behind.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Jeff King @ 2011-11-01 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Näwe, git@vger.kernel.org
In-Reply-To: <7vmxcfn23i.fsf@alter.siamese.dyndns.org>
On Tue, Nov 01, 2011 at 11:12:49AM -0700, Junio C Hamano wrote:
> Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
>
> >>> * 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...
>
> There are only handful of commits that even remotely touch http related
> codepath between v1.7.7 and v1.7.8-rc0:
>
> * deba493 http_init: accept separate URL parameter
>
> This could change the URL string given to http_auth_init().
>
> * 070b4dd http: use hostname in credential description
>
> This only changes the prompt string; as far as I understand it, the
> condition the password is prompted in the callsites of git_getpass()
> has not changed.
>
> * 6cdf022 remote-curl: Fix warning after HTTP failure
> * be22d92 http: avoid empty error messages for some curl errors
> * 8abc508 http: remove extra newline in error message
> * 8d677ed http: retry authentication failures for all http requests
> * 28d0c10 remote-curl: don't retry auth failures with dumb protocol
>
> These shouldn't affect anything wrt prompting, unless you are somehow
> internally reauthenticating.
>
> Could you try reverting deba493 and retest, and then if the behaviour is
> the same "need ENTER", further revert 070b4dd and retest?
I don't use .netrc, but with all of my patches (most of which aren't
even in what you are running), I tried not to affect the netrc case. I
just checked a few things, and it seems to be working as I expect. Do we
have a repeatable test?
-Peff
^ permalink raw reply
* Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns
From: Junio C Hamano @ 2011-11-01 18:14 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER Gábor, git
In-Reply-To: <20111101152148.GA5552@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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.
I tend to agree with your inclination. Let's go with the current simple
version and see if real users want something different.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Junio C Hamano @ 2011-11-01 18:12 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org, Jeff King
In-Reply-To: <4EAFC18A.1070502@atlas-elektronik.com>
[administrivia: dropped the kernel mailing list from and added Peff to Cc]
Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
>>> * 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...
There are only handful of commits that even remotely touch http related
codepath between v1.7.7 and v1.7.8-rc0:
* deba493 http_init: accept separate URL parameter
This could change the URL string given to http_auth_init().
* 070b4dd http: use hostname in credential description
This only changes the prompt string; as far as I understand it, the
condition the password is prompted in the callsites of git_getpass()
has not changed.
* 6cdf022 remote-curl: Fix warning after HTTP failure
* be22d92 http: avoid empty error messages for some curl errors
* 8abc508 http: remove extra newline in error message
* 8d677ed http: retry authentication failures for all http requests
* 28d0c10 remote-curl: don't retry auth failures with dumb protocol
These shouldn't affect anything wrt prompting, unless you are somehow
internally reauthenticating.
Could you try reverting deba493 and retest, and then if the behaviour is
the same "need ENTER", further revert 070b4dd and retest?
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Junio C Hamano @ 2011-11-01 17:15 UTC (permalink / raw)
To: Roland Kaufmann; +Cc: git
In-Reply-To: <CANEMaQRoXRygmrYsu0xF6mWq50r9Qhh-YuXXNAhyQewd+fDtsQ@mail.gmail.com>
Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
> 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 think I misstated the precedence order. What I had in mind was roughly
like this:
1. "git diff" (and others like "git log") without "--dirdiff" option:
GIT_EXTERNAL_DIFF is used just as before and no GIT_EXTERNAL_TREEDIFF
is consulted;
2. "git diff --dirdiff": GIT_EXTERNAL_TREEDIFF is used if set, otherwise
GIT_EXTERNAL_DIFF is used.
That way, people who have been using GIT_EXTERNAL_DIFF that is capable of
comparing two directories do not have to change anything and can just give
"--dirdiff" when they want to operate the command with this new mode of
comparison. People whose GIT_EXTERNAL_DIFF is not capable of comparing two
directories have two choices, but in either case they first would need to
find an external tool they want to use with the "--dirdiff" mode. If they
want to use the same new external tool for non "--dirdiff" mode, then they
can set GIT_EXTERNAL_DIFF to it. If they want to keep using the command
they have been using with GIT_EXTERNAL_DIFF when not in "--dirdiff" mode,
however, they can keep their GIT_EXTERNAL_DIFF to the old "two files
comparison" tool, and set GIT_EXTERNAL_TREEDIFF to the new one.
But that is all about envisioning how a proper integration of the feature
in the main "diff/log -p" command codepath would work. I do not know if it
is worth to add that to your script, which would be a stop-gap experiment
until we find out if the "populate two temporary directories and have a
tool compare them as a whole" mode is useful.
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 16:45 UTC (permalink / raw)
To: kusmabite
Cc: Johannes Schindelin, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <CABPQNSaCRRRpEQPG1Mb4DovkMdQSBhHTm-i7y5M4iT+ndHX4XA@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> 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...
I can queue this for v1.7.8-rc1 if you want, as it is a fix whether or not
we define MSVC or not while building.
-- >8 --
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Tue, 1 Nov 2011 12:56:21 +0100
Subject: [PATCH] mingw: poll.h is no longer in sys/
Earlier we moved this header file in the code but forgot to
update the Makefile that refers to it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 4c09b35..ee34eab 100644
--- a/Makefile
+++ b/Makefile
@@ -515,7 +515,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
--
1.7.8.rc0.88.g45c5be
> Anyway, with that fix in place, it still breaks here:
> ...
> 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 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...
It seems, from your description, that msvc update series has some way to
go and it probably is better to be cooked by Windows-savvy folks for
another cycle. Which would mean that your upload-archive series is still
good to go as long as it works for non-MSVC/mingw people, right?
^ permalink raw reply related
* Re: imap-send badly handles commit bodies beginning with "From <"
From: Jeff King @ 2011-11-01 16:14 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Magnus Bäck, git, Andrew Eikum
In-Reply-To: <4EB01918.8080604@alum.mit.edu>
On Tue, Nov 01, 2011 at 05:06:48PM +0100, Michael Haggerty wrote:
> On 11/01/2011 04:38 PM, Jeff King wrote:
> > Right. If you properly quote and unquote "From " lines, then mbox can be
> > unambiguous.
>
> That is not quite true. The RFC says only that lines matching "^From "
> should be quoted, not lines matching "^>From " (or, generally, "^>*From
> "). So the quoting is lossy; it is *not* possible to tell whether a
> line starting with ">From " should be unquoted (it could have been
> ">From " in the original).
That was what I meant by "properly". Note that the second link Magnus
mentioned (and which is referred to in the RFC in the paragraph
immediately following the discussion of "from" quoting) discusses this
explicitly.
The real issue with mbox is not that it can't be done well, but that you
have no clue which variant the writing end used. In practice, it works
OK because it's simple and those corner cases just don't come up much
(at least for a reasonably defensive reader).
-Peff
^ permalink raw reply
* Re: imap-send badly handles commit bodies beginning with "From <"
From: Michael Haggerty @ 2011-11-01 16:06 UTC (permalink / raw)
To: Jeff King; +Cc: Magnus Bäck, git, Andrew Eikum
In-Reply-To: <20111101153803.GB5552@sigill.intra.peff.net>
On 11/01/2011 04:38 PM, Jeff King wrote:
> Right. If you properly quote and unquote "From " lines, then mbox can be
> unambiguous.
That is not quite true. The RFC says only that lines matching "^From "
should be quoted, not lines matching "^>From " (or, generally, "^>*From
"). So the quoting is lossy; it is *not* possible to tell whether a
line starting with ">From " should be unquoted (it could have been
">From " in the original).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: imap-send badly handles commit bodies beginning with "From <"
From: Jeff King @ 2011-11-01 15:38 UTC (permalink / raw)
To: Magnus Bäck; +Cc: git, Andrew Eikum
In-Reply-To: <20111030090111.GA1624@jpl.local>
On Sun, Oct 30, 2011 at 10:01:11AM +0100, Magnus Bäck wrote:
> > Mbox does have this problem, but I think in this case it is a
> > particularly crappy implementation of mbox in imap-send. Look at
> > imap-send.c:split_msg; it just looks for "From ".
>
> While there seems to be about a million different implementations of
> mbox creation and parsing, the relevant RFC[0] points to [1] as an
> authoritative source. The latter claims that lines matching "^From "
> denote a message boundary and that lines within a message that match
> the same pattern should be quoted with ">". That would suggest that
> the problem isn't imap-send.c but whatever code produces the mbox
> file in the first place. Of course, if that software isn't part of
> Git I guess we'll have to deal with the situation anyway. And whatever
> the RFCs say, we still need to be as compatible is possible with
> whatever software is out there.
Right. If you properly quote and unquote "From " lines, then mbox can be
unambiguous. But many pieces of software don't quote them (including
git, I think, but I didn't check), so it's prudent when reading to look
for something that actually appears to be a "From" line.
If somebody wants to tackle >From quoting of commit messages in
git-format-patch, they can certainly do so. In practice, it doesn't tend
to come up (because sane readers expect there to be a date at the end of
the line), so nobody has put forth the effort.
-Peff
^ 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
* 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: 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: 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
* 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: 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
* 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
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