* Re: [PATCH] document 'T' status from git-status
From: Mark Dominus @ 2011-10-31 14:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpqhdrdys.fsf@alter.siamese.dyndns.org>
> It is trivial if
Yes, it was very stupid of me to miss that.
> I dunno.
>
> An obvious alternative is to add T next to all occurrences of M in the
> table where we say "M is possible", but unless it is accompanied by an
> explanation "T is just a special case of M", I suspect the resulting
> description would be harder to understand than currently is, and as long
> as the reader understands "T is just a special case of M", then there
> isn't much point adding T everywhere M appears in the table anyway, so...
If you are suggesting that the patch you gave is preferable to actually
including T in the table, then I agree. Your patch is also better than
what I sent because it includes the unusual word "filetype", which the
user is likely to search for after seeing it in the git-status output.
^ permalink raw reply
* [PATCH] t7511: avoid use of reserved filename on Windows.
From: Pat Thoyts @ 2011-10-31 14:07 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, msysGit, Pat Thoyts
PRN is a special filename on Windows to send data to the printer. As
this is generated during test 3 substitute an alternate prefix to avoid this.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
t/t7511-status-index.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7511-status-index.sh b/t/t7511-status-index.sh
index bca359d..b5fdc04 100755
--- a/t/t7511-status-index.sh
+++ b/t/t7511-status-index.sh
@@ -24,7 +24,7 @@ check() {
check 1
check 2 p
-check 3 pr
+check 3 px
check 4 pre
check 5 pref
check 6 prefi
--
1.7.8.rc0.200.gbcc18
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Näwe @ 2011-10-31 14:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Linux Kernel
In-Reply-To: <7vfwi9rc0g.fsf@alter.siamese.dyndns.org>
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.
Stefan
--
----------------------------------------------------------------
/dev/random says: Justice is incidental to law and order.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* git rev-parse --since=1970-01-01 does not work reliably
From: Dmitry V. Levin @ 2011-10-31 16:17 UTC (permalink / raw)
To: git
Hi,
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
The problem is that several internal git functions implicitly convert
time_t to unsigned long, so when time_t gets negative, all date string
processing breaks.
--
ldv
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Junio C Hamano @ 2011-10-31 17:19 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org, Linux Kernel
In-Reply-To: <4EAEAE13.50101@atlas-elektronik.com>
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.
Thanks.
I have been pushing my updates out to code.google.com via authentication
token stored in ~/.netrc over https, so it would be nice to see what
breaks for you that works for me. There probably is something subtly
different.
^ permalink raw reply
* Re: [PATCH] blame.c: Properly initialize strbuf after calling, textconv_object()
From: Sebastian Schuberth @ 2011-10-31 17:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit
In-Reply-To: <7vd3dht4ms.fsf@alter.siamese.dyndns.org>
On Fri, Oct 28, 2011 at 19:20, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Thanks; do you have no addition to the test suite to demonstrate the
>>>>> breakage?
>>>>
>>>> Not yet. I'll try to come up with something.
>>>
>>> Let's do this.
>>
>> Thanks, but that does not seem to work for me. The test breaks both
>> without and with my patch. I'll look into it.
>
> Thanks. I suspect the difference is because you are on a crlf-native
> platform while I am not...
I've got a test now. However, that test revealed some more related
issues. I'll come up with a v2 of the patch this week.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 18:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFz3=cbciRfTYodNhdEetXYxTARGTfpP9GL9RZK222XmKQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> For the people who use "git request-pull", I'm attaching a trivial
> patch to make it add this kind of signature if you give it the "-s"
> flag. It basically just adds a hunk like the appended crazy example to
> the pull request, and it's small enough and simple enough that it
> makes verification simple too with just the above kind of trivial
> cut-and-paste thing.
>
> (Junio cc'd, I think he had something more complicated in mind)
You have misread me this time.
I think the minimalistic "paste this line to your 'git pull' command line
and expect to get history leading to this commit" like you did in your
patch would be the solution that is the least painful and still useful,
which is an important criterion for wide adoption.
> Now, admittedly it would be *even nicer* if this gpg-signed block was
> instead uploaded as a signed tag automatically, and "git pull" would
> notice such a signed tag (tagname the same as the branch name + date
> or something) and would download and verify the tag as I pull. Then I
> wouldn't even need to actually do the cut-and-paste at all. But this
> is the *really* simple approach that gets up 95% of the way there.
I however have a small trouble with "lieutenants use signed tags in order
to prove who they are to Linus", depending on the details.
It certainly lets you run "git tag --verify" after you pulled and will
give you assurance that you pulled the right thing from the right person,
but what do you plan to do to the tag from your lieutenants after you
fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)
and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on
average. Will these tags be pushed out to your public history?
On one hand, we (not just you but the consumers of "Linus kernel") can
consider these tags are of ephemeral nature. Once they are used for _you_
to verify the authenticity, they are not needed anymore. The consumers of
"Linus kernel" by definition trusts what you publish, so as long as they
have a way to verify the tip commit you push out, they _should_ be happy.
If you take this stance, you would not push these tags out so that you do
not have to contaminate the tags namespace with them, and you might even
choose to discard them once you pulled and verified the lieutenants' tips
to avoid contamination of your own refs namespace.
On the other hand, the consumers of "Linus kernel" may want to say that
they trust your tree and your tags because they can verify them with your
GPG signature, but also they can independently verify the lieutenants'
trees you pulled from are genuine. Keeping signed tags and publishing them
is one way to make it possible, but 400 extra tags in 3 months feels like
an approach with too much downside (i.e. noise) for that benefit.
On Git mailing list, we have been toying with a couple of ideas. The
simplest one (cooking in next) is to allow committers to add gpg signature
in an additional header of the commit objects. "git show" and friends are
taught how to verify these signatures when asked.
This might have a potential downside on the lieutenants' workflow; after
integrating the work by their sub-lieutenants and by themselves, they
would test and review the result to convince themselves that it is worth
asking you to pull, and then they have to either
(1) "commit --amend --gpg-signature" the tip; or
(2) "commit --allow-empty --gpg-signature" to add an empty commit
whose sole purpose is to hold the signature (and avoid amending
the tip)
before pushing it out, asking you to pull.
An alternative we have discussed was to store gpg signature for the commit
("push certificate") somewhere in notes tree and push that out, certifying
that the commit indeed came from the pusher, but that would:
(1) require upstreams to fetch (and possibly suffer from merge conflicts
in notes tree) push certificate whenever they pull from their
lieutenants; and
(2) require downstreams to also fetch the notes tree for "push
certificates" (especially when the central repository is shared among
multiple people) before adding their own signature and then push it
back (and possiblly suffer from "non-fast-forward" in notes tree).
both of which are downsides coming from "notes" being not a very good
match for what these signatures are trying to achieve.
Namely, the current "notes" mechanism is designed to keep track of history
of changes made to notes attached to commits, but for the signature
application, we do not care about the order that signatures came to two
separate commits. "Non-fast-forward" conflicts while pushing, or having to
fetch and merge before adding one's own signature, are unwanted burden
imposed only by choosing to use "notes" for storing and conveying the
signature.
Also the "notes" approach would end up mixing "push certificates" for
different branches (this won't be an issue in your repository where there
is only one branch) into a single "notes" tree. We would want to use
something that behaves more like the "auto-following" semantics of tag
objects. You would want to fetch only signatures that are attached to the
commits you are fetching. Use of signed tags, or commit objects that can
be signed in-place, have this property, but storing signature in notes
tree does not give it to us.
I think further discussions on this should continue on the git mailing
list.
^ permalink raw reply
* [PATCHv2] Compile fix for MSVC
From: Vincent van Ravesteijn @ 2011-10-31 19:12 UTC (permalink / raw)
To: git; +Cc: kusmabite, ramsay, msysgit, gitster
This is a re-roll of the patch series sent to the list
on 21-10-2011.
This time the lines are not wrapped and the commit messages
are updated with changes from me and Junio.
[PATCH 1/3] Compile fix for MSVC: Do not include sys/resources.h
[PATCH 2/3] Compile fix for MSVC: Include <io.h>
[PATCH 3/3] MSVC: Remove unneeded header stubs
^ permalink raw reply
* [PATCH 1/3] Compile fix for MSVC: Do not include sys/resources.h
From: Vincent van Ravesteijn @ 2011-10-31 19:12 UTC (permalink / raw)
To: git; +Cc: kusmabite, ramsay, msysgit, gitster, Vincent van Ravesteijn
In-Reply-To: <1320088364-25916-1-git-send-email-vfr@lyx.org>
Do not include header files when compiling with MSVC that do not
exist and which are also not included when compiling with MINGW.
A direct consequence is that git can be compiled again with MSVC
because the missing "sys/resources.h" is no longer included.
Instead of current
#ifndef mingw32 is the only one that is strange
... everything for systems that is not strange ...
#else
... include mingw specific tweaks ...
#endif
#ifdef msvc is also strange
... include msvc specific tweaks ...
#endif
it turns things around and says what it wants to achieve in a more direct
way, i.e.
#if mingw32
#include "compat/mingw.h"
#elif msvc
#include "compat/msvc.h"
#else
... all the others ...
#endif
which makes it look simpler.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
---
git-compat-util.h | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5ef8ff7..53186da 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -116,7 +116,12 @@
#else
#include <poll.h>
#endif
-#ifndef __MINGW32__
+#if defined(__MINGW32__)
+/* pull in Windows compatibility stuff */
+#include "compat/mingw.h"
+#elif defined(_MSC_VER)
+#include "compat/msvc.h"
+#else
#include <sys/wait.h>
#include <sys/resource.h>
#include <sys/socket.h>
@@ -145,12 +150,6 @@
#include <grp.h>
#define _ALL_SOURCE 1
#endif
-#else /* __MINGW32__ */
-/* pull in Windows compatibility stuff */
-#include "compat/mingw.h"
-#endif /* __MINGW32__ */
-#ifdef _MSC_VER
-#include "compat/msvc.h"
#endif
#ifndef NO_LIBGEN_H
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/3] Compile fix for MSVC: Include <io.h>
From: Vincent van Ravesteijn @ 2011-10-31 19:12 UTC (permalink / raw)
To: git; +Cc: kusmabite, ramsay, msysgit, gitster, Vincent van Ravesteijn
In-Reply-To: <1320088364-25916-1-git-send-email-vfr@lyx.org>
This include is needed for _commit(..) which is used in mingw.h.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
compat/msvc.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/compat/msvc.h b/compat/msvc.h
index a33b01c..aa4b563 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -4,6 +4,7 @@
#include <direct.h>
#include <process.h>
#include <malloc.h>
+#include <io.h>
/* porting function */
#define inline __inline
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/3] MSVC: Remove unneeded header stubs
From: Vincent van Ravesteijn @ 2011-10-31 19:12 UTC (permalink / raw)
To: git; +Cc: kusmabite, ramsay, msysgit, gitster, Vincent van Ravesteijn
In-Reply-To: <1320088364-25916-1-git-send-email-vfr@lyx.org>
These headers are no longer needed since they are no longer
unnecessarily included in git-compat-util.h.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
compat/vcbuild/include/arpa/inet.h | 1 -
compat/vcbuild/include/grp.h | 1 -
compat/vcbuild/include/inttypes.h | 1 -
compat/vcbuild/include/netdb.h | 1 -
compat/vcbuild/include/netinet/in.h | 1 -
compat/vcbuild/include/netinet/tcp.h | 1 -
compat/vcbuild/include/pwd.h | 1 -
compat/vcbuild/include/sys/ioctl.h | 1 -
compat/vcbuild/include/sys/select.h | 1 -
compat/vcbuild/include/sys/socket.h | 1 -
compat/vcbuild/include/sys/wait.h | 1 -
compat/vcbuild/include/termios.h | 1 -
12 files changed, 0 insertions(+), 12 deletions(-)
delete mode 100644 compat/vcbuild/include/arpa/inet.h
delete mode 100644 compat/vcbuild/include/grp.h
delete mode 100644 compat/vcbuild/include/inttypes.h
delete mode 100644 compat/vcbuild/include/netdb.h
delete mode 100644 compat/vcbuild/include/netinet/in.h
delete mode 100644 compat/vcbuild/include/netinet/tcp.h
delete mode 100644 compat/vcbuild/include/pwd.h
delete mode 100644 compat/vcbuild/include/sys/ioctl.h
delete mode 100644 compat/vcbuild/include/sys/select.h
delete mode 100644 compat/vcbuild/include/sys/socket.h
delete mode 100644 compat/vcbuild/include/sys/wait.h
delete mode 100644 compat/vcbuild/include/termios.h
diff --git a/compat/vcbuild/include/arpa/inet.h b/compat/vcbuild/include/arpa/inet.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/arpa/inet.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/grp.h b/compat/vcbuild/include/grp.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/grp.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/inttypes.h b/compat/vcbuild/include/inttypes.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/inttypes.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netdb.h b/compat/vcbuild/include/netdb.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netdb.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/in.h b/compat/vcbuild/include/netinet/in.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netinet/in.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/tcp.h b/compat/vcbuild/include/netinet/tcp.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netinet/tcp.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/pwd.h b/compat/vcbuild/include/pwd.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/pwd.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/ioctl.h b/compat/vcbuild/include/sys/ioctl.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/ioctl.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/select.h b/compat/vcbuild/include/sys/select.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/select.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/socket.h b/compat/vcbuild/include/sys/socket.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/socket.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/wait.h b/compat/vcbuild/include/sys/wait.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/wait.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/termios.h b/compat/vcbuild/include/termios.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/termios.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
--
1.7.4.1
^ permalink raw reply related
* Reference has invalid format: check maybe a bit to harsh?
From: Peter Oberndorfer @ 2011-10-31 19:14 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty
Hi,
i am using the next branch for testing and i noticed the following:
about any git command i execute in a certain repo dies with
fatal: Reference has invalid format:
'refs/patches/obd_development/blah:_various_improvements_remote_debugging'
This is probably caused by
dce4bab6567de7c458b334e029e3dedcab5f2648 add_ref(): verify that the refname is
formatted correctly
The invalid refs(about 30, loose and packed) containing a ':' were created by
stgit a long time ago(Dec 2006)
Personally i do not care too much, i patched my git to not die at this point
but to only display a error.
-> The invalid refs are not accessible, but the rest of the repo still works.
But i'm just wondering if dieing when seeing a single invalid ref might be a
bit too harsh since no git tools can be used anymore on this repo at all.
Small side note:
It seems t1402-check-ref-format.sh contains not test
for the invalid ref char ':' yet.
(i do not know if it is tested somewhere else...)
Thanks,
Greetings Peter
^ permalink raw reply
* Re: Reference has invalid format: check maybe a bit to harsh?
From: Junio C Hamano @ 2011-10-31 19:54 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Michael Haggerty
In-Reply-To: <60007404.ge1WXNp2Qn@soybean>
Peter Oberndorfer <kumbayo84@arcor.de> writes:
> The invalid refs(about 30, loose and packed) containing a ':' were created by
> stgit a long time ago(Dec 2006)
I think even back then colon was one of the forbidden letters in a
refname. Of course, it is entirely possible that broken third-party tools
may have created such file that is not a ref in .git/refs hierarchy by
hand, and we may not be carefully rejecting such broken refs for a long
time.
... Goes and asks "git blame" ...
03feddd (git-check-ref-format: reject funny ref names., 2005-10-13)
started disallowing control characters and other characters that are used
for range operators and the separator between LHS and RHS of refspecs,
further tightened by 6828399 (Forbid pattern maching characters in
refnames., 2005-12-15).
> But i'm just wondering if dieing when seeing a single invalid ref might be a
> bit too harsh since no git tools can be used anymore on this repo at all.
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
I think we would be in a good shape.
^ permalink raw reply
* Re: sparse checkout using exclusions
From: Eric Raible @ 2011-10-31 20:16 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git@vger.kernel.org
In-Reply-To: <CALkWK0=X4O9jBbx_ZDXbtnDCmTb9fHbm13Z-pqTNBooA0Z=c0g@mail.gmail.com>
On 10/28/2011 10:46 PM, Ramkumar Ramachandra wrote:
>
> This issue was fixed in 5e821231 (git-read-tree.txt: update sparse
> checkout examples, 2011-09-26).
>
> Cheers.
>
> -- Ram
git tag -l --contains => v1.7.8-rc0
I'm running 1.7.7.1.msysgit.0, so I don't have it yet.
And neither do any of the online man pages I could find.
But I'm happy that it's fixed. And the commit message is
better than what I would have come up with.
Thanks - Eric
^ permalink raw reply
* Re: Reference has invalid format: check maybe a bit to harsh?
From: Junio C Hamano @ 2011-10-31 20:19 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Peter Oberndorfer, git
In-Reply-To: <7vty6pos20.fsf@alter.siamese.dyndns.org>
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?
^ permalink raw reply
* Re: Out of memory error with git rebase
From: Junio C Hamano @ 2011-10-31 20:21 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83r51ta1rq.fsf@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> From the documentation I can't figure out any reason why one
> wouldn't always want to use -m. Why is it not the default? I
> think it's pretty much impossible for ordinary users to figure out
> that they need -m in a situation like this.
Because most people do not have too large binary blobs in the history, and
at least when "rebase" was originally written, merge-based rebasing was
way slower than patch-based one.
^ permalink raw reply
* Re: jc/lookup-object-hash from pu crashes on ARM
From: Junio C Hamano @ 2011-10-31 20:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111031125648.GA1757@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Even better could be to start aligning the hashes we pass around,
> using something like this:
>
> union object_hash {
> unsigned char sha1[20];
> uint32_t chunk[5];
> };
>
> which could speed up functions like hashcpy(), hashcmp(), and
> hasheq(). But it's probably not worth the fuss.
The "flag" field in struct ref_list should be moved down to assure
alignment.
struct ref_list {
struct ref_list *next;
unsigned char flag; /* ISSYMREF? ISPACKED? */
unsigned char sha1[20];
unsigned char peeled[20];
char name[FLEX_ARRAY];
};
I am very tempted to take that "union" approach (modulo that I would call
that an "object_name") in the longer run, though.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-10-31 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton
In-Reply-To: <7vy5w1ow90.fsf@alter.siamese.dyndns.org>
(removing linux-ide and linux-kernel)
On Mon, Oct 31, 2011 at 11:23:55AM -0700, Junio C Hamano wrote:
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine. Keeping signed tags and publishing them
> is one way to make it possible, but 400 extra tags in 3 months feels like
> an approach with too much downside (i.e. noise) for that benefit.
I wouldn't put it as "we don't trust Linus's tree", because it's not
true. In general, we do trust Linus's tree. On the other hand, it's
useful if the proof which was submitted at the time of the push could
be verified by third parties.
Suppose the project wasn't Linus, but some other project, say, a
hypothetical Desktop system called Troll3. Let's assume that it's run
by a sole dictator, S. Crew Powerusers, who blindly assumes that any
tree on github is secure, and is confident he or she can detect social
engineering attacks caused by a bad guy grabbing a developer's SSH key
used to push to github, and who can fake a pull request to Linus that
looks real but is really originated by the bad guy. Let's assume
further that the pull request has a signed tag which could be used to
detect such forgeries, but because Mr. Powerusers can't be bothered to
check the tag, because he can't figure out how to update his GPG
keyring and besides, he hates crypto stuff --- and the bad guys know
this, and are good (Kevin Mitnick or better) at social engineering
attacks.
In this sort of scenario, it's useful if *other* people could
independently verify the Troll3 git tree via the crypto signatures,
even though the central maintainer couldn't be bothered to check the
crypto signatures.
Here's an idea.... what if the "signed push" information could be
embedded into the merge commit's description? That is, the
information could sent via a signed git tag, or some other mechanism,
but then part of the git merge would incorporate the GPG signature
into the merge commit's description field (and we could always create
a merge commit so there's a place to put the digital siganture). That
way, it's mostly out of the way, but it's in a well-defined place
where it will always easy to have a third party independently verify
the source of a set of commits in the git tree.
The problem with notes and tags is that they have to be pushed
separately, and might get lost; where as if they are stored in the
merge commit's description, they will always be there.
- Ted
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-10-31 20:34 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, kusmabite, ramsay, msysgit, gitster
In-Reply-To: <1320088364-25916-1-git-send-email-vfr@lyx.org>
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.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 20:53 UTC (permalink / raw)
To: Ted Ts'o
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton
In-Reply-To: <20111031203059.GJ16825@thunk.org>
Ted Ts'o <tytso@mit.edu> writes:
> Suppose the project wasn't Linus, but some other project, say, a
> ...
> this, and are good (Kevin Mitnick or better) at social engineering
> attacks.
>
> In this sort of scenario, it's useful if *other* people could
> independently verify the Troll3 git tree via the crypto signatures,
> even though the central maintainer couldn't be bothered to check the
> crypto signatures.
I think we are in total agreement here ;-)
> Here's an idea.... what if the "signed push" information could be
> embedded into the merge commit's description? That is, the
> information could sent via a signed git tag, or some other mechanism,...
I think you described what the signed-commit series that is cooking in
'next' is about way better than I have done so far ;-)
The contributors sign the tips of their histories (which can independently
be validated), the integrator pulls and can choose to bother or not to
bother the tips s/he obtains, and the integrator signs his/her tip before
s/he pushes the integration result out for general consumption.
> ...
> The problem with notes and tags is that they have to be pushed
> separately, and might get lost; where as if they are stored in the
> merge commit's description, they will always be there.
Exactly.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 22:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: git, Linus Torvalds, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <20111031084048.GA11807__21610.4542407722$1320051469$gmane$org@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> That said, even the "BEGIN PGP SIGNED MESSAGE" things are a massive
>> pain in the butt. We need to automate this some sane way, both for
>> the sender and for the recipient.
>
> The most practical form would be if Git supported such oneliner pull
> requests:
>
> git pull git://foo.com bar.branch \
> --pull-sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \
> --gpg-by: "Ingo Molnar <mingo@kernel.org>" \
> --gpg-sig: 8a6f134afd1d212fe21345
>
> maintainers could just paste them into a shell and it would abort if
> it's not trusted. The maintainer verifies the visible, 'Ingo Molnar'
> bit. The 8a6f134afd1d212fe21345 is a signed-by-Ingo-Molnar version of
> this content:
>
> git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4
As a command line syntax, I think the new "--flag"s should all come
before non flag options to the "pull" subcommand, i.e.
git pull --sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \
--gpg-by "Ingo Molnar <mingo@kernel.org>" \
git://foo.com bar.branch
I do not understand what you meant by that "8a6f13...". When I run
$ echo "git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4" |
gpg -sa
I would get about 20 lines of solid gibberish, nothing close to that
clean and concise 20-or-so character sequence.
In any case, I do not think that "this site, that branch" information is
essential for the purpose of validation. I think I saw Linus responding to
a pull request saying "Your pull request says master but I found nothing
there; I assume you meant for-linus branch" or something similar, and as
long as that matches the expectation of the contributor, especially if you
specify "I want you to get _this_ commit" in your request-pull message, it
should not matter how/where Linus gets the history leading to that commit.
As "git-pull" is still a scripted Porcelain, interested people should be
able to experiment this idea by doing something like this:
1. The requestor signs the tip commit to be fetched with the version of
git from the "next" branch, i.e. "git commit -S", and pushes it to his
publishing location;
2. Around line 207, "git pull" spawns "git fetch", stops if dry-run. At
that point, you can:
- parse FETCH_HEAD and verify the SHA-1 matches what you got from the
command line;
- run "git show -s --show-signature FETCH_HEAD" (again, use the
version of git from the "next" branch) to let GPG parse the
signature.
and stop if either test fails.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <7vy5w1ow90.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 11:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It certainly lets you run "git tag --verify" after you pulled and will
> give you assurance that you pulled the right thing from the right person,
> but what do you plan to do to the tag from your lieutenants after you
> fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)
> and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on
> average. Will these tags be pushed out to your public history?
No, you misunderstand.
I can do that kind of "crazy manual check of a tag" today. And it's
too painful to be useful in the long run (or even the short run - I'd
much prefer the pgp signature in the email which is easier to check
and more visible anyway). Fetching a tag by name and saving it as a
tag is indeed pointless.
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).
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com>
On 10/31/2011 03:18 PM, Linus Torvalds wrote:
> On Mon, Oct 31, 2011 at 11:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> It certainly lets you run "git tag --verify" after you pulled and will
>> give you assurance that you pulled the right thing from the right person,
>> but what do you plan to do to the tag from your lieutenants after you
>> fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)
>> and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on
>> average. Will these tags be pushed out to your public history?
>
> No, you misunderstand.
>
> I can do that kind of "crazy manual check of a tag" today. And it's
> too painful to be useful in the long run (or even the short run - I'd
> much prefer the pgp signature in the email which is easier to check
> and more visible anyway). Fetching a tag by name and saving it as a
> tag is indeed pointless.
>
> 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).
>
Perhaps we should introduce the notion of a "private tag" or something
along those lines? (I guess that would still have to be possible to
push it, but not pull it by default...)
-hpa
^ permalink raw reply
* [PATCH v2] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-10-31 22:21 UTC (permalink / raw)
To: gitster; +Cc: git
Watching patches serially it can be difficult to get an overview of how
a pervasive change is distributed through-out different modules. Thus;
Extract snapshots of the files that have changed between two revisions
into temporary directories and launch a graphical tool to show the diff
between them.
Use existing functionality in git-diff to get the files themselves, and
git-difftool to launch the diff viewer.
Based on a script called 'git-diffc' by Nitin Gupta.
Signed-off-by: Roland Kaufmann <rlndkfmn+git@gmail.com>
---
Following issues are addressed in this revised patch:
* Test explicitly for errors. Use `die` to show messages and exit.
However, I assume that git, mkdir and cp are capable of producing
sensible messages themselves, and in those cases just exit.
* Temporary directory is created using mktemp using the -d option which
is usable on most modern platforms. On more crippled platforms, I
revert to using Perl, since it has the best chance of being available
(if not, then I reckon there are larger parts of Git that won't work).
I have tested this approach with msysGit. Unfortunately, I don't have
testing capabilities for Solaris, HP-UX or AIX.
* Snapshots are taken using only one invocation of `git diff`; no
separate listing of files processed.
* If there are no files in either snapshots (i.e. you are comparing two
empty directories), then don't launch the diff-viewer. This takes
care of many cases where it is invoked with options that are really
not applicable.
* Scripts and manpage are put in contrib/ to gather feedback about the
usefulness and design issues before I make a go at adding it as an
option to git-diff itself. (README tells how to install since it is
not in the main Makefile).
contrib/dirdiff/README | 10 +++++
contrib/dirdiff/git-dirdiff--helper.sh | 37 ++++++++++++++++++++
contrib/dirdiff/git-dirdiff.sh | 58 ++++++++++++++++++++++++++++++++
contrib/dirdiff/git-dirdiff.txt | 55 ++++++++++++++++++++++++++++++
4 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 contrib/dirdiff/README
create mode 100755 contrib/dirdiff/git-dirdiff--helper.sh
create mode 100755 contrib/dirdiff/git-dirdiff.sh
create mode 100644 contrib/dirdiff/git-dirdiff.txt
diff --git a/contrib/dirdiff/README b/contrib/dirdiff/README
new file mode 100644
index 0000000..d06461a
--- /dev/null
+++ b/contrib/dirdiff/README
@@ -0,0 +1,10 @@
+# install on GNU, BSD:
+for f in "" "--helper"; do
+ b=git-dirdiff$f
+ sudo install -m 0755 contrib/dirdiff/$b.sh $(git --exec-path)/$b
+done
+
+# install on Windows
+for /f %a in ('git --exec-path') do set GIT_PATH=%a
+set GIT_PATH=%GIT_PATH:/=\%
+for %a in ("" "--helper") do copy contrib\dirdiff\git-dirdiff%~a.sh "%GIT_PATH%\%~a" /y
diff --git a/contrib/dirdiff/git-dirdiff--helper.sh b/contrib/dirdiff/git-dirdiff--helper.sh
new file mode 100755
index 0000000..8ff0124
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff--helper.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Accumulate files in a changeset into a pre-defined directory.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# check that we are called by git-dirdiff
+test -z "$__GIT_DIFF_DIR" &&
+ die Error: Do not call $(basename "$0") directly
+
+# what is the directory name of the file that has changed
+RELDIR=$(dirname "$1") ||
+ exit $?
+
+# don't attempt to copy new or removed files
+if test "$2" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/old/$RELDIR" ||
+ exit $?
+ cp "$2" "$__GIT_DIFF_DIR/old/$1" ||
+ exit $?
+fi
+if test "$5" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/new/$RELDIR" ||
+ exit $?
+ cp "$5" "$__GIT_DIFF_DIR/new/$1" ||
+ exit $?
+fi
diff --git a/contrib/dirdiff/git-dirdiff.sh b/contrib/dirdiff/git-dirdiff.sh
new file mode 100755
index 0000000..faf2f00
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+#
+# Display differences between two commits with a directory comparison.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# TMPDIR points to the designated space for temporary files; only if
+# not set use /tmp (MSYS even mounts %TEMP% to there)
+test -z "$TMPDIR" && TMPDIR=/tmp
+
+# create a temporary directory to hold snapshots of changed files
+# note that SunOS and MSYS do not have mktemp (but GnuWin32 has!)
+case $(uname -s) in
+MINGW* | SunOS* | HP-UX* | AIX*)
+ __GIT_DIFF_DIR=$(perl -e "use File::Temp qw/tempdir/; print tempdir(\"git-dirdiff.XXXXXX\", DIR=>\"$TMPDIR\")")
+ ;;
+*)
+ __GIT_DIFF_DIR=$(mktemp -d "$TMPDIR/git-dirdiff.XXXXXX")
+ ;;
+esac
+test -d "$__GIT_DIFF_DIR" -a -w "$__GIT_DIFF_DIR" ||
+ die Error: Could not create a temporary subdir in $TMPDIR
+
+# cleanup after we're done
+trap 'rm -rf $__GIT_DIFF_DIR' 0
+
+# export this variable so that scripts called indirectly can access it
+export __GIT_DIFF_DIR
+
+# let the helper script accumulate all changed files into the temporary
+# directory letting 'git diff' do all the heavy lifting
+GIT_EXTERNAL_DIFF=git-dirdiff--helper git --no-pager diff "$@" ||
+ exit $?
+
+# if there are only hidden files, then the first argument will be the
+# wildcard, and $2 and $3 will be the special directory files . and ..
+isempty () {
+ set - $1/* $1/.*
+ test ! \( -f "$1" -o -f "$4" \)
+}
+
+# no-op if no files were changed
+isempty "$__GIT_DIFF_DIR/old" && isempty "$__GIT_DIFF_DIR/new" &&
+ exit 0
+
+# run original diff program, reckoning it will understand directories
+# modes and shas does not apply to the root directories so submit dummy
+# values for those, hoping that the diff tool does not use them.
+git-difftool--helper - "$__GIT_DIFF_DIR/old" deadbeef 0755 "$__GIT_DIFF_DIR/new" babeface 0755 ||
+ exit $?
diff --git a/contrib/dirdiff/git-dirdiff.txt b/contrib/dirdiff/git-dirdiff.txt
new file mode 100644
index 0000000..bdd2581
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.txt
@@ -0,0 +1,55 @@
+git-dirdiff(1)
+==============
+
+NAME
+----
+git-dirdiff - Show changes using directory compare
+
+SYNOPSIS
+--------
+[verse]
+'git dirdiff' [<options>] [<commit> [<commit>]] [--] [<path>...]
+
+DESCRIPTION
+-----------
+'git dirdiff' is a git command that allows you to compare revisions
+as a difference between two directories. 'git dirdiff' is a frontend
+to linkgit:git-diff[1].
+
+OPTIONS
+-------
+See linkgit:git-diff[1] for the list of supported options.
+
+CONFIG VARIABLES
+----------------
+'git dirdiff' uses the same config variables as linkgit:git-difftool[1]
+to determine which difftool should be used.
+
+TEMPORARY FILES
+---------------
+'git dirdiff' creates a directory with 'mktemp' to hold snapshots of the
+files which are different in the two revisions. This directory is removed
+when the diff viewer terminates.
+
+NOTES
+-----
+The diff viewer must support being passed directories instead of files
+as its arguments.
++
+Files that are not put under version control are not included when
+viewing the difference between a revision and the working directory.
+
+SEE ALSO
+--------
+linkgit:git-diff[1]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-difftool[1]::
+ Show changes using common diff tools
+
+linkgit:git-config[1]::
+ Get and set repository or global options
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.7.1
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF1F40.3030907@zytor.com>
On Mon, Oct 31, 2011 at 3:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Perhaps we should introduce the notion of a "private tag" or something
> along those lines? (I guess that would still have to be possible to
> push it, but not pull it by default...)
All tags are private by default.
We actually *only* fetch tags if somebody explicitly asks for them
(--tags), or when fetching from a named remote (and even then it will
only fetch tags that point to objects you fetched by default iirc -
you have to mark the remote specially to get *all* tags).
But if you do the normal "git pull git://git.kernel.org/name/of/repo"
- which is how things happen as a result of a pull request - you won't
get tags at all - you have to ask for them by name or use "--tags" to
get them all.
Linus
^ 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