* Re: What should "git fetch origin +next" should do?
From: Ramkumar Ramachandra @ 2011-10-17 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h45s8rh.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> I just tried to update one of them with "git pull --ff-only", and after
> seeing that the fetch phase failed with non-ff on 'next', ran
>
> $ git fetch origin +next
>
> which happily copied the tip of updated next to FETCH_HEAD and nowhere
> else. Of course, a colon-less refspec means do not store it anywhere,
> i.e. "<colon-less-refspec>" === "<colon-less refspec>:", so prefixing it
> with '+' to force would logically be a no-op. But it nevertheless was
> somewhat surprising and irritating.
Interesting: I wouldn't have expected this behavior either. I'll see
if I can add something useful to this.
> As some might know, I use the traditional non-separate-remotes layout in
> many of my working trees. I am old fashioned.
As an interesting aside, I recently stopped using the word 'origin' to
name a remote since I started using multiple remotes: your remote is
called 'junio', mine's called 'ram', Jonathan's is called 'jrn', and
so on. I personally use a variation of `git fetch junio master:master
next:next +pu:pu`. It "fails" when:
1. Some uncommitted work is left: I'm a bit messy with multiple
worktrees (git-new-workdir).
2. I'm doing some work directly on top of `master` or some other
upstream branch, and haven't forked out yet (I only fork out and name
the branch if the volume of work justifies it).
3. Sometimes `next` is non-ff, and I'm curious about what happened. I
inspect the changes before invariably using a `git reset --hard
junio/next` to throw away the useless commits.
> (2) Do notice '+' and understand that it is a request to force fetch into
> some ref locally, and from the lack of colon and RHS, assume that the
> user wants Git to infer the RHS using the configured refspec (in my
> case, "refs/heads/next:refs/heads/next" is one of the configured
> fetch refspec; "refs/heads/*:refs/remotes/origin/*" would be the one
> that would match in the separate-remotes layout). In other words,
> treat it as if the user typed "+refs/heads/next:refs/heads/next" (or
> "+refs/heads/next:refs/remotes/origin/next" in the separate-remote
> layout) from the command line.
Ugh, no. Such smartness is probably desirable at the `pull` level.
> (3) Do notice '+' is applied to 'next' but otherwise ignore the fact that
> it is a command line pathspec, which would cause us to ignore
> configured refspecs. In other words, fetch normally as if there were
> no refspec on the command line, but when updating refs/heads/next (or
> refs/remotes/origin/next in the separate-remotes layout), allow non
> fast-forward updates.
This is unnecessarily complicated and ugly imho. I think `git fetch`
is trying to be over-smart here: If I don't choose to update my local
refs by hand immediately after the fetch, I'll be surprised later.
> Perhaps we can/want to implement (1)?
Yeah, I think it's the right thing to do. For the implementation,
should we update the condition in fetch.c:451 or try to implement it
at the refspec-parsing level?
Thanks.
-- Ram
^ permalink raw reply
* Re: What should "git fetch origin +next" should do?
From: Ramkumar Ramachandra @ 2011-10-17 16:15 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Junio C Hamano, git
In-Reply-To: <4E9C3D27.3060504@xiplink.com>
Hi Marc,
Marc Branchaud writes:
> Being hip and modern :) I use separate remote refspecs. As I read your post,
> I kept thinking that it makes no sense for fetch to ever update local refs
> and that you're a victim of your stodgy old ways.
Hm, I like the symmetry with the `git push` UI. I wouldn't want to
checkout every non-ff upstream branch and merge by hand before
rebasing my work on top of it!
-- Ram
^ permalink raw reply
* Re: [PATCH] Git-p4: git-p4.changeOnSubmit to do 'change' instead of 'submit'.
From: Andrei Warkentin @ 2011-10-17 16:18 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, gitster, Pete Wyckoff, Andrei Warkentin
In-Reply-To: <4E99E8D2.6020107@diamand.org>
Hi,
----- Original Message -----
> From: "Luke Diamand" <luke@diamand.org>
> To: "Andrei Warkentin" <andreiw@vmware.com>
> Cc: git@vger.kernel.org, gitster@pobox.com, "Pete Wyckoff" <pw@padd.com>
> Sent: Saturday, October 15, 2011 4:10:58 PM
> Subject: Re: [PATCH] Git-p4: git-p4.changeOnSubmit to do 'change' instead of 'submit'.
>
> On 14/10/11 22:51, Andrei Warkentin wrote:
> > Many users of p4/sd use changelists for review, regression
> > tests and batch builds, thus changes are almost never directly
> > submitted.
> >
> > This new config option lets a 'p4 change -i' run instead of
> > the 'p4 submit -i'.
> >
> > Signed-off-by: Andrei Warkentin<andreiw@vmware.com>
> > ---
> > contrib/fast-import/git-p4 | 16 ++++++++++++----
> > contrib/fast-import/git-p4.txt | 10 ++++++++++
> > 2 files changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/contrib/fast-import/git-p4
> > b/contrib/fast-import/git-p4
> > index 2f7b270..19c295b 100755
> > --- a/contrib/fast-import/git-p4
> > +++ b/contrib/fast-import/git-p4
> > @@ -959,7 +959,10 @@ class P4Submit(Command, P4UserMap):
> > submitTemplate =
> > message[:message.index(separatorLine)]
> > if self.isWindows:
> > submitTemplate =
> > submitTemplate.replace("\r\n", "\n")
> > - p4_write_pipe("submit -i", submitTemplate)
> > + if gitConfig("git-p4.changeOnSubmit"):
> > + p4_write_pipe("change -i", submitTemplate)
> > + else:
> > + p4_write_pipe("subadasdmit -i",
> > submitTemplate)
>
>
> What does "p4 subadasmit" do? That's a new command to me!
>
Ack, that's emabarrasing. How did that get there :-)?
Anyway, the other suggestion I had was to create a new command
instead of overriding behaviour of an existing one. Of course,
copy-pasting P4Submit into P4Change is silly, so...
How about something like this?
The commands dict maps command name to class and optional dict passed to cmd.run(). That way 'change'
can really mean P4Submit with an extra parameter not to submit but to do a changelist instead. The
reason why I initially made the config flag was because I didn't want to copy-paste P4Submit into P4Change.
commands = {
"debug" : [ P4Debug, {} ]
"submit" : [ P4Submit, { "doChange" : 0 } ]
"commit" : [ P4Submit, { "doChange" : 0 } ]
"change" : [ P4Submit, { "doChange" : 1 } ]
"sync" : [ P4Sync, {} ],
"rebase" : [ P4Rebase, {} ],
"clone" : [ P4Clone, {} ],
"rollback" : [ P4RollBack, {} ],
"branches" : [ P4Branches, {} ]
}
Thanks for the review,
A
^ permalink raw reply
* Re: What should "git fetch origin +next" should do?
From: Junio C Hamano @ 2011-10-17 17:09 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <4E9C3D27.3060504@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> On 11-10-16 03:20 AM, Junio C Hamano wrote:
>> As some might know, I use the traditional non-separate-remotes layout in
>> many of my working trees. I am old fashioned.
>
> Being hip and modern :) I use separate remote refspecs. As I read your post,
> I kept thinking that it makes no sense for fetch to ever update local refs
> and that you're a victim of your stodgy old ways.
Imagine a scenario where I run the same "git fetch origin +next" in a
repository with separate remotes layout, expecting that the remote
tracking branch refs/remotes/origin/next to be force updated. The fetched
value will be stored only in FETCH_HEAD, and I would feel exactly the same
minor irritation.
In other words, the issue does not have anything to do with the layout.
My mention of layout variants was only to clarify that the ref to be force
updated on the local side is determined by the suggested behaviours (2)
and (3) based on the fetch refspec (i.e. refs/heads/next in the
traditional layout, refs/remotes/origin/next in the separate remotes
layout).
This is a tangent but we have seen in the past some new people wonder why
their configured remote tracking refs are not updated when they do
$ git fetch origin next
This is a variant without '+', and in such a case, in addition to list the
fetched tip in FETCH_HEAD, it might be more natural for the user to expect
that the usual remote tracking branch update to happen. And I suspect
that the suggested semantics (2) might better match what the users expect
in general.
That is, when fetching from a remote that has configured fetch refspecs,
colon-less refspecs are given from the command line, are first matched
against the configured fetch refspecs for the remote, and used to update
the remote tracking branches. IOW, with the separate remote layout fetch
refspec, the above command line is re-written to
$ git fetch origin refs/heads/next:refs/remotes/origin/next
and leaves the fetched tip of 'next' in FETCH_HEAD and updates the remote
tracking branch; nothing else is fetched.
And if we apply the '+' prefix in this context, as the natural
consequence, my original example would be rewritten to:
$ git fetch origin +refs/heads/next:refs/remotes/origin/next
in a repository with the separate remote layout fetch refspec, and in a
repository with the non-separate remote layout, it would be rewritten to:
$ git fetch origin +refs/heads/next:refs/heads/next
Historically, we never used configured fetch refspecs when refspecs are
given on the command line, so such a change definitely breaks backward
compatibility, but possibly in a good way, and might deserve consideration
for Git 2.0.
^ permalink raw reply
* Re: What should "git fetch origin +next" should do?
From: Jeff King @ 2011-10-17 17:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h45s8rh.fsf@alter.siamese.dyndns.org>
On Sun, Oct 16, 2011 at 12:20:02AM -0700, Junio C Hamano wrote:
> I just tried to update one of them with "git pull --ff-only", and after
> seeing that the fetch phase failed with non-ff on 'next', ran
>
> $ git fetch origin +next
>
> which happily copied the tip of updated next to FETCH_HEAD and nowhere
> else. Of course, a colon-less refspec means do not store it anywhere,
> i.e. "<colon-less-refspec>" === "<colon-less refspec>:", so prefixing it
> with '+' to force would logically be a no-op. But it nevertheless was
> somewhat surprising and irritating.
I don't see that this has anything to do with the "+" at all. If I said:
$ git fetch origin next
I think the exact same confusion exists. I told git to update 'next'
from origin, but it didn't touch refs/remotes/origin/next. You and I
both know what is happening, because we understand that "next" is a
refspec, and that it has no RHS. But I suspect that is not how many git
users think of it.
We've discussed this before, of course:
http://thread.gmane.org/gmane.comp.version-control.git/127163/focus=127215
-Peff
^ permalink raw reply
* Re: regression in git-gui since 2c5c66b... Merge branch 'jp/get-ref-dir-unsorted
From: Junio C Hamano @ 2011-10-17 17:22 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Mark Levedahl, git
In-Reply-To: <4E9C2F3C.7080405@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> static int resolve_gitlink_packed_ref(char *name, int pathlen, const
> char *refname, unsigned char *result)
> {
> int retval = -1;
> struct ref_entry *ref;
> struct ref_array *array = get_packed_refs(name);
>
> ref = search_ref_array(array, refname);
> if (ref != NULL) {
> memcpy(result, ref->sha1, 20);
> retval = 0;
> }
> return retval;
> }
>
> The problem is that the parameter "name" is not NUL-terminated. The old
> code turned it into a (NUL-terminated) filename via
>
> strcpy(name + pathlen, "packed-refs");
>
> but the new code passes it (unterminated) to get_packed_refs()
Thanks for digging this through before I got to it. Very much appreciated,
and sorry or the mismerge (incidentally this was why I wanted to merge
early these two topics that tried to improve different things that
happened to touch the same part of the code, as I knew such a merge was
risky and needed plenty time before it hits released versions).
^ permalink raw reply
* Re: [PATCH v3 2/7] invalidate_ref_cache(): take the submodule as parameter
From: Junio C Hamano @ 2011-10-17 18:00 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <4E960F91.5020103@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 10/12/2011 09:19 PM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> ...
>> Probably that is what all the existing callers want, but I would have
>> expected that an existing feature would be kept, perhaps like this
>> instead:
>>
>> if (!submodule) {
>> struct ref_cache *c;
>> for (c = ref_cache; c; c = c->next)
>> clear_ref_cache(c);
>> } else {
>> clear_ref_cache(get_ref_cache(submodule);
>> }
> ...
> Your specific suggestion would not work because currently
> submodule==NULL signifies the main module. However, it would be easy to
> add the few-line function when/if it is needed.
I think "submodule==NULL" is probably a mistake; "" would make more sense
given that you are storing the string in name[FLEX_ARRAY] field.
^ permalink raw reply
* Re: [PATCH 3/3] git-gui: new config to control staging of untracked files
From: Heiko Voigt @ 2011-10-17 18:34 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Pat Thoyts, git
In-Reply-To: <03727ea04f20c953e7de3f84ab1724a8360ca2c4.1318620267.git.bert.wesarg@googlemail.com>
Hi,
what the series tries to achieve looks good to me. Just one comment.
On Fri, Oct 14, 2011 at 09:25:21PM +0200, Bert Wesarg wrote:
[...]
> diff --git a/lib/index.tcl b/lib/index.tcl
> index 014acf9..45094c2 100644
> --- a/lib/index.tcl
> +++ b/lib/index.tcl
> @@ -367,7 +367,19 @@ proc do_add_all {} {
> }
> }
> if {[llength $untracked_paths]} {
> - set reply [ask_popup [mc "Stage also untracked files?"]]
> + set reply 0
> + switch -- [get_config gui.stageuntracked] {
> + no {
> + set reply 0
> + }
[...]
Here I am wondering whether we have a similar mechanism in git gui like
in core git that makes yes,true,1 equivalents (and similar with other
values) ? If we don't I think the series is fine as it is otherwise it
probably makes sense to use that mechanism.
Cheers Heiko
^ permalink raw reply
* Re: What should "git fetch origin +next" should do?
From: Junio C Hamano @ 2011-10-17 18:34 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111017171041.GA12837@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think the exact same confusion exists. I told git to update 'next'
> from origin, but it didn't touch refs/remotes/origin/next.
Except that you didn't tell git to *update* the remote tracking branch for
'next'; you merely told it to fetch 'next' at the remote.
> ... But I suspect that is not how many git users think of it.
I am inclined to agree that it might be the case; see my other message in
this thread.
> We've discussed this before, of course:
>
> http://thread.gmane.org/gmane.comp.version-control.git/127163/focus=127215
Yes, you brought up the "remote state as of the time I told git to record
it is a precious piece of information" issue, and I share the reasoning,
hence I am somewhat torn.
We might be better off biting the bullet and do the "rewrite a command
line colon-less refspec using a matching configured refspec iff exists"
and defer the history of remote tracking branches to its reflog in the
longer term.
^ permalink raw reply
* [PATCH] resolve_gitlink_packed_ref(): fix mismerge
From: Junio C Hamano @ 2011-10-17 18:43 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Mark Levedahl, git
In-Reply-To: <7v4nz7o7mg.fsf@alter.siamese.dyndns.org>
2c5c66b (Merge branch 'jp/get-ref-dir-unsorted', 2011-10-10) merged a
topic that forked from the mainline before a new helper function
get_packed_refs() refactored code to read packed-refs file. The merge made
the call to the helper function with an incorrect argument. The parameter
to the function has to be a path to the submodule.
Fix the mismerge.
Helped-by: Mark Levedahl <mlevedahl@gmail.com>
Helped-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> ...
>> The problem is that the parameter "name" is not NUL-terminated. The old
>> code turned it into a (NUL-terminated) filename via
>>
>> strcpy(name + pathlen, "packed-refs");
>>
>> but the new code passes it (unterminated) to get_packed_refs()
Let's do this on the 'master' front while mh/refs-api and mh/refs-api-2
(the new 14 patch series) are cooking in the 'next' branch. The added
test does not pass until the second-to-last patch in your new series.
I made trial merges of this with mh/refs-api and mh/refs-api-2 and both
were trivial to resolve (merge with mh/refs-api will keep the fix, and
merge with mh/refs-api-2 can be made by dropping this change), so this is
purely as interim fix plus---the value of the patch lies primarily in the
test for regression avoidance.
refs.c | 12 +++++++++++-
t/t3000-ls-files-others.sh | 19 +++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 9911c97..cab4394 100644
--- a/refs.c
+++ b/refs.c
@@ -393,12 +393,22 @@ static struct ref_array *get_loose_refs(const char *submodule)
#define MAXDEPTH 5
#define MAXREFLEN (1024)
+/*
+ * Called by resolve_gitlink_ref_recursive() after it failed to read
+ * from "name", which is "module/.git/<refname>". Find <refname> in
+ * the packed-refs file for the submodule.
+ */
static int resolve_gitlink_packed_ref(char *name, int pathlen, const char *refname, unsigned char *result)
{
int retval = -1;
struct ref_entry *ref;
- struct ref_array *array = get_packed_refs(name);
+ struct ref_array *array;
+ /* being defensive: resolve_gitlink_ref() did this for us */
+ if (pathlen < 6 || memcmp(name + pathlen - 6, "/.git/", 6))
+ die("Oops");
+ name[pathlen - 6] = '\0'; /* make it path to the submodule */
+ array = get_packed_refs(name);
ref = search_ref_array(array, refname);
if (ref != NULL) {
memcpy(result, ref->sha1, 20);
diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh
index 2eec011..e9160df 100755
--- a/t/t3000-ls-files-others.sh
+++ b/t/t3000-ls-files-others.sh
@@ -65,4 +65,23 @@ test_expect_success '--no-empty-directory hides empty directory' '
test_cmp expected3 output
'
+test_expect_success SYMLINKS 'ls-files --others with symlinked submodule' '
+ git init super &&
+ git init sub &&
+ (
+ cd sub &&
+ >a &&
+ git add a &&
+ git commit -m sub &&
+ git pack-refs --all
+ ) &&
+ (
+ cd super &&
+ "$TEST_DIRECTORY/../contrib/workdir/git-new-workdir" ../sub sub
+ git ls-files --others --exclude-standard >../actual
+ ) &&
+ echo sub/ >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.7.7.370.gefe43
^ permalink raw reply related
* Re: [PATCH v4 0/7] Provide API to invalidate refs cache
From: Heiko Voigt @ 2011-10-17 18:47 UTC (permalink / raw)
To: mhagger
Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski,
Johan Herland, Julian Phillips
In-Reply-To: <1318819091-7066-1-git-send-email-mhagger@alum.mit.edu>
Hi,
On Mon, Oct 17, 2011 at 04:38:04AM +0200, mhagger@alum.mit.edu wrote:
> I won't myself have time to figure out who, outside of refs.c, has to
> *call* invalidate_ref_cache(). The candidates that I know off the top
> of my head are git-clone, git-submodule [1], and git-pack-refs. It
> would be great if experts in those areas would insert calls to
> invalidate_ref_cache() where needed.
[...]
> [1] http://marc.info/?l=git&m=131827641227965&w=2
> In this mailing list thread, Heiko Voigt stated that git-submodule
> does not modify any references, so it should not have to use the
> API.
This is not entirely true. I was saying that my submodule-merge code is
currently the only one using the refs api for submodules and that does
not need to modify submodule refs. I imagine that there will be some
users when submodule support matures (e.g. recursive push).
Cheers Heiko
^ permalink raw reply
* Re: [PATCH 3/3] git-gui: new config to control staging of untracked files
From: Bert Wesarg @ 2011-10-17 18:47 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Pat Thoyts, git
In-Reply-To: <20111017183430.GA2540@sandbox-rc>
On Mon, Oct 17, 2011 at 20:34, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> Hi,
>
> what the series tries to achieve looks good to me. Just one comment.
Thanks.
>
> On Fri, Oct 14, 2011 at 09:25:21PM +0200, Bert Wesarg wrote:
> [...]
>> diff --git a/lib/index.tcl b/lib/index.tcl
>> index 014acf9..45094c2 100644
>> --- a/lib/index.tcl
>> +++ b/lib/index.tcl
>> @@ -367,7 +367,19 @@ proc do_add_all {} {
>> }
>> }
>> if {[llength $untracked_paths]} {
>> - set reply [ask_popup [mc "Stage also untracked files?"]]
>> + set reply 0
>> + switch -- [get_config gui.stageuntracked] {
>> + no {
>> + set reply 0
>> + }
> [...]
>
> Here I am wondering whether we have a similar mechanism in git gui like
> in core git that makes yes,true,1 equivalents (and similar with other
> values) ?
But it is not only yes,true,1 or no,false,0 its a tristate with the
third state 'ask'. For booleans, there is such functionality in git
gui. See is_config_true and is_config_false. Reusing these for this
tristate wouldn't work. The current check here is indeed very strict
and should be loosen by at least ignoring the case, surrounding
spaces, and allow also true/false. But also note, that this variable
can be set via the Options menu, so you can't mistype it.
Bert
> If we don't I think the series is fine as it is otherwise it
> probably makes sense to use that mechanism.
>
> Cheers Heiko
>
^ permalink raw reply
* Re: [PATCH] Git-p4: git-p4.changeOnSubmit to do 'change' instead of 'submit'.
From: Luke Diamand @ 2011-10-17 18:53 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: git, gitster, Pete Wyckoff, Andrei Warkentin
In-Reply-To: <83923897.7841.1318868319131.JavaMail.root@zimbra-prod-mbox-2.vmware.com>
On 17/10/11 17:18, Andrei Warkentin wrote:
> Hi,
>
> ----- Original Message -----
> Anyway, the other suggestion I had was to create a new command
> instead of overriding behaviour of an existing one. Of course,
> copy-pasting P4Submit into P4Change is silly, so...
>
> How about something like this?
>
> The commands dict maps command name to class and optional dict passed to cmd.run(). That way 'change'
> can really mean P4Submit with an extra parameter not to submit but to do a changelist instead. The
> reason why I initially made the config flag was because I didn't want to copy-paste P4Submit into P4Change.
>
> commands = {
> "debug" : [ P4Debug, {} ]
> "submit" : [ P4Submit, { "doChange" : 0 } ]
> "commit" : [ P4Submit, { "doChange" : 0 } ]
> "change" : [ P4Submit, { "doChange" : 1 } ]
> "sync" : [ P4Sync, {} ],
> "rebase" : [ P4Rebase, {} ],
> "clone" : [ P4Clone, {} ],
> "rollback" : [ P4RollBack, {} ],
> "branches" : [ P4Branches, {} ]
> }
>
> Thanks for the review,
> A
>
Sounds plausible to me. The alternative would be a command line
parameter, although that could get annoying and error prone, especially
as you can't easily unsubmit a perforce change.
^ permalink raw reply
* Re: [PATCH/RFC 1/2] gitweb: change format_diff_line() to remove leading SP from $diff_class
From: Junio C Hamano @ 2011-10-17 19:02 UTC (permalink / raw)
To: Kato Kazuyoshi; +Cc: git
In-Reply-To: <CAFo4x0LP4fXgSNAnss_WRLo-TH_qe=esYn7P+=iS6t87tdzcbw@mail.gmail.com>
Kato Kazuyoshi <kato.kazuyoshi@gmail.com> writes:
> The format_diff_line() will return $diff_class and HTML in upcoming changes.
An auxiliary piece of information like this is fine at the end of the
commit log message, but the patch itself wants to be justified
standalone. Perhaps this should be sufficient:
The $diff_class variable to classify the kind of line in the diff
output was prefixed with a SP, only so that the code to synthesize
value for "class" attribute can blindly concatenate it with
another value "diff". This made the code unnecessarily ugly.
Instead, add SP that separates the value of $diff_class from
another class value "diff" where <div class="..."> string is
created and drop the leading SP from the value of $diff_class.
Explained this way, it does not even have to mention that the return value
will be changed in a different patch.
We all know that the hidden motivation of this change is that the caller
of this function, after it starts using the returned value of $diff_class,
does not want to worry about the ugly SP prefix in that variable. Saying
only "This function will return this variable in the future" still does
not fully explain that hidden motivation unless you say "and the caller
shouldn't have to worry about the leading SP", so let's not even mention
it in the log message of this change.
> ---
Sign-off?
> gitweb/gitweb.perl | 24 +++++++++++++-----------
> 1 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 85d64b2..095adda 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2235,28 +2235,30 @@ sub format_diff_line {
> ...
> +
> + my $div_open = '<div class="' . (join ' ', ('diff', $diff_class)) . '">';
I think using a separate helper variable like this is a good change. You
do not have to worry about the issue in three different places.
But doesn't join(" ", ("frotz", "")) still give you "frotz "? It is OK to
punt and say
my $div_open = '<div class="diff $diff_class">';
which would be far easier to read. It may sacrifice a bit of tidiness in
the resulting HTML but the tidiness of the source outweighs it.
Of course, if you have tons of classes, it may be worth doing something
like
join(" ", grep { defined $_ && $_ ne ""} @diff_classes);
but I do not think it is worth it in this particular case.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 00/14] Tidying up references code
From: Junio C Hamano @ 2011-10-17 19:12 UTC (permalink / raw)
To: mhagger
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <1318837163-27112-1-git-send-email-mhagger@alum.mit.edu>
mhagger@alum.mit.edu writes:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
> Patch series re-rolled against v4 of "Provide API to invalidate refs
> cache"...
Thanks; queued (but not pushed out yet).
> BTW, whenever I add comments to existing code, it is just an attempt
> to record information that I have inferred from reverse-engineering.
Thanks again. I often find me scratching head while reading other people's
code, long after I reviewed (or read other's reviews) and accepted their
patches. It often is not the lack of review that caused undercommented
code to get in my tree. During the review process, the issue the code is
trying to solve is so fresh in everybody's mind, that certain things do
not need to be explained to be understood. But that kind of memory
eventually fades and only the code remains.
It is a rather unfortunate result of the human nature that the next person
who touches that code is in the best position to find out what aspect of
the code is hard to understand and deserves comment.
^ permalink raw reply
* Re: Re: [PATCH 3/3] git-gui: new config to control staging of untracked files
From: Heiko Voigt @ 2011-10-17 19:27 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Pat Thoyts, git
In-Reply-To: <CAKPyHN3pKUSLTs8_5QMo5i+=3w7KXAHJjDOfQ1XYG92ZbQ1SeA@mail.gmail.com>
Hi,
On Mon, Oct 17, 2011 at 08:47:50PM +0200, Bert Wesarg wrote:
> On Mon, Oct 17, 2011 at 20:34, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> > Here I am wondering whether we have a similar mechanism in git gui like
> > in core git that makes yes,true,1 equivalents (and similar with other
> > values) ?
>
> But it is not only yes,true,1 or no,false,0 its a tristate with the
> third state 'ask'. For booleans, there is such functionality in git
> gui. See is_config_true and is_config_false. Reusing these for this
> tristate wouldn't work. The current check here is indeed very strict
> and should be loosen by at least ignoring the case, surrounding
> spaces, and allow also true/false. But also note, that this variable
> can be set via the Options menu, so you can't mistype it.
Well if using git config you can ;-). I just wanted to ask whether we
may already have machinery which supports such tristate.
If we do not I think the current "strict" configuration is fine. In most
cases the user will use the gui itself to configure such behavior so
thats no big deal.
If someone needs that it can be added later on.
Thanks, Heiko
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: add a feature to show side-by-side diff
From: Junio C Hamano @ 2011-10-17 19:37 UTC (permalink / raw)
To: Kato Kazuyoshi; +Cc: git
In-Reply-To: <CAFo4x0L4BAKnCDa1uEK0Rskd9kTsR-94D4mkYKnLGqVDnuyuBA@mail.gmail.com>
Kato Kazuyoshi <kato.kazuyoshi@gmail.com> writes:
> @@ -2276,7 +2279,7 @@ sub format_diff_line {
> }
> $line = "<span class=\"chunk_info\">@@ $from_text $to_text @@</span>" .
> "<span class=\"section\">" . esc_html($section, -nbsp=>1) .
> "</span>";
Corrupt patch (wrapped long line); please fix.
I suspect you have similar issues in the [PATCH 1/2] message, too.
^ permalink raw reply
* Re: [PATCH v4 0/7] Provide API to invalidate refs cache
From: Michael Haggerty @ 2011-10-17 19:43 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski,
Johan Herland, Julian Phillips
In-Reply-To: <20111017184708.GB2540@sandbox-rc>
On 10/17/2011 08:47 PM, Heiko Voigt wrote:
> On Mon, Oct 17, 2011 at 04:38:04AM +0200, mhagger@alum.mit.edu wrote:
>> [1] http://marc.info/?l=git&m=131827641227965&w=2
>> In this mailing list thread, Heiko Voigt stated that git-submodule
>> does not modify any references, so it should not have to use the
>> API.
>
> This is not entirely true. I was saying that my submodule-merge code is
> currently the only one using the refs api for submodules and that does
> not need to modify submodule refs. I imagine that there will be some
> users when submodule support matures (e.g. recursive push).
Sorry for misunderstanding/misrepresenting you; thanks for the
clarification.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 2/2] daemon: report permission denied error to clients
From: Clemens Buchacher @ 2011-10-17 19:48 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20111017020912.GB18536@sigill.intra.peff.net>
On Sun, Oct 16, 2011 at 10:09:12PM -0400, Jeff King wrote:
> On Mon, Oct 17, 2011 at 12:11:16AM +0200, Clemens Buchacher wrote:
>
> > If passed an inaccessible url, git daemon returns the
> > following error:
> >
> > $ git clone git://host/repo
> > fatal: remote error: no such repository: /repo
> >
> > In case of a permission denied error, return the following
> > instead:
> >
> > fatal: remote error: permission denied: /repo
> >
> > Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> > ---
>
> I like the intent. This actually does leak a little more information
> than the existing --informative-errors, as before you couldn't tell the
> difference between "not found" and "not exported".
I think you mean that before, you couldn't tell the difference
between "not found" and "permission denied".
> > -static char *path_ok(char *directory)
> > +static int path_ok(char *directory, const char **return_path)
> > {
> > static char rpath[PATH_MAX];
> > static char interp_path[PATH_MAX];
> > @@ -120,13 +120,13 @@ static char *path_ok(char *directory)
> >
> > if (daemon_avoid_alias(dir)) {
> > logerror("'%s': aliased", dir);
> > - return NULL;
> > + return -1;
> > }
> >
> > if (*dir == '~') {
> > if (!user_path) {
> > logerror("'%s': User-path not allowed", dir);
> > - return NULL;
> > + return EACCES;
>
> The new calling conventions for this function seem a little weird. I
> would expect either "return negative, and set errno" for usual library
> code, or possibly "return negative error value". But "return -1, or a
> positive error code" seems unusual to me.
Yes indeed, will fix.
Clemens
^ permalink raw reply
* Re: [PATCH 2/2] daemon: report permission denied error to clients
From: Jeff King @ 2011-10-17 19:51 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20111017194821.GA29479@ecki>
On Mon, Oct 17, 2011 at 09:48:21PM +0200, Clemens Buchacher wrote:
> > I like the intent. This actually does leak a little more information
> > than the existing --informative-errors, as before you couldn't tell the
> > difference between "not found" and "not exported".
>
> I think you mean that before, you couldn't tell the difference
> between "not found" and "permission denied".
Ah, right. Sorry, I was thinking path_ok handled the export-ok flag, but
I already handled it in my patch to run_service. So it is leaking a
little more, but even less than I indicated. And at any rate, I think it
is consistent with what --informative-errors is meant to do, so it's a
good change.
> > The new calling conventions for this function seem a little weird. I
> > would expect either "return negative, and set errno" for usual library
> > code, or possibly "return negative error value". But "return -1, or a
> > positive error code" seems unusual to me.
>
> Yes indeed, will fix.
Thanks.
-Peff
^ permalink raw reply
* [PATCH] use test number as port number
From: Clemens Buchacher @ 2011-10-17 19:55 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20111017020103.GA18536@sigill.intra.peff.net>
Test 5550 was apparently using the default port number by mistake.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Sun, Oct 16, 2011 at 10:01:03PM -0400, Jeff King wrote:
>
> LIB_DAEMON_PORT=${LIB_DAEMON_PORT-'5570'}
Thanks, I missed that.
Clemens
t/t5550-http-fetch.sh | 2 +-
t/t5570-git-daemon.sh | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t5550-http-fetch.sh b/t/t5550-http-fetch.sh
index a1883ca..8a77750 100755
--- a/t/t5550-http-fetch.sh
+++ b/t/t5550-http-fetch.sh
@@ -8,8 +8,8 @@ if test -n "$NO_CURL"; then
test_done
fi
-. "$TEST_DIRECTORY"/lib-httpd.sh
LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5550'}
+. "$TEST_DIRECTORY"/lib-httpd.sh
start_httpd
test_expect_success 'setup repository' '
diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
index e6482eb..a92d996 100755
--- a/t/t5570-git-daemon.sh
+++ b/t/t5570-git-daemon.sh
@@ -3,6 +3,7 @@
test_description='test fetching over git protocol'
. ./test-lib.sh
+LIB_DAEMON_PORT=${LIB_DAEMON_PORT-'5570'}
. "$TEST_DIRECTORY"/lib-daemon.sh
start_daemon
--
1.7.7
^ permalink raw reply related
* [PATCH v2 2/2] daemon: report permission denied error to clients
From: Clemens Buchacher @ 2011-10-17 19:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <1318803076-4229-2-git-send-email-drizzd@aon.at>
If passed an inaccessible url, git daemon returns the
following error:
$ git clone git://host/repo
fatal: remote error: no such repository: /repo
In case of a permission denied error, return the following
instead:
fatal: remote error: permission denied: /repo
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Compared to v1 of this patch, the calling convention of path_ok are
back to what they were previously. Now the only change is that it
sets errno.
daemon.c | 15 +++++++++++++--
path.c | 31 +++++++++++++++++++++----------
t/t5570-git-daemon.sh | 2 +-
3 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/daemon.c b/daemon.c
index 72fb53a..2f7f84e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -120,12 +120,14 @@ static char *path_ok(char *directory)
if (daemon_avoid_alias(dir)) {
logerror("'%s': aliased", dir);
+ errno = 0;
return NULL;
}
if (*dir == '~') {
if (!user_path) {
logerror("'%s': User-path not allowed", dir);
+ errno = EACCES;
return NULL;
}
if (*user_path) {
@@ -158,6 +160,7 @@ static char *path_ok(char *directory)
if (*dir != '/') {
/* Allow only absolute */
logerror("'%s': Non-absolute path denied (interpolated-path active)", dir);
+ errno = EACCES;
return NULL;
}
@@ -173,6 +176,7 @@ static char *path_ok(char *directory)
if (*dir != '/') {
/* Allow only absolute */
logerror("'%s': Non-absolute path denied (base-path active)", dir);
+ errno = EACCES;
return NULL;
}
snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
@@ -190,7 +194,9 @@ static char *path_ok(char *directory)
}
if (!path) {
+ int err = errno;
logerror("'%s' does not appear to be a git repository", dir);
+ errno = err;
return NULL;
}
@@ -221,6 +227,7 @@ static char *path_ok(char *directory)
}
logerror("'%s': not in whitelist", path);
+ errno = EACCES;
return NULL; /* Fallthrough. Deny by default */
}
@@ -269,8 +276,12 @@ static int run_service(char *dir, struct daemon_service *service)
return daemon_error(dir, "service not enabled");
}
- if (!(path = path_ok(dir)))
- return daemon_error(dir, "no such repository");
+ if (!(path = path_ok(dir))) {
+ if (errno == EACCES)
+ return daemon_error(dir, "permission denied");
+ else
+ return daemon_error(dir, "no such repository");
+ }
/*
* Security on the cheap.
diff --git a/path.c b/path.c
index 6f3f5d5..227d8d7 100644
--- a/path.c
+++ b/path.c
@@ -288,6 +288,7 @@ char *enter_repo(char *path, int strict)
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
+ errno = 0;
if (!path)
return NULL;
@@ -301,12 +302,15 @@ char *enter_repo(char *path, int strict)
path[len-1] = 0;
len--;
}
- if (PATH_MAX <= len)
+ if (PATH_MAX <= len) {
+ errno = ENAMETOOLONG;
return NULL;
+ }
if (path[0] == '~') {
char *newpath = expand_user_path(path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
+ errno = 0;
return NULL;
}
/*
@@ -319,9 +323,10 @@ char *enter_repo(char *path, int strict)
strcpy(validated_path, path);
path = used_path;
}
- else if (PATH_MAX - 10 < len)
+ else if (PATH_MAX - 10 < len) {
+ errno = ENAMETOOLONG;
return NULL;
- else {
+ } else {
path = strcpy(used_path, path);
strcpy(validated_path, path);
}
@@ -331,23 +336,29 @@ char *enter_repo(char *path, int strict)
if (!access(path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
+ } else if (errno == EACCES) {
+ return NULL;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i])
+ return NULL;
+ if (chdir(path))
return NULL;
path = validated_path;
}
else if (chdir(path))
return NULL;
- if (access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
- validate_headref("HEAD") == 0) {
- set_git_dir(".");
- check_repository_format();
- return path;
+ if (access("objects", X_OK) || access("refs", X_OK))
+ return NULL;
+ if (validate_headref("HEAD")) {
+ errno = 0;
+ return NULL;
}
- return NULL;
+ set_git_dir(".");
+ check_repository_format();
+ return path;
}
int set_shared_perm(const char *path, int mode)
diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
index aa5771a..e6482eb 100755
--- a/t/t5570-git-daemon.sh
+++ b/t/t5570-git-daemon.sh
@@ -141,7 +141,7 @@ start_daemon --informative-errors
test_expect_success 'clone non-existent' "test_remote_error clone nowhere.git 'no such repository'"
test_expect_success 'push disabled' "test_remote_error push repo.git 'service not enabled'"
-test_expect_success 'read access denied' "test_remote_error -x fetch repo.git 'no such repository'"
+test_expect_success 'read access denied' "test_remote_error -x fetch repo.git 'permission denied'"
test_expect_success 'not exported' "test_remote_error -n fetch repo.git 'repository not exported'"
stop_daemon
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 1/2] daemon: add tests
From: Clemens Buchacher @ 2011-10-17 20:05 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20111017020103.GA18536@sigill.intra.peff.net>
On Sun, Oct 16, 2011 at 10:01:03PM -0400, Jeff King wrote:
>
> Thanks, it's nice to have some tests. Overall, some of the tests feel a
> little silly, because the results should be exactly the same as fetching
> or pushing a local repository (so the "set-head" thing, for example,
> really has little to do with git-daemon).
Hmm, yes. Actually, I thought I had found a bug with the failure of
"set-head -a". But now I see that in t5505 this treated like a
feature.
Would it be difficult to support this over the git protocol? Maybe
I will have a look.
Clemens
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jeff King @ 2011-10-17 20:08 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20111017200528.GA19054@ecki>
On Mon, Oct 17, 2011 at 10:05:28PM +0200, Clemens Buchacher wrote:
> On Sun, Oct 16, 2011 at 10:01:03PM -0400, Jeff King wrote:
> >
> > Thanks, it's nice to have some tests. Overall, some of the tests feel a
> > little silly, because the results should be exactly the same as fetching
> > or pushing a local repository (so the "set-head" thing, for example,
> > really has little to do with git-daemon).
>
> Hmm, yes. Actually, I thought I had found a bug with the failure of
> "set-head -a". But now I see that in t5505 this treated like a
> feature.
It's not a feature, exactly. It's just documenting that we fail in the
face of ambiguous HEADs. Arguably, the test should be switched to use
text_expect_failure to document that we would prefer it the other way,
but it doesn't work now.
> Would it be difficult to support this over the git protocol? Maybe
> I will have a look.
It needs a protocol extension to communicate symbolic ref destinations.
The topic has come up a few times, and I think Junio even had patches at
one point.
-Peff
^ permalink raw reply
* [PATCH] Allow to specify the editor used for git rebase -i by config/environment var
From: Peter Oberndorfer @ 2011-10-17 20:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Phil Hord
The search order for choosing the sequence editor is:
$GIT_SEQUENCE_EDITOR
git config sequence.editor
git var GIT_EDITOR (default editor for commit messages)
With this change is it possible to have a separate
(possibly graphical) editor that helps the user
during a interactive rebase.
Using $GIT_EDITOR or core.editor config var for this is not possible
since they is also used to start the commit message editor for reword action.
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
---
I reworded the commit message and the config description a bit.
renamed to sequence.editor / $GIT_SEQUENCE_EDITOR
and moved the helper to git-rebase--interactive.sh
Documentation/config.txt | 7 +++++++
git-rebase--interactive.sh | 15 ++++++++++++++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 03296b7..048c5f9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -473,6 +473,13 @@ core.editor::
variable when it is set, and the environment variable
`GIT_EDITOR` is not set. See linkgit:git-var[1].
+sequence.editor::
+ Text editor used by git rebase -i for editing the rebase todo file.
+ The value is meant to be interpreted by the shell when it is used.
+ It can be overridden by the 'GIT_SEQUENCE_EDITOR' environment variable.
+ When not configured the default commit message editor is used instead.
+ See linkgit:git-var[1]
+
core.pager::
The command that git will use to paginate output. Can
be overridden with the `GIT_PAGER` environment
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 94f36c2..13a0661 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -161,6 +161,19 @@ do_with_author () {
)
}
+git_sequence_editor() {
+ if test -z "${GIT_SEQUENCE_EDITOR:+set}"
+ then
+ GIT_SEQUENCE_EDITOR="$(git config sequence.editor)"
+ if [ -z "$GIT_SEQUENCE_EDITOR" ]
+ then
+ GIT_SEQUENCE_EDITOR="$(git var GIT_EDITOR)" || return $?
+ fi
+ fi
+
+ eval "$GIT_SEQUENCE_EDITOR" '"$@"'
+}
+
pick_one () {
ff=--ff
case "$1" in -n) sha1=$2; ff= ;; *) sha1=$1 ;; esac
@@ -832,7 +845,7 @@ has_action "$todo" ||
die_abort "Nothing to do"
cp "$todo" "$todo".backup
-git_editor "$todo" ||
+git_sequence_editor "$todo" ||
die_abort "Could not execute editor"
has_action "$todo" ||
--
1.7.7.329.g2140c
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox