On Sat, Jan 24, 2015 at 12:37 AM, Jeff King p...@peff.net wrote:
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
Jeff King p...@peff.net writes:
On Tue, Feb 17, 2015 at 08:03:00AM -0800, Junio C Hamano wrote:
Whether or not we decide on a different error-handling convention in the
future, it is a fact of life that a good bit of code already uses the
strbuf convention documented by Jonathan's patch.
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The second batch of topics have been merged to 'master'. I am
tempted to start discarding topics in the Stalled category that
haven't seen
On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote:
Dan Langille (dalangil) dalan...@cisco.com writes:
I did not test this patch. Is that holding up a commit?
I am hoping that you rebuilt the Git you use with this patch by the
time you wrote the message I am responding
Martin Fick mf...@codeaurora.org writes:
Sorry for the long winded rant. I suspect that some variation of all
my suggestions have already been suggested, but maybe they will
rekindle some older, now useful thoughts, or inspire some new ones.
And maybe some of these are better to pursue then
Le 12/02/2015 10:34, Jeff King a écrit :
The beginnings of the Google Summer of Code deadlines are upon us again.
Organization applications are due February 20th (next Friday).
- Do we want to do it?
Unfortunately not so much response on this topic. I was planning to
apply as a student.
Jeff King wrote:
On Thu, Feb 12, 2015 at 03:01:18PM -0800, Junio C Hamano wrote:
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
Dan Langille (dalangil) dalan...@cisco.com writes:
On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote:
Dan Langille (dalangil) dalan...@cisco.com writes:
I did not test this patch. Is that holding up a commit?
I am hoping that you rebuilt the Git you use with this
On Tue, Feb 17, 2015 at 3:32 PM, Junio C Hamano gits...@pobox.com wrote:
A few typofixes and clarifications.
*4* The scheme in *3* can be extended to bring the fetcher
step-wise. If the server's state was X when the fetcher last
bring the fetcher up-to-date step-wise, or update the
Jens Lehmann jens.lehm...@web.de writes:
Yup, but we should also mention '--merge' and '--rebase' here.
This has been sitting in the Stalled pile for quite a while and I am
getting tired of waiting. How does this look?
-- 8 --
From: Michal Sojka sojk...@fel.cvut.cz
Date: Mon, 3 Nov 2014
On Thu, Feb 12, 2015 at 1:34 AM, Jeff King p...@peff.net wrote:
The beginnings of the Google Summer of Code deadlines are upon us again.
Organization applications are due February 20th (next Friday).
- Do we want to do it?
- Who would like to volunteer to be the org admin?
I would
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/17/2015 10:57 PM, Junio C Hamano wrote:
...
Do you mean that we would end up reading refs/heads/hold if the user
did this:
git rev-parse --verify HEAD -- precious
ln -s ../../../precious .git/refs/heads/hold
because that
Linus Torvalds torva...@linux-foundation.org writes:
So basically I agree that git request-pull has changed behavior, but
the new behavior is *more* in line with other git commands, and the
old behavior was actually really really odd with that whole extensive
guess what the user means. No
On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote:
You can't symlink refs like this. The loose refs in the filesystem may
be migrated into the packed-refs file, at which point your symlink
will be broken. That is a likely reason why git would not find any refs.
So your
There is no reason to reserve a gap between the public and private
flags values.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 5e6355c..4de1383 100644
--- a/refs.c
+++ b/refs.c
@@ -44,7
Matthieu Moy matthieu@grenoble-inp.fr writes:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
On 02/05/2015 09:03 PM, Jeff King wrote:
On Thu, Feb 05, 2015 at 04:13:03PM +0100, Dmitry Neverov wrote:
[...]
One more thing about my setup: since git p4 promotes a use of a linear
history I use a separate repository for another branch in perforce. In
order to be able to cherry-pick between
Creating a reference requires a new_sha1 that is not NULL and not
null_sha1.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index e3c4ab5..b9cf284 100644
---
Michael Haggerty mhag...@alum.mit.edu writes:
For example I want to rename the constants to REF_NODEREF -
REF_NO_DEREF and REF_ISPRUNING - REF_IS_PRUNING [1], but am leaving
that for when the refs code is not in so much flux. I can reorganize the
constants and docs then.
These renames are
On 02/13/2015 12:08 AM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
I am more worried about variable length part pushing the information
that is given later out to the right,
Michael Haggerty mhag...@alum.mit.edu writes:
I think we all agree that the early part of the new documentation
text is good, but the last section that proposes to store more
detailed errors in caller supplied strbuf in textual form was
controversial (and I have not convinced myself it is a
On Tue, Feb 17, 2015 at 08:03:00AM -0800, Junio C Hamano wrote:
Whether or not we decide on a different error-handling convention in the
future, it is a fact of life that a good bit of code already uses the
strbuf convention documented by Jonathan's patch. So I think it is OK
to merge it
It makes no sense to delete a reference that is already known not to
exist.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index b9cf284..d5bfd11 100644
---
Instead, verify the reference's old value if and only if old_sha1 is
non-NULL.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
builtin/receive-pack.c | 3 +--
builtin/update-ref.c | 5 +++--
refs.c | 11 ++-
Add more information to the comment introducing the four reference
transaction update functions, so that each function's docstring
doesn't have to repeat it. Add a pointer from the individual
functions' docstrings to the introductory comment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Instead of having a separate have_old field, record this boolean value
as a bit in the flags field.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 45 -
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/refs.c b/refs.c
Committing involves the following steps:
1. Determine the current value of HEAD (if any).
2. Create the new commit object.
3. Update HEAD.
Please note that step 2 can take arbitrarily long, because it might
involve the user editing a commit message.
If a second process sneaks in a commit during
Instead, verify the reference's old value if and only if old_sha1 is
non-NULL.
ref_transaction_delete() will get the same treatment in a moment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
branch.c | 5 +++--
On Feb 17, 2015, at 4:51 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0),
If HEAD doesn't point at anything during the initial check, then we
should make sure that it *still* doesn't point at anything when we are
ready to update the reference. Otherwise, another process might commit
while we are working (e.g., while we are waiting for the user to edit
the commit
It is only used internally now. Document it a little bit better, too.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
refs.c | 6 ++
refs.h | 4 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index
Add a docstring for update_ref(), emphasizing its similarity to
ref_transaction_update(). Rename its parameters to match those of
ref_transaction_update().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
refs.c | 8
refs.h | 13
Change the following functions' flags arguments from int to
unsigned int:
* ref_transaction_update()
* ref_transaction_create()
* ref_transaction_delete()
* update_ref()
* delete_ref()
* lock_ref_sha1_basic()
Also change the flags member in struct ref_update to unsigned.
Suggested-by: Junio C
This is v3 of the patch series; I think I have addressed all of the
feedback raised about v1 [1] and v2 [2]. Thanks to Stefan Beller and
Junio for their feedback about v2.
There are only two significant changes since v2:
* Add a new patch [03/13] that changes a lot of flags variables from
int
If NULL is passed to ref_transaction_update()'s new_sha1 parameter,
then just verify old_sha1 (under lock) without trying to change the
new value of the reference.
Use this functionality to add a new function ref_transaction_verify(),
which checks the current value of the reference under lock but
On 02/12/2015 07:13 PM, Stefan Beller wrote:
On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Committing involves the following steps:
[...]
diff --git a/t/t7516-commit-races.sh b/t/t7516-commit-races.sh
new file mode 100755
index 000..08e6a6c
---
On 02/12/2015 08:36 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
diff --git a/t/t7516-commit-races.sh b/t/t7516-commit-races.sh
new file mode 100755
index 000..08e6a6c
--- /dev/null
+++ b/t/t7516-commit-races.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
On 02/12/2015 08:15 PM, Junio C Hamano wrote:
Stefan Beller sbel...@google.com writes:
On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
- int flags; /* REF_NODEREF? */
- int have_old; /* 1 if old_sha1 is valid, 0 otherwise */
+ /*
+*
Jeff King p...@peff.net writes:
Sometimes a breakage in pu is surprising (e.g., it breaks only on a
platform that the maintainer does not run make test on) and we would
want to know about it. But sometimes it is merely that there is a
work-in-progress. And it probably requires a human to tell
On 17/02/2015 20:57, Junio C Hamano wrote:
Sorry, I was asking what you mean by complains (i.e. the exact
error message). I was and am guessing it is something like this:
warn: No match for commit 3188ab3... found at url
warn: Are you sure you pushed 'HEAD' there?
Yes, it is.
On 02/17/2015 05:55 PM, Jeff King wrote:
On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote:
You can't symlink refs like this. The loose refs in the filesystem may
be migrated into the packed-refs file, at which point your symlink
will be broken. That is a likely reason why git
Jeff King p...@peff.net writes:
If we wanted to implement @{push} (or @{publish}) to mean the
tracking ref of the remote ref you would push to if you ran git-push,
then this is a step in the wrong direction.
Is that because push_default variable needs to be looked at from
sha1_name.c when
This fixes a memory leak, when building the cache entries as
refresh_cache_entry may decide to return NULL in case of
I am not sure how severe this memory leak is as it was found by
scan.coverity.com, CID 290041.
Signed-off-by: Stefan Beller sbel...@google.com
---
read-cache.c | 10 --
On 17/02/15 17:58, Fairuzan Roslan wrote:
On Feb 17, 2015, at 4:51 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects:
On Tue, Feb 17, 2015 at 10:14 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
This fixes a memory leak, when building the cache entries as
refresh_cache_entry may decide to return NULL in case of
in case of what?
Yeah, I got distracted when rewriting
For the record, that commit also sporadically breaks test 3910 on my
system (mentioning since it's not on the list)
On Tue, Feb 17, 2015 at 12:55 AM, Jeff King p...@peff.net wrote:
On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote:
Make test has been failing for 'pu' yesterday
Stefan Beller sbel...@google.com writes:
This fixes a memory leak, when building the cache entries as
refresh_cache_entry may decide to return NULL in case of
in case of what?
I briefly wondered if refresh_cache_ent() should do the freeing but
that does not make sense at all if done
On Tue, Feb 17, 2015 at 09:45:07AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
If we wanted to implement @{push} (or @{publish}) to mean the
tracking ref of the remote ref you would push to if you ran git-push,
then this is a step in the wrong direction.
Is that
On 16/02/2015 20:47, Junio C Hamano wrote:
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
Paolo Bonzini bonz...@gnu.org writes:
On 16/02/2015 20:47, Junio C Hamano wrote:
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
All looked sensible from a cursory read.
Will replace, wait for a few days and will merge to 'next' unless I
hear otherwise from others.
Thanks.
--
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
On Tue, Feb 17, 2015 at 12:34 PM, Paolo Bonzini bonz...@gnu.org wrote:
I guess only Linus could answer that, since he wrote 024d34cb0 and he
knows the intent better than anyone else.
I don't even understand your problem.
You said
when $3 is not passed git will try to use HEAD as the
On 17/02/2015 21:42, Linus Torvalds wrote:
when $3 is not passed git will try to use HEAD as the default but
it cannot be resolved to a tag, neither locally (patch 2) nor remotely
(patch 3)
which makes absolutely no sense.
Indeed, that's why I wrote patches even though I did find the
Linus Torvalds torva...@linux-foundation.org writes:
HEAD is not a tag. Never has been, never will be. If you want me to
pull a tag, then you damn well should say what tag you want, not just
randomly say HEAD.
So what is it you want to do? At no point is HEAD should resolve as a
tag
On Tue, Feb 17, 2015 at 12:53 PM, Paolo Bonzini bonz...@gnu.org wrote:
Without $3, git tries to do things that make no sense like git show-ref
--heads --tags HEAD; or that make little sense when requesting a pull,
like looking for HEAD in the output of git ls-remote. But from the
release
Looking for HEAD in git ls-remote? Perfectly sensible:
[torvalds@i7 linux]$ git ls-remote origin | grep HEAD
cc4f9c2a91b7be7b3590bb1cbe8148873556aa3f HEAD
that's the default thing when you don't specify any particular branch or tag.
Sure. But if I got a pull request saying
On Tue, Feb 17, 2015 at 1:03 PM, Junio C Hamano gits...@pobox.com wrote:
HEAD should resolve as a tag is not sensible, but HEAD should
locally DWIM to something sensible is still possible, no?
I disagree. Why? Because what you have locally is *not* necessarily
the same thing you have remotely.
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/17/2015 05:55 PM, Jeff King wrote:
On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote:
There's a bunch of code in refs.c that is there explicitly for reading
loose references that are symlinks. If the link contents literally
On Tue, Feb 17, 2015 at 1:10 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Sure. But if I got a pull request saying please pull
git://example.org/foo.git HEAD I would think that the sender
messed up the pull request. So *in the context of git-request-pull*
${remote:-HEAD} makes little sense
Am 16.02.2015 um 23:10 schrieb Junio C Hamano:
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
Make test has been failing for 'pu' yesterday for and today at
t4016-diff-quote.sh. Full log:
http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log
I noticed this a few times before and it tends to get fixed again
relatively quickly. So I'm
On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote:
Make test has been failing for 'pu' yesterday for and today at
t4016-diff-quote.sh. Full log:
http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log
I noticed this a few times
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s,
Jeff King p...@peff.net writes:
So we probably would do something similar to @{push} side, which
would mean that push_default variable and the logic needs to be
visible to remote.c if we want to have the helper that is similar to
set_merge() that is used from branch_get() to support
On 02/17/2015 10:57 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/17/2015 05:55 PM, Jeff King wrote:
On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote:
There's a bunch of code in refs.c that is there explicitly for reading
loose references
On Mon, Feb 16, 2015 at 12:47:54AM -0500, Jeff King wrote:
When the push_default flag was originally added, it was
made globally visible to all code. This might have been
useful if other commands or library calls ended up depending
on it, but as it turns out, only builtin/push.c cares.
Commit 6b8fda2 (pack-objects: use bitmaps when packing objects -
2013-12-21) turns off reachability bitmap optimization if --stdout is
not specified. I wonder if we could lift this restriction?
My use case is debugging pack-objects in gdb (repeatedly) where this
optimization could really save
On Tue, Feb 17, 2015 at 05:36:30PM +0700, Duy Nguyen wrote:
On Tue, Feb 17, 2015 at 5:13 PM, Jeff King p...@peff.net wrote:
If the only reason is for gdb, then perhaps:
set args pack-objects --stdout /dev/null /dev/null
in gdb would help?
Right. I used gdb --args command /dev/null
On Tue, Feb 17, 2015 at 05:07:36PM +0700, Duy Nguyen wrote:
Commit 6b8fda2 (pack-objects: use bitmaps when packing objects -
2013-12-21) turns off reachability bitmap optimization if --stdout is
not specified. I wonder if we could lift this restriction?
I'm not sure what else would break if
On Tue, Feb 17, 2015 at 5:13 PM, Jeff King p...@peff.net wrote:
If the only reason is for gdb, then perhaps:
set args pack-objects --stdout /dev/null /dev/null
in gdb would help?
Right. I used gdb --args command /dev/null instead. Stupid
question. Sorry for the noise.
--
Duy
--
To
70 matches
Mail list logo
