* Re: [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpqe1cbds.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 8:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> In any case, there's no need for ad hominem arguments; there is a
>> problem when using zsh, that's a fact.
>
> There was no ad-hominem argument at all.
>
> Read your two lines I quoted "... the code is now actually understandable
> (at least to me), while before it looked like voodoo", which was your
> words. What does it tell the reader? The patch author (1) did not
> understand existing code (voodoo) and (2) the change is a good thing as a
> style/readability improvement.
I disagree. Another possibility is that the code actually looked like
voodoo (it was obfuscated). You might disagree, but the fact that one
of the main editors (the most used?) doesn't even recognize the syntax
of this code I think is pretty telling.
> I was saying that I did not want to see that in the justification, because
> (2) is not true, while (1) may be.
That's not true: (2) might be true; at least it's debatable.
> The patch as-is is a good change that works around issues with zsh's POSIX
> emulation, and that is sufficient-enough justification. IOW, we are in
> agreement on the later half of your sentence.
So, I shall just remove that part of the explanation?
--
Felipe Contreras
^ permalink raw reply
* Re: Why does git stash create two commits?
From: Seth Robertson @ 2012-01-30 18:25 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4F26DF7B.7050109@ubuntu.com>
In message <4F26DF7B.7050109@ubuntu.com>, Phillip Susi writes:
git stash makes two commits, one that has no changes from the base,
and one to stash your changes in. Why?
git-stash can make up to three commits:
working directory (of files git knows about)
index
working directory (of files git does not know about)
The third commit only appears if you use --all or --include-untracked.
Most likely you do not use -u/-a and your index has not been touched
yet, so you only see two commits, of which one is empty.
-Seth Robertson
^ permalink raw reply
* Re: [PATCH v2 4/4] completion: be nicer with zsh
From: Jonathan Nieder @ 2012-01-30 18:25 UTC (permalink / raw)
To: Felipe Contreras
Cc: Felipe Contreras, git, Lee Marlow, Shawn O. Pearce,
SZEDER Gábor
In-Reply-To: <CAMP44s0ACC+AnwHGtBLe8C1S_sxWj6SbMbawDThvLQAA0pKMYQ@mail.gmail.com>
Felipe Contreras wrote:
> The commands might fail, that's why '2> /dev/null' was used before,
> and ':' is used right now.
Wait, what?
: is a no-op command. It does not redirect stderr automatically or
do any other magical thing.
[...]
> And IMO harder to read. But you are correct that most of the code uses
> [[]], which I think is a shame. But I guess people want to keep using
> that.
[[ has simpler syntax wrt quoting and other details. But now that I
check, the code uses [ a lot, too (which, like "test", is a plain
built-in command), so I suppose consistency is the only reason to
prefer one over another. "git log --grep='if \['" tells me the use of
'[' instead of 'test' here is deliberate.
^ permalink raw reply
* Re: [PATCH v2 1/4] completion: simplify __git_remotes
From: Junio C Hamano @ 2012-01-30 18:27 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, git, Felipe Contreras, Shawn O. Pearce,
SZEDER Gábor
In-Reply-To: <20120130173446.GF10618@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Felipe Contreras wrote:
>
>> From: Felipe Contreras <felipe.contreras@gmail.com>
>>
>> There's no need for all that complicated code that requires nullglob,
>> and the complexities related to such option.
>>
>> As an advantage, this would allow us to get rid of __git_shopt, which is
>> used only in this fuction to enable 'nullglob' in zsh.
>
> That is all a longwinded way to say "zsh doesn't support the same
> interface as bash for setting the nullglob option, so let's avoid
> it and use 'ls' which is simpler", right?
;-)
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 1496c6d..086e38d 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -644,12 +644,7 @@ __git_refs_remotes ()
>> __git_remotes ()
>> {
>> local i ngoff IFS=$'\n' d="$(__gitdir)"
>> - __git_shopt -q nullglob || ngoff=1
>> - __git_shopt -s nullglob
>> - for i in "$d/remotes"/*; do
>> - echo ${i#$d/remotes/}
>> - done
>> - [ "$ngoff" ] && __git_shopt -u nullglob
>> + test -d "$d/remotes" && ls -1 "$d/remotes"
Yeah, very nice reduction of unnecessary code.
The original loop might have been justifiable if it were doing something
more meaningful inside (e.g. making sure the file really describes a
remote), but as far as I can tell, it merely is a poor-man's emulation of
"ls -1".
You updated it to make the code say what it wanted to say in the way it
should have said from day one ;-).
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Junio C Hamano @ 2012-01-30 18:48 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4F263AEE.4080409@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> [3] If commit 0000000 were treated specially, then there would be no
> unborn branches but only branches pointing at the empty commit. In that
> case, my expectation would change--the old branch should be left
> pointing at 0000000. But currently git has no concept of an unborn
> branch that is not HEAD.
And it probably is not a good thing to add such. Under that constraints,
HEAD that says refs/heads/foo where foo does not exist yet needs to be
special cased at places where it matters.
For that matter, even if we artificially created refs/heads/foo before any
commit is made and made it point at 0{40}, you would need to add special
cases to other parts of the system (e.g. "commit" needs to notice that the
result should be a root, not a child of 0{40}; "checkout other_branch"
needs to notice that it should refrain from running the equivalent of
"read-tree -m HEAD other_branch" because HEAD does not point at a real
tree; etc.), so it does not change the fact that the unborn branch is case
is special.
Note that I am not saying that we shouldn't add support for special cases
with special case codepaths.
Perhaps we would need to sprinkle more special case magic like this (this
is for the special case that arises from the same cause)?
builtin/branch.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7095718..0997e75 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -640,6 +640,13 @@ static int edit_branch_description(const char *branch_name)
struct strbuf buf = STRBUF_INIT;
struct strbuf name = STRBUF_INIT;
+ strbuf_addf(&name, "refs/heads/%s", branch_name);
+ if (!ref_exists(name.buf)) {
+ strbuf_reset(&name);
+ return error("No such branch '%s'.", branch_name);
+ }
+ strbuf_reset(&name);
+
read_branch_desc(&buf, branch_name);
if (!buf.len || buf.buf[buf.len-1] != '\n')
strbuf_addch(&buf, '\n');
^ permalink raw reply related
* Re: [PATCH] completion: add new zsh completion
From: Junio C Hamano @ 2012-01-30 18:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, Felipe Contreras, git
In-Reply-To: <4F267AC9.1080407@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> Something along the lines of
>>
>> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>
>> should do it (mostly untested, and written by a non-ZSH expert).
>
> Moreover, if zsh is POSIX compliant, the value of ZSH_VERSION will be an
> empty string after this statement. That may or (more likely) may not be
> what you want.
As this split-file is about only zsh completion, it can be as non-POSIX as
it wants, and it appears that zsh is not striving to be POSIX compliant,
judging from Felipe's other messages.
Whatever works for zsh is just fine.
^ permalink raw reply
* Re: [PATCH v2 4/4] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 18:56 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, git, Lee Marlow, Shawn O. Pearce,
SZEDER Gábor
In-Reply-To: <20120130182547.GA22549@burratino>
On Mon, Jan 30, 2012 at 8:25 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> The commands might fail, that's why '2> /dev/null' was used before,
>> and ':' is used right now.
>
> Wait, what?
>
> : is a no-op command. It does not redirect stderr automatically or
> do any other magical thing.
Why don't you go ahead and try it?
bash -c ': echo "err" > /dev/stderr'
I don't see anything here.
But actually, if I use $(echo "err" > /dev/stderr); _then_ I get
something. Smells a lot like a bug to me.
In any case, if you expected ':' to print errors, now I understand why
you removed 2>/dev/null in eaa4e6e.
> [...]
>> And IMO harder to read. But you are correct that most of the code uses
>> [[]], which I think is a shame. But I guess people want to keep using
>> that.
>
> [[ has simpler syntax wrt quoting and other details. But now that I
> check, the code uses [ a lot, too (which, like "test", is a plain
> built-in command), so I suppose consistency is the only reason to
> prefer one over another. "git log --grep='if \['" tells me the use of
> '[' instead of 'test' here is deliberate.
Maybe '[' then.
--
Felipe Contreras
^ permalink raw reply
* Re: i18n: Avoid sentence puzzles
From: Junio C Hamano @ 2012-01-30 18:57 UTC (permalink / raw)
To: Frederik Schwarzer; +Cc: git
In-Reply-To: <201201301231.21090.schwarzerf@gmail.com>
Frederik Schwarzer <schwarzerf@gmail.com> writes:
> So my question would be: Is it considered worth it to extend the code
> for translators' and translations' sake? If so, I would be glad to
> help with that.
The sample you supplied for 'branch' vs 'remote branch' is a good change
in the logic to choose what translatable message to use, and I do suspect
that there are other instances of problems of this kind.
I am expecting that we may see some activity to the logic in that file
during this cycle, and we would need to be careful not make people step on
other people's toes, though.
^ permalink raw reply
* Re: [PATCH v2 4/4] completion: be nicer with zsh
From: Jonathan Nieder @ 2012-01-30 19:03 UTC (permalink / raw)
To: Felipe Contreras
Cc: Felipe Contreras, git, Lee Marlow, Shawn O. Pearce,
SZEDER Gábor
In-Reply-To: <CAMP44s1SzE1h+4Eoebr2LrnLNgFX1UE2+O8z6yYDuukmaijf7Q@mail.gmail.com>
Felipe Contreras wrote:
> On Mon, Jan 30, 2012 at 8:25 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> : is a no-op command. It does not redirect stderr automatically or
>> do any other magical thing.
>
> Why don't you go ahead and try it?
>
> bash -c ': echo "err" > /dev/stderr'
: is a no-op command. If you have any questions after reading about
it in your manual or online help system of choice, I'll be happy to
answer them.
[...]
> Maybe '[' then.
Honestly, I don't care. :)
(If I had to choose a convention for scripts specific to ksh-style
shells, in order of preference, I would rank them:
1. Always use [[.
2. Use "test", spelled out, like the portable shell code in git does.
3. Use [.
If you have arguments for one convention or another that are
compelling enough that the codebase won't be flipping back and forth
and a patch to go along with them, I imagine no one will mind.)
By the way, since I forget to say enough: thanks for taking care about
this code. Simpler code is definitely a good thing.
Regards,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 3/4] completion: cleanup __gitcomp*
From: Junio C Hamano @ 2012-01-30 19:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, git, Felipe Contreras, Ted Pavlic,
SZEDER Gábor, Shawn O. Pearce
In-Reply-To: <20120130175004.GG10618@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> I imagine it would have been enough to say something along the lines of
> "The __gitcomp and __gitcomp_nl functions are unnecessarily verbose.
> __gitcomp_nl sets IFS to " \t\n" unnecessarily before setting it to "\n"
> by mistake. Both functions use 'if' statements to read parameters
> with defaults, where the ${parameter:-default} idiom would be just as
> clear. By fixing these, we can make each function almost a one-liner."
>
> By the way, the subject ("clean up __gitcomp*") tells me almost as
> little as something like "fix __gitcomp*". A person reading the
> shortlog would like to know _how_ you are fixing it, or what the
> impact of the change will be --- e.g., something like "simplify
> __gitcomp and __gitcomp_nl" would be clearer.
I love both of the above two paragraphs. Thanks.
> [...]
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
> [...]
>> @@ -524,18 +520,8 @@ __gitcomp ()
>> # appended.
>> __gitcomp_nl ()
>> {
>> - local s=$'\n' IFS=' '$'\t'$'\n'
>> - local cur_="$cur" suffix=" "
>> -
>> - if [ $# -gt 2 ]; then
>> - cur_="$3"
>> - if [ $# -gt 3 ]; then
>> - suffix="$4"
>> - fi
>> - fi
>> -
>> - IFS=$s
>> - COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
>> + local IFS=$'\n'
>> + COMPREPLY=($(compgen -P "${2-}" -S "${4:- }" -W "$1" -- "${3:-$cur}"))
>
> This loses the nice name $suffix for the -S argument. Not a problem,
> just noticing.
The patch looks good, including the localness that is kept for IFS.
^ permalink raw reply
* Re: Fwd: Gitweb error
From: Jakub Narebski @ 2012-01-30 19:08 UTC (permalink / raw)
To: rajesh boyapati, git
In-Reply-To: <CA+EqV8xB6vcDrqM3EY7uRfu0c7sOj6FbMXci+5w2qgi5RSWrbw@mail.gmail.com>
On Mon, 30 Jan 2012, rajesh boyapati wrote:
> 2012/1/28 Jakub Narebski <jnareb@gmail.com>
>> On Fri, 27 Jan 2012, rajesh boyapati wrote:
>>> my $alternate = 1;
>>> for (my $i = $from; $i <= $to; $i++) {
>>> my $entry = $headlist->[$i];
>>> my %ref = %$entry;
>>> my $curr = $ref{'id'} eq $head;
>>> if ($alternate) {
>>> print "<tr class=\"dark\">\n";
>>> } else {
>>> print "<tr class=\"light\">\n";
>>> }
>>> $alternate ^= 1;
>>
>> Hmmmm... I see that we do not check if $head is defined here before using
>> it. This can happen legitimately if we are on yet to be born orphan branch
>> (so $head, which should be named $head_at, is undefined) but there exist
>> other branches (so $headlist is not empty).
>>
>> But I don't think it is what happened in your case, is it?
tldr; It did happen.
> For my git projects on gerrit, our main branch name is "base".
> We don't have any code on "master" branch.
> May be the $HEAD is looking for master branch(or checked out branch in git
> project).--> In our case, "master" is an empty branch.
> Also, In the git projects, the HEAD file is pointing to "ref:
> refs/heads/master".
> So, I think that's the reason for errors.
>
> How can I make $HEAD to point to a branch other than "master"?.
> a) I can do this by pointing HEAD file in git projects to other branch
[...]
> b) Is there any way, other than doing above step (a) ?.
> I mean I don't want to have a code on "master" branch and also I
> don't want to point HEAD file in git projects to some other branch.
> Do I need to make any modifications to "gitweb.cgi" for this?
Now that I know the source of this error, I can write test case
for it, and fix it. I'll try to do it soon.
So finally what you would need for (b) is just upgrade gitweb.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 4/4] completion: be nicer with zsh
From: Junio C Hamano @ 2012-01-30 19:09 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, Felipe Contreras, git, Lee Marlow,
Shawn O. Pearce, SZEDER Gábor
In-Reply-To: <20120130182547.GA22549@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Felipe Contreras wrote:
>
>> The commands might fail, that's why '2> /dev/null' was used before,
>> and ':' is used right now.
>
> Wait, what?
>
> : is a no-op command. It does not redirect stderr automatically or
> do any other magical thing.
s/no-op/true/ ;-)
> ..., so I suppose consistency is the only reason to
> prefer one over another.
Yes. And the script may probably use [[ very heavily.
Early return after || i.e.
A || return
B
simply looks ugly and misleading, especially when the remainder B is just
a single line. But I stopped caring about the styles in this particular
script long time ago, so...
^ permalink raw reply
* Re: git rebase and MacOS 10.7.2 file versions
From: Torsten Bögershausen @ 2012-01-30 19:11 UTC (permalink / raw)
To: Thomas Röfer; +Cc: git
In-Reply-To: <A9AB7E23-3C22-4BCC-8E25-EF2D66B57E61@dfki.de>
On 30.01.12 17:46, Thomas Röfer wrote:
> Hi,
>
> I get mysterious behavior during git rebase on MacOS 10.7.x. git reports unresolvable conflicts, stops the rebase, but afterwards the list of files that needs to be fixed is empty. git rebase --skip does not help, because then the commit is actually missing.
>
> What helps is to abort the rebase, copy the conflicting files, delete the originals and move back the copies instead. The files themselves are identical before deleting and after restoring and their access rights are also unchanged. What is actually different is that all the conflicting files so far had older versions stored by Lion's "file versions" feature. The restored copies do not have such a version history. Since "file versions" cannot be deactivated, editing a file with an application that supports it (e.g. TextEdit) will basically result in strange git conflicts later.
>
> I have tested this with a number of git versions, but the behavior is always the same.
>
> All this may simply be a bug in MacOS 10.7.x, but maybe there is a workaround for git to make this work again.
>
> Best regards,
>
> Thomas Röfer
Hi,
is that problem reproducable? It seems so.
Could provide a simple demo, what you have done and how to reproduce the error?
If that is the case, chances that we can reproduce it are much better.
And so are the chances that somebody reading this list can help you.
>Lion's "file versions" feature..
Are the files identical when you run e.g. md5sum on them?
And what does a simple "ls" from a terminal say?
/Torsten
^ permalink raw reply
* Re: Why does git stash create two commits?
From: Junio C Hamano @ 2012-01-30 19:11 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4F26DF7B.7050109@ubuntu.com>
Phillip Susi <psusi@ubuntu.com> writes:
> git stash makes two commits, one that has no changes from the base,
> and one to stash your changes in. Why?
The only reason the former is identical to the base is because you are not
incrementally building your next commit using "git add". It represents the
state of your index. The latter represents the state of the tracked files
in your working tree.
^ permalink raw reply
* Re: [PATCH v2 4/4] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 19:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Felipe Contreras, git, Lee Marlow,
Shawn O. Pearce, SZEDER Gábor
In-Reply-To: <7vliopatxg.fsf@alter.siamese.dyndns.org>
2012/1/30 Junio C Hamano <gitster@pobox.com>:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Felipe Contreras wrote:
>> ..., so I suppose consistency is the only reason to
>> prefer one over another.
>
> Yes. And the script may probably use [[ very heavily.
>
> Early return after || i.e.
>
> A || return
> B
>
> simply looks ugly and misleading, especially when the remainder B is just
> a single line. But I stopped caring about the styles in this particular
> script long time ago, so...
What would you rather use?
[ "$__git_merge_strategies" ] &&
__git_merge_strategies=$(__git_list_merge_strategies)
That's 90 characters long. Although much better without the 2>/dev/null.
if [ "$__git_merge_strategies" ]; then
__git_merge_strategies=$(__git_list_merge_strategies)
fi
That's even more lines =/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 4/4] completion: be nicer with zsh
From: Jonathan Nieder @ 2012-01-30 19:28 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Felipe Contreras, git, Lee Marlow,
Shawn O. Pearce, SZEDER Gábor
In-Reply-To: <CAMP44s0dU5zQLnen_DSONOum7P1UsPTASSkF1sJE2m7kAwx21A@mail.gmail.com>
Felipe Contreras wrote:
> What would you rather use?
>
> [ "$__git_merge_strategies" ] &&
> __git_merge_strategies=$(__git_list_merge_strategies)
>
> That's 90 characters long. Although much better without the 2>/dev/null.
>
> if [ "$__git_merge_strategies" ]; then
> __git_merge_strategies=$(__git_list_merge_strategies)
> fi
Neither, since they both have the test inverted. But I prefer to
explicitly use the "-n" operator.
[[ -n $__git_merge_strategies ]] ||
__git_merge_strategies=$(__git_list_merge_strategies)
seems as fine as any other spelling to me. It means "either this
value has already been computed and cached, or we need to compute it".
^ permalink raw reply
* [PATCH] completion: --edit and --no-edit for git-merge
From: Adrian Weimann @ 2012-01-30 19:29 UTC (permalink / raw)
To: git, gitster; +Cc: Adrian Weimann
In-Reply-To: <7vhazdcazt.fsf@alter.siamese.dyndns.org>
Signed-off-by: Adrian Weimann <adrian.weimann@googlemail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1496c6d..78be195 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1622,7 +1622,7 @@ _git_log ()
__git_merge_options="
--no-commit --no-stat --log --no-log --squash --strategy
- --commit --stat --no-squash --ff --no-ff --ff-only
+ --commit --stat --no-squash --ff --no-ff --ff-only --edit --no-edit
"
_git_merge ()
--
1.7.9
^ permalink raw reply related
* Re: git-gui Ctrl-U (unstage) broken
From: Clemens Buchacher @ 2012-01-30 19:22 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Victor Engmark, git
In-Reply-To: <877h0at7ua.fsf@fox.patthoyts.tk>
Hi Victor,
Victor Engmark <victor.engmark@gmail.com> writes:
>
> Version info:
>
> git-gui version 0.12.0.64.g89d6
> git version 1.7.1
>
> Tcl/Tk version 8.5.8
> Aspell 0.60.6, en_US
I could reproduce this issue on my Fedora 14 box at dayjob with the
git-gui package that corresponds to git version 1.7.4.4 (git-gui version
0.13.0.8.g8f855 according to git.git).
But I cannot reproduce with the current git version or even with git
1.7.1 and git-gui 0.12.0.64.g89d6 on my Arch Linux box, where I have
Tcl/Tk version 8.5.11.
I have to check which Tcl/Tk version the F14 box uses. But the bug does
not seem to depend on the git gui version. Have you tried upgrading
Tcl/Tk?
Clemens
^ permalink raw reply
* git-svn branches with revision id's in name
From: Stephen Duncan Jr @ 2012-01-30 19:42 UTC (permalink / raw)
To: git
A project I work on recently changed it's SVN structure, causing me to
do a new git svn clone. The new structure is like this:
{project}/branches/
/master
/develop
/qa
/feature
/feature1
/feature2
/release
/release1
/release2
/hotfix
/hotfix1
/hotfix2
So I set up my svn-remote sections as follows:
[svn-remote "svn"]
url = {url}
fetch = {project}/branches/master:refs/remotes/trunk
fetch = {project}/branches/develop:refs/remotes/develop
fetch = {project}/branches/qa:refs/remotes/qa
branches = {project}/branches/{feature,release,hotfix}/*:refs/remotes/*/*
This seems to have worked fine, for the most part, but unlike my
previous git-svn checkouts, it has created several branches with
revision numbers as part of the name:
$ git branch -a
* master
remotes/develop
remotes/develop@29271
remotes/develop@32463
remotes/develop@34103
remotes/feature/xyz
remotes/feature/xyz@26438
remotes/feature/xyz@27542
remotes/feature/xyz@35233
Why have these remote branches been created? What impact does this
have on my checkout? Can I remove safely remove them? How? I was
unable to figure out how to reference this behavior in order to search
for information on it.
--
Stephen Duncan Jr
www.stephenduncanjr.com
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 20:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <201201301657.12944.jnareb@gmail.com>
* Jakub Narebski <jnareb@gmail.com> [120130 16:56]:
> On Mon, 30 Jan 2012, Bernhard R. Link wrote:
>
> > This commit changes the project listing views (project_list,
> > project_index and opml) to limit the output to only projects in a
> > subdirectory if the new optional parameter ?pf=directory name is
> > used.
>
> It would be nice to have in this or in a separate commit an update
> to get_page_title() for HTML output, and to git_opml() updating
> <title> element in OPML output, so that it mentions that project
> list is limitied to $project_filter subdirectory.
Indeed. I overlooked that.
> > Reusing $project instead of adding a new parameter would have been
> > nicer from a UI point-of-view (including PATH_INFO support) but
> > would complicate the $project validating code that is currently
> > being used to ensure nothing is exported that should not be viewable.
>
> Nb. I wonder if we should make it invalid to have both 'project' and
> 'project_filter' parameters...
$project_filter should be ignored when $project is defined which is
enforced in all but those three actions.
action=project_list gets confused (shows wrong breadcrumbs) if $project
is defined, but that is unrelated to this changes, so one might to fix
that independently.
I'll resend the series as replies to this mail. What to do next? Wait
foranother explitit Acked-By of those? Or resend it to gitster@pobox.com
if no new issues are found?
Bernhard R. Link
^ permalink raw reply
* [PATCH 1/6] gitweb: move hard coded .git suffix out of git_get_projects_list
From: Bernhard R. Link @ 2012-01-30 20:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
Use of the filter option of git_get_projects_list is currently
limited to forks. It hard codes removal of ".git" suffixes from
the filter.
To make it more generic move the .git suffix removal to the callers.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes to v5.5:
- split first patch in two as suggested by Jakub Narebski
---
gitweb/gitweb.perl | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..0ee3290 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2831,8 +2831,6 @@ sub git_get_projects_list {
my $filter = shift || '';
my @list;
- $filter =~ s/\.git$//;
-
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
@@ -6007,7 +6005,7 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list($project);
+ my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6066,7 +6064,7 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list($project);
+ @forklist = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 2/6] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Bernhard R. Link @ 2012-01-30 20:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
Use of the filter option of git_get_projects_list is currently limited
to forks. It currently assumes the project belonging to the filter
directory was already validated to be visible in the project list.
To make it more generic add an optional argument to denote visibility
verification is still needed.
If there is a projects list file (GITWEB_LIST) only projects from
this list are returned anyway, so no more checks needed.
If there is no projects list file and the caller requests strict
checking (GITWEB_STRICT_EXPORT), do not jump directly to the
given directory but instead do a normal search and filter the
results instead.
The only effect of GITWEB_STRICT_EXPORT without GITWEB_LIST is to make
sure no project can be viewed without also be found starting from
project root. git_get_projects_list without this patch does not enforce
this but all callers only call it with a filter already checked this
way. With this parameter a caller can request this check if the filter
cannot be checked this way.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes to v5:
- split first patch in two as suggested by Jakub Narebski
- replace "and not" with the more common "&& !"
---
gitweb/gitweb.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ee3290..9a296e2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2829,6 +2829,7 @@ sub git_get_project_url_list {
sub git_get_projects_list {
my $filter = shift || '';
+ my $paranoid = shift;
my @list;
if (-d $projects_list) {
@@ -2839,7 +2840,7 @@ sub git_get_projects_list {
my $pfxlen = length("$dir");
my $pfxdepth = ($dir =~ tr!/!!);
# when filtering, search only given subdirectory
- if ($filter) {
+ if ($filter && !$paranoid) {
$dir .= "/$filter";
$dir =~ s!/+$!!;
}
@@ -2864,6 +2865,10 @@ sub git_get_projects_list {
}
my $path = substr($File::Find::name, $pfxlen + 1);
+ # paranoidly only filter here
+ if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
+ next;
+ }
# we check related file in $projectroot
if (check_export_ok("$projectroot/$path")) {
push @list, { path => $path };
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 3/6] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 20:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
This commit changes the project listing views (project_list,
project_index and opml) to limit the output to only projects in a
subdirectory if the new optional parameter ?pf=directory name is
used.
The implementation of the filter reuses the implementation used for
the 'forks' action (i.e. listing all projects within that directory
from the projects list file (GITWEB_LIST) or only projects in the
given subdirectory of the project root directory without a projects
list file).
Reusing $project instead of adding a new parameter would have been
nicer from a UI point-of-view (including PATH_INFO support) but
would complicate the $project validating code that is currently
being used to ensure nothing is exported that should not be viewable.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
changed since v5.5:
- change page titles to show what directory it is limited to
---
gitweb/gitweb.perl | 31 +++++++++++++++++++++++++------
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9a296e2..b895f4c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -760,6 +760,7 @@ our @cgi_param_mapping = (
search_use_regexp => "sr",
ctag => "by_tag",
diff_style => "ds",
+ project_filter => "pf",
# this must be last entry (for manipulation from JavaScript)
javascript => "js"
);
@@ -976,7 +977,7 @@ sub evaluate_path_info {
our ($action, $project, $file_name, $file_parent, $hash, $hash_parent, $hash_base,
$hash_parent_base, @extra_options, $page, $searchtype, $search_use_regexp,
- $searchtext, $search_regexp);
+ $searchtext, $search_regexp, $project_filter);
sub evaluate_and_validate_params {
our $action = $input_params{'action'};
if (defined $action) {
@@ -994,6 +995,13 @@ sub evaluate_and_validate_params {
}
}
+ our $project_filter = $input_params{'project_filter'};
+ if (defined $project_filter) {
+ if (!validate_pathname($project_filter)) {
+ die_error(404, "Invalid project_filter parameter");
+ }
+ }
+
our $file_name = $input_params{'file_name'};
if (defined $file_name) {
if (!validate_pathname($file_name)) {
@@ -3734,7 +3742,12 @@ sub run_highlighter {
sub get_page_title {
my $title = to_utf8($site_name);
- return $title unless (defined $project);
+ unless (defined $project) {
+ if (defined $project_filter) {
+ $title .= " - " . to_utf8($project_filter);
+ }
+ return $title;
+ }
$title .= " - " . to_utf8($project);
return $title unless (defined $action);
@@ -5984,7 +5997,7 @@ sub git_project_list {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
@@ -6023,7 +6036,7 @@ sub git_forks {
}
sub git_project_index {
- my @projects = git_get_projects_list();
+ my @projects = git_get_projects_list($project_filter, $strict_export);
if (!@projects) {
die_error(404, "No projects found");
}
@@ -7860,7 +7873,7 @@ sub git_atom {
}
sub git_opml {
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
@@ -7871,11 +7884,17 @@ sub git_opml {
-content_disposition => 'inline; filename="opml.xml"');
my $title = esc_html($site_name);
+ my $filter = " within subdirectory ";
+ if (defined $project_filter) {
+ $filter .= esc_html($project_filter);
+ } else {
+ $filter = "";
+ }
print <<XML;
<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
<head>
- <title>$title OPML Export</title>
+ <title>$title OPML Export$filter</title>
</head>
<body>
<outline text="git RSS feeds">
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 4/6] gitweb: limit links to alternate forms of project_list to active project_filter
From: Bernhard R. Link @ 2012-01-30 20:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
If project_list action is given a project_filter argument, pass that to
TXT and OPML formats.
This way [OPML] and [TXT] links provide the same list of projects as
the projects_list page they are linked from.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes since v5:
add additional description paragraph from Jakub Narebski
---
gitweb/gitweb.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b895f4c..9299504 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3981,9 +3981,11 @@ sub git_footer_html {
}
} else {
- print $cgi->a({-href => href(project=>undef, action=>"opml"),
+ print $cgi->a({-href => href(project=>undef, action=>"opml",
+ project_filter => $project_filter),
-class => $feed_class}, "OPML") . " ";
- print $cgi->a({-href => href(project=>undef, action=>"project_index"),
+ print $cgi->a({-href => href(project=>undef, action=>"project_index",
+ project_filter => $project_filter),
-class => $feed_class}, "TXT") . "\n";
}
print "</div>\n"; # class="page_footer"
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 5/6] gitweb: show active project_filter in project_list page header
From: Bernhard R. Link @ 2012-01-30 20:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
In the page header of a project_list view with a project_filter
given show breadcrumbs in the page headers showing which directory
it is currently limited to and also containing links to the parent
directories.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes since v5:
- improve description, better?
- equalize whitespace
---
gitweb/gitweb.perl | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9299504..27db84e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3841,6 +3841,18 @@ sub print_header_links {
}
}
+sub print_nav_breadcrumbs_path {
+ my $dirprefix = undef;
+ while (my $part = shift) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project => undef,
+ project_filter => $dirprefix,
+ action => "project_list")},
+ esc_html($part)) . " / ";
+ }
+}
+
sub print_nav_breadcrumbs {
my %opts = @_;
@@ -3859,6 +3871,8 @@ sub print_nav_breadcrumbs {
print " / $opts{-action_extra}";
}
print "\n";
+ } elsif (defined $project_filter) {
+ print_nav_breadcrumbs_path(split '/', $project_filter);
}
}
--
1.7.8.3
^ 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