Nico Schlömer wrote:
> I just double-checked and I can only produce this issue on one machine
> (tested on 3). Apparently, this is has nothing to do with Git itself
> then.
>
> Any ideas of what could be wrong?
What's different about that one machine?
e.g. SVN version, 64 vs 32-bit, Perl version
> On Feb 17, 2015, at 1:34 PM, Torsten Bögershausen wrote:
>
> On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
>>> On Feb 17, 2015, at 3:08 AM, Matthieu Moy
>>> wrote:
>>>
>>> [ Please, don't top post on this list ]
>>>
>>> Fairuzan Roslan writes:
>>>
I don’t see the issue for the owne
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
On Feb 17, 2015, at 3:08 AM, Matthieu Moy wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan writes:
I don’t see the issue for the owner of his/her own file to have write
access.
Object and pack files are not meant to be modified.
There currently is a thread on the Gerrit list about how much faster cloning
can be when using Gerrit/jgit GCed packs with bitmaps versus C git GCed packs
with bitmaps.
Some differences outlined are that jgit seems to have more bitmaps, it creates
one for every refs/heads, is C git doing that?
Hi all,
Teaching a university class using git, we encountered a case of
potentially incorrect behavior when students made changes to a file,
forgot to commit them, and then pulled a new one-line change from our
remote repository. This resulted in the uncommitted changes being
overwritten without a
On Sun, Feb 15, 2015 at 10:45 PM, Jeff King wrote:
> On Sun, Feb 15, 2015 at 11:59:02PM -0500, Nicolas Pitre wrote:
>
>> Yet, I think the biggest problem with pack v4 at the moment is the
>> packing algorithm for tree objects. We are piggy-backing on the pack v2
>> object delta compression sortin
> On Feb 17, 2015, at 3:08 AM, Matthieu Moy
> wrote:
>
> [ Please, don't top post on this list ]
>
> Fairuzan Roslan writes:
>
>> I don’t see the issue for the owner of his/her own file to have write
>> access.
>
> Object and pack files are not meant to be modified. Hence, they are
> read-o
On Mon, Feb 16, 2015 at 10:43 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> ... And the whole output is checksummed by a single sha1
>> over the whole stream that comes at the end.
>>
>> I think the most feasible thing would be to quickly spool it to a
>> server on the LAN, and then use an e
On Tue, Feb 17, 2015 at 06:16:39AM +0700, Duy Nguyen wrote:
> On Mon, Feb 16, 2015 at 10:47 PM, Jeff King wrote:
> > Each clone generates the pack on the fly
> > based on what's on disk and streams it out. It should _usually_ be the
> > same, but there's nothing to guarantee byte-for-byte equalit
On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano wrote:
> Julien Cretel writes:
>
>> As of Git 2.3.0, the output of "git log --decorate" is ambiguous as to
>> whether the HEAD is detached or not.
>
> It sounds as if you are reporting some regression, but has any
> version of Git ever done so, or
2015-02-09 14:55 GMT-07:00 Junio C Hamano :
>
> Alex Henrie writes:
>
> > This is just a friendly reminder that this patch has been sitting in
> > the mailing list archives for a couple of weeks, and it has not yet
> > been accepted or commented on.
>
> I think that is because the message was not
On Mon, Feb 16, 2015 at 10:47 PM, Jeff King wrote:
> Each clone generates the pack on the fly
> based on what's on disk and streams it out. It should _usually_ be the
> same, but there's nothing to guarantee byte-for-byte equality between
> invocations.
It's usually _not_ the same. I tried when I
Julien Cretel writes:
> As of Git 2.3.0, the output of "git log --decorate" is ambiguous as to
> whether the HEAD is detached or not.
It sounds as if you are reporting some regression, but has any
version of Git ever done so, or is this just a new feature that
does not exist yet?
> More specifi
As of Git 2.3.0, the output of "git log --decorate" is ambiguous as to
whether the HEAD is detached or not.
More specifically, consider the following output of "git log --decorate":
4d860e9 (HEAD, master, dev) Remove trailing whitespace
Whether the HEAD is attached to master or detached, the
Jeff King writes:
>> Is there a general concensus on the direction?
>>
>> I am inclined to merge this to 'next', if there is a general
>> understanding that we will try to make the headers _the_ single
>> source of truth of the API by (1) not adding to api-*.txt without
>> describing new things
Sometimes people respond "y" (or "yes") when asked
this question:
Which 8bit encoding should I declare [UTF-8]?
We already have a mechanism to avoid accepting a mistyped e-mail
address (we ask to confirm when the given address lacks "@" in it);
reuse it to trigger the same confirmation when g
Karsten Blees writes:
> However, the Makefile has this to say on the subject:
>
> # Define USE_NSEC below if you want git to care about sub-second file mtimes
> # and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
> # it will BREAK YOUR LOCAL DIFFS! show-diff and anything
Duy Nguyen writes:
> On Thu, Feb 12, 2015 at 4:23 AM, Junio C Hamano wrote:
> ...
>> If you want to detect the content changes across working tree, index
>> and the tree objects by reusing hash_sha1_file(), however, you must
>> not feed the checked out (aka "smudged") representation to it.
>> Yo
Am 13.02.2015 um 20:28 schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Am 13.02.2015 um 00:38 schrieb Junio C Hamano:
>>>
>>> We do have sec/nsec fields in cache_time structure, so I have
>>> nothing against updating the msysGit port to fill that value.
>
> Having said that, we do not enabl
On 16.02.15 20:06, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> The issue is that having object and pack files read-only on the
>> filesystem is a safety feature to prevent accidental modifications (even
>> though it's actually not that effective, since brute-force "sed -i" or
>> "perl -i" s
Paolo Bonzini writes:
> From: Paolo Bonzini
>
> After updating to git 2.3.0, "git request-pull" is stubbornly complaining
> that I lack a matching tag on the remote side unless I pass the third
> argument. But I did prepare and push a signed tag.
A few questions.
- what old version did you u
[ Please, don't top post on this list ]
Fairuzan Roslan writes:
> I don’t see the issue for the owner of his/her own file to have write
> access.
Object and pack files are not meant to be modified. Hence, they are
read-only so that an (accidental) attempt to modify them fails.
> Setting tmp id
Matthieu Moy writes:
> The issue is that having object and pack files read-only on the
> filesystem is a safety feature to prevent accidental modifications (even
> though it's actually not that effective, since brute-force "sed -i" or
> "perl -i" still accept to modify read-only files).
I did no
Jeff King writes:
> ... And the whole output is checksummed by a single sha1
> over the whole stream that comes at the end.
>
> I think the most feasible thing would be to quickly spool it to a
> server on the LAN, and then use an existing fetch-in-parallel tool
> to grab it from there over the W
I don’t see the issue for the owner of his/her own file to have write access.
Setting tmp idx & pack files to read-only even for the file owner is not a
safety feature.
The real issue here is that in AFP file system can’t even unlink or rename or
delete the tmp idx and pack file with no write ac
Fairuzan Roslan writes:
> Hi,
>
> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
> causing a lot of issues (unable to unlink/write/rename) to those
> people who use AFP shares.
Is it a problem when using Git (like "git gc" failing to remove old
packs), or when trying to remove
From: Paolo Bonzini
After updating to git 2.3.0, "git request-pull" is stubbornly complaining
that I lack a matching tag on the remote side unless I pass the third
argument. But I did prepare and push a signed tag.
This looks like a bug to me; when $3 is not passed git will try to use
"HEAD" as
From: Paolo Bonzini
If the third argument is not passed, "git show-ref --tags HEAD" will
never return anything and git-request-pull will never detect a tag
name.
Instead, "git tag --points-at" can find it. Use it if "git show-ref"
fails.
Signed-off-by: Paolo Bonzini
---
git-request-pull.sh |
From: Paolo Bonzini
If the third argument is not passed to "git request-pull", the
find_matching_ref script will look for HEAD in the remote side
which does not work. Instead, default to the ref names found
via "git show-ref" or "git tag".
Signed-off-by: Paolo Bonzini
---
git-request-pull.sh
From: Paolo Bonzini
"tag foo" in requests has been replaced with "tags/foo" (commit f032d66,
request-pull: do not emit "tag" before the tagname, 2011-12-19). Adjust
the parsing script to match; since the new format does not have spaces,
doing nothing is fine.
Signed-off-by: Paolo Bonzini
---
Hi,
Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot
of issues (unable to unlink/write/rename) to those people who use AFP shares.
In order to be able to write/unlink/delete/rename a file on AFP filesystem the
owner of the file must have at least a u+w access to i
On Mon, Feb 16, 2015 at 07:31:33AM -0800, David Lang wrote:
> >Then the server streams the data to the client. It might do some light
> >work transforming the data as it comes off the disk, but most of it is
> >just blitted straight from disk, and the network is the bottleneck.
>
> Depending on h
On Mon, 16 Feb 2015, Jeff King wrote:
On Mon, Feb 16, 2015 at 05:31:13AM -0800, David Lang wrote:
I think it's an interesting question to look at, but before you start
looking at changing the architecture of the current code, I would suggest
doing a bit more analisys of the problem to see if t
I just double-checked and I can only produce this issue on one machine
(tested on 3). Apparently, this is has nothing to do with Git itself
then.
Any ideas of what could be wrong?
Cheers,
Nico
On Thu, Feb 12, 2015 at 8:18 PM, Eric Wong wrote:
> Valery Yundin wrote:
>> On 31 January 2015 at 13:
On Mon, Feb 16, 2015 at 05:31:13AM -0800, David Lang wrote:
> I think it's an interesting question to look at, but before you start
> looking at changing the architecture of the current code, I would suggest
> doing a bit more analisys of the problem to see if the bottleneck is really
> where you
On Mon, 16 Feb 2015, Koosha Khajehmoogahi wrote:
Cloning huge repositories like Linux kernel takes considerable amount
of time. Is it possible to incorporate a multi-threaded simultaneous
connections functionality for cloning? To what extent do we need to
change the architecture of the current c
Hi,
On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:
We should definitely make recovery like this harder, but is there a
reason for why you don't use "git reset --keep" instead of --hard?
This was only the second time in years of git usage that the reset was
incorrectly done. I suppose at thi
Greetings,
Cloning huge repositories like Linux kernel takes considerable amount
of time. Is it possible to incorporate a multi-threaded simultaneous
connections functionality for cloning? To what extent do we need to
change the architecture of the current code and how large would be the
scope of
On Mon, Feb 16, 2015 at 7:10 PM, Ævar Arnfjörð Bjarmason
wrote:
>> We should definitely make recovery like this harder, but is there a
>> reason for why you don't use "git reset --keep" instead of --hard?
>> It'll keep any local changes to your index/staging area, and reset the
>> files that don't
On Mon, Feb 16, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher
> wrote:
>> Long story short: I failed big time yesterday with accidentally executing
>> git reset hard in the wrong terminal window but managed to recover my
>> changes from the sta
On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher
wrote:
> Long story short: I failed big time yesterday with accidentally executing
> git reset hard in the wrong terminal window but managed to recover my
> changes from the staging area by manually examining blobs touched recently.
>
> After that h
On Mon, Feb 16, 2015 at 1:45 PM, Jeff King wrote:
> Somewhat related to this, I was playing this weekend with the idea of
> generating fast tree diffs from our on-disk deltas. That is, given a
> base tree and a binary delta against it, could I reliably reproduce a
> diff (one way or the other) in
Hi,
Long story short: I failed big time yesterday with accidentally
executing git reset hard in the wrong terminal window but managed to
recover my changes from the staging area by manually examining blobs
touched recently.
After that however I figured I might want to add a precaution for my
Hi,
- Original Message -
> GitHub is organizing a Git-related conference to be held April 8-9,
> 2015, in Paris. Details here:
>
> http://git-merge.com/
>
> The exact schedule is still being worked out, but there is going to be
> some dedicated time/space for Git (and libgit2 and JGit
On Mon, Feb 16, 2015 at 11:59 AM, Nicolas Pitre wrote:
>> I think pack v4 does not deliver its best promise that walking a tree
>> is simply following pointers and jumping from place to place. When we
>> want to copy from the middle of another tree, we need to scan from the
>> beginning of the tre
On 13/02/15 21:19, Junio C Hamano wrote:
I am inclined to squash these into one commit before starting to
merge them down to 'next' and then to 'master', after getting
Tested-by: from those with older Getopt::Long (prior to 2.32).
Junio C Hamano (1):
SQUASH??? t9001: turn --no$option workarou
On Thu, Feb 12, 2015 at 4:23 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> -int add_excludes_from_file_to_list(const char *fname,
>> -const char *base,
>> -int baselen,
>> -struct excl
`git_config_parse_key()` is used to sanitize the input key.
Some callers of the function like `git_config_set_multivar_in_file()`
get the pre-sanitized key directly from the user so it becomes
necessary to raise an error specifying what went wrong when the entered
key is syntactically malformed.
48 matches
Mail list logo
