[PATCH v2 1/4] completion: prioritize ./git-completion.bash

[Ramkumar Ramachandra]

To ease development, prioritize ./git-completion.bash over other
standard system paths.

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.zsh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.zsh 
b/contrib/completion/git-completion.zsh
index fac5e71..6fca145 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z "$script" ]; then
local -a locations
local e
locations=(
+   $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu, 
new debian
'/usr/share/bash-completion/git' # gentoo
-   $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e && script="$e" && break
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 3/4] completion: fix branch.autosetup(merge|rebase)

[Ramkumar Ramachandra]

When attempting to complete

  $ git config branch.auto

'autosetupmerge' and 'autosetuprebase' don't come up. This is because
"$cur" is matched with "branch.*" and a list of branches are
completed. Add 'autosetup(merge|rebase)' to the list of branches using
__gitcomp_2 ().

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.bash | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 64b20b8..cbb4eca 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1856,7 +1856,9 @@ _git_config ()
;;
branch.*)
local pfx="${cur%.*}." cur_="${cur#*.}"
-   __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
+   __gitcomp_2 "$(__git_heads)" "
+   autosetupmerge autosetuprebase
+   " "$pfx" "$cur_" "."
return
;;
guitool.*.*)
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] completion: fix remote.pushdefault

[Ramkumar Ramachandra]

When attempting to complete

  $ git config remote.push

'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_2 ().

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index cbb4eca..04d72a1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1900,7 +1900,7 @@ _git_config ()
;;
remote.*)
local pfx="${cur%.*}." cur_="${cur#*.}"
-   __gitcomp_nl "$(__git_remotes)" "$pfx" "$cur_" "."
+   __gitcomp_2 "$(__git_remotes)" "pushdefault" "$pfx" "$cur_" "."
return
;;
url.*.*)
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 2/4] completion: introduce __gitcomp_2 ()

[Ramkumar Ramachandra]

There are situations where two classes of completions possible. For
example

  branch.

should try to complete

  branch.master.
  branch.autosetupmerge
  branch.autosetuprebase

The first candidate has the suffix ".", and the second/ third candidates
have the suffix " ". To facilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.bash | 30 ++
 contrib/completion/git-completion.zsh  | 10 ++
 2 files changed, 40 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 51c2dd4..64b20b8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,36 @@ __gitcomp_nl ()
__gitcompadd "$1" "${2-}" "${3-$cur}" "${4- }"
 }
 
+# Generates completion reply from two sets of completion words, with
+# configurable suffixes for each.
+#
+# It accepts 2 to 6 arguments:
+# 1: First set of possible completion words.
+# 2: Second set of possible completion words.
+# 3: A prefix to be added to each completion word (both $1 and $2)
+#(optional).
+# 4: Generate possible completion matches for this word (optional).
+# 5: A suffix to be appended to each completion word in the first set
+#($1) instead of the default space (optional).
+# 6: A suffix to be appended to each completion word in the second set
+#($2) instead of the default space (optional).
+__gitcomp_2 ()
+{
+   local pfx="${3-}" cur_="${4-$cur}" sfx="${5- }" sfx2="${6- }" i=0
+   local IFS=$' \t\n'
+
+   for x in $1; do
+   if [[ "$x" == "$cur_"* ]]; then
+   COMPREPLY[i++]="$pfx$x$sfx"
+   fi
+   done
+   for x in $2; do
+   if [[ "$x" == "$cur_"* ]]; then
+   COMPREPLY[i++]="$pfx$x$sfx2"
+   fi
+   done
+}
+
 # Generates completion reply with compgen from newline-separated possible
 # completion filenames.
 # It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh 
b/contrib/completion/git-completion.zsh
index 6fca145..261a7f5 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,16 @@ __gitcomp_nl ()
compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
 }
 
+__gitcomp_2 ()
+{
+   emulate -L zsh
+
+   local IFS=$' \t\n'
+   compset -P '*[=:]'
+   compadd -Q -S "${5- }" -p "${3-}" -- ${=1} && _ret=0
+   compadd -Q -S "${6- }" -p "${3-}" -- ${=2} && _ret=0
+}
+
 __gitcomp_file ()
 {
emulate -L zsh
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] Fix branch.autosetup(merge|rebase) completion

[Ramkumar Ramachandra]

Hi,

In this iteration, I've removed hunks to prevent completing:

  $ git config remote.pushdefault.
  $ git config branch.autosetupmerge.
  $ git config branch.autosetuprebase.

Since they're perfectly valid remote/ branch names.

Thanks.

Ramkumar Ramachandra (4):
  completion: prioritize ./git-completion.bash
  completion: introduce __gitcomp_2 ()
  completion: fix branch.autosetup(merge|rebase)
  completion: fix remote.pushdefault

 contrib/completion/git-completion.bash | 36 --
 contrib/completion/git-completion.zsh  | 12 +++-
 2 files changed, 45 insertions(+), 3 deletions(-)

-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] Introduce git submodule add|update --attach

[Francesco Pretto]

2014/1/3 Francesco Pretto :
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully supported. At some point "git submodule add" (without
> the "--attached" switch) could be also modified to produce a detached
> HEAD by default, removing any remaining inconsistency.

Junio, please let me amend this affirmation as it's inaccurate.
According to the current *upstream* features this should the supported
use case for submodules:
- there's a maintainer "add" user that adds the submodule. He will
need to track the upstream submodule revision sha1, so he will clone
the repository with an *attached* HEAD;
- there's a developer "update" use that just clone the submodule
repository and track the sha1 decided by the maintainer "add" user. He
won't need to track upstream submodule revision sha1 so cloning the
repository with a *detached* HEAD. Subsequent "merge" or "rebase"
update operations will keep the HEAD detached.

We should *not* modify/break this default workflow in any way.

The current documentation seems to be misleading when saying that
"This [the update command] will make the submodules HEAD be detached
**unless** --rebase or --merge is specified", as it seems to imply
that the update operation will result in a repository with the HEAD
attached. The repository will be indeed updated merging changes, but
the HEAD will stay detached.

Now, the use case I would like git to support is this:
- there's a maintainer "add" user that adds the submodule. He won't
track the upstream submodule revision sha1, so
"submodule..ignore" will be set to "all". He will still clone
the repository with an *attached* HEAD;
- there's a developer "update" user. He will clone the submodule
repository with an *attached* HEAD. Subsequent "merge" or "rebase"
update operations will keep the HEAD attached.

To fully support this workflow in my patch I want to:
- introduce a "submodule..attach" property so "update" users
will clone the submodule repository with an attached HEAD;
- introduce "--attach|--dettach" switches to "update" commmant to
eventually override "submodule..attach" property value in the
command line;
- introduce "--attach" (but better rename it to "--keep-attached" or
something else) switch to the "add" operation. This "--keep-attached"
will:
* set "submodule..attach" to true;
* set "submodule..ignore" to all.

Being the workflow complementary, and the behavior fully optional, I
think the proposed feature should be solid. Give me some time to
produce an improved patch and let see if I can convince you.

Regards,
Francesco
--
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://vger.kernel.org/majordomo-info.html

Rev: Collabration.

[Ojong Kenchrist]

Kenchrist Computer Research Center

N22, Ikom Ogoja Rd Edor

 CRS NIG.


The Office of  GIT.

 
Application 
In 24yrs as a tecnician on repairs, sales of electronics, 3yrs computer 
training. Came out as the best student, with a Diploma certificate. Started a 
computer free training center. The need to forther via the help of free Online 
Self Research Studies ''OSRS'' in the internet.
Specifically on computer science, website designing/programming. 

Well, in the process of studies i now discover ''GIT HUB'' being reliable to 
collabrate my training center with. Infact, it's via step i received 315 
Universities mail's interested to join me. With the request of  computer 
science/engineering accredited certificate. 

This is why:
Am applying to ''GIT'' to colabrate my computer training center which WiII grow 
to an Institution via the acceptance of this application. 

 Thanks yours faithful friend 

Ojong 
Kenchrist.N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf

[PATCH] get_octopus_merge_bases(): cleanup redundant variable

[Vasily Makarov]

pptr is needless. Some related code got cleaned as well

Signed-off-by: Vasily Makarov 
---
 commit.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/commit.c b/commit.c
index de16a3c..4a7a192 100644
--- a/commit.c
+++ b/commit.c
@@ -834,26 +834,23 @@ static struct commit_list *merge_bases_many(struct commit 
*one, int n, struct co
 struct commit_list *get_octopus_merge_bases(struct commit_list *in)
 {
struct commit_list *i, *j, *k, *ret = NULL;
-   struct commit_list **pptr = &ret;
 
-   for (i = in; i; i = i->next) {
-   if (!ret)
-   pptr = &commit_list_insert(i->item, pptr)->next;
-   else {
-   struct commit_list *new = NULL, *end = NULL;
-
-   for (j = ret; j; j = j->next) {
-   struct commit_list *bases;
-   bases = get_merge_bases(i->item, j->item, 1);
-   if (!new)
-   new = bases;
-   else
-   end->next = bases;
-   for (k = bases; k; k = k->next)
-   end = k;
-   }
-   ret = new;
+   commit_list_insert(in->item, &ret);
+
+   for (i = in->next; i; i = i->next) {
+   struct commit_list *new = NULL, *end = NULL;
+
+   for (j = ret; j; j = j->next) {
+   struct commit_list *bases;
+   bases = get_merge_bases(i->item, j->item, 1);
+   if (!new)
+   new = bases;
+   else
+   end->next = bases;
+   for (k = bases; k; k = k->next)
+   end = k;
}
+   ret = new;
}
return ret;
 }
-- 
1.8.3.2

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] Speed up is_git_command() by checking early for internal commands

[Jeff King]

On Thu, Jan 02, 2014 at 11:41:05AM -0800, Junio C Hamano wrote:

>  - builtin/merge.c is the same, but it is conceptually even worse.
>It has the end-user supplied string and wants to see if it is a
>valid strategy.  If the user wants to use a custom strategy, a
>single stat() to make sure if it exists should suffice, and the
>error codepath should load the command list to present the names
>of available ones in the error message.

Is it a single stat()? I think we would need to check each element of
$PATH. Though in practice, the exec-dir would be the first thing we
check, and where we would find the majority of hits. So it would still
be a win, as we would avoid touching anything but the exec-dir in the
common case.

-Peff
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] Speed up is_git_command() by checking early for internal commands

[Kent R. Spillner]

> Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
> call to list_commands_in_dir(). Avoid the file I/O by adding an early
> check for internal commands.

Considering the purpose of the series is it better to say "builtin" instead of 
"internal" in the commit message?--
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://vger.kernel.org/majordomo-info.html

[PATCH] l10n: de.po: fix translation of 'prefix'

[Ralf Thielow]

The word 'prefix' is currently translated as 'Prefix'
which is not a German word. It should be translated as
'Präfix'.

Signed-off-by: Ralf Thielow 
---
 po/de.po | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/po/de.po b/po/de.po
index 5e2d709..c0bbb65 100644
--- a/po/de.po
+++ b/po/de.po
@@ -72,7 +72,7 @@ msgstr "Archivformat"
 
 #: archive.c:328 builtin/log.c:1193
 msgid "prefix"
-msgstr "Prefix"
+msgstr "Präfix"
 
 #: archive.c:329
 msgid "prepend prefix to each pathname in the archive"
@@ -3716,7 +3716,7 @@ msgid ""
 msgstr ""
 "Eingabehilfe:\n"
 "1  - nummeriertes Element auswählen\n"
-"foo- Element anhand eines eindeutigen Prefix auswählen\n"
+"foo- Element anhand eines eindeutigen Präfix auswählen\n"
 "   - (leer) nichts auswählen"
 
 #: builtin/clean.c:298
@@ -3734,7 +3734,7 @@ msgstr ""
 "1  - einzelnes Element auswählen\n"
 "3-5- Bereich von Elementen auswählen\n"
 "2-3,6-9- mehrere Bereiche auswählen\n"
-"foo- Element anhand eines eindeutigen Prefix auswählen\n"
+"foo- Element anhand eines eindeutigen Präfix auswählen\n"
 "-...   - angegebenes Element abwählen\n"
 "*  - alle Elemente auswählen\n"
 "   - (leer) Auswahl beenden"
@@ -6452,7 +6452,7 @@ msgstr "kennzeichnet die Serie als n-te Fassung"
 
 #: builtin/log.c:1194
 msgid "Use [] instead of [PATCH]"
-msgstr "verwendet [] anstatt [PATCH]"
+msgstr "verwendet [] anstatt [PATCH]"
 
 #: builtin/log.c:1197
 msgid "store resulting files in "
@@ -8182,7 +8182,7 @@ msgid ""
 "[-u [--exclude-per-directory=] | -i]] [--no-sparse-checkout] [--"
 "index-output=] (--empty |  [ []])"
 msgstr ""
-"git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=] "
+"git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=] "
 "[-u [--exclude-per-directory=] | -i]] [--no-sparse-checkout] [--"
 "index-output=] (--empty |  [ "
 "[]])"
@@ -9782,15 +9782,15 @@ msgstr "gibt Tag-Inhalte aus"
 
 #: builtin/write-tree.c:13
 msgid "git write-tree [--missing-ok] [--prefix=/]"
-msgstr "git write-tree [--missing-ok] [--prefix=/]"
+msgstr "git write-tree [--missing-ok] [--prefix=/]"
 
 #: builtin/write-tree.c:26
 msgid "/"
-msgstr "/"
+msgstr "/"
 
 #: builtin/write-tree.c:27
 msgid "write tree object for a subdirectory "
-msgstr "schreibt das \"Tree\"-Objekt für ein Unterverzeichnis "
+msgstr "schreibt das \"Tree\"-Objekt für ein Unterverzeichnis "
 
 #: builtin/write-tree.c:30
 msgid "only useful for debugging"
-- 
1.8.5.2.314.gb83cf2e

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] completion: fix branch.autosetup(merge|rebase)

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>> If we are looking at "branch.autosetupmerge." followed by something,
>> who typed that final dot?
>
> I admit that it's a very unlikely case. The user did:
>
>   $ branch.autosetupmer
>
> hit backspace to delete the trailing space, inserted a dot, and hit  
> again.
>
>> If you are working on a topic about
>> auto-setup-merge and named your branch "autosetupmerge", don't you
>> want to be able to configure various aspect of that branch via
>> branch.autosetupmerge.{remote,merge} etc., just like you can do so
>> for your "topic" branch via branch.topic.{remote,merge} etc.,
>> regardless of your use of "autosetupmerge" option across branches?
>
> My reasoning was that being correct was more important that being
> complete. So, if by some horrible chance, the user names her branch
> "autosetupmerge", we don't aid her in completions.
>
>> Besides, it smells fishy to me that you need to enumerate and
>> special case these two here, and then you have to repeat them below
>> in a separate case arm.
>
> I'm not too irked about correctness in this odd case; seeing that you
> aren't either, I'll resubmit the series without this hunk (+ the hunk
> in remote.pushdefault).

You seem to be calling it "incorrect" to give the same degree of
completion for a branch the user named "autosetupmerge" as another
branch "topic", but I think it is incorrect not to, so I cannot tell
if we are agreeing or disagreeing.

Puzzled...
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>> __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
>> __gitcomp_nl_append $"autosetupmerge\nautosetuprebase\n" "$pfx" 
>> "$cur_" " "
>
> This is not a bad idea at all. I'm just afraid that we might be
> leaving open ends: What happens if the $pfx isn't the same in both
> cases? Who keeps track of the index "i" of COMPREPLY (it's currently a
> local variable)? If we make it global, doesn't every function that
> deals with COMPREPLY be careful to reset it?

I am not sure what you are worried about $pfx; what does it do when
you have strings with different prefix in COMPREPLY? If it breaks,
then the answer is "don't do it then".

Doesn't an array know its own length and give you a way to ask?

> More importantly, can you see a usecase for more than two completion classes?

I am not sure why you think it is more important.

Somebody lacked forsight and designed an interface that would allow
only one "completion classes" (whatever that means) and called the
result sufficient. It has been sufficient for a long time.

Later you came, found that one was not enough, and added an inteface
that would allow only two, and called the result sufficient.  See a
pattern?

Anticipating unforseen possibilities for enhancement and preparing
an easy way to support them without overengineering is what the
"prepare an appending variant" suggestion is about, and by
definition, unforseen possibilities have not been seen yet ;-)

Imagine if one is flipping 47 topic branches from 6 contributors
whose names all begin with 'j'.  I can see that such a person would
appreciate if "git config branch.j" did not dump all 47 topics
at once but offered "jc/ jk/ jl/ jm/ jn/ js/" instead, and then a
follow-up completion of "git config branch.jk/" expanded to
names of topics from that single contributor "jk".  Wouldn't the way
to give these be either to return these two-letter hierarchy names
with slash as the suffix or to return list of two-letter plus a
slash with an empty suffix?  Either way, that is using something
different from a dot or a space, so that may count as the third, I
guess.
--
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://vger.kernel.org/majordomo-info.html

Re: aborted 'git fetch' leaves workspace unusable

[Junio C Hamano]

Stephen Leake  writes:

> Junio C Hamano  writes:
>
>> stephen_le...@stephe-leake.org writes:
>>
>>> However, in this case, even running the fetch was a mistake; I would
>>> have prefered that it leave FETCH_HEAD in its previous state.
>>
>> I think the clearing of leftover FETCH_HEAD is one of the early
>> things "git fetch" does, unless "--append" is in effect.  I haven't
>> looked at the code for a long time, but it may be possible to move
>> the logic of doing so around so that this clearing is done as lazily
>> as possible.
>>
>> I however suspect that such a change may have fallouts on other
>> people who are writing tools like yours; they may be depending on
>> seeing FETCH_HEAD cleared after a failed fetch, and be surprised to
>> see a stale contents after they (attempt to) run "git fetch" in it.
>>
>> So it is not so clear if it is a good thing to change the behaviour
>> of "git fetch" not to touch FETCH_HEAD upon a failure.
>
> Ok; backwards compatibility is important.
>
> Perhaps FETCH_HEAD could be copied to FETCH_HEAD_prev or some such, to
> allow recovering in an error case?

As FETCH_HEAD is purely ephemeral (so are other ephemeral markers
like MERGE_HEAD and friends), and the promise between "git fetch"
and its users has always been that an invocation of "git fetch"
clears FETCH_HEAD (logical consequence of which is that the user
runs "git fetch" only when s/he are _done_ with the old FETCH_HEAD),
I doubt FETCH_HEAD_prev would add much value to the system and only
introduce more things we have to worry about, like "when will it be
cleaned?", "what happens to the old value in FETCH_HEAD_prev?".

It is like asking "Should 'rm -f foo' save the original 'foo' to
somewhere else just in case?".

If your emacs wrapper for some reason needs to know what happened in
the last fetch, I imagine that it can check and record what was in
FETCH_HEAD before issuing "git fetch", so...


--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] Speed up is_git_command() by checking early for internal commands

[Junio C Hamano]

Jeff King  writes:

> On Thu, Jan 02, 2014 at 11:41:05AM -0800, Junio C Hamano wrote:
>
>>  - builtin/merge.c is the same, but it is conceptually even worse.
>>It has the end-user supplied string and wants to see if it is a
>>valid strategy.  If the user wants to use a custom strategy, a
>>single stat() to make sure if it exists should suffice, and the
>>error codepath should load the command list to present the names
>>of available ones in the error message.
>
> Is it a single stat()? I think we would need to check each element of
> $PATH. 

Yeah, load_command_list() iterates over the members of env_path.

> Though in practice, the exec-dir would be the first thing we
> check, and where we would find the majority of hits. So it would still
> be a win, as we would avoid touching anything but the exec-dir in the
> common case.

Exactly.
--
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://vger.kernel.org/majordomo-info.html

[PATCH] submodule: Respect reqested branch on all clones

[W. Trevor King]

From: "W. Trevor King" 

The previous code only checked out the requested branch in cmd_add.
This commit moves the branch-checkout logic into module_clone, where
it can be shared by cmd_add and cmd_update.  I also update the initial
checkout command to use 'rebase' to preserve branches setup during
module_clone.

Signed-off-by: W. Trevor King 
---

On Fri, Jan 03, 2014 at 09:49:01AM +0100, Francesco Pretto wrote:
> - there's a developer "update" user. He will clone the submodule
> repository with an *attached* HEAD. Subsequent "merge" or "rebase"
> update operations will keep the HEAD attached.

'merge' and 'rebase' updates don't change the HEAD attachment.
Branches stay branches and detached HEADs stay detached.  If you've
moved away from the 'checkout' update mechanism, the only thing you
still need is a way to get an initial checkout on a branch.  This
should do it (I can add tests if folks like the general approach).

 git-submodule.sh | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..e2e5a6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -253,6 +253,7 @@ module_clone()
url=$3
reference="$4"
depth="$5"
+   branch="$6"
quiet=
if test -n "$GIT_QUIET"
then
@@ -306,7 +307,14 @@ module_clone()
echo "gitdir: $rel/$a" >"$sm_path/.git"
 
rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
-   (clear_local_git_env; cd "$sm_path" && GIT_WORK_TREE=. git config 
core.worktree "$rel/$b")
+   (
+   clear_local_git_env
+   cd "$sm_path" &&
+   GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
+   if test -n "$branch"; then
+   git checkout -f -q -B "$branch" "origin/$branch" && 
echo "checked out $branch"
+   fi
+   ) || die "$(eval_gettext "Unable to setup cloned submodule 
'\$sm_path'")"
 }
 
 isnumber()
@@ -469,16 +477,7 @@ Use -f if you really want to add it." >&2
echo "$(eval_gettext "Reactivating local git 
directory for submodule '\$sm_name'.")"
fi
fi
-   module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" 
"$depth" || exit
-   (
-   clear_local_git_env
-   cd "$sm_path" &&
-   # ash fails to wordsplit ${branch:+-b "$branch"...}
-   case "$branch" in
-   '') git checkout -f -q ;;
-   ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
-   esac
-   ) || die "$(eval_gettext "Unable to checkout submodule 
'\$sm_path'")"
+   module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" 
"$depth" "$branch" || exit
fi
git config submodule."$sm_name".url "$realrepo"
 
@@ -815,7 +814,7 @@ Maybe you want to use 'update --init'?")"
 
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
-   module_clone "$sm_path" "$name" "$url" "$reference" 
"$depth" || exit
+   module_clone "$sm_path" "$name" "$url" "$reference" 
"$depth" "$branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
-   update_module= ;;
+   if test -n "$branch"; then
+   update_module="!git reset --hard -q"
+   else
+   update_module=
+   fi
+   ;;
esac
 
must_die_on_failure=
-- 
1.8.5.2.gaa5d535.dirty

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] fetch --prune: Always print header url

[Junio C Hamano]

Tom Miller  writes:

> If "fetch --prune" is run with no new refs to fetch, but it has refs
> to prune. Then, the header url is not printed as it would if there were
> new refs to fetch.
>
> Output before this patch:
>
>   $ git fetch --prune remote-with-no-new-refs
>x [deleted] (none) -> origin/world
>
> Output after this patch:
>
>   $ git fetch --prune remote-with-no-new-refs
>   From https://github.com/git/git
>x [deleted] (none) -> origin/test
>
> Signed-off-by: Tom Miller 

And (needless to say) when there are refs to be fetched and also
pruned, the "shown_url" logic prevents us from giving two identical
headers "From ".  Sounds sane.

> ---
>
> I decided it is not worth writing a function to format the header url
> that is printed by fetch. Instead, I will duplicate the formatting logic
> for now because I plan on following up this patch set with another patch
> to stop striping the trailing "/" and ".git" from the url. When that
> patch is finished it will remove the majority of the duplicated logic.

OK, let's see how it goes.

Will replace what has been queued on 'pu'.  The incremental change
relative to the old one looked sensible and I think this one is
ready for 'next'.

Thanks.


>  builtin/fetch.c  | 32 +++-
>  t/t5510-fetch.sh | 12 
>  2 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 1e7d617..1b81cf9 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -44,6 +44,7 @@ static struct transport *gtransport;
>  static struct transport *gsecondary;
>  static const char *submodule_prefix = "";
>  static const char *recurse_submodules_default;
> +static int shown_url = 0;
>  
>  static int option_parse_recurse_submodules(const struct option *opt,
>  const char *arg, int unset)
> @@ -535,7 +536,7 @@ static int store_updated_refs(const char *raw_url, const 
> char *remote_name,
>  {
>   FILE *fp;
>   struct commit *commit;
> - int url_len, i, shown_url = 0, rc = 0;
> + int url_len, i, rc = 0;
>   struct strbuf note = STRBUF_INIT;
>   const char *what, *kind;
>   struct ref *rm;
> @@ -708,17 +709,36 @@ static int fetch_refs(struct transport *transport, 
> struct ref *ref_map)
>   return ret;
>  }
>  
> -static int prune_refs(struct refspec *refs, int ref_count, struct ref 
> *ref_map)
> +static int prune_refs(struct refspec *refs, int ref_count, struct ref 
> *ref_map,
> + const char *raw_url)
>  {
> - int result = 0;
> + int url_len, i, result = 0;
>   struct ref *ref, *stale_refs = get_stale_heads(refs, ref_count, 
> ref_map);
> + char *url;
>   const char *dangling_msg = dry_run
>   ? _("   (%s will become dangling)")
>   : _("   (%s has become dangling)");
>  
> + if (raw_url)
> + url = transport_anonymize_url(raw_url);
> + else
> + url = xstrdup("foreign");
> +
> + url_len = strlen(url);
> + for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
> + ;
> +
> + url_len = i + 1;
> + if (4 < i && !strncmp(".git", url + i - 3, 4))
> + url_len = i - 3;
> +
>   for (ref = stale_refs; ref; ref = ref->next) {
>   if (!dry_run)
>   result |= delete_ref(ref->name, NULL, 0);
> + if (verbosity >= 0 && !shown_url) {
> + fprintf(stderr, _("From %.*s\n"), url_len, url);
> + shown_url = 1;
> + }
>   if (verbosity >= 0) {
>   fprintf(stderr, " x %-*s %-*s -> %s\n",
>   TRANSPORT_SUMMARY(_("[deleted]")),
> @@ -726,6 +746,7 @@ static int prune_refs(struct refspec *refs, int 
> ref_count, struct ref *ref_map)
>   warn_dangling_symref(stderr, dangling_msg, ref->name);
>   }
>   }
> + free(url);
>   free_refs(stale_refs);
>   return result;
>  }
> @@ -854,11 +875,12 @@ static int do_fetch(struct transport *transport,
>* don't care whether --tags was specified.
>*/
>   if (ref_count) {
> - prune_refs(refs, ref_count, ref_map);
> + prune_refs(refs, ref_count, ref_map, transport->url);
>   } else {
>   prune_refs(transport->remote->fetch,
>  transport->remote->fetch_refspec_nr,
> -ref_map);
> +ref_map,
> +transport->url);
>   }
>   }
>   free_refs(ref_map);
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 5d4581d..87e896d 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -614,4 +614,16 @@ test_expect_success 'all boundary commits are excluded' '
>   test_bundle_object_count .git/objects/pack/

Re: [PATCH] get_octopus_merge_bases(): cleanup redundant variable

[Junio C Hamano]

Vasily Makarov  writes:

> pptr is needless. Some related code got cleaned as well
>
> Signed-off-by: Vasily Makarov 
> ---
>  commit.c | 33 +++--
>  1 file changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/commit.c b/commit.c
> index de16a3c..4a7a192 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -834,26 +834,23 @@ static struct commit_list *merge_bases_many(struct 
> commit *one, int n, struct co
>  struct commit_list *get_octopus_merge_bases(struct commit_list *in)
>  {
>   struct commit_list *i, *j, *k, *ret = NULL;
> - struct commit_list **pptr = &ret;
>  
> - for (i = in; i; i = i->next) {
> - if (!ret)
> - pptr = &commit_list_insert(i->item, pptr)->next;
> - else {
> - struct commit_list *new = NULL, *end = NULL;
> -
> - for (j = ret; j; j = j->next) {
> - struct commit_list *bases;
> - bases = get_merge_bases(i->item, j->item, 1);
> - if (!new)
> - new = bases;
> - else
> - end->next = bases;
> - for (k = bases; k; k = k->next)
> - end = k;
> - }
> - ret = new;
> + commit_list_insert(in->item, &ret);

I suspect that the original code would have behaved well (and I also
suspect that it was designed to) even if in==NULL upon entry, but
this version will crash here.  Nothing a simple

if (!in)
return NULL;

upfront cannot fix, though.

And if we add these three lines back, the patch will become 18
insertions with 18 deletions but the result is very much more
readable than the original ;-).

> +
> + for (i = in->next; i; i = i->next) {
> + struct commit_list *new = NULL, *end = NULL;
> +
> + for (j = ret; j; j = j->next) {
> + struct commit_list *bases;
> + bases = get_merge_bases(i->item, j->item, 1);
> + if (!new)
> + new = bases;
> + else
> + end->next = bases;
> + for (k = bases; k; k = k->next)
> + end = k;
>   }
> + ret = new;
>   }
>   return ret;
>  }
--
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://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/gitmodules: Only 'update' and 'url' are required

[W. Trevor King]

From: "W. Trevor King" 

Before this commit, all the settings fell under the initial "Each
submodule section also contains the following required keys:".  The
example shows sections with just 'update' and 'url' entries, but we
should still make the required/optional distinction explicit for the
descriptions.

Signed-off-by: W. Trevor King 
---
 Documentation/gitmodules.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f7be93f..347a9f7 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -35,6 +35,8 @@ submodule..url::
linkgit:git-clone[1] or (if it begins with ./ or ../) a location
relative to the superproject's origin repository.
 
+In addition, there are a number of optional keys:
+
 submodule..update::
Defines what to do when the submodule is updated by the superproject.
If 'checkout' (the default), the new commit specified in the
-- 
1.8.5.2.gaa5d535.dirty

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] completion: fix branch.autosetup(merge|rebase)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> You seem to be calling it "incorrect" to give the same degree of
> completion for a branch the user named "autosetupmerge" as another
> branch "topic", but I think it is incorrect not to, so I cannot tell
> if we are agreeing or disagreeing.

No, what's incorrect is providing completions for

  $ git config branch.autosetupmerge.

when no branch called "autosetupmerge" exists. The purpose of the hunk
(which I now removed) was to prevent such completions, but it has the
side-effect of also preventing a legitimate completion in the case
when the user really has a branch named "autosetupmerge".

What is your take on the issue?
--
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://vger.kernel.org/majordomo-info.html

[PATCH] get_octopus_merge_bases(): cleanup redundant variable

[Vasily Makarov]

pptr is needless. Some related code got cleaned as well

Signed-off-by: Vasily Makarov 
---
 commit.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/commit.c b/commit.c
index de16a3c..8e48c49 100644
--- a/commit.c
+++ b/commit.c
@@ -834,26 +834,26 @@ static struct commit_list *merge_bases_many(struct commit 
*one, int n, struct co
 struct commit_list *get_octopus_merge_bases(struct commit_list *in)
 {
struct commit_list *i, *j, *k, *ret = NULL;
-   struct commit_list **pptr = &ret;
 
-   for (i = in; i; i = i->next) {
-   if (!ret)
-   pptr = &commit_list_insert(i->item, pptr)->next;
-   else {
-   struct commit_list *new = NULL, *end = NULL;
-
-   for (j = ret; j; j = j->next) {
-   struct commit_list *bases;
-   bases = get_merge_bases(i->item, j->item, 1);
-   if (!new)
-   new = bases;
-   else
-   end->next = bases;
-   for (k = bases; k; k = k->next)
-   end = k;
-   }
-   ret = new;
+   if (!in)
+   return NULL;
+
+   commit_list_insert(in->item, &ret);
+
+   for (i = in->next; i; i = i->next) {
+   struct commit_list *new = NULL, *end = NULL;
+
+   for (j = ret; j; j = j->next) {
+   struct commit_list *bases;
+   bases = get_merge_bases(i->item, j->item, 1);
+   if (!new)
+   new = bases;
+   else
+   end->next = bases;
+   for (k = bases; k; k = k->next)
+   end = k;
}
+   ret = new;
}
return ret;
 }
-- 
1.8.3.2

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> I am not sure what you are worried about $pfx; what does it do when
> you have strings with different prefix in COMPREPLY? If it breaks,
> then the answer is "don't do it then".
>
> Doesn't an array know its own length and give you a way to ask?

Right. I was just throwing counterpoints at the wall.

> Imagine if one is flipping 47 topic branches from 6 contributors
> whose names all begin with 'j'.  I can see that such a person would
> appreciate if "git config branch.j" did not dump all 47 topics
> at once but offered "jc/ jk/ jl/ jm/ jn/ js/" instead, and then a
> follow-up completion of "git config branch.jk/" expanded to
> names of topics from that single contributor "jk".  Wouldn't the way
> to give these be either to return these two-letter hierarchy names
> with slash as the suffix or to return list of two-letter plus a
> slash with an empty suffix?  Either way, that is using something
> different from a dot or a space, so that may count as the third, I
> guess.

Ah, after completing branch.jk/, we would want no suffix: so the
example definitely counts as a third "completion class". I agree with
your reasoning, and will rework the series to do the _append () thing
you suggested.

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://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] completion: fix branch.autosetup(merge|rebase)

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>> You seem to be calling it "incorrect" to give the same degree of
>> completion for a branch the user named "autosetupmerge" as another
>> branch "topic", but I think it is incorrect not to, so I cannot tell
>> if we are agreeing or disagreeing.
>
> No, what's incorrect is providing completions for
>
>   $ git config branch.autosetupmerge.
>
> when no branch called "autosetupmerge" exists.  The purpose of the
> hunk (which I now removed) was to prevent such completions, ...

Hmph, but in a repository without 'foo', I just did

$ git config branch.foo.
branch.foo.merge  branch.foo.rebase 
branch.foo.mergeoptions   branch.foo.remote 

and got offered the above. How would that removed hunk that special
cased those autosetupmerge etc. helped such case?

If it _were_ about correctness, and the definition of correctness
were that "completing branch.foo. to offer these four variables
is wrong until refs/heads/foo materializes", the "fix" would have
checked if there already is such a branch and refused to complete
otherwise, not special case a few known names such as autosetup*.

As there is no reason to forbid setting configuration variables for
a branch 'foo' you are going to create before you actually create it
with "git branch foo", I do not necessarily agree with the above
definition of correctness, either.

So it was completely bogus hunk and it is good we noticed and
decided to remove it, I guess.
--
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://vger.kernel.org/majordomo-info.html

[PATCH v3 0/4] Fix branch.autosetup(merge|rebase) completion

[Ramkumar Ramachandra]

Hi Junio et al,

In v3, I've implemented __gitcomp_nl_append (), like you
suggested. After implementing it, I feel foolish about having gone
around my head to do __gitcomp_2 ().

Thanks.

Ramkumar Ramachandra (4):
  completion: prioritize ./git-completion.bash
  completion: introduce __gitcomp_nl_append ()
  completion: fix branch.autosetup(merge|rebase)
  completion: fix remote.pushdefault

 contrib/completion/git-completion.bash | 15 +++
 contrib/completion/git-completion.zsh  | 10 +-
 2 files changed, 24 insertions(+), 1 deletion(-)

-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] completion: prioritize ./git-completion.bash

[Ramkumar Ramachandra]

To ease development, prioritize ./git-completion.bash over other
standard system paths.

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.zsh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.zsh 
b/contrib/completion/git-completion.zsh
index fac5e71..6fca145 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z "$script" ]; then
local -a locations
local e
locations=(
+   $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu, 
new debian
'/usr/share/bash-completion/git' # gentoo
-   $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e && script="$e" && break
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] completion: introduce __gitcomp_nl_append ()

[Ramkumar Ramachandra]

There are situations where multiple classes of completions possible. For
example

  branch.

should try to complete

  branch.master.
  branch.autosetupmerge
  branch.autosetuprebase

The first candidate has the suffix ".", and the second/ third candidates
have the suffix " ". To facilitate completions of this kind, create a
variation of __gitcomp_nl () that appends to the existing list of
completion candidates, COMPREPLY.

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.bash | 13 +
 contrib/completion/git-completion.zsh  |  8 
 2 files changed, 21 insertions(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 51c2dd4..bf358d6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,19 @@ __gitcomp_nl ()
__gitcompadd "$1" "${2-}" "${3-$cur}" "${4- }"
 }
 
+# Variation of __gitcomp_nl () that appends to the existing list of
+# completion candidates, COMPREPLY.
+__gitcomp_nl_append ()
+{
+   local IFS=$'\n'
+   local i=${#COMPREPLY[@]}
+   for x in $1; do
+   if [[ "$x" == "$3"* ]]; then
+   COMPREPLY[i++]="$2$x$4"
+   fi
+   done
+}
+
 # Generates completion reply with compgen from newline-separated possible
 # completion filenames.
 # It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh 
b/contrib/completion/git-completion.zsh
index 6fca145..6b77968 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,14 @@ __gitcomp_nl ()
compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
 }
 
+__gitcomp_nl_append ()
+{
+   emulate -L zsh
+
+   local IFS=$'\n'
+   compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
+}
+
 __gitcomp_file ()
 {
emulate -L zsh
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] completion: fix remote.pushdefault

[Ramkumar Ramachandra]

When attempting to complete

  $ git config remote.push

'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_nl_append ().

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 75c7302..345ceff 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1883,6 +1883,7 @@ _git_config ()
remote.*)
local pfx="${cur%.*}." cur_="${cur#*.}"
__gitcomp_nl "$(__git_remotes)" "$pfx" "$cur_" "."
+   __gitcomp_nl_append "pushdefault" "$pfx" "$cur_"
return
;;
url.*.*)
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

[PATCH v3 3/4] completion: fix branch.autosetup(merge|rebase)

[Ramkumar Ramachandra]

When attempting to complete

  $ git config branch.auto

'autosetupmerge' and 'autosetuprebase' don't come up. This is because
"$cur" is matched with "branch.*" and a list of branches are
completed. Add 'autosetupmerge', 'autosetuprebase' to the list of
branches using __gitcomp_nl_append ().

Signed-off-by: Ramkumar Ramachandra 
---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index bf358d6..75c7302 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1840,6 +1840,7 @@ _git_config ()
branch.*)
local pfx="${cur%.*}." cur_="${cur#*.}"
__gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
+   __gitcomp_nl_append $'autosetupmerge\nautosetuprebase\n' "$pfx" 
"$cur_"
return
;;
guitool.*.*)
-- 
1.8.5.2.227.g53f3478

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH] l10n: de.po: fix translation of 'prefix'

[Thomas Rast]

Ralf Thielow  writes:

> The word 'prefix' is currently translated as 'Prefix'
> which is not a German word. It should be translated as
> 'Präfix'.

Indeed :-)

Thanks!

-- 
Thomas Rast
t...@thomasrast.ch
--
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://vger.kernel.org/majordomo-info.html

Re: [RFH/PATCH] graph: give an extra gap after showing root commit

[Thomas Rast]

Hi Junio,

I briefly looked at d84a3da (jc/graph-post-root-gap) in pu, and have
this nit:

> diff --git a/t/t6016-rev-list-graph-simplify-history.sh 
> b/t/t6016-rev-list-graph-simplify-history.sh
> [...]
> +one_independent_branch () {
> + git checkout --orphan root$1 A1 &&
> + test_commit root_$1 &&

The naming of root0 etc. makes the test below rather confusing to read,
because test_commit root_0 also creates a tag called root_0.  So you set
up history that has a tag root_0 that points *only* at the root, and a
branch root0 that includes two more commits.

> +test_expect_failure 'multi-root does show necessary post-root gap' '
> + sed -e "s/ #$/ /" >expect <<-\EOF &&
> + * further_2
> + * then_2
> + * root_2
> +   * further_1
> +   * then_1
> +   * root_1
> + * further_0
> + * then_0
> + * root_0
> + EOF
> + git log --graph --format=%s root0 root1 root2 >actual &&
> + test_cmp expect actual
> +'

-- 
Thomas Rast
t...@thomasrast.ch
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/18] remote-bzr: massive changes

[Ted Zlatanov]

On Wed, 01 May 2013 11:38:47 -0700 Junio C Hamano  wrote: 

JCH> Felipe Contreras  writes:
>> On Wed, May 1, 2013 at 11:39 AM, Junio C Hamano  wrote:
>>> Felipe Contreras  writes:
>>> 
> So let's go ahead and apply these directly on top of 'master', once
> we hear from Emacs folks and they are happy with it.  I'll queue it
> on 'pu' so that I do not have to go back to the list archive when it
> happens.
 
 I already heard that everything seems to be working correctly, except
 one feature, the biggest change, which I screwed up with a one-liner
 commit. That's why I added a test. Anyway, I've fixed it in my github
 branch and in this patch series, and I've told them to try the fix.
>>> 
>>> Let us know when they make progress on that front.
>>> 
>>> If Emacs decides to switch to Git and decides to use this version of
>>> remote-bzr for their conversion, or at least a nontrivial group of
>>> developers favor to do so, without seeing concrete technical points
>>> that say remote-bzr is not yet ready (e.g. "the conversion is still
>>> wrong and X, Y and Z needs to be fixed"), that would be a very
>>> welcome solid vote of confidence in favor of us going ahead with
>>> this.
>> 
>> Seems unlikely for political reasons (isn't it always for GNU?), since
>> RMS is heavily involved in the decision.

JCH> I am very aware of that discussion (and the original one when they
JCH> decided to use bzr).  That is exactly why I said "at least ... favor
JCH> to do so".

FYI, in case you're not aware, there's a pretty strong feeling on
emacs-devel that the switch to Git will happen and RMS is not opposed.

I don't know if they'll use remote-bzr, though.  It's more likely
they'll use one of the already-existing mirrors and sync it up, based on
the feedback so far.  It's a good time to bring remote-bzr up on
emacs-devel if you want it to be considered.

HTH
Ted

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/4] completion: introduce __gitcomp_nl_append ()

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> diff --git a/contrib/completion/git-completion.bash 
> b/contrib/completion/git-completion.bash
> index 51c2dd4..bf358d6 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -233,6 +233,19 @@ __gitcomp_nl ()
>   __gitcompadd "$1" "${2-}" "${3-$cur}" "${4- }"
>  }
>  
> +# Variation of __gitcomp_nl () that appends to the existing list of
> +# completion candidates, COMPREPLY.
> +__gitcomp_nl_append ()
> +{
> + local IFS=$'\n'
> + local i=${#COMPREPLY[@]}
> + for x in $1; do
> + if [[ "$x" == "$3"* ]]; then
> + COMPREPLY[i++]="$2$x$4"
> + fi
> + done
> +}

Hmph. Why so much duplication with __gitcompadd, though.

I would have expected that this "append" behaviour to be done at the
lower level by introducing __gitcompappend that does not forcibly
truncate by starting from a hard-coded i=0, i.e. a collection of
small helper functions plus a single implementation of the logic to
push elements into COMPREPLY[] in __gitcompappend, perhaps like
these:

__gitcompappend () {
local i=${#COMPREPLY[@]}
for x in $1; do
if [[ "$x" == "$3"* ]]; then
COMPREPLY[i++]="$2$x$4"
fi
done
}

__gitcompadd () {
COMPREPLY=()
__gitcompappend "$@"
}

__gitcomp_nl_append () {
local IFS=$'\n'
__gitcompappend "$1" "${2-}" "${3-$cur}" "${4- }"
}

__gitcomp_nl () {
COMPREPLY=()
__gitcomp_nl_append "$@"
}

Is it because going this route and doing it at such a low level
would make zsh completion (which I have no clue about ;-)
unnecessarily complex?

> +
>  # Generates completion reply with compgen from newline-separated possible
>  # completion filenames.
>  # It accepts 1 to 3 arguments:
> diff --git a/contrib/completion/git-completion.zsh 
> b/contrib/completion/git-completion.zsh
> index 6fca145..6b77968 100644
> --- a/contrib/completion/git-completion.zsh
> +++ b/contrib/completion/git-completion.zsh
> @@ -76,6 +76,14 @@ __gitcomp_nl ()
>   compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
>  }
>  
> +__gitcomp_nl_append ()
> +{
> + emulate -L zsh
> +
> + local IFS=$'\n'
> + compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
> +}
> +
>  __gitcomp_file ()
>  {
>   emulate -L zsh
--
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://vger.kernel.org/majordomo-info.html

Re: Bug report: stash in upstream caused remote fetch to fail

[Matt Burke]

I ran into the same (or similar) problem as reported in
. I have a script
that, among other things, clones a git repository. Here's where it
does that:

+ git init -q
+ git fetch -q -fu ../../../other '+refs/*:refs/*'
fatal: bad object 9b985fbe6a2b783c16756077a8be261c94b6c197
error: ../../../other did not send all necessary objects

In ../../../other:

$ git rev-parse stash@{0}
9b985fbe6a2b783c16756077a8be261c94b6c197
$ grep stash .git/packed-refs
9b985fbe6a2b783c16756077a8be261c94b6c197 refs/stash
$ cat .git/refs/stash
9b985fbe6a2b783c16756077a8be261c94b6c197

I removed the line from packed-refs and removed the refs/stash file,
and the problem went away. Restoring packed-refs or refs/stash makes
the error occur again.

When this was reported before, Thomas Rast wrote:

> Do you, by any chance, still have a copy of the upstream repo before you
> trashed the stash?  It would be interesting to know whether there was
> actually some repository corruption going on (that went unnoticed by
> fsck, no less) or if there was a bug in the transmission.

I've still got the repository, and am happy to help debug this.

--
Matt
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] completion: fix remote.pushdefault

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> When attempting to complete
>
>   $ git config remote.push
>
> 'pushdefault' doesn't come up. This is because "$cur" is matched with
> "remote.*" and a list of remotes are completed. Add 'pushdefault' to the
> list of remotes using __gitcomp_nl_append ().

"Add ... to the list of remotes" (same for "list of branches" in
3/4) sounds somewhat funny, doesn't it?  How about

Add remote.pushdefault as a candidate for completion, too.

or something like that instead?

>
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  contrib/completion/git-completion.bash | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/contrib/completion/git-completion.bash 
> b/contrib/completion/git-completion.bash
> index 75c7302..345ceff 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1883,6 +1883,7 @@ _git_config ()
>   remote.*)
>   local pfx="${cur%.*}." cur_="${cur#*.}"
>   __gitcomp_nl "$(__git_remotes)" "$pfx" "$cur_" "."
> + __gitcomp_nl_append "pushdefault" "$pfx" "$cur_"
>   return
>   ;;
>   url.*.*)
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] completion: prioritize ./git-completion.bash

[brian m. carlson]

On Fri, Jan 03, 2014 at 01:30:28PM +0530, Ramkumar Ramachandra wrote:
> To ease development, prioritize ./git-completion.bash over other
> standard system paths.
> 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  contrib/completion/git-completion.zsh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/completion/git-completion.zsh 
> b/contrib/completion/git-completion.zsh
> index fac5e71..6fca145 100644
> --- a/contrib/completion/git-completion.zsh
> +++ b/contrib/completion/git-completion.zsh
> @@ -30,10 +30,10 @@ if [ -z "$script" ]; then
>   local -a locations
>   local e
>   locations=(
> + $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>   '/etc/bash_completion.d/git' # fedora, old debian
>   '/usr/share/bash-completion/completions/git' # arch, ubuntu, 
> new debian
>   '/usr/share/bash-completion/git' # gentoo
> - $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>   )
>   for e in $locations; do
>   test -f $e && script="$e" && break

I'm not clear on this change.  It looks like this loads
git-completion.bash from the same directory as git-completion.zsh.  Is
this correct?  Your commit message says "./", and if that's the case, it
has the same security problems as putting "." first in your PATH.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] completion: prioritize ./git-completion.bash

[Junio C Hamano]

"brian m. carlson"  writes:

> On Fri, Jan 03, 2014 at 01:30:28PM +0530, Ramkumar Ramachandra wrote:
>> To ease development, prioritize ./git-completion.bash over other
>> standard system paths.
>> 
>> Signed-off-by: Ramkumar Ramachandra 
>> ---
>>  contrib/completion/git-completion.zsh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/contrib/completion/git-completion.zsh 
>> b/contrib/completion/git-completion.zsh
>> index fac5e71..6fca145 100644
>> --- a/contrib/completion/git-completion.zsh
>> +++ b/contrib/completion/git-completion.zsh
>> @@ -30,10 +30,10 @@ if [ -z "$script" ]; then
>>  local -a locations
>>  local e
>>  locations=(
>> +$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>  '/etc/bash_completion.d/git' # fedora, old debian
>>  '/usr/share/bash-completion/completions/git' # arch, ubuntu, 
>> new debian
>>  '/usr/share/bash-completion/git' # gentoo
>> -$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>  )
>>  for e in $locations; do
>>  test -f $e && script="$e" && break
>
> I'm not clear on this change.  It looks like this loads
> git-completion.bash from the same directory as git-completion.zsh.  Is
> this correct?

I think the idea is to help those who have installed a closer to
bleeding-edge version of completion scripts --- they will not be
reading their zsh completions from the system default locations,
and the place next to it would be a place more likely to have the
matching bleeding-edge version of bash completion than the system
default place.

> Your commit message says "./", and if that's the case, it
> has the same security problems as putting "." first in your PATH.

A correct observation. I think

Subject: zsh completion: find matching custom bash completion

If zsh completion is being read from a location that is
different from system-wide default, it is likely that the
user is trying to use a custom version, perhaps closer to
the bleeding edge, installed in her own directory. We will
more likely to find the matching bash completion script in
the same directory than in those system default places.

would probably a lot closer to what the patch really does.
--
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://vger.kernel.org/majordomo-info.html