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 how
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 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
Matthieu Moy matthieu@grenoble-inp.fr 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
On 16.02.15 20:06, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr 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
Paolo Bonzini bonz...@gnu.org writes:
From: Paolo Bonzini pbonz...@redhat.com
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.
Jeff King p...@peff.net 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
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com 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
From: Paolo Bonzini pbonz...@redhat.com
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
From: Paolo Bonzini pbonz...@redhat.com
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
From: Paolo Bonzini pbonz...@redhat.com
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
From: Paolo Bonzini pbonz...@redhat.com
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
Fairuzan Roslan fairuzan.ros...@gmail.com 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
Am 13.02.2015 um 20:28 schrieb Junio C Hamano:
Karsten Blees karsten.bl...@gmail.com 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
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
Sometimes people respond yENTER (or yesENTER) 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
Duy Nguyen pclo...@gmail.com writes:
On Thu, Feb 12, 2015 at 4:23 AM, Junio C Hamano gits...@pobox.com 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)
Karsten Blees karsten.bl...@gmail.com 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!
Jeff King p...@peff.net 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
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?
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
I don’t see the issue for the owner of his/her own file to have write
access.
On Tue, Feb 17, 2015 at 06:16:39AM +0700, Duy Nguyen wrote:
On Mon, Feb 16, 2015 at 10:47 PM, Jeff King p...@peff.net 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
On Mon, Feb 16, 2015 at 10:47 PM, Jeff King p...@peff.net 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
On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano gits...@pobox.com wrote:
Julien Cretel j.cre...@umail.ucc.ie 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
Julien Cretel j.cre...@umail.ucc.ie 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
2015-02-09 14:55 GMT-07:00 Junio C Hamano gits...@pobox.com:
Alex Henrie alexhenri...@gmail.com 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
On Sun, Feb 15, 2015 at 10:45 PM, Jeff King p...@peff.net 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
On Mon, Feb 16, 2015 at 10:43 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com 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
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
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
ava...@gmail.com 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
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 this
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
On Feb 17, 2015, at 1:34 PM, Torsten Bögershausen tbo...@web.de wrote:
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com
Nico Schlömer nico.schloe...@gmail.com 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
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
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 normalper...@yhbt.net wrote:
Valery Yundin
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
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
On Mon, Feb 16, 2015 at 1:45 PM, Jeff King p...@peff.net 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
`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.
On Mon, Feb 16, 2015 at 11:59 AM, Nicolas Pitre n...@fluxnic.net 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
On Thu, Feb 12, 2015 at 4:23 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
-int add_excludes_from_file_to_list(const char *fname,
-const char *base,
-int baselen,
-
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
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:41 AM, Armin Ronacher
armin.ronac...@active-4.com 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
On Mon, Feb 16, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Long story short: I failed big time yesterday with accidentally executing
git reset hard in the wrong terminal window but managed
48 matches
Mail list logo
