On do, 2014-08-21 at 19:57 -0700, Howard Chu wrote:
I maintain multiple copies of the same repo because I keep each one checked
out to different branch/rev levels. It would be nice if, similar to clone
--reference, we could also use git fetch --reference to reference a local
repo
when
IMPORTANT OFFER!!!
I, Liliane authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Liliane_Bettencourt
I write to you because I intend to give to you a portion of my
Net-worth which I have been banking. I want to cede it out as gift
hoping it would be of help to you and
I tried sending this mail to the git for humans mailing list but got
no response, so I'll try here.
I've been running the git filter-branch described on this page:
http://stackoverflow.com/questions/14759345/how-to-split-a-git-repository-and-follow-directory-renames.
But the resulting history
On 08/20/2014 11:47 PM, Ronnie Sahlberg wrote:
[...]
Since we already display broken/unresolvable refs, I think the most
consistent path is to also allow showing the refs broken/illegal-names
too in the list. (when DO_FOR_EACH_INCLUDE_BROKEN is specified)
Of course, an end user could fix this
On Fri, Aug 22, 2014 at 6:21 AM, Jeff King p...@peff.net wrote:
-- 8 --
Subject: teach fast-export an --anonymize option
Sometimes users want to report a bug they experience on
their repository, but they are not at liberty to share the
contents of the repository. It would be useful if they
On Thu, Aug 21, 2014 at 10:39 PM, Matthias Urlichs matth...@urlichs.de wrote:
What I would like to have, instead, is a version of shallow cloning which
cuts off not at a pre-determined depth, but at a given branch (or set of
branches). In other words, given
+-J--K (packaged)
On Aug 22, 2014, at 12:26 AM, Junio C Hamano gits...@pobox.com wrote:
Steffen Prohaska proha...@zib.de writes:
Similar to testing expectations about malloc with GIT_ALLOC_LIMIT (see
commit d41489), it can be useful to test expectations about mmap.
This introduces a new environment
GIT_ALLOC_LIMIT limits xmalloc()'s size, which is of type size_t. Use
ssize_t to store the limit for consistency. The change has no direct
practical impact, because we use GIT_ALLOC_LIMIT to test small sizes.
The cast of size in the call to die() is changed to uintmax_t to match
the format
It is only the path that matters in the decision whether to filter or
not. Clarify this by making path the single argument of
would_convert_to_git().
Signed-off-by: Steffen Prohaska proha...@zib.de
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
Similar to testing expectations about malloc with GIT_ALLOC_LIMIT (see
commit d41489), it can be useful to test expectations about mmap.
This introduces a new environment variable GIT_MMAP_LIMIT to limit the
largest allowed mmap length (in KB). xmmap() is modified to check the
limit. Together
Only changes since PATCH v3: Use ssize_t to store limits.
Steffen Prohaska (4):
convert: Refactor would_convert_to_git() to single arg 'path'
Introduce GIT_MMAP_LIMIT to allow testing expected mmap size
Change GIT_ALLOC_LIMIT check to use ssize_t for consistency
convert: Stream from fd to
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for example if it computes a sha1 for binary data,
like git media. The file size that the previous implementation could
handle was limited
Hi,
Duy Nguyen:
On Thu, Aug 21, 2014 at 10:39 PM, Matthias Urlichs matth...@urlichs.de
wrote:
What I would like to have, instead, is a version of shallow cloning which
cuts off not at a pre-determined depth, but at a given branch (or set of
branches). In other words, given
Keep poll's timeout at -1 when uploadpack.keepalive = 0, instead of
setting it to -1000, since some pedantic old systems (eg HP-UX) and
the gnulib compat/poll will treat only -1 as the valid value for
an infinite timeout.
Signed-off-by: Edward Thomson ethom...@microsoft.com
---
upload-pack.c |
Hi,
Michael Haggerty wrote[1]:
Jonathan Nieder wrote:
The check-ref-format documentation is pretty unclear, but the
intent is that it would be used like
git check-ref-format heads/master
(see the surviving examples in contrib/examples/). That way, it can
enforce the rule (from
On Fri, Aug 22, 2014 at 03:19:11PM +, Edward Thomson wrote:
Keep poll's timeout at -1 when uploadpack.keepalive = 0, instead of
setting it to -1000, since some pedantic old systems (eg HP-UX) and
the gnulib compat/poll will treat only -1 as the valid value for
an infinite timeout.
That
Jeff King p...@peff.net writes:
Since we're now translating the keepalive value, and since there's no
way to set it to 0 (nor would that really have any meaning), I guess
we could switch the internal no keepalive value to 0, and do:
ret = poll(pfd, pollsize, keepalive ? 1000 * keepalive :
Steffen Prohaska proha...@zib.de writes:
+ if (limit == -1) {
+ const char *env = getenv(GIT_MMAP_LIMIT);
+ limit = env ? atoi(env) * 1024 : 0;
... this should then be changed to atol(env), and ...
In the real codepath (not debugging aid like this) we try to avoid
On Fri, Aug 22, 2014 at 08:56:12AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Since we're now translating the keepalive value, and since there's no
way to set it to 0 (nor would that really have any meaning), I guess
we could switch the internal no keepalive value to 0,
On 14-08-19 12:07 PM, Robert Dailey wrote:
On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Thanks for reporting. The remote used is the default remote that git
fetch without further arguments would use:
get_default_remote () {
On Fri, Aug 22, 2014 at 12:03:34PM -0400, Jeff King wrote:
Yeah, I wasn't thinking we would get negative values from the user (we
don't document them at all), but we should probably do something
sensible. Let's just leave it at Ed's patch.
Thanks, both. Apologies for the dumb question: is
Junio C Hamano gits...@pobox.com writes:
Steffen Prohaska proha...@zib.de writes:
+ if (limit == -1) {
+ const char *env = getenv(GIT_MMAP_LIMIT);
+ limit = env ? atoi(env) * 1024 : 0;
... this should then be changed to atol(env), and ...
In the real codepath (not
Junio C Hamano gits...@pobox.com writes:
There are a few gotchas I can certainly use help on, especially from
a smart-http expert ;-).
* pushed-to URL will identify the site and the repository, so
you cannot MITM my push to an experimental server and replay it
against the
Thanks; will replace what has been on 'pu' with this one with some
tweaks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King p...@peff.net writes:
On Fri, Aug 22, 2014 at 03:19:11PM +, Edward Thomson wrote:
Keep poll's timeout at -1 when uploadpack.keepalive = 0, instead of
setting it to -1000, since some pedantic old systems (eg HP-UX) and
the gnulib compat/poll will treat only -1 as the valid value
Junio C Hamano gits...@pobox.com writes:
There is 1000 * wakeup in credential-cache--daemon.c, by the way.
Ah, nevermind. That uses an expiration computed, not some we can
choose to block indefinitely configuration.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of
Edward Thomson ethom...@edwardthomson.com writes:
On Fri, Aug 22, 2014 at 12:03:34PM -0400, Jeff King wrote:
Yeah, I wasn't thinking we would get negative values from the user (we
don't document them at all), but we should probably do something
sensible. Let's just leave it at Ed's patch.
Jonathan Nieder jrnie...@gmail.com writes:
Michael Haggerty wrote[1]:
Jonathan Nieder wrote:
The check-ref-format documentation is pretty unclear, but the
intent is that it would be used like
git check-ref-format heads/master
(see the surviving examples in contrib/examples/). That
From: Jeff King p...@peff.net: Friday, August 22, 2014 12:21 AM
On Thu, Aug 21, 2014 at 06:49:10PM -0400, Jeff King wrote:
The few things I don't anonymize are:
1. ref prefixes. We see the same distribution of refs/heads vs
refs/tags, etc.
2. refs/heads/master is left untouched, for
Junio C Hamano wrote:
implication of which is that the 'at least one slash'
rule was to expect things are 'refs/anything' so there will be at
least one. Even back then, that anything alone had at least one
slash (e.g. heads/master), but the intention was *never* that we
would
Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is
incorrectly set on Mingw git. However, the Makefile variable is not
propagated to the C preprocessor and results in no change. This patch
pushes the definition to the C code and adds a test to validate that
when core.eol as
Fix the broken chain
Reported-By: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t0026-eol-config.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t0026-eol-config.sh b/t/t0026-eol-config.sh
index 43a580a..4806969
Some of the tests were written with the assumption that the native eol would
always be lf. After defining NATIVE_CRLF on MinGW, these tests began failing.
This change will update the tests to also handle a native eol of crlf.
Signed-off-by: Brice Lambson brice...@live.com
Signed-off-by: Torsten
On 21.08.2014 13:35, Petr Stodulka wrote:
Hi guys,
I wanted post you patch here for this bug, but I can't find primary
source of this problem [0], because I don't understand some ideas in the
code.
[…]
Any next ideas/hints or explanation of these functions? I began study
source code and
On 20.08.2014 00:06, Junio C Hamano wrote:
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
and so on. Whenever there is no tag at the tip of the branch, we'd
know there is something wrong.
Who creates
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
and so on. Whenever there is no tag at the tip of the branch, we'd
know
The first round is found at $gmane/255520
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means
An update command in the protocol exchange consists of 40-hex old
object name, SP, 40-hex new object name, SP, and a refname, but the
first instance is further followed by a NUL with feature requests.
The command structure, which has a flex-array member that stores the
refname at the end, was
Ideally, we should have also allowed the first shallow to carry
the feature request trailer, but that is water under the bridge
now. This makes the next step to factor out the queuing of commands
easier to review.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/receive-pack.c | 26
This piece of code reads object names of shallow boundaries, not
old_sha1[], i.e. the current value the ref points at, which is to be
replaced by what is in new_sha1[].
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3
Make a helper function to accept a line of a protocol message and
queue an update command out of the code from read_head_info().
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/receive-pack.c | 50 +-
1 file changed, 29 insertions(+),
20e8b465 (refactor ref status logic for pushing, 2010-01-08)
restructured the code to set status for each ref to be pushed, but
did not quite go far enough. We inspect the status set earlier by
set_refs_status_for_push() and then perform yet another update to
the status of a ref with an otherwise
A run of 'var ? var : ' fed to a long printf string in a deeply
nested block was hard to read. Move it outside the loop and format
it into a strbuf.
As an added bonus, the trick to add agent=agent-name by using
two conditionals is replaced by a more readable version.
Signed-off-by: Junio C
A new helper function ref_update_to_be_sent() decides for each ref
if the update is to be sent based on the status previously set by
set_ref_status_for_push() and also if this is a mirrored push.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 36
We tried to avoid sending one extra byte, NUL and nothing behind it
to signal there is no protocol capabilities being sent, on the first
command packet on the wire, but it just made the code look ugly.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 4 +---
1 file changed, 1
The main loop over remote_refs list inspects the ref status
to see if we need to generate pack data (i.e. a delete-only push
does not need to send any additional data), resets it to expecting
the status report state, and formats the actual update commands
to be sent.
Split the former two out of
The variable counts how many non-deleting command is being sent, but
is only checked with 0-ness to decide if we need to send the pack
data.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c
We use it to make sure that the feature request is sent only once on
the very first request packet (ignoring the shallow line, which
was an unfortunate mistake we cannot retroactively fix with existing
receive-pack already deployed in the field) and we set it to true
with cmds_sent++, not because
Earlier, ffb6d7d5 (Move commit GPG signature verification to
commit.c, 2013-03-31) moved this helper that used to be in pretty.c
(i.e. the output code path) to commit.c for better reusability.
It was a good first step in the right direction, but still suffers a
myopic view that commits will be
Everywhere else we use PKT-LINE to denote the pkt-line formatted
data, but shallow/deepen messages are described with PKT_LINE().
Fix them.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/technical/pack-protocol.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it
We would want to update the interim protocol so that we do not send
the usual update commands when the push certificate feature is in
use, as the same information is in the certificate. Once that
happens, the push-cert packet may become the only protocol command,
but then there is no packet to
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
and so on. Whenever there is
Our signed-tag objects set the standard format used by Git to store
GPG-signed payload (i.e. the payload followed by its detached
signature), and it made sense to have a helper to find the boundary
between the payload and its signature in tag.c back then.
Newer code added later to parse other
In order to prevent a valid push certificate for pushing into an
repository from getting replayed to push to an unrelated one, send a
nonce string from the receive-pack process and have the signer
include it in the push certificate. The original nonce is exported
as GIT_PUSH_CERT_NONCE for the
With the interim protocol, we used to send the update commands even
though we already send a signed copy of the same information when
push certificate is in use. Update the send-pack/receive-pack pair
not to do so.
The notable thing on the receive-pack side is that it makes sure
that there is no
Reusing the GPG signature check helpers we already have, verify
the signature in receive-pack and give the results to the hooks
via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables.
Policy decisions, such as accepting or rejecting a good signature by
a key that is not fully trusted, is
On 22.08.2014 22:33, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:33, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags like:
master_2014_08_21
On 23.08.2014 00:32, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:33, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
So there would be tags
Torsten Bögershausen tbo...@web.de writes:
Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is
incorrectly set on Mingw git. However, the Makefile variable is not
propagated to the C preprocessor and results in no change. This patch
pushes the definition to the C code and
On Fri, Aug 22, 2014 at 10:59 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
There are a few gotchas I can certainly use help on, especially from
a smart-http expert ;-).
* pushed-to URL will identify the site and the repository, so
you cannot MITM
Junio C Hamano wrote:
Michael Haggerty wrote[1]:
Jonathan Nieder wrote:
The check-ref-format documentation is pretty unclear, but the
intent is that it would be used like
git check-ref-format heads/master
(see the surviving examples in contrib/examples/). That way, it can
enforce the
I noticed that git pack-refs --all will pack a top-level ref like
refs/foo, but will not actually prune $GIT_DIR/refs/foo. I do not
see the point in having a policy not to pack refs/foo if --all is
given. But even if we did have such a policy, this seems broken; we
should either pack and prune, or
Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally external
programs should never do this, because they would miss
packed-refs.
That commit claims that packed-refs does not pack
After we have packed all refs, we prune any loose refs that
correspond to what we packed. We do so by first taking a
lock with lock_ref_sha1, and then deleting the loose ref
file.
However, lock_ref_sha1 will refuse to take a lock on any
refs that exist at the top-level of the refs/ directory,
and
We have a global pointer pack_data pointing to the current
pack we have open. Inside end_packfile we have two new
pointers, old_p and new_p. The latter points to pack_data,
and the former points to the new installed version of the
packfile we get when we hand the file off to the regular
sha1_file
When creating a new annotated tag, we sprintf the refname
into a static-sized buffer. If we have an absurdly long
tagname, like:
git init repo
cd repo
git commit --allow-empty -m foo
git tag -m message mytag
git fast-export mytag |
perl -lpe '/^tag/ and s/mytag/a x 8192/e' |
git
We can use lock_any_ref_for_update instead. Besides being
more flexible, the only difference between the two is that
lock_ref_sha1 does not allow top-level refs like
refs/foo to be updated. However, we know that we do not
have such a ref, because we explicitly add the tags/
prefix ourselves.
Note
On Fri, Aug 22, 2014 at 11:45:15AM -0700, Jonathan Nieder wrote:
Junio C Hamano wrote:
implication of which is that the 'at least one slash'
rule was to expect things are 'refs/anything' so there will be at
least one. Even back then, that anything alone had at least one
On Fri, Aug 22, 2014 at 10:46 PM, Jeff King p...@peff.net wrote:
After much head scratching over the years, I am of the opinion that
nobody every really _meant_ to prevent refs/foo...
Yup, that matches my understanding.
--
To unsubscribe from this list: send the line unsubscribe git in
the
72 matches
Mail list logo
