On 2014-08-23 00.54, Junio C Hamano wrote:
> Torsten Bögershausen 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
>> pu
On Fri, Aug 22, 2014 at 07:39:59PM +0100, Philip Oakley wrote:
> Just a bit of bikeshedding for future improvements..
>
> The .gitignore is another potential user problem area that may benefit form
> not being anonymised when problems strike.
Thanks, I had meant to mention some implications for
On Fri, Aug 22, 2014 at 10:46 PM, Jeff King 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 body of a
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/' so there will be at
> > least one. Even back then, that alone had at least one
> > slash
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.
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
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
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,
an
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
re
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
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/). Th
On Fri, Aug 22, 2014 at 10:59 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> There are a few gotchas I can certainly use help on, especially from
>> a smart-http expert ;-).
>>
>> * "pushed-to " will identify the site and the repository, so
>>you cannot MITM my push to an experiment
Torsten Bögershausen 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 adds a test t
On 23.08.2014 00:32, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On 22.08.2014 22:33, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
On 22.08.2014 22:03, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> So there would be tags like:
>> master_2014_08_21
>>
Stefan Beller writes:
> On 22.08.2014 22:33, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> On 22.08.2014 22:03, Junio C Hamano wrote:
Stefan Beller writes:
> So there would be tags like:
> master_2014_08_21
> master_2014_08_22
> ...
> maint_2014_08
On 22.08.2014 22:33, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On 22.08.2014 22:03, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
So there would be tags like:
master_2014_08_21
master_2014_08_22
...
maint_2014_08_13
maint_2014_08_21
>>>
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 kind
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 hoo
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 left
Stefan Beller writes:
> On 22.08.2014 22:03, Junio C Hamano wrote:
>> Stefan Beller 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
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 put
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
---
Documentation/technical/pack-protocol.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Docum
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 d
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 the
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 beca
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
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index c1
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
---
send-pack.c | 36 +---
1 file chan
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
---
send-pack.c | 4 +---
1 file changed, 1 insertion(+), 3 dele
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=" by using
two conditionals is replaced by a more readable version.
Signed-off-by: Junio C Hamano
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
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
---
builtin/receive-pack.c | 50 +-
1 file changed, 29 insertions(+), 21 deletions(-)
di
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
---
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
---
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --
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 al
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
On 22.08.2014 22:03, Junio C Hamano wrote:
> Stefan Beller 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 ther
Stefan Beller 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 that tag?
--
To
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 onl
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 c
Fix the broken && chain
Reported-By: Eric Sunshine
Signed-off-by: Torsten Bögershausen
---
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 100755
--- a/t/t0026-eol-config.sh
+++
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
Signed-off-by: Torsten Bögershausen
---
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 native
Junio C Hamano wrote:
>implication of which is that the 'at least one slash'
> rule was to expect things are 'refs/' so there will be at
> least one. Even back then, that alone had at least one
> slash (e.g. heads/master), but the intention was *never* that we
> would forbid tha
From: "Jeff King" : 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 convenience
Jonathan Nieder 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
Edward Thomson 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.
>
> Thanks, both.
Junio C Hamano 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 a message to
Jeff King 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 for
>
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
Junio C Hamano writes:
> There are a few gotchas I can certainly use help on, especially from
> a smart-http expert ;-).
>
> * "pushed-to " will identify the site and the repository, so
>you cannot MITM my push to an experimental server and replay it
>against the authoritative server.
>
Junio C Hamano writes:
> Steffen Prohaska 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
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: i
On 14-08-19 12:07 PM, Robert Dailey wrote:
> On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder wrote:
>> Thanks for reporting. The remote used is the default remote that "git
>> fetch" without further arguments would use:
>>
>> get_default_remote () {
>> curr_branch=$(git s
On Fri, Aug 22, 2014 at 08:56:12AM -0700, Junio C Hamano wrote:
> Jeff King 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, a
Steffen Prohaska 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
atoi/a
Jeff King 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 : -1);
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.
Tha
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 ru
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
---
upload-pack.c |4 +++-
1 file change
Hi,
Duy Nguyen:
> On Thu, Aug 21, 2014 at 10:39 PM, Matthias Urlichs
> 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
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 b
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
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 wi
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
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/con
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 strin
On Aug 22, 2014, at 12:26 AM, Junio C Hamano wrote:
> Steffen Prohaska 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 variable GIT_MMAP_LIMIT to li
On Thu, Aug 21, 2014 at 10:39 PM, Matthias Urlichs 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 Fri, Aug 22, 2014 at 6:21 AM, Jeff King 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 could
>
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
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
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 o
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
74 matches
Mail list logo
