Michael Haggerty 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 symbolic
Linus Torvalds 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 other git command ever did
On Tue, Feb 17, 2015 at 3:32 PM, Junio C Hamano 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 fetcher step-wise"
On Thu, Feb 12, 2015 at 1:34 AM, Jeff King 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 like for
"Dan Langille (dalangil)" writes:
>> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>>
>> "Dan Langille (dalangil)" 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 mess
Martin Fick 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 more parallelism?
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. Th
On Sat, Jan 24, 2015 at 12:37 AM, Jeff King 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 Git (and
> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>
> "Dan Langille (dalangil)" 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 to and have been using i
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 n
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 much
Jeff King 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. S
Jens Lehmann 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
Date: Mon, 3 Nov 2014 11:09:51 +0100
Subject: [PATCH] submodule:
On 02/17/2015 10:57 PM, Junio C Hamano wrote:
> Michael Haggerty 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 a
Jeff King 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 @{upstream}.
>
Am 16.02.2015 um 23:10 schrieb Junio C Hamano:
> 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
>> #
Michael Haggerty 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 start
>>>
On Tue, Feb 17, 2015 at 1:10 PM, Paolo Bonzini 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 to me.
Umm.
On Tue, Feb 17, 2015 at 1:03 PM, Junio C Hamano 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.
And that'
> 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 sayin
On Tue, Feb 17, 2015 at 12:53 PM, Paolo Bonzini 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 notes of 2
Linus Torvalds 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" sensible.
"HEAD should resol
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 fin
On Tue, Feb 17, 2015 at 12:34 PM, Paolo Bonzini 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 default but
it c
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 re
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
> warn: Are you sure you pushed 'HEAD' there?
Yes, it is.
Paolo Bonzini writes:
> On 16/02/2015 20:47, Junio C Hamano wrote:
>> 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
Jeff King 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 the
> d
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 http://v
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 wrote:
> On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote:
>
>> Make test has been failing for 'pu' yesterday for and t
On Tue, Feb 17, 2015 at 10:14 AM, Junio C Hamano wrote:
> Stefan Beller 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 the commit message as I was
On Tue, Feb 17, 2015 at 09:45:07AM -0800, Junio C Hamano wrote:
> Jeff King 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 bec
Stefan Beller 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 unconditionally because
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
---
read-cache.c | 10 --
1 file changed, 8 i
On 17/02/15 17:58, Fairuzan Roslan wrote:
>
>> On Feb 17, 2015, at 4:51 PM, Matthieu Moy
>> wrote:
>>
>> Fairuzan Roslan writes:
>>
>>> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
>>> Cloning into 'oh-my-zsh'...
>>> remote: Counting objects: 11830, done.
>>> remote: Total 11830 (d
Jeff King 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 resolvin
Matthieu Moy 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(...);
> }
> }
I agree wi
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
Reviewed-by: Stefan Beller
---
branch.c | 5 +++--
builtin/commit.c | 2 +-
builtin/fetch.c
Creating a reference requires a new_sha1 that is not NULL and not
null_sha1.
Signed-off-by: Michael Haggerty
Reviewed-by: Stefan Beller
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index e3c4ab5..b9cf284 100644
--- a/refs.c
+++ b/refs.c
@@ -3690,6 +3690,8 @@
There is no reason to "reserve" a gap between the public and private
flags values.
Signed-off-by: Michael Haggerty
---
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 +44,8 @@ static uns
Instead of having a separate have_old field, record this boolean value
as a bit in the "flags" field.
Signed-off-by: Michael Haggerty
---
refs.c | 45 -
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/refs.c b/refs.c
index a203e44..e3a2
It makes no sense to delete a reference that is already known not to
exist.
Signed-off-by: Michael Haggerty
Reviewed-by: Stefan Beller
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index b9cf284..d5bfd11 100644
--- a/refs.c
+++ b/refs.c
@@ -3702,6 +3702,8 @@ i
Instead, verify the reference's old value if and only if old_sha1 is
non-NULL.
Signed-off-by: Michael Haggerty
Reviewed-by: Stefan Beller
---
builtin/receive-pack.c | 3 +--
builtin/update-ref.c | 5 +++--
refs.c | 11 ++-
refs.h | 6 +++---
4 files
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
---
refs.h | 66 +
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
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:
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
Reviewed-by: Stefan Beller
---
refs.c | 8
refs.h | 13 ++---
2 files changed, 14 inserti
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
"in
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 message)
It is only used internally now. Document it a little bit better, too.
Signed-off-by: Michael Haggerty
Reviewed-by: Stefan Beller
---
refs.c | 6 ++
refs.h | 4 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index ab2f2a9..5e6355c 100644
--- a/refs.c
+++
> On Feb 17, 2015, at 4:51 PM, Matthieu Moy
> wrote:
>
> Fairuzan Roslan 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: 1
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.
> >
>
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
Michael Haggerty 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 good idea
>> y
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
On 02/13/2015 12:08 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jeff King 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, e.g. "erro
Michael Haggerty 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 very sensible. T
On 02/12/2015 08:36 PM, Junio C Hamano wrote:
> Michael Haggerty 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
>> +
>> +test_descript
On 02/12/2015 07:13 PM, Stefan Beller wrote:
> On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty
> 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
>> --- /dev/null
>> ++
On 02/12/2015 08:15 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Thu, Feb 12, 2015 at 3:12 AM, Michael Haggerty
>> wrote:
>>> - int flags; /* REF_NODEREF? */
>>> - int have_old; /* 1 if old_sha1 is valid, 0 otherwise */
>>> + /*
>>> +* One or more of REF_H
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.
>
On Tue, Feb 17, 2015 at 05:36:30PM +0700, Duy Nguyen wrote:
> On Tue, Feb 17, 2015 at 5:13 PM, Jeff King wrote:
> > If the only reason is for gdb, then perhaps:
> >
> > set args pack-objects --stdout /dev/null
> >
> > in gdb would help?
>
> Right. I used "gdb --args command >/dev/null" instead
On Tue, Feb 17, 2015 at 5:13 PM, Jeff King wrote:
> If the only reason is for gdb, then perhaps:
>
> set args pack-objects --stdout /dev/null
>
> in gdb would help?
Right. I used "gdb --args command >/dev/null" instead. Stupid
question. Sorry for the noise.
--
Duy
--
To unsubscribe from this l
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 16/02/2015 20:47, Junio C Hamano wrote:
> 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
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 time
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 t
Fairuzan Roslan 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, done.
> Resolving deltas
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 wonderin
70 matches
Mail list logo
