Re: [PATCH] status: add advice on how to push/pull to tracking branch
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: I don't understand what you mean by non-current. If you mean a local branch not pointed to by HEAD, then I don't understand the remark, as the message is shown by git status (looking more closely, it is also shown by git checkout, but after switching branch so also showing a message about the current branch) and precisely talks about the current branch. Ah, Ok, I somehow thought that branch -v would also use this information, and/or during my absense this function from remote.c got linked into git remote show ;-) OK. So it is not an issue right now, but we will have to worry about the messaging when we start using this to describe a branch that is not currently checked out. (Anyway, we'd have to reword it a bit: saying Your branch ... would be wrong in this case) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: Crash when pushing large binary file
On Fri, Nov 16, 2012 at 1:54 PM, Thomas Gay t...@tokyois.com wrote: If you set receive.unpacklimit to 1 on the receiving end, does it still crash? Yes. The crash log looks the same too. If it still says unpack-objects died of signal 11 then it was not done the right way. The receiving end can use either unpack-objects or index-pack for storing the objects. I know unpack-objects is not ready for large blobs (though I cannot explain your crash log, that's why I still need you to test it this way). I was hoping to force it use index-pack and see it still crashes. If it does, we have other problems than unpack-objects not being ready for large blobs. If it does not, I'd say it's a known issue with a known solution (I was planning on merging unpack-objects functionality back to index-pack). We can try again this way. index-pack will be used if the number of transfer objects exceeds 100 (by default). You are pusing 16 objects, which is why unpack-objects is used. We can try to push garbage to the other end to meet the 100 limit, then reset the branch at the other end later. You can run git gc early on the other end to clean up garbage, or it'll be done automatically at some point in future. Make sure there is no changes in index and worktree, or adjust you may want to change the last four commands slightly. mkdir tmp for i in `seq 200`;do echo $i tmp/$i; git add $i; done git commit -m 'useless stuff' git push where? # should not crash again git reset --hard HEAD^ git push same-where?-above -- Duy -- 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 v4 0/4] Introduce diff.submodule
Jeff King wrote: It may be worth squashing this test into patch 3: Looks good. Thanks. BTW, while writing the test, I noticed two minor nits with your tests: 1. They can use test_config, which is simpler (you do not need to unset yourself after the test) and safer (the unset happens via test_when_finished, so it works even if the test fails). I see. Can you squash this in? -- 8 -- diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh index e401814..876800f 100755 --- a/t/t4041-diff-submodule-option.sh +++ b/t/t4041-diff-submodule-option.sh @@ -56,7 +56,7 @@ EOF test_expect_success '--submodule=short overrides diff.submodule' - git config diff.submodule log + test_config diff.submodule log git add sm1 git diff --submodule=short --cached actual cat expected -EOF @@ -68,7 +68,6 @@ index 000..a2c4dab @@ -0,0 +1 @@ +Subproject commit $fullhead1 EOF - git config --unset diff.submodule test_cmp expected actual 2. You can still indent expected output when using -. I know; however, I wanted to be consistent with the surrounding code. Ram -- 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: Local clones aka forks disk size optimization
Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44: On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill andrew.ard...@gmail.com wrote: On 15 November 2012 12:15, Javier Domingo javier...@gmail.com wrote: Hi Andrew, Doing this would require I got tracked which one comes from which. So it would imply some logic (and db) over it. With the hardlinking way, it wouldn't require anything. The idea is that you don't have to do anything else in the server. I understand that it would be imposible to do it for windows users (but using cygwin), but for *nix ones yes... Javier Domingo Paraphrasing from git-clone(1): When cloning a repository, if the source repository is specified with /path/to/repo syntax, the default is to clone the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository) --no-hardlinks can be used. So hardlinks should be used where possible, and if they are not try upgrading Git. I think that covers all the use cases you have? I am not sure it does. My understanding is this: 'git clone -l' saves space on the initial clone, but subsequent pushes end up with the same objects duplicated across all the forks (assuming most of the forks keep up with some canonical repo). The alternates mechanism can give you ongoing savings (as long as you push to the main repo first), but it is dangerous, in the words of the git-clone manpage. You have to be confident no one will delete a ref from the main repo and then do a gc or let it auto-gc. He's looking for something that addresses both these issues. As an additional idea, I suspect this is what the namespaces feature was created for, but I am not sure, and have never played with it till now. Maybe someone who knows namespaces very well will chip in... I dunno about namespaces, but a safe route with alternates seems to be: Provide one main clone which is bare, pulls automatically, and is there to stay (no pruning), so that all others can use that as a reliable alternates source. Michael -- 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: gitpacker progress report and a question
Eric S. Raymond e...@thyrsus.com writes: if commitcount 1: do_or_die(rm `git ls-tree --name-only HEAD`) This will fail on file names containing whitespace or glob meta characters. Better use git rm -qr . here. You don't have to care about the index since you are doing git add -A later anyway. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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 4/4] RelNotes 1.8.1: Another grammar thinko
From: Horst H. von Brand vonbr...@inf.utfsm.cl Signed-off-by: Horst H. von Brand vonbr...@inf.utfsm.cl --- Documentation/RelNotes/1.8.1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt index 668f1a3..88179b4 100644 --- a/Documentation/RelNotes/1.8.1.txt +++ b/Documentation/RelNotes/1.8.1.txt @@ -136,7 +136,7 @@ details). (merge 25dc8da js/format-2047 later to maint). * Sometimes curl_multi_timeout() function suggested a wrong timeout - value when there is no file descriptors to wait on and the http + value when there are no file descriptors to wait on and the http transport ended up sleeping for minutes in select(2) system call. A workaround has been added for this. (merge 7202b81 sz/maint-curl-multi-timeout later to maint). -- 1.8.0.197.g5a90748 -- 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 2/4] RelNotes 1.8.1: Awkward wording
From: Horst H. von Brand vonbr...@inf.utfsm.cl Signed-off-by: Horst H. von Brand vonbr...@inf.utfsm.cl --- Documentation/RelNotes/1.8.1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt index 559cd05..69baa35 100644 --- a/Documentation/RelNotes/1.8.1.txt +++ b/Documentation/RelNotes/1.8.1.txt @@ -100,7 +100,7 @@ details). * git mergetool feeds /dev/null as a common ancestor when dealing with an add/add conflict, but p4merge backend cannot handle - it. Work it around by passing a temporary empty file. + it. Work around this by passing a temporary empty file. (merge 3facc60 da/mergetools-p4 later to maint). * git log -F -E --grep='ere' failed to use the given ere -- 1.8.0.197.g5a90748 -- 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 3/4] RelNotes 1.8.1: Grammar thinko
From: Horst H. von Brand vonbr...@inf.utfsm.cl Signed-off-by: Horst H. von Brand vonbr...@inf.utfsm.cl --- Documentation/RelNotes/1.8.1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt index 69baa35..668f1a3 100644 --- a/Documentation/RelNotes/1.8.1.txt +++ b/Documentation/RelNotes/1.8.1.txt @@ -132,7 +132,7 @@ details). (merge 11fbe18 po/maint-refs-replace-docs later to maint). * Various rfc2047 quoting issues around a non-ASCII name on the - From: line in the output from format-patch has been corrected. + From: line in the output from format-patch have been corrected. (merge 25dc8da js/format-2047 later to maint). * Sometimes curl_multi_timeout() function suggested a wrong timeout -- 1.8.0.197.g5a90748 -- 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 1/4] RelNotes 1.8.1: Typo
From: Horst H. von Brand vonbr...@inf.utfsm.cl Signed-off-by: Horst H. von Brand vonbr...@inf.utfsm.cl --- Documentation/RelNotes/1.8.1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt index 107e5f3..559cd05 100644 --- a/Documentation/RelNotes/1.8.1.txt +++ b/Documentation/RelNotes/1.8.1.txt @@ -36,7 +36,7 @@ UI, Workflows Features give the default number of context lines in the patch output, to override the hardcoded default of 3 lines. - * git format-patch leraned the --notes=ref option to give + * git format-patch learned the --notes=ref option to give notes for the commit after the three-dash lines in its output. * git log --grep=pcre learned to honor the grep.patterntype -- 1.8.0.197.g5a90748 -- 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] tcsh-completion re-using git-completion.bash
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam marc.khou...@gmail.com wrote:
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
As I said, I don't think this is needed. It can be done in a single
stand-alone script without modifications to git-completion.bash.
This works:
Thank you for taking the time to try things out.
What you suggest below is an improvement on solution (C).
I had chosen (A) instead because (C) creates a third script
which gets generated each time a new shell is started.
It should be safe, but it felt a little wrong.
But I have to admit I was on the fence between the two
solutions.
If you guys don't think it is bad to generate a third script
(that the user may notice in his ${HOME}),
I'll post a new patch (and try once more to get gmail not to
replace the tabs with spaces), using your improved
solution (C).
set called = ($_)
I fought with this a lot before posting to the list.
It seems that $_ is not set when a double sourcing
happens. Testing the solution as an actual user
showed me that when I start a new shell it
sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
and then $_ is empty for some reason.
I couldn't find another way to figure out where the script
is located, which is why I had to force the user to use
${HOME} for everything.
set script = ${called[2]}.tmp
cat \EOF $script
source $HOME/.git-completion.sh
This is nice. Shame on me not to have thought about it.
In my version I actually 'cat' the entire bash script into $script
instead of simply sourcing it.
# Set COMP_WORDS in a way that can be handled by the bash script.
COMP_WORDS=($1)
# Set COMP_CWORD to the cursor location as bash would.
if [ -n ${2-} ]; then
COMP_CWORD=$2
else
Since this code will be part of a tcsh-only script, I don't think
we need to prepare for a possible $2. tcsh won't provide it.
So, I'll remove that logic, which will simplify things slightly.
# Assume the cursor is at the end of parameter #1.
# We must check for a space as the last character which will
# tell us that the previous word is complete and the cursor
# is on the next word.
if [ ${1: -1} == ]; then
# The last character is a space, so our location is at the end
# of the command-line array
COMP_CWORD=${#COMP_WORDS[@]}
else
# The last character is not a space, so our location is on the
# last word of the command-line array, so we must decrement
the
# count by 1
COMP_CWORD=$((${#COMP_WORDS[@]}-1))
fi
fi
# Call _git() or _gitk() of the bash script, based on the first
# element of the command-line
_${COMP_WORDS[0]}
IFS=$'\n'
echo ${COMPREPLY[*]}
\EOF
complete git 'p/*/`bash ${script} ${COMMAND_LINE} | sort | uniq`/'
complete gitk 'p/*/`bash ${script} ${COMMAND_LINE} | sort | uniq`/'
I am worried about 'sort' and 'uniq' being aliased by the user, so I was
thinking of using '\sort | \uniq'
I'll work on the new version of the solution.
Thanks again
Marc
--
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: Local clones aka forks disk size optimization
-Original Message- From: Javier Domingo Sent: Wednesday, November 14, 2012 8:15 PM Hi Andrew, Doing this would require I got tracked which one comes from which. So it would imply some logic (and db) over it. With the hardlinking way, it wouldn't require anything. The idea is that you don't have to do anything else in the server. I understand that it would be imposible to do it for windows users Not true, it is a file system issue not an os issue. FAT does not support hard links, but ext2,3,4 and NTFS do. (but using cygwin), but for *nix ones yes... Javier Domingo smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam marc.khou...@gmail.com wrote:
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam marc.khou...@gmail.com
wrote:
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
As I said, I don't think this is needed. It can be done in a single
stand-alone script without modifications to git-completion.bash.
This works:
Thank you for taking the time to try things out.
What you suggest below is an improvement on solution (C).
I had chosen (A) instead because (C) creates a third script
which gets generated each time a new shell is started.
We could generate the script only when it's not already present. The
disadvantage is that if this script is updated, the helper one would
not. One way to solve the problem would be to append the current
version of git, and figure a way to query it out. Another would be to
checksum it. But then again, maybe it's more expensive to check the
version or checksum than just write the file again.
Is it possible to just check if this is a login shell?
set called = ($_)
I fought with this a lot before posting to the list.
It seems that $_ is not set when a double sourcing
happens. Testing the solution as an actual user
showed me that when I start a new shell it
sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
and then $_ is empty for some reason.
I couldn't find another way to figure out where the script
is located, which is why I had to force the user to use
${HOME} for everything.
Ah :(
--
Felipe Contreras
--
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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam marc.khou...@gmail.com wrote:
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam marc.khou...@gmail.com
wrote:
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
As I said, I don't think this is needed. It can be done in a single
stand-alone script without modifications to git-completion.bash.
This works:
Thank you for taking the time to try things out.
What you suggest below is an improvement on solution (C).
I had chosen (A) instead because (C) creates a third script
which gets generated each time a new shell is started.
We could generate the script only when it's not already present. The
disadvantage is that if this script is updated, the helper one would
not.
I didn't like that too much either.
One way to solve the problem would be to append the current
version of git, and figure a way to query it out. Another would be to
checksum it. But then again, maybe it's more expensive to check the
version or checksum than just write the file again.
Yeah, I'm also thinking that re-generating the script is not bad enough
to introduce this complexity.
Is it possible to just check if this is a login shell?
I think it would be nice to allow the user to manually
source git-completion.tcsh, in case they want to make
manual modifications to it.
I think the most user-friendly option is to actually re-generate the
script each time. It feels wrong, but it works well :)
set called = ($_)
I fought with this a lot before posting to the list.
It seems that $_ is not set when a double sourcing
happens. Testing the solution as an actual user
showed me that when I start a new shell it
sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
and then $_ is empty for some reason.
I couldn't find another way to figure out where the script
is located, which is why I had to force the user to use
${HOME} for everything.
Ah :(
--
Felipe Contreras
--
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] tcsh-completion re-using git-completion.bash
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
Here's another version which adds contrib/completion/git-completion.tcsh but
does not modify contrib/completion/git-completion.bash at all.
(Sorry, but I still can't get gmail to stop changing the tabs for spaces)
Thanks in advance.
Marc
contrib/completion/git-completion.tcsh | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 000..76395f9
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat EOF ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source
Re: cloning a namespace downloads all the objects
Sitaram Chamarty sitar...@gmail.com writes: Hi, I have a repo on a server, which contains, as namespaces, the contents of several different repos of varying sizes. When I run a clone command for the smallest of the namespaces (I have a script that intercepts the clone and sets GIT_NAMESPACE appropriately), I get the correct set of refs, but *all* the objects from *all* the namespaces. And since no refs from the other namespaces have come down, a 'git gc --prune=now', run immediately after, reduces the size of .git/objects to the size I would expect for just that small namespace. In effect, it is bringing down data that is not reachable and will be wiped out on the next gc. Is this expected? I do not think so. This was done with a series between a1bea2c (ref namespaces: infrastructure, 2011-07-05) and bf7930c (ref namespaces: tests, 2011-07-21); Josh, care to comment on and to look into it? -- 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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam marc.khou...@gmail.com wrote: On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Is it possible to just check if this is a login shell? I think it would be nice to allow the user to manually source git-completion.tcsh, in case they want to make manual modifications to it. Yeah, they could still do that... because they would be running in a login shell. What I meant is that if the user does: tcsh my_script_that_has_nothing_to_do_with_completion.sh, they would not be executing this whole script. I think the most user-friendly option is to actually re-generate the script each time. It feels wrong, but it works well :) I'm not too strongly opposed to add that function to the bash completion, but to do it only for tcsh doesn't sound right, specially when there are other alternatives. Correct me if I'm wrong, but very few people use tcsh. -- Felipe Contreras -- 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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 5:12 PM, Marc Khouzam marc.khou...@gmail.com wrote:
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 000..76395f9
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat EOF ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source ${__git_tcsh_completion_original_script}
+
+# Set COMP_WORDS in a way that can be handled by the bash script.
+COMP_WORDS=(\$1)
+
+# The cursor is at the end of parameter #1.
+# We must check for a space as the last character which will
+# tell us that the previous word is complete and the cursor
+# is on the next word.
+if [ \${1: -1} == ]; then
+ # The last character is a space, so our location is at the end
+ # of the command-line array
+ COMP_CWORD=\${#COMP_WORDS[@]}
+else
+ # The last character is not a space, so our location is on the
+ # last word of the command-line array, so we must decrement the
+ # count by 1
+ COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
+fi
+
+# Call _git() or _gitk() of the bash script, based on the first
+# element of the command-line
+_\${COMP_WORDS[0]}
+
+IFS=\$'\n'
+echo \${COMPREPLY[*]}
+EOF
+
+complete git 'p/*/`bash ${__git_tcsh_completion_script}
${COMMAND_LINE} | \sort | \uniq`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
${COMMAND_LINE} | \sort | \uniq`/'
This looks good to me. Except that maybe the sort and uniq can be
moved to inside the script.
--
Felipe Contreras
--
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: cloning a namespace downloads all the objects
On Fri, Nov 16, 2012 at 08:43:13AM -0800, Junio C Hamano wrote: I have a repo on a server, which contains, as namespaces, the contents of several different repos of varying sizes. When I run a clone command for the smallest of the namespaces (I have a script that intercepts the clone and sets GIT_NAMESPACE appropriately), I get the correct set of refs, but *all* the objects from *all* the namespaces. And since no refs from the other namespaces have come down, a 'git gc --prune=now', run immediately after, reduces the size of .git/objects to the size I would expect for just that small namespace. In effect, it is bringing down data that is not reachable and will be wiped out on the next gc. Is this expected? I do not think so. This was done with a series between a1bea2c (ref namespaces: infrastructure, 2011-07-05) and bf7930c (ref namespaces: tests, 2011-07-21); Josh, care to comment on and to look into it? I'd guess that the create_full_pack logic in create_pack_file is to blame. The client asked for everything we advertised, so we pass --all to pack-objects rather than giving it the specific list of tips. We'd have to either fix that logic, or teach the pack-objects subprocess to respect GIT_NAMESPACE when processing --all. -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
Auto-repo-repair
Hi folks, suppose the following scenario: I've broken some repo (missing objects), eg by messing something up w/ alternates, broken filesystem, or whatever. And I've got a bunch of remotes which (together) contain all of the lost objects. Now I'd like to run some $magic_command which automatically fetches all the missing objects and so repair my local repo. Is this already possible right now ? thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: Local clones aka forks disk size optimization
Provide one main clone which is bare, pulls automatically, and is there to stay (no pruning), so that all others can use that as a reliable alternates source. The problem here, IMHO, is the assumption, that the main repo will never be cleaned up. But what to do if you dont wanna let it grow forever ? hmm, distributed GC is a tricky problem. maybe it could be easier having two kind of alternates: a) classical: gc+friends will drop local objects that are already there b) fallback: normal operations fetch objects if not accessible from anywhere else, but gc+friends do not skip objects from there. And extend prune machinery to put some backup of the dropped objects to some separate store. This way we could use some kind of rotating archive: * GC'ed objects will be stored in the backup repo for some while * there are multiple active (rotating) backups kept for some time, each cycle, only the oldest one is dropped (and maybe objects in a newer backup are removed from the older ones) * downstream repos must be synced often enough, so removed objects are fetched back from the backups early enough You could see this as some heap: * the currently active objects (directly referenced) are always on the top * once they're not referenced, they sink a lever deeper * when the're referenced again, they immediately jump up to the top * at some point in time unreferenced objects sink too deep that they're dropped completely cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam marc.khou...@gmail.com wrote: On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Is it possible to just check if this is a login shell? I think it would be nice to allow the user to manually source git-completion.tcsh, in case they want to make manual modifications to it. Yeah, they could still do that... because they would be running in a login shell. What I meant is that if the user does: tcsh my_script_that_has_nothing_to_do_with_completion.sh, they would not be executing this whole script. Oh, I see now. I can put a check in the script for the existence of the $prompt variable. This will indicate if it is a login shell or not. However, a good .cshrc file should already have such a check to avoid sourcing a bunch of useless things. So, I personally think that we should not add it to the git-completion.tcsh script but let the tcsh user decide to do it herself. But I don't mind being overruled :) I think the most user-friendly option is to actually re-generate the script each time. It feels wrong, but it works well :) I'm not too strongly opposed to add that function to the bash completion, but to do it only for tcsh doesn't sound right, specially when there are other alternatives. I agree, and this is why I made the proposed __git_complete_with_output () generic. That way it could be used by other shells or programs. But at this time, only tcsh would make use of it. If you think having __git_complete_with_output () could be useful for others, I think we should go with solution (A). If you don't think so, or if it is better to wait until a need arises first, then solution (C) will work fine. Correct me if I'm wrong, but very few people use tcsh. Less than I originally thought, when I started working on this patch :-\ But I'm still hoping that the those people will be a little happier with their git completion. Marc -- Felipe Contreras -- 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 v4] tcsh-completion re-using git-completion.bash
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
As suggested, I put the 'sort | uniq' inside the script.
In that case, I don't need to worry about aliases since 'sort |uniq' will
be executed in bash, for which the tcsh user surely doesn't have aliases setup.
Thanks
Marc
contrib/completion/git-completion.tcsh | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 000..f0327fc
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat EOF ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source ${__git_tcsh_completion_original_script}
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Torsten Bögershausen tbo...@web.de writes: My understanding: Either use people cygwin 1.5 or they use cygwin 1.7, and in this case the installation is updated frequently. Peff or Junio, please go ahead with the patch. If it turns out that we want to support cygwin installations like 1.7.7 which could be upgraded, but are not upgraded since they are production machines we do not dare to touch we can still improve the autodetection. OK. I moved the topic forward but we may still want to rename the name of the macro to have CYGWIN somewhere in the name. -- 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: Auto-repo-repair
On Fri, Nov 16, 2012 at 06:51:45PM +0100, Enrico Weigelt wrote: I've broken some repo (missing objects), eg by messing something up w/ alternates, broken filesystem, or whatever. And I've got a bunch of remotes which (together) contain all of the lost objects. Now I'd like to run some $magic_command which automatically fetches all the missing objects and so repair my local repo. Is this already possible right now ? You can't reliably just grab the broken objects, because most transports don't support grabbing arbitrary objects (you can do it if you have shell access to a known-good repository, but it's not automated). The simplest thing is usually to re-clone the known-good remotes, then copy the resulting packfiles into your original repository. You'll have duplicated objects until your next gc, but the resulting repack should skip any corrupted objects and use the known-good ones. -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: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: That is a good question. That confirmation step does come after they have typed their cover letter. However, if they are using --compose, they are dumped in their editor with something like: From Jeff King p...@peff.net # This line is ignored. GIT: Lines beginning in GIT: will be removed. GIT: Consider including an overall diffstat or table of contents GIT: for the patch you are writing. GIT: GIT: Clear the body content if you don't wish to send a summary. From: Jeff King p...@peff.net Subject: In-Reply-To: which I think would count as sufficient notice of the address being used. OK. Tentatively I replaced your old series with these 8 patches including the last one, as I tend to agree with the value the earlier clean-up in the series gives us in the longer term. As you and Felipe discussed, we may want to replace the last one with a simpler don't bother asking patch, but I think that is more or less an orthogonal issue. I'm not sure how orthogonal it is. The latter half of my series is about exposing the user_ident_sufficiently_given() flag. If we go with Felipe's patch, then that exposed information has no users, and it may not be worth it (OTOH, it's possible that some third-party script may want it). -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 5/6] completion: refactor __gitcomp related tests
Not asking for a re-roll but am asking for clarification so that I
can locally update before queuing.
Felipe Contreras felipe.contre...@gmail.com writes:
Lots of duplicated code!
... removed, you mean?
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 76
++-
1 file changed, 27 insertions(+), 49 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 59cdbfd..66c7af6 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -71,87 +71,65 @@ test_completion ()
newline=$'\n'
-test_expect_success '__gitcomp - trailing space - options' '
- sed -e s/Z$// expected -\EOF
- --reuse-message=Z
- --reedit-message=Z
- --reset-author Z
- EOF
+# Test __gitcomp.
+# Arguments are:
+# 1: typed text so far (cur)
+# *: arguments to pass to __gitcomp
s/\*/remainder/, perhaps? I think you shift $1 out and do not pass
it to __gitcomp.
And expected output is from the standard input just like
test_completion?
+test_gitcomp ()
+{
+ sed -e 's/Z$//' expected
(
local -a COMPREPLY
- cur=--re
- __gitcomp --dry-run --reuse-message= --reedit-message=
- --reset-author
+ cur=$1
+ shift
+ __gitcomp $@
IFS=$newline
echo ${COMPREPLY[*]} out
)
test_cmp expected out
+}
+
+test_expect_success '__gitcomp - trailing space - options' '
+ test_gitcomp --re --dry-run --reuse-message= --reedit-message=
+ --reset-author -EOF
+ --reuse-message=Z
+ --reedit-message=Z
+ --reset-author Z
+ EOF
'
Nice shrinkage.
--
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 5/6] completion: refactor __gitcomp related tests
On Fri, Nov 16, 2012 at 8:13 PM, Junio C Hamano gits...@pobox.com wrote:
Not asking for a re-roll but am asking for clarification so that I
can locally update before queuing.
Felipe Contreras felipe.contre...@gmail.com writes:
Lots of duplicated code!
... removed, you mean?
Yes.
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 76
++-
1 file changed, 27 insertions(+), 49 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 59cdbfd..66c7af6 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -71,87 +71,65 @@ test_completion ()
newline=$'\n'
-test_expect_success '__gitcomp - trailing space - options' '
- sed -e s/Z$// expected -\EOF
- --reuse-message=Z
- --reedit-message=Z
- --reset-author Z
- EOF
+# Test __gitcomp.
+# Arguments are:
+# 1: typed text so far (cur)
+# *: arguments to pass to __gitcomp
s/\*/remainder/, perhaps? I think you shift $1 out and do not pass
it to __gitcomp.
Right, by * I meant the rest.
And expected output is from the standard input just like
test_completion?
Correct.
+test_gitcomp ()
+{
+ sed -e 's/Z$//' expected
(
local -a COMPREPLY
- cur=--re
- __gitcomp --dry-run --reuse-message= --reedit-message=
- --reset-author
+ cur=$1
+ shift
+ __gitcomp $@
IFS=$newline
echo ${COMPREPLY[*]} out
)
test_cmp expected out
+}
+
+test_expect_success '__gitcomp - trailing space - options' '
+ test_gitcomp --re --dry-run --reuse-message= --reedit-message=
+ --reset-author -EOF
+ --reuse-message=Z
+ --reedit-message=Z
+ --reset-author Z
+ EOF
'
Nice shrinkage.
That's a comment about the whole patch series I hope :)
Cheers.
--
Felipe Contreras
--
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: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
On Fri, Nov 16, 2012 at 8:08 PM, Jeff King p...@peff.net wrote: On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: That is a good question. That confirmation step does come after they have typed their cover letter. However, if they are using --compose, they are dumped in their editor with something like: From Jeff King p...@peff.net # This line is ignored. GIT: Lines beginning in GIT: will be removed. GIT: Consider including an overall diffstat or table of contents GIT: for the patch you are writing. GIT: GIT: Clear the body content if you don't wish to send a summary. From: Jeff King p...@peff.net Subject: In-Reply-To: which I think would count as sufficient notice of the address being used. OK. Tentatively I replaced your old series with these 8 patches including the last one, as I tend to agree with the value the earlier clean-up in the series gives us in the longer term. As you and Felipe discussed, we may want to replace the last one with a simpler don't bother asking patch, but I think that is more or less an orthogonal issue. I'm not sure how orthogonal it is. The latter half of my series is about exposing the user_ident_sufficiently_given() flag. If we go with Felipe's patch, then that exposed information has no users, and it may not be worth it (OTOH, it's possible that some third-party script may want it). Well, who is using user_ident_sufficiently_given() in the first place? I think 'git commit' might be suffering from the same problem that prompted you to split it. Cheers. -- Felipe Contreras -- 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 v4] tcsh-completion re-using git-completion.bash
Marc Khouzam marc.khou...@gmail.com writes:
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
...
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
As suggested, I put the 'sort | uniq' inside the script.
In that case, I don't need to worry about aliases since 'sort |uniq' will
be executed in bash, for which the tcsh user surely doesn't have aliases
setup.
OK, so does this look OK to everybody (it does, looking at the
difference between v3 and this one, to me)?
The patch may deserve a Reviewed-by: by Felipe, by the way. I can
add one while applying.
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: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
Jeff King p...@peff.net writes: On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote: ... OK. Tentatively I replaced your old series with these 8 patches including the last one, as I tend to agree with the value the earlier clean-up in the series gives us in the longer term. As you and Felipe discussed, we may want to replace the last one with a simpler don't bother asking patch, but I think that is more or less an orthogonal issue. I'm not sure how orthogonal it is. The latter half of my series is about exposing the user_ident_sufficiently_given() flag. If we go with Felipe's patch, then that exposed information has no users, and it may not be worth it (OTOH, it's possible that some third-party script may want it). Oh, no, you are correct. I shouldn't have said the last one, but instead the later ones. The first two we should definitely keep, at least, but the other three are not so clear. -- 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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 7:20 PM, Marc Khouzam marc.khou...@gmail.com wrote: On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam marc.khou...@gmail.com wrote: On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Is it possible to just check if this is a login shell? I think it would be nice to allow the user to manually source git-completion.tcsh, in case they want to make manual modifications to it. Yeah, they could still do that... because they would be running in a login shell. What I meant is that if the user does: tcsh my_script_that_has_nothing_to_do_with_completion.sh, they would not be executing this whole script. Oh, I see now. I can put a check in the script for the existence of the $prompt variable. This will indicate if it is a login shell or not. However, a good .cshrc file should already have such a check to avoid sourcing a bunch of useless things. So, I personally think that we should not add it to the git-completion.tcsh script but let the tcsh user decide to do it herself. But I don't mind being overruled :) Sounds sensible to me. I think the most user-friendly option is to actually re-generate the script each time. It feels wrong, but it works well :) I'm not too strongly opposed to add that function to the bash completion, but to do it only for tcsh doesn't sound right, specially when there are other alternatives. I agree, and this is why I made the proposed __git_complete_with_output () generic. That way it could be used by other shells or programs. But at this time, only tcsh would make use of it. If you think having __git_complete_with_output () could be useful for others, I think we should go with solution (A). If you don't think so, or if it is better to wait until a need arises first, then solution (C) will work fine. I don't see how it could be useful to others, and if we find out that it could, we can always move the code. Correct me if I'm wrong, but very few people use tcsh. Less than I originally thought, when I started working on this patch :-\ But I'm still hoping that the those people will be a little happier with their git completion. I think they would :) But we don't need to modify bash's script for that (for now). Cheers. -- Felipe Contreras -- 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: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
On Fri, Nov 16, 2012 at 08:57:43PM +0100, Felipe Contreras wrote: I'm not sure how orthogonal it is. The latter half of my series is about exposing the user_ident_sufficiently_given() flag. If we go with Felipe's patch, then that exposed information has no users, and it may not be worth it (OTOH, it's possible that some third-party script may want it). Well, who is using user_ident_sufficiently_given() in the first place? I think 'git commit' might be suffering from the same problem that prompted you to split it. It is just `git commit` now. It does not suffer from the problems that prompted the author/committer split: http://article.gmane.org/gmane.comp.version-control.git/209635 To expand on what I wrote there, we cannot hit case 2 because we always ask for the committer within the same process. Case 1 is not interesting, because we would only fail to show it if is identical to a non-implicit committer (so even if it was implicit, we know that it is a sane value). -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] Add support for a 'pre-push' hook
Aske Olsson askeols...@gmail.com writes:
If the script .git/hooks/pre-push exists and is executable it will be
called before a `git push` command, and when the script exits with a
non-zero status the push will be aborted.
That sounds like a sane thing to do.
Documentation/git-push.txt | 11 +++-
Documentation/githooks.txt | 12 +
builtin/push.c | 6 +++
t/t5542-pre-push-hook.sh | 132
+
It would be nice to provide a sample hook in the default template. See
the template/ directory in Git's source code.
+--no-verify::
+ This option bypasses the pre-push hook.
+ See also linkgit:githooks[5].
+
-q::
--quiet::
Suppress all output, including the listing of updated refs,
Here, and below: you seem to have whitespace damage. Somebody replaced
tabs with spaces I guess. Using git send-email helps avoiding this.
+D=`pwd`
Unused variable, left from previous hacking I guess.
+# hook that always succeeds
+mk_hook_exec () {
+cat $HOOK EOF
+#!/bin/sh
+exit 0
+EOF
+chmod +x $HOOK
+}
+
+# hook that fails
+mk_hook_fail () {
+cat $HOOK EOF
+#!/bin/sh
+exit 1
+EOF
+chmod +x $HOOK
+}
I'd add a touch hook-ran in the script, a rm -f hook-ran before
launching git-push, and test the file existance after the hook to make
sure it was ran.
+test_expect_success 'push with no pre-push hook' '
+ mk_repo_pair
+ (
+ cd master
+ echo one foo git add foo git commit -m one
+ git push --mirror up
+ )
+'
+
+test_expect_success 'push --no-verify with no pre-push hook' '
+ mk_repo_pair
I don't think you need to re-create the repos for each tests. Tests are
good, but they're better when they're fast so avoiding useless
operations is good.
We try to write tests so that one test failure does not imply failures
of the next tests (i.e. stopping in the middle should not not leave
garbage that would prevent the next test from running), but do not
necessarily write 100% self-contained tests.
+ echo one foo git add foo git commit -m one
test_commit ?
+test_expect_success 'push with failing pre-push hook' '
+ mk_repo_pair
+ (
+ mk_hook_fail
+ cd master
+ echo one foo git add foo git commit -m one
+ test_must_fail git push --mirror up
+ )
+'
It would be cool to actually check that the push was not performed
(verify that the target repo is still pointing to the old revision).
Otherwise, an implementation that would call run_hook after pushing
would pass the tests.
+test_expect_success 'push with non-executable pre-push hook' '
+ mk_repo_pair
+ (
+ mk_hook_no_exec
+ cd master
+ echo one foo git add foo git commit -m one
+ git push --mirror up
+ )
+'
+
+test_expect_success 'push --no-verify with non-executable pre-push hook' '
+ mk_repo_pair
+ (
+ mk_hook_no_exec
+ cd master
+ echo one foo git add foo git commit -m one
+ git push --no-verify --mirror up
+ )
+'
These two tests are not testing much. The hook is not executable, so it
shouldn't be ran, but you do not check whether the hook is ran or not.
At least make the exit 0 an exit 1 in the hook.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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] Add support for a 'pre-push' hook
Aske Olsson askeols...@gmail.com writes:
If the script .git/hooks/pre-push exists and is executable it will be
called before a `git push` command, and when the script exits with a
non-zero status the push will be aborted.
The hook can be overridden by passing the '--no-verify' option to
`git push`.
The pre-push hook is usefull to run tests etc. before push. Or to make
sure that if a binary solution like git-media, git-annex or git-bin is
used the binaries are uploaded before the push, so when others do a
fetch the binaries will be available already. This also reduces the
need for introducing extra (git) commands to e.g. sync binaries.
Signed-off-by: Aske Olsson askeols...@gmail.com
---
...
+[[pre-push]]
+pre-push
+
+
+This hook is invoked by 'git push' and can be bypassed with the
+`--no-verify` option. It takes no parameter, and is invoked before
+the push happens.
+Exiting with a non-zero status from this script causes 'git push'
+to abort.
...
+ if (!no_verify run_hook(NULL, pre-push)) {
+ die(_(pre-push hook failed: exiting\n));
+ }
NAK, at least in the current form. At least the system should tell
the hook where it is pushing and what is being pushed.
After working on my notebook, I may want to push to my desktop
machine first to test it, without having to test locally on an
underpowered CPU, but when I am publishing the end result to the
wider world, I do want to test the result beforehand. Without
where am I pushing, the hook would not help me to enforce testing
only for the latter.
A lazy git push without any other argument may be configured in my
repository to push its maint, master, next and pu branches
to the public repository. I may say git push origin +pu, while on
one of the topic branches, to push only the pu branches out before
I am confident that the other branches I'll eventually publish are
ready (it is more likely that I may even *know* they are broken and
do not pass the test in such a case, and that is why I am pushing
only pu out). I'd want to run tests only on 'pu' in such a case.
Without what am I pushing, the hook would not be able to help me
doing that, either.
Besides, there are five valid reasons to add a new hook to the
system, but your version of pre-push does not satisfy any of them:
http://thread.gmane.org/gmane.comp.version-control.git/94111/focus=71069
It is more like to always cause an action before running a git
operation locally, so you can even write
cat $HOME/bin/git-mypush \EOF
#!/bin/sh
run test || exit
exec git push $@
EOF
chmod +x $HOME/bin/git-mypush
and then can run git mypush instead of adding this hook.
--
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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
I agree, and this is why I made the proposed
__git_complete_with_output () generic. That way it could be
used by other shells or programs. But at this time, only tcsh
would make use of it.
If you think having __git_complete_with_output () could
be useful for others, I think we should go with solution (A).
If you don't think so, or if it is better to wait until a need
arises first, then solution (C) will work fine.
I think it would be useful.
I don't see how it could be useful to others, and if we find out that
it could, we can always move the code.
For zsh, perhaps?
As I understand the main issues with using the completion script with
zsh are the various little incompatibilities between the two shells
and bugs in zsh's emulation of Bash's completion-related builtins.
Running the completion script under Bash and using its results in zsh
would solve these issues at the root. And would allow as to remove
some if [[ -n ${ZSH_VERSION-} ]] code.
--
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 5/6] completion: refactor __gitcomp related tests
On Sun, Nov 11, 2012 at 03:35:57PM +0100, Felipe Contreras wrote:
Lots of duplicated code!
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 76
++-
1 file changed, 27 insertions(+), 49 deletions(-)
Despite the impressive numbers, these tests are more useful without
this cleanup.
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 59cdbfd..66c7af6 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -71,87 +71,65 @@ test_completion ()
newline=$'\n'
-test_expect_success '__gitcomp - trailing space - options' '
- sed -e s/Z$// expected -\EOF
- --reuse-message=Z
- --reedit-message=Z
- --reset-author Z
- EOF
+# Test __gitcomp.
+# Arguments are:
+# 1: typed text so far (cur)
The first argument is not the typed text so far, but the word
currently containing the cursor position.
+# *: arguments to pass to __gitcomp
+test_gitcomp ()
+{
+ sed -e 's/Z$//' expected
(
local -a COMPREPLY
- cur=--re
- __gitcomp --dry-run --reuse-message= --reedit-message=
- --reset-author
+ cur=$1
+ shift
+ __gitcomp $@
IFS=$newline
echo ${COMPREPLY[*]} out
)
test_cmp expected out
+}
+
+test_expect_success '__gitcomp - trailing space - options' '
+ test_gitcomp --re --dry-run --reuse-message= --reedit-message=
+ --reset-author -EOF
+ --reuse-message=Z
+ --reedit-message=Z
+ --reset-author Z
+ EOF
'
test_expect_success '__gitcomp - trailing space - config keys' '
- sed -e s/Z$// expected -\EOF
+ test_gitcomp br branch. branch.autosetupmerge
+ branch.autosetuprebase browser. -\EOF
branch.Z
branch.autosetupmerge Z
branch.autosetuprebase Z
browser.Z
EOF
- (
- local -a COMPREPLY
- cur=br
- __gitcomp branch. branch.autosetupmerge
- branch.autosetuprebase browser.
- IFS=$newline
- echo ${COMPREPLY[*]} out
- )
- test_cmp expected out
'
test_expect_success '__gitcomp - option parameter' '
- sed -e s/Z$// expected -\EOF
+ test_gitcomp --strategy=re octopus ours recursive resolve subtree \
+ re -\EOF
recursive Z
resolve Z
EOF
- (
- local -a COMPREPLY
- cur=--strategy=re
- __gitcomp octopus ours recursive resolve subtree
- re
- IFS=$newline
- echo ${COMPREPLY[*]} out
- )
- test_cmp expected out
'
test_expect_success '__gitcomp - prefix' '
- sed -e s/Z$// expected -\EOF
+ test_gitcomp branch.me remote merge mergeoptions rebase \
+ branch.maint. me -\EOF
branch.maint.merge Z
branch.maint.mergeoptions Z
EOF
- (
- local -a COMPREPLY
- cur=branch.me
- __gitcomp remote merge mergeoptions rebase
- branch.maint. me
- IFS=$newline
- echo ${COMPREPLY[*]} out
- )
- test_cmp expected out
'
test_expect_success '__gitcomp - suffix' '
- sed -e s/Z$// expected -\EOF
+ test_gitcomp branch.me master maint next pu branch. \
+ ma . -\EOF
branch.master.Z
branch.maint.Z
EOF
- (
- local -a COMPREPLY
- cur=branch.me
- __gitcomp master maint next pu
- branch. ma .
- IFS=$newline
- echo ${COMPREPLY[*]} out
- )
- test_cmp expected out
'
test_expect_success 'basic' '
--
1.8.0
--
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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 9:40 PM, SZEDER Gábor sze...@ira.uka.de wrote:
On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
I agree, and this is why I made the proposed
__git_complete_with_output () generic. That way it could be
used by other shells or programs. But at this time, only tcsh
would make use of it.
If you think having __git_complete_with_output () could
be useful for others, I think we should go with solution (A).
If you don't think so, or if it is better to wait until a need
arises first, then solution (C) will work fine.
I think it would be useful.
For what?
I don't see how it could be useful to others, and if we find out that
it could, we can always move the code.
For zsh, perhaps?
Nope.
As I understand the main issues with using the completion script with
zsh are the various little incompatibilities between the two shells
and bugs in zsh's emulation of Bash's completion-related builtins.
Running the completion script under Bash and using its results in zsh
would solve these issues at the root. And would allow as to remove
some if [[ -n ${ZSH_VERSION-} ]] code.
We can remove that code already, because we now have code that is
superior than zsh's bash completion emulation:
http://article.gmane.org/gmane.comp.version-control.git/208173
This is the equivalent of what Marc is doing, except that zsh has no
problems running bash's code. Note there's a difference with zsh's
emulation bash (or rather bourne shell, or k shell), and zsh's
emulation of bash's _completion_. The former is fine, the later is
not.
Of course, people might not be aware of this new script, and would
expect sourcing the bash one to work right away. Maybe at some point
we might throw a warning to suggest them to use my new script. But I
think we should wait a few releases just to make sure that people test
it and nothing is broken.
Cheers.
--
Felipe Contreras
--
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/6] completion: add comment for test_completion()
On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor sze...@ira.uka.de wrote: On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote: So that it's easier to understand what it does. Also, make sure we pass only the first argument for completion. Shouldn't cause any functional changes because run_completion only checks $1. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t9902-completion.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh index cbd0fb6..5c06709 100755 --- a/t/t9902-completion.sh +++ b/t/t9902-completion.sh @@ -54,10 +54,14 @@ run_completion () __git_wrap__git_main print_comp } +# Test high-level completion +# Arguments are: +# 1: typed text so far (cur) Bash manuals calls this the current command line or words in the current command line. I'm not sure what you mean with '(cur)' here. The current _word_ text typed so far. The variable $cur in the completion script (or in bash-completion in general) is something completely different. I believe bash's completion, this test, and the whole git completion stuff uses the same definition of 'cur'. Cheers. -- Felipe Contreras -- 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/6] completion: add comment for test_completion()
On Fri, Nov 16, 2012 at 10:06 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor sze...@ira.uka.de wrote: On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote: So that it's easier to understand what it does. Also, make sure we pass only the first argument for completion. Shouldn't cause any functional changes because run_completion only checks $1. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t9902-completion.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh index cbd0fb6..5c06709 100755 --- a/t/t9902-completion.sh +++ b/t/t9902-completion.sh @@ -54,10 +54,14 @@ run_completion () __git_wrap__git_main print_comp } +# Test high-level completion +# Arguments are: +# 1: typed text so far (cur) Bash manuals calls this the current command line or words in the current command line. I'm not sure what you mean with '(cur)' here. The current _word_ text typed so far. The variable $cur in the completion script (or in bash-completion in general) is something completely different. I believe bash's completion, this test, and the whole git completion stuff uses the same definition of 'cur'. Oops, actually in this particular helper this is not actually 'cur'. I think 'command line' might be more appropriate. -- Felipe Contreras -- 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] tcsh-completion re-using git-completion.bash
SZEDER Gábor sze...@ira.uka.de writes: For zsh, perhaps? Yeah, I was wondering about that. If we make zsh completion read output from a little stub in bash completion, just like Felipe steered this series for tcsh, we do not have to worry about zsh does not split words unless emulating a shell and here is a way to tell zsh to do so kind of stuff in bash completion. The point is not about the quality of zsh's emulation of (k)sh when it is run under that mode, but is about not having to have that logic in bash-only part in the first place. -- 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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 10:03:41PM +0100, Felipe Contreras wrote:
On Fri, Nov 16, 2012 at 9:40 PM, SZEDER Gábor sze...@ira.uka.de wrote:
On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
I agree, and this is why I made the proposed
__git_complete_with_output () generic. That way it could be
used by other shells or programs. But at this time, only tcsh
would make use of it.
If you think having __git_complete_with_output () could
be useful for others, I think we should go with solution (A).
If you don't think so, or if it is better to wait until a need
arises first, then solution (C) will work fine.
I think it would be useful.
For what?
For zsh.
I don't see how it could be useful to others, and if we find out that
it could, we can always move the code.
For zsh, perhaps?
Nope.
Sure.
As I understand the main issues with using the completion script with
zsh are the various little incompatibilities between the two shells
and bugs in zsh's emulation of Bash's completion-related builtins.
Running the completion script under Bash and using its results in zsh
would solve these issues at the root. And would allow as to remove
some if [[ -n ${ZSH_VERSION-} ]] code.
We can remove that code already, because we now have code that is
superior than zsh's bash completion emulation:
http://article.gmane.org/gmane.comp.version-control.git/208173
Which depends on the completion script having a wrapper function
around compgen filling COMPREPLY. However, COMPREPLY will be soon
filled by hand-rolled code to prevent expansion issues with compgen,
and there will be no such wrapper.
This is the equivalent of what Marc is doing, except that zsh has no
problems running bash's code. Note there's a difference with zsh's
emulation bash (or rather bourne shell, or k shell), and zsh's
emulation of bash's _completion_. The former is fine, the later is
not.
There are a couple of constructs supported by Bash but not by zsh,
which we usually try to avoid.
--
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] Add support for a 'pre-push' hook
Matthieu Moy matthieu@grenoble-inp.fr writes:
+# hook that fails
+mk_hook_fail () {
+cat $HOOK EOF
+#!/bin/sh
+exit 1
+EOF
+chmod +x $HOOK
+}
I'd add a touch hook-ran in the script, a rm -f hook-ran before
launching git-push, and test the file existance after the hook to make
sure it was ran.
And if you create that evidence that it did ran file without using
touch, it would be perfect. Unless you are updating the timestamp
of an existing file while preserving the contents of it, it is
misleading to use touch.
All other points in your review are good. 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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 10:22 PM, SZEDER Gábor sze...@ira.uka.de wrote:
On Fri, Nov 16, 2012 at 10:03:41PM +0100, Felipe Contreras wrote:
As I understand the main issues with using the completion script with
zsh are the various little incompatibilities between the two shells
and bugs in zsh's emulation of Bash's completion-related builtins.
Running the completion script under Bash and using its results in zsh
would solve these issues at the root. And would allow as to remove
some if [[ -n ${ZSH_VERSION-} ]] code.
We can remove that code already, because we now have code that is
superior than zsh's bash completion emulation:
http://article.gmane.org/gmane.comp.version-control.git/208173
Which depends on the completion script having a wrapper function
around compgen filling COMPREPLY.
No, it does not. Previous incarnations didn't have this dependency:
http://article.gmane.org/gmane.comp.version-control.git/196720
I just thought it was neater this way.
However, COMPREPLY will be soon
filled by hand-rolled code to prevent expansion issues with compgen,
and there will be no such wrapper.
I'm still waiting to see a resemblance of that code, but my bet would
be that there will be a way to fill both COMPREPLY, and call zsh's
compadd. But it's hard to figure that out without any code. Which is
why I'm thinking on doing it myself.
But even in that case, if push comes to shoves, this zsh wrapper can
ultimately read COMPREPLY and figure things backwards, as even more
previous versions did:
http://article.gmane.org/gmane.comp.version-control.git/189310
This is the equivalent of what Marc is doing, except that zsh has no
problems running bash's code. Note there's a difference with zsh's
emulation bash (or rather bourne shell, or k shell), and zsh's
emulation of bash's _completion_. The former is fine, the later is
not.
There are a couple of constructs supported by Bash but not by zsh,
which we usually try to avoid.
Yes, and is that a big deal?
Cheers.
--
Felipe Contreras
--
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] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 10:20 PM, Junio C Hamano gits...@pobox.com wrote:
SZEDER Gábor sze...@ira.uka.de writes:
For zsh, perhaps?
Yeah, I was wondering about that.
If we make zsh completion read output from a little stub in bash
completion, just like Felipe steered this series for tcsh, we do not
have to worry about zsh does not split words unless emulating a
shell and here is a way to tell zsh to do so kind of stuff in bash
completion.
Do we worry about that now? If we do, the only reason is because we
hadn't had a proper wrapper, like the one I'm proposing to merge. So,
we had to put things inside if [[ -n ${ZSH_VERSION-} ]]. Those things
would move to my wrapper.
The only exception where we had to change code outside of that chunk
that I'm aware of is '8d58c90 completion: Use parse-options raw output
for simple long options', which is probably fixed in later versions of
zsh, and if not, we could always replace those functions inside my
wrapper.
The point is not about the quality of zsh's emulation
of (k)sh when it is run under that mode, but is about not having to
have that logic in bash-only part in the first place.
As I said, that logic can be moved away _if_ my wrapper is merged. But
then again, that would cause regressions to existing users.
Maybe we should warn them right now that they should be using my
wrapper, and that this method of zsh support would be obsoleted. But
my wrapper probably hasn't received enough testing, so do we really
want to do that right now?
Either way, I'm confident that whatever code we need can be
consolidated in git-completion.zsh, even without having to run bash.
Cheers.
--
Felipe Contreras
--
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 5/6] completion: refactor __gitcomp related tests
SZEDER Gábor sze...@ira.uka.de writes: On Sun, Nov 11, 2012 at 03:35:57PM +0100, Felipe Contreras wrote: Lots of duplicated code! No functional changes. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t9902-completion.sh | 76 ++- 1 file changed, 27 insertions(+), 49 deletions(-) Despite the impressive numbers, these tests are more useful without this cleanup. Is this because consolidation of the duplicated part of the tests into a single helper makes it harder to instrument one test you are interested in (or developing) for debugging? It indeed is a problem, and cutting and pasting the same code to multiple tests is one way to solve the problem (you can easily instrument the copy in the test you are interested in while leaving others intact), but I do not think that is a good solution. A bugfix or enhancement to the shared (or duplicated) part can be done by touching one place only after this change, while with the current code you have to repeat the same fix to all places, no? +# Test __gitcomp. +# Arguments are: +# 1: typed text so far (cur) The first argument is not the typed text so far, but the word currently containing the cursor position. Care to update this with a follow-up patch, so that I do not have to keep track of minute details ;-)? -- 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 4/6] completion: consolidate test_completion*() tests
Felipe Contreras felipe.contre...@gmail.com writes:
No need to have two versions; if a second argument is specified, use
that, otherwise use stdin.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 204c92a..59cdbfd 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -60,19 +60,15 @@ run_completion ()
# 2: expected completion
test_completion ()
{
- test $# -gt 1 echo $2 expected
+ if [ $# -gt 1 ]; then
+ echo $2 expected
+ else
+ sed -e 's/Z$//' expected
+ fi
As $2 could begin with dash, end with \c, etc. that possibly can
be misinterpred by echo, I'd rewrite this as
printf '%s\n' $2 expected
Otherwise looked fine; 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
What's cooking in git.git (Nov 2012, #05; Fri, 16)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Big thanks go to Jeff who curated topics in flight while I was on vacation. I merged a couple of topics to 'next', and made the fifth batch of topics graduate to 'master'. Over the weekend, I'll start merging maintenance topics to 'maint' in preparation for cutting 1.8.1, hopefully sometime late next week. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * as/maint-doc-fix-no-post-rewrite (2012-11-02) 1 commit (merged to 'next' on 2012-11-09 at 117a91e) + commit: fixup misplacement of --no-post-rewrite description * cr/cvsimport-local-zone (2012-11-04) 2 commits (merged to 'next' on 2012-11-04 at 292f0b4) + cvsimport: work around perl tzset issue + git-cvsimport: allow author-specific timezones Allows cvsimport to read per-author timezone from the author info file. * jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit (merged to 'next' on 2012-11-04 at eda85ef) + get_fetch_map(): tighten checks on dest refs This was split out from discarded jc/maint-push-refs-all topic. * jc/prettier-pretty-note (2012-11-13) 12 commits (merged to 'next' on 2012-11-14 at 7230f26) + format-patch: add a blank line between notes and diffstat (merged to 'next' on 2012-11-04 at 40e3e48) + Doc User-Manual: Patch cover letter, three dashes, and --notes + Doc format-patch: clarify --notes use case + Doc notes: Include the format-patch --notes option + Doc SubmittingPatches: Mention --notes option after cover letter + Documentation: decribe format-patch --notes + format-patch --notes: show notes after three-dashes + format-patch: append --signature after notes + pretty_print_commit(): do not append notes message + pretty: prepare notes message at a centralized place + format_note(): simplify API + pretty: remove reencode_commit_message() Emit the notes attached to the commit in format-patch --notes output after three-dashes. * jc/same-encoding (2012-11-04) 1 commit (merged to 'next' on 2012-11-04 at 54991f2) + reencode_string(): introduce and use same_encoding() Various codepaths checked if two encoding names are the same using ad-hoc code and some of them ended up asking iconv() to convert between utf8 and UTF-8. The former is not a valid way to spell the encoding name, but often people use it by mistake, and we equated them in some but not all codepaths. Introduce a new helper function to make these codepaths consistent. * jh/symbolic-ref-d (2012-10-21) 1 commit (merged to 'next' on 2012-11-04 at b0762f5) + git symbolic-ref --delete $symref Add symbolic-ref -d SYM to delete a symbolic ref SYM. It is already possible to remove a symbolic ref with update-ref -d --no-deref, but it may be a good addition for completeness. * jk/maint-diff-grep-textconv (2012-10-28) 1 commit (merged to 'next' on 2012-11-04 at 790337b) + diff_grep: use textconv buffers for add/deleted files (this branch is used by jk/pickaxe-textconv.) Fixes inconsistent use of textconv with git log -G. * js/hp-nonstop (2012-10-30) 1 commit (merged to 'next' on 2012-11-09 at fe58205) + fix 'make test' for HP NonStop * mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit (merged to 'next' on 2012-11-13 at bd74252) + push/pull: adjust missing upstream help text to changed interface Follow-on to the new --set-upstream-to topic from v1.8.0 to avoid suggesting the deprecated --set-upstream. * mh/notes-string-list (2012-11-08) 5 commits (merged to 'next' on 2012-11-09 at 7a4c58c) + string_list_add_refs_from_colon_sep(): use string_list_split() + notes: fix handling of colon-separated values + combine_notes_cat_sort_uniq(): sort and dedup lines all at once + Initialize sort_uniq_list using named constant + string_list: add a function string_list_remove_empty_items() Improve the asymptotic performance of the cat_sort_uniq notes merge strategy. * mh/strbuf-split (2012-11-04) 4 commits (merged to 'next' on 2012-11-09 at fa984b1) + strbuf_split*(): document functions + strbuf_split*(): rename delim parameter to terminator + strbuf_split_buf(): simplify iteration + strbuf_split_buf(): use ALLOC_GROW() Cleanups and documentation for strbuf_split. * mm/maint-doc-commit-edit (2012-11-02) 1 commit (merged to 'next' on 2012-11-09 at 8dab7f5) + Document 'git commit --no-edit' explicitly * ph/submodule-sync-recursive (2012-10-29) 2 commits (merged to 'next' on 2012-11-04 at a000f78) + Add tests for submodule sync --recursive + Teach --recursive to submodule sync Adds --recursive option to submodule sync. -- [New Topics] * jl/submodule-rm (2012-11-14) 1 commit - docs:
Re: [PATCH 6/5] sequencer.c: refrain from adding duplicate s-o-b lines
On Thu, Nov 15, 2012 at 6:03 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: Detect whether the s-o-b already exists in the commit footer and refrain from adding a duplicate. If you are trying to forbid git cherry-pick -s $other from adding s-o-b: A when $other ends with these two existing s-o-b: s-o-b: A s-o-b: B then I think that is a wrong thing to do. In such a case, the resulting commit should gain another s-o-b from A to record the provenance as a chain of events. A originally wrote the patch, B forwarded it (possibly with his own tweaks), and then A picked it up and recorded the result to the history, possibly with a final tweak or two. Hmm. I've never thought that it was necessary to add an additional sob for the patches that I've cherry picked that I had previously signed-off-on. I considered one sign-off to be enough. In your example, A is the committer and the patch set already contains A's sign-off. For me that indicates that A still considers the commit to comply with whatever s-o-b implies. We also seem to have a few tools to help people avoid adding duplicate sob's, like the current behavior of format-patch and the sample commit-msg hook. I did some quick searching through the kernel commits to try to find some examples that could set a precedence. I didn't find anything that supported either argument. I didn't see any commits that were cherry-picked _and_ had an existing sob that was not the last sob. I didn't see any that had duplicate sob lines either. I'm not mentioning this to say that lack of a prior use should mean we should actively disallow the practice of adding duplicate sob's, I'm just providing it as a data point. I've always thought that the reason that 'commit -s' and 'cherry-pick -s' checked only the last line of the commit message was simply that a full scan of the footer had not been implemented. Whichever behavior is determined to be the right way for git to do it, format-patch should be brought in-line with the others and be built on top of the code in sequencer.c. So, if git _should_ create duplicate sob's then this patch should just be dropped. Duy's unification patch can just be built on top of sequencer.c:append_signoff() without bringing over any of the duplicate sob detection from log-tree.c. -Brandon -- 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
git log implementation details
Hello, I was wondering how the command git log is actually retrieving the commit log for a given file behind the scene. Is it by walking down the object tree and scanning each commit/tree object? Or any cache/index used here? Thank you, Nicolas -- 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
[RFC/PATCH 0/5] completion: compgen/compadd cleanups
Hi, These were hinted by SZEDER, so I went ahead and implemented the changes trying to keep in mind the new zsh completion werapper. The resulting code should be more efficient, and a known breakage is fixed. The first two patches come from another patch series for convenience. Take them with a pinch of salt. Felipe Contreras (5): completion: get rid of empty COMPREPLY assignments completion: add new __gitcompadd helper completion: trivial test improvement completion: get rid of compgen completion: refactor __gitcomp_1 contrib/completion/git-completion.bash | 68 +- t/t9902-completion.sh | 3 +- 2 files changed, 27 insertions(+), 44 deletions(-) -- 1.8.0 -- 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
[RFC/PATCH 1/5] completion: get rid of empty COMPREPLY assignments
There's no functional reason for those, the only purpose they are supposed to serve is to say we don't provide any words here, but even for that it's not used consitently. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/completion/git-completion.bash | 28 1 file changed, 28 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index be800e0..7bdd6a8 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -238,7 +238,6 @@ __gitcomp () case $cur_ in --*=) - COMPREPLY=() ;; *) local IFS=$'\n' @@ -486,7 +485,6 @@ __git_complete_remote_or_refspec () case $cmd in push) no_complete_refspec=1 ;; fetch) - COMPREPLY=() return ;; *) ;; @@ -502,7 +500,6 @@ __git_complete_remote_or_refspec () return fi if [ $no_complete_refspec = 1 ]; then - COMPREPLY=() return fi [ $remote = . ] remote= @@ -776,7 +773,6 @@ _git_am () return esac - COMPREPLY=() } _git_apply () @@ -796,7 +792,6 @@ _git_apply () return esac - COMPREPLY=() } _git_add () @@ -811,7 +806,6 @@ _git_add () return esac - COMPREPLY=() } _git_archive () @@ -856,7 +850,6 @@ _git_bisect () __gitcomp_nl $(__git_refs) ;; *) - COMPREPLY=() ;; esac } @@ -969,7 +962,6 @@ _git_clean () return ;; esac - COMPREPLY=() } _git_clone () @@ -993,7 +985,6 @@ _git_clone () return ;; esac - COMPREPLY=() } _git_commit () @@ -1027,7 +1018,6 @@ _git_commit () return esac - COMPREPLY=() } _git_describe () @@ -1158,7 +1148,6 @@ _git_fsck () return ;; esac - COMPREPLY=() } _git_gc () @@ -1169,7 +1158,6 @@ _git_gc () return ;; esac - COMPREPLY=() } _git_gitk () @@ -1246,7 +1234,6 @@ _git_init () return ;; esac - COMPREPLY=() } _git_ls_files () @@ -1265,7 +1252,6 @@ _git_ls_files () return ;; esac - COMPREPLY=() } _git_ls_remote () @@ -1381,7 +1367,6 @@ _git_mergetool () return ;; esac - COMPREPLY=() } _git_merge_base () @@ -1397,7 +1382,6 @@ _git_mv () return ;; esac - COMPREPLY=() } _git_name_rev () @@ -1567,7 +1551,6 @@ _git_send_email () return ;; esac - COMPREPLY=() } _git_stage () @@ -1680,7 +1663,6 @@ _git_config () return ;; *.*) - COMPREPLY=() return ;; esac @@ -2060,7 +2042,6 @@ _git_remote () __gitcomp $c ;; *) - COMPREPLY=() ;; esac } @@ -2104,7 +2085,6 @@ _git_rm () return ;; esac - COMPREPLY=() } _git_shortlog () @@ -2173,8 +2153,6 @@ _git_stash () *) if [ -z $(__git_find_on_cmdline $save_opts) ]; then __gitcomp $subcommands - else - COMPREPLY=() fi ;; esac @@ -2187,14 +2165,12 @@ _git_stash () __gitcomp --index --quiet ;; show,--*|drop,--*|branch,--*) - COMPREPLY=() ;; show,*|apply,*|drop,*|pop,*|branch,*) __gitcomp_nl $(git --git-dir=$(__gitdir) stash list \ | sed -n -e 's/:.*//p') ;; *) - COMPREPLY=() ;; esac fi @@ -2311,7 +2287,6 @@ _git_svn () __gitcomp --revision= --parent ;; *) - COMPREPLY=() ;; esac fi @@ -2336,13 +2311,10 @@ _git_tag () case $prev in -m|-F) - COMPREPLY=() ;; -*|tag) if [ $f = 1 ]; then
[RFC/PATCH 2/5] completion: add new __gitcompadd helper
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems override __gitcompadd, and do
something different instead.
Also, this allows the simplification of the completion tests (separate
patch).
There should be no functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7bdd6a8..975ae13 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -225,6 +225,11 @@ _get_comp_words_by_ref ()
fi
fi
+__gitcompadd ()
+{
+ COMPREPLY=($(compgen -W $1 -P $2 -S $4 -- $3))
+}
+
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -241,9 +246,7 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} \
- -W $(__gitcomp_1 ${1-} ${4-}) \
- -- $cur_))
+ __gitcompadd $(__gitcomp_1 ${1-} ${4-}) ${2-} $cur_
;;
esac
}
@@ -260,7 +263,7 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ __gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
__git_heads ()
@@ -1603,7 +1606,7 @@ _git_config ()
local remote=${prev#remote.}
remote=${remote%.fetch}
if [ -z $cur ]; then
- COMPREPLY=(refs/heads/)
+ __gitcompadd refs/heads/
return
fi
__gitcomp_nl $(__git_refs_remotes $remote)
--
1.8.0
--
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
[RFC/PATCH 3/5] completion: trivial test improvement
Instead of passing a dummy , let's check if the last character is a
space, and then move the _cword accordingly.
Apparently we were passing all the way to compgen, which fortunately
expanded it to nothing.
Lets do the right thing though.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index cbd0fb6..0b5e1f5 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -51,6 +51,7 @@ run_completion ()
local _cword
_words=( $1 )
(( _cword = ${#_words[@]} - 1 ))
+ test ${1: -1} == ' ' (( _cword += 1 ))
__git_wrap__git_main print_comp
}
@@ -156,7 +157,7 @@ test_expect_success '__gitcomp - suffix' '
'
test_expect_success 'basic' '
- run_completion git \\
+ run_completion git
# built-in
grep -q ^add \$ out
# script
--
1.8.0
--
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
[RFC/PATCH 4/5] completion: get rid of compgen
The functionality we use is very simple, plus, this fixes a known
breakage 'complete tree filename with metacharacters'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 975ae13..ad3e1fe 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -227,7 +227,11 @@ fi
__gitcompadd ()
{
- COMPREPLY=($(compgen -W $1 -P $2 -S $4 -- $3))
+ for x in $1; do
+ if [[ $x = $3* ]]; then
+ COMPREPLY+=($2$x$4)
+ fi
+ done
}
# Generates completion reply with compgen, appending a space to possible
--
1.8.0
--
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
[RFC/PATCH 5/5] completion: refactor __gitcomp_1
It's only used by __gitcomp, so move some code there and avoid going
through the loop again.
We could get rid of it altogether, but it's useful for zsh's completion
wrapper.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index ad3e1fe..d92d11e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -58,15 +58,12 @@ __gitdir ()
__gitcomp_1 ()
{
- local c IFS=$' \t\n'
- for c in $1; do
- c=$c$2
- case $c in
- --*=*|*.) ;;
- *) c=$c ;;
- esac
- printf '%s\n' $c
- done
+ local c=$1
+ case $c in
+ --*=*|*.) ;;
+ *) c=$c ;;
+ esac
+ printf '%s\n' $c
}
# The following function is based on code from:
@@ -249,10 +246,16 @@ __gitcomp ()
--*=)
;;
*)
- local IFS=$'\n'
- __gitcompadd $(__gitcomp_1 ${1-} ${4-}) ${2-} $cur_
+ local c IFS=$' \t\n'
+ for c in ${1-}; do
+ c=`__gitcomp_1 $c${4-}`
+ if [[ $c = $cur_* ]]; then
+ COMPREPLY+=(${2-}$c)
+ fi
+ done
;;
esac
+
}
# Generates completion reply with compgen from newline-separated possible
--
1.8.0
--
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] Add support for a 'pre-push' hook
On 11/16/2012 09:30 PM, Junio C Hamano wrote:
Aske Olsson askeols...@gmail.com writes:
If the script .git/hooks/pre-push exists and is executable it will be
called before a `git push` command, and when the script exits with a
non-zero status the push will be aborted.
The hook can be overridden by passing the '--no-verify' option to
`git push`.
The pre-push hook is usefull to run tests etc. before push. Or to make
sure that if a binary solution like git-media, git-annex or git-bin is
used the binaries are uploaded before the push, so when others do a
fetch the binaries will be available already. This also reduces the
need for introducing extra (git) commands to e.g. sync binaries.
Signed-off-by: Aske Olsson askeols...@gmail.com
---
...
+[[pre-push]]
+pre-push
+
+
+This hook is invoked by 'git push' and can be bypassed with the
+`--no-verify` option. It takes no parameter, and is invoked before
+the push happens.
+Exiting with a non-zero status from this script causes 'git push'
+to abort.
...
+ if (!no_verify run_hook(NULL, pre-push)) {
+ die(_(pre-push hook failed: exiting\n));
+ }
NAK, at least in the current form. At least the system should tell
the hook where it is pushing and what is being pushed.
I agree.
Besides, there are five valid reasons to add a new hook to the
system, but your version of pre-push does not satisfy any of them:
http://thread.gmane.org/gmane.comp.version-control.git/94111/focus=71069
Here I disagree. I think it satisfies (1):
(1) A hook that countermands the normal decision made by the
underlying command. Examples of this class are the update
hook and the pre-commit hook.
pre-push would be very similar in spirit to pre-commit: pre-commit is a
filter that can prevent a bad commit from getting into the local
repository; pre-push is similarly a filter between the local repo and
remote repositories.
I also think it satisfies (2) and/or (5b):
(2) A hook that operates on data generated after the command
starts to run. [...]
(5) [...] Another example is the post-checkout
hook that gets information that is otherwise harder to get
(namely, if it was a branch checkout or file checkout --
you can figure it out by examining the command line but
that already is part of the processing git-checkout does
anyway, so no need to force duplicating that code in the
userland).
It would not be trivial for a wrapper script to figure out what branches
and commits are about to be pushed. But git push could tell the hook
script what branches are to be pushed. And if the pre-push hook is run
after negotiation between client and server of what commits need to be
transfered, the hook could also be provided that information and use it
to figure out which commits it should vet.
Although a pre-receive script on the remote repository could do most of
the same things as a pre-push script, the latter would sometimes have
advantages because it is run client-side:
* When the user doesn't have the ability to change the pre-receive
script on the server (think public git hosting services).
* For user-specific actions that are not wanted by all users pushing to
the same server (for example, maybe I add the string WIP to commit
messages for commits that are not ready to be pushed; my pre-push script
could verify that I don't push such a commit by accident).
* Preventing secret info (password files, proprietary branches) from
being pushed. Even if the remote repo were taught to reject them, they
would have already traversed the internet.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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] Rename V15_MINGW_HEADERS into CYGWIN_OLD_WINSOCK_HEADERS
See commit 380a4d927bff693c42fc6b22c3547bdcaac4bdc3: Update cygwin.c for new mingw-64 win32 api headers Cygwin up to 1.7.16 uses some header file from the WINE project Cygwin 1.7.17 uses some header file from the mingw-64 project As the old cygwin (like 1.5) never used mingw, the name V15_MINGW_HEADERS is confusing. Rename it into CYGWIN_OLD_WINSOCK_HEADERS Addtional note: Cygwin versions 1.7.1 up to 1.7.16 are expected to upgrade to Cygwin 1.7.17 or higher As a temporary workaround make can be run as CYGWIN_OLD_WINSOCK_HEADERS=Yes make Signed-off-by: Torsten Bögershausen tbo...@web.de --- Makefile| 6 +++--- compat/cygwin.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index c3edf8c..c2ea735 100644 --- a/Makefile +++ b/Makefile @@ -1089,7 +1089,7 @@ ifeq ($(uname_O),Cygwin) NO_SYMLINK_HEAD = YesPlease NO_IPV6 = YesPlease OLD_ICONV = UnfortunatelyYes - V15_MINGW_HEADERS = YesPlease + CYGWIN_OLD_WINSOCK_HEADERS = YesPlease endif NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease @@ -1901,8 +1901,8 @@ ifdef NO_REGEX COMPAT_CFLAGS += -Icompat/regex COMPAT_OBJS += compat/regex/regex.o endif -ifdef V15_MINGW_HEADERS - COMPAT_CFLAGS += -DV15_MINGW_HEADERS +ifdef CYGWIN_OLD_WINSOCK_HEADERS + COMPAT_CFLAGS += -DCYGWIN_OLD_WINSOCK_HEADERS endif ifdef USE_NED_ALLOCATOR diff --git a/compat/cygwin.c b/compat/cygwin.c index 59d86e4..b9f2862 100644 --- a/compat/cygwin.c +++ b/compat/cygwin.c @@ -1,5 +1,5 @@ #define WIN32_LEAN_AND_MEAN -#ifdef V15_MINGW_HEADERS +#ifdef CYGWIN_OLD_WINSOCK_HEADERS #include ../git-compat-util.h #include win32.h #else -- 1.7.12 -- 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: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 16.11.12 19:52, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: My understanding: Either use people cygwin 1.5 or they use cygwin 1.7, and in this case the installation is updated frequently. Peff or Junio, please go ahead with the patch. If it turns out that we want to support cygwin installations like 1.7.7 which could be upgraded, but are not upgraded since they are production machines we do not dare to touch we can still improve the autodetection. OK. I moved the topic forward but we may still want to rename the name of the macro to have CYGWIN somewhere in the name. I send a patch some seconds ago. I forgot to mention that this should be applied to next -- 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
