* 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
* 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: 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: [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: [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: 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
* 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: 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
* 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: 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
* {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: [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
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