* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: netroby @ 2011-10-31 9:16 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mail List, Tomas Carnecky, Jeff King
In-Reply-To: <20111031090717.GA24978@elie.hsd1.il.comcast.net>
the example :
i want to clone the freebsd and linux kernel git repo , to view their
source code.
git://github.com/freebsd/freebsd.git
git://github.com/torvalds/linux.git
they are big project, so they are huge.
thanks for your tips. it will let me have a try .
I am current using 256K Adsl , so it is very not stable when clone in progress.
netroby
----------------------------------
http://www.netroby.com
On Mon, Oct 31, 2011 at 17:07, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> netroby wrote:
>
>> Is it possible to let git clone continue last break point.
>> when we git clone very large project from the web, we may face some
>> interupt, then we must clone it from zero .
>
> You might find [1] useful as a stopgap (thanks, Tomas!).
>
> Something like Jeff's "priming the well with a server-specified
> bundle" proposal[2] might be a good way to make the same trick
> transparent to clients in the future.
>
> Even with that, later fetches, which grab a pack generated on the fly
> to only contain the objects not already fetched, are generally not
> resumable. Overcoming that would presumably require larger protocol
> changes, and I don't know of anyone working on it. (My workaround
> when in a setup where this mattered was to use the old-fashioned
> "dumb" http protocol. It worked fine.)
>
> Hope that helps,
> Jonathan
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/181380
> [2] http://thread.gmane.org/gmane.comp.version-control.git/164569/focus=164701
> http://thread.gmane.org/gmane.comp.version-control.git/168906/focus=168912
>
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-10-31 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vty6rrow8.fsf@alter.siamese.dyndns.org>
On 2011-10-30 07:09, Junio C Hamano wrote:
> I do not think any of our scripted Porcelains use "set -e"; rather
> they try to catch errors and produce messages that are more
> appropriate for specific error sites.
git-dirdiff being a wrapper script, I reasoned that the underlaying
command would already have printed a sufficient error message, so what
was left was just to exit. But you're right in that some of the commands
will not give sufficient context. I'll put in some more detailed error
handling.
> I do not think any of our scripted Porcelains use "mktemp"
> especially "mktemp -d". How portable is it?
Even if it is not part of Posix, I reckon since it is a part of the
coreutils, it is available in most GNU userlands, inclusive GnuWin32.
I don't have any live BSD systems available, but based on the man pages
it seems to be available there too, albeit with some different options.
--tmpdir seems to be more of a problem in than respect than -d. I'll see
if I can find a set of options that are digestable to most platforms.
I think it is unfortunate to use the current directory as scratch space;
it can be a network disk, or even read-only. mktemp can in contrast make
a directory in a place which is not spilled to disk.
> It is not clear to me why you need to grab the list of paths in toc
> and iterate over them one by one. IOW, why isn't this sufficient?
This design decision was probably appropriate in an earlier iteration,
but as you point out, it is indeed superfluous now! I apologize for not
realizing that myself.
> suspect is true), we would probably want to make it an option to
> "git diff" itself, and not a separate git subcommand like "dirdiff".
> I can see
Although being an able *user* of Git, I am not (yet) familiar enough
with the codebase to have a patch ready for `git diff` itself. It would
certainly require more rigorous testing.
> "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`?
> 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`.
> For example, how well does this approach work with -M/-C (I do not
> think it would do anything useful, but I haven't thought things
> through). It would be nice if we gave the hint to the external
As of now, files that are moved will turn up a different places in the
tree without any annotations, and off the top of my head I don't see any
obvious way to propagate such hints. If the diff tool is sophisticated
can probably use the same heuristics as Git currently does, but I am
unaware of any that is able to do that yet.
> I wouldn't mind carrying a polished version of this in contrib/ for
> a cycle or two in order to let people try it out and get kinks out of
> its design.
I would appreciate that! I'll submit a reworked proposal taking you
comments into account. It may take a few days due to unrelated
engagements, though.
--
Roland.
^ permalink raw reply
* Re: Out of memory error with git rebase
From: Hannu Koivisto @ 2011-10-31 10:33 UTC (permalink / raw)
To: git
In-Reply-To: <4EA7E710.1020006@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Am 26.10.2011 11:21, schrieb Hannu Koivisto:
>> If 'git rebase origin/master' dies with an out of memory error
>> (probably due to a few of large binary files in the repository, the
>
> Try 'git rebase -m origin/master'. Without -m, rebase uses
> format-patch+am, i.e., assuming there are changes to the binary files
> that are to be rebased, a binary patch file would have to be generated
> and applied later. This is very likely where git bails out.
Thanks, -m seems to help, even though the large binary files are
not touched by the rebased commits (instead, they are touched by
the commits on top of which I'm rebasing).
>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.
--
Hannu
^ permalink raw reply
* [PATCH] t7511: avoid use of reserved filename on Windows.
From: Pat Thoyts @ 2011-10-31 11:44 UTC (permalink / raw)
To: "Git; +Cc: "msysGit
PRN is a special filename on Windows to send data to the printer. As
this is generated during test 2 - use an alternate prefix.
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: New Feature wanted: Is it possible to let git clone continue last break point?
From: Michael Schubert @ 2011-10-31 12:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: netroby, Git Mail List
In-Reply-To: <m3obwx4j7s.fsf@localhost.localdomain>
On 10/31/2011 10:14 AM, Jakub Narebski wrote:
> netroby <hufeng1987@gmail.com> writes:
>
>> Is it possible to let git clone continue last break point.
>> when we git clone very large project from the web, we may face some
>> interupt, then we must clone it from zero .
>>
>> it is bad feeling for low connection speed users.
>>
>> please help us out.
>>
>> we need git clone continue last break point
>
> Resuming "git clone" is not currently possible in Git, and it would be
> difficult to add such feature to Git; there were several attempts and
> neither succeeded.
>
> What you can do is generate a starter bundle out of your repository
> (using "git bundle"), and serve this file via HTTP / FTP / BitTorrent,
> i.e. some resumable transport. Then you "git clone <bundle file>",
> fix up configuration, and fetch the rest since bundle creation.
There's also a "git bundler service":
http://comments.gmane.org/gmane.comp.version-control.git/181380
^ permalink raw reply
* jc/lookup-object-hash from pu crashes on ARM
From: Jonathan Nieder @ 2011-10-31 12:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzkglrnmc.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/lookup-object-hash (2011-08-11) 6 commits
> - object hash: replace linear probing with 4-way cuckoo hashing
> - object hash: we know the table size is a power of two
> - object hash: next_size() helper for readability
> - pack-objects --count-only
> - object.c: remove duplicated code for object hashing
> - object.c: code movement for readability
The code from the tip commit crashes on ARM for me (and presumably
would also misbehave on other platforms that care about alignment):
$ git branch -av
Bus error
The following might avoid that:
static inline unsigned int H(const unsigned char *sha1, int ix)
{
unsigned int hash;
memcpy(&hash, sha1 + ix * sizeof(unsigned int),
sizeof(unsigned int));
return hash % (obj_hash_size - 1);
}
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.
Call chain:
cmd_branch -> print_ref_list -> for_each_rawref ->
do_for_each_ref -> do_one_ref(entry=0x175508) ->
append_ref(sha1=0x175509) ->
lookup_commit_reference_gently -> parse_object ->
parse_object_buffer -> lookup_commit -> lookup_object
This is from testing pu (ed7c265e), in case that's relevant. Aside
from that, the topic looks neat. :)
^ permalink raw reply
* 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
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