* Moving .git around
From: Geoff Russell @ 2008-07-24 1:32 UTC (permalink / raw)
To: git
For reasons which would take a while to explain, I'm building a repository
in a directory using "--git-dir=xxxx/.git --work-tree=." and
then doing an "mv xxxx/.git ./.git" and then trying to work with
that repository --- but can't
Below is a sample script. The last line (git add) fails with
fatal: unable to create
'/usr/local/AusTop/AuPrograms/AuServer/testgit/aaa/bbb/.git/index.lock':
No such file or directory
git doesn't seem to realise that there is a .git back up the tree.
I'm using 1.5.5.1
Cheers,
Geoff Russell
------------------------ sample script
#!/bin/sh
if [ -d "testgit" ] ; then
echo "remove testgit"
/bin/rm -rf testgit
fi
mkdir testgit && echo yyyy >testgit/sample.sh && cd testgit
mkdir aaa && mkdir aaa/bbb
echo xxxx > aaa/bbb/sample2.sh
mkdir xxx
git --git-dir=xxx/.git --work-tree=. init
git --git-dir=xxx/.git --work-tree=. add *.sh
git --git-dir=xxx/.git --work-tree=. commit -m demo
mv xxx/.git .
cd aaa/bbb
git add sample2.sh
^ permalink raw reply
* Re: [PATCH] (unnamed)
From: Junio C Hamano @ 2008-07-24 0:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7vej5k8719.fsf@gitster.siamese.dyndns.org>
Ooops.
I sent out before I can decide what the title should be. Sorry, will
think of something.
^ permalink raw reply
* Re: [PATCH] t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
From: Brandon Casey @ 2008-07-24 0:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20080724001916.GP32057@genesis.frugalware.org>
Miklos Vajna wrote:
> On Tue, Jul 22, 2008 at 04:17:43PM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> t/t0002-gitfile.sh | 2 +-
>> t/t1002-read-tree-m-u-2way.sh | 12 ++++++------
>> t/t2201-add-update-typechange.sh | 10 +++++-----
>> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> Hmm, after applying this patch, I have:
>
> ~/git/t$ git grep 'diff -U'
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 4.out >4diff.out
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 5.out >5diff.out
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 14.out >14diff.out
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 15.out >15diff.out
>
> Any reason you left this out? ;-)
I have the patch below in my repo so I can run this test. (copy/pasted
and white-space corrupted since I haven't figured out how to reply to a
message and import a patch correctly using thunderbird).
As you can see I just replaced the 'diff -U0' with 'git diff -U0' and then
stripped off the git bits from the diff in the compare_change() function.
I think there is probably a better way to fix this, so I left it out.
Thinking about it now, it would have made sense to hold off on the part of
the patch I submitted which applies to t1002-read-tree-m-u-2way.sh until I
had a solution for the rest of these 'diff -U0's.
-brandon
diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh
index aa9dd58..5e40cec 100755
--- a/t/t1002-read-tree-m-u-2way.sh
+++ b/t/t1002-read-tree-m-u-2way.sh
@@ -14,6 +14,8 @@ _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
compare_change () {
sed >current \
+ -e '1{/^diff --git /d;}' \
+ -e '2{/^index /d;}' \
-e '/^--- /d; /^+++ /d; /^@@ /d;' \
-e 's/^\(.[0-7][0-7][0-7][0-7][0-7][0-7]\) '"$_x40"' /\1 X /' "$1"
test_cmp expected current
@@ -75,7 +77,7 @@ test_expect_success \
git update-index --add yomin &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >4.out || return 1
- diff -U0 M.out 4.out >4diff.out
+ git diff -U0 --no-index M.out 4.out >4diff.out
compare_change 4diff.out expected &&
check_cache_at yomin clean &&
sum bozbar frotz nitfol >actual4.sum &&
@@ -94,7 +96,7 @@ test_expect_success \
echo yomin yomin >yomin &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >5.out || return 1
- diff -U0 M.out 5.out >5diff.out
+ git diff -U0 --no-index M.out 5.out >5diff.out
compare_change 5diff.out expected &&
check_cache_at yomin dirty &&
sum bozbar frotz nitfol >actual5.sum &&
@@ -206,7 +208,7 @@ test_expect_success \
git update-index --add nitfol &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >14.out || return 1
- diff -U0 M.out 14.out >14diff.out
+ git diff -U0 --no-index M.out 14.out >14diff.out
compare_change 14diff.out expected &&
sum bozbar frotz >actual14.sum &&
grep -v nitfol M.sum > expected14.sum &&
@@ -227,7 +229,7 @@ test_expect_success \
echo nitfol nitfol nitfol >nitfol &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >15.out || return 1
- diff -U0 M.out 15.out >15diff.out
+ git diff -U0 --no-index M.out 15.out >15diff.out
compare_change 15diff.out expected &&
check_cache_at nitfol dirty &&
sum bozbar frotz >actual15.sum &&
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] bring description of git diff --cc up to date
From: Jonathan Nieder @ 2008-07-24 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am09oqe.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Let's just do this. I think it is clear enough.
Works for me. Thanks, and sorry I dragged this on so.
^ permalink raw reply
* [PATCH]
From: Junio C Hamano @ 2008-07-24 0:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
f2eba66 (Enable HEAD@{...} and make it independent from the current
branch, 2007-02-03) introduced dwim_log() to handle <refname>@{...}
syntax, and as part of its processing, it checks if the ref exists by
calling refsolve_ref(). It should call it as a reader to make sure the
call returns NULL for a nonexistent ref (not as a potential writer in
which case it does not return NULL).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I found this purely by accident. "echo >.git/logs/refs/heads/HEAD"
would make your "git rev-parse HEAD@{1}" complain about a refname
'HEAD' being ambiguous without this patch.
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b0b2167..4fb77f8 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -273,7 +273,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
const char *ref, *it;
strcpy(path, mkpath(*p, len, str));
- ref = resolve_ref(path, hash, 0, NULL);
+ ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
if (!stat(git_path("logs/%s", path), &st) &&
^ permalink raw reply related
* Re: [PATCH] t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
From: Miklos Vajna @ 2008-07-24 0:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <E23rxnPh0xeYPsUuTseZ3Y6bteX3uHIcbLzTlyVPsX_N5fqcvRp1vA@cipher.nrlssc.navy.mil>
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
On Tue, Jul 22, 2008 at 04:17:43PM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> t/t0002-gitfile.sh | 2 +-
> t/t1002-read-tree-m-u-2way.sh | 12 ++++++------
> t/t2201-add-update-typechange.sh | 10 +++++-----
> 3 files changed, 12 insertions(+), 12 deletions(-)
Hmm, after applying this patch, I have:
~/git/t$ git grep 'diff -U'
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 4.out >4diff.out
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 5.out >5diff.out
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 14.out >14diff.out
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 15.out >15diff.out
Any reason you left this out? ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitk highlighting descendents/ancestors
From: Matt Seitz (matseitz) @ 2008-07-24 0:12 UTC (permalink / raw)
To: git
"Paul Mackerras" <paulus@samba.org> wrote in message news:<17530.60026.636981.60532@cargo.ozlabs.ibm.com>...
> I have implemented a feature in gitk (on the "new" branch) where it
> can highlight the commits that are, or are not, descendents or
> ancestors of the selected commit. For now it is invoked via a
> drop-down menu.
Is this feature still available? I don't see the menu running 1.5.6 on Cygwin. A coworker running 1.5.0.7 on Linux sees it.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 0:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwsjcft5g.fsf@gitster.siamese.dyndns.org>
On Wed, 23 July 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>
>>> Some people prefer to stay anonymous, so I think email is out.
>>>
>>>> 04. Which programming languages you are proficient with?
>>>> (The choices include programming languages used by git)
>>>> (zero or more: multiple choice)
>>>> - C, shell, Perl, Python, Tcl/Tk
>>>> + (should we include other languages, like C++, Java, PHP,
>>>> Ruby,...?)
>>>
>>> Yes, I think this should be a long list.
>>
>> I'd rather not have a "laundry list" of languages. I have put C++
>> because QGit uses it, Java because of egit/jgit, PHP for web
>> interfaces, Ruby because of GitHub and because of Ruby comminity
>> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
>> JavaScript here. What other languages should be considered?
>
> I refrained saying this in my initial response, but my initial reaction
> was "Why are you even asking this?".
>
> Yes, "getting to know you" demographics are customary done in surveys, and
> you kept it to the minimum which is also good, but I do not think this
> particular question is very interesting. For one thing, the question
> assumes the participant is a programmer, and we are giving an impression
> that we are interested in better programmers. Do we *still* require users
> to be a programmer to use git? I do not think so. Having to answer "none
> of these" to this question would make you feel unnecessarily bad, even if
> you are not a programmer and you know at the intellectual level that it is
> not your flaw not to be proficient in any.
The idea, I think, was to gauge which parts of Git would be hard to
find developers for, because of small number of people proficient in
the programming language the part is written in. I'm thinking here
about Tcl/Tk and gitk and git-gui, see
http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
Nevertheless, _if_ this question is to stay (I am not sure one way or
another), we would better add "I am not programmer" or something like
that to the list of possible answers.
> Asking about geographic location and preferred human languages might help
> to gauge what l10n are desired for GUIs, but even there, don't forget that
> we are no company. We do not research markets and translate messages to
> missing languages, however popular, before being asked. That's not how we
> operate. So the result of these questions will be mainly to satisfy our
> curiosity, nothing more.
It would also answer question if adding support for i18n in git, for
example support for translating git commands messages, is something
which people would want or not. If they would be translated or not
it would depend on people, but one cannot even begin translation
efforts if there is no infrastructure in place.
But as the rest of localization / internationalization / translation
questions ("What do you need translated?" for example) were removed
from proposed set of questions for this year survey, perhaps this
question should be removed as well.
> "What kind of content do you track" might also be an equally interesting
> question. It also falls into the curiosity department, though.
True.
What should be the list of possible choices? Source code,
documentation, configuration, backup, binary files, other?
>> I'm not sure about having multiple choice vs. free-form question here.
>> Multiple choice is easier to analyze, especially if one would want
>> histogram of replies...
>
> And when you expect very many respondents, (1) you cannot afford to
> free-form; and (2) statistics over multiple choices, as long as choices
> are well seeded, will give you a good enough overview picture.
I wonder how many responses will we get this year. In 2006 there were
around 117 responses (but IIRC it was announced only on git mailing
list, wasn't it?), in 2007 survey there were 683 individual responses.
Git is even more popular now, I think...
OTOH there are some questions, like "feature requests/proposals"
question which *do require* free-form question. But they should
be few, and preferably for questions for which we don't need
histogram of replies.
I'll convert as much questions as possible to multiple choice
(pre-seeded), trying to come up with a good set of canned responses.
A question: if analysis of responses was not a problem, do you prefer
free form, or "select a choice" question?
>> Again: free form has some hassles, but so does coming up with good
>> choice of fixed answers in multiple choice question.
>
> You need to do at least one or the other, and I do not think there is any
> way to avoid that. Without a good choices, histogram would become useless
> (not necessarily because the answer will be dominated by "Other", but the
> seeing the choices tends to set the frame of mind when/before somebody
> answers the question). With free-form, you will spend the rest of your
> life analyzing to get any useful insight.
True... well, depending of course on the number of replies. Analysing
around 50 free-form replies (half of 100 individual responses to survey)
is not impossible; analysing 250+ is a lot of work.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git Documentation
From: Karl Hasselström @ 2008-07-24 0:31 UTC (permalink / raw)
To: Pedro Melo; +Cc: Scott Chacon, git
In-Reply-To: <EDFF27AB-9B74-4868-A0BF-61AC8ED75037@simplicidade.org>
On 2008-07-22 11:15:40 +0100, Pedro Melo wrote:
> I also point them to Tommi Virtanen "Git for Computer
> Scientists":http://eagain.net/articles/git-for-computer-scientists/.
> It was that article that made it all "click" for me regarding git.
Me too.
I've found that starting off by explaining how git represents history
with blobs, trees, and commits (no need to mention tags or other
objects just yet), and how branches and merging just fall out
naturally from the commit DAG, is a good way to get people to
appreciate just how simple git's data model is. After that five-minute
introduction, they have a reasonable mental model of what the git
commands operate on -- then they just need to fill in the details,
like what commands there are and how they work.
(I've never taught git to anyone who didn't already know what a DAG or
a cryptographic hash is -- presumably, that would make it take more
than five minutes.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] bash completion: Add completion for 'git help'
From: Lee Marlow @ 2008-07-24 0:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1216854795-51155-1-git-send-email-lee.marlow@gmail.com>
Renamed cached __git_commandlist to __git_porcelain_commandlist
and added __git_all_commandlist that only filters out *--* helpers.
Completions for 'git help' will use the __git_all_commandlist, while
__git_porcelain_commandlist is used for git command completion.
Users who actually read man pages may want to see help for plumbing
commands.
Options added: --all --info --man --web
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
This version fixes a small error in the __git_all_commands
contrib/completion/git-completion.bash | 46 +++++++++++++++++++++++++++-----
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..f3bdea4 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -349,10 +349,10 @@ __git_complete_revlist ()
esac
}
-__git_commands ()
+__git_all_commands ()
{
- if [ -n "$__git_commandlist" ]; then
- echo "$__git_commandlist"
+ if [ -n "$__git_all_commandlist" ]; then
+ echo "$__git_all_commandlist"
return
fi
local i IFS=" "$'\n'
@@ -360,6 +360,24 @@ __git_commands ()
do
case $i in
*--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist=
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if [ -n "$__git_porcelain_commandlist" ]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i IFS=" "$'\n'
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
applymbox) : ask gittus;;
applypatch) : ask gittus;;
archimport) : import;;
@@ -427,8 +445,8 @@ __git_commands ()
esac
done
}
-__git_commandlist=
-__git_commandlist="$(__git_commands 2>/dev/null)"
+__git_porcelain_commandlist=
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
@@ -767,6 +785,18 @@ _git_gc ()
COMPREPLY=()
}
+_git_help ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--all --info --man --web"
+ return
+ ;;
+ esac
+ __gitcomp "$(__git_all_commands)"
+}
+
_git_ls_remote ()
{
__gitcomp "$(__git_remotes)"
@@ -1369,7 +1399,8 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|--help|-p|--paginate) ;;
+ --version|-p|--paginate) ;;
+ --help) command="help"; break ;;
*) command="$i"; break ;;
esac
c=$((++c))
@@ -1389,7 +1420,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
esac
return
fi
@@ -1414,6 +1445,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* Re: [PATCH] t9700/test.pl: backwards compatibility improvements
From: Brandon Casey @ 2008-07-24 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtzeg89cj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I have applied everything except for this one. I think it is Ok, but
> let's hear success or breakage stories from the list first and then remind
> me if the patch seems Ok, please?
will do.
^ permalink raw reply
* [PATCH] bash completion: Add completion for 'git help'
From: Lee Marlow @ 2008-07-24 0:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1216854795-51155-1-git-send-email-lee.marlow@gmail.com>
Renamed cached __git_commandlist to __git_porcelain_commandlist
and added __git_all_commandlist that only filters out *--* helpers.
Completions for 'git help' will use the __git_all_commandlist, while
__git_porcelain_commandlist is used for git command completion.
Users who actually read man pages may want to see help for plumbing
commands.
Options added: --all --info --man --web
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
This version fixes a small error in the __git_all_commands
contrib/completion/git-completion.bash | 46 +++++++++++++++++++++++++++-----
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..f3bdea4 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -349,10 +349,10 @@ __git_complete_revlist ()
esac
}
-__git_commands ()
+__git_all_commands ()
{
- if [ -n "$__git_commandlist" ]; then
- echo "$__git_commandlist"
+ if [ -n "$__git_all_commandlist" ]; then
+ echo "$__git_all_commandlist"
return
fi
local i IFS=" "$'\n'
@@ -360,6 +360,24 @@ __git_commands ()
do
case $i in
*--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist=
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if [ -n "$__git_porcelain_commandlist" ]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i IFS=" "$'\n'
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
applymbox) : ask gittus;;
applypatch) : ask gittus;;
archimport) : import;;
@@ -427,8 +445,8 @@ __git_commands ()
esac
done
}
-__git_commandlist=
-__git_commandlist="$(__git_commands 2>/dev/null)"
+__git_porcelain_commandlist=
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
@@ -767,6 +785,18 @@ _git_gc ()
COMPREPLY=()
}
+_git_help ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--all --info --man --web"
+ return
+ ;;
+ esac
+ __gitcomp "$(__git_all_commands)"
+}
+
_git_ls_remote ()
{
__gitcomp "$(__git_remotes)"
@@ -1369,7 +1399,8 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|--help|-p|--paginate) ;;
+ --version|-p|--paginate) ;;
+ --help) command="help"; break ;;
*) command="$i"; break ;;
esac
c=$((++c))
@@ -1389,7 +1420,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
esac
return
fi
@@ -1414,6 +1445,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* Re: [PATCH] perl/Makefile: update NO_PERL_MAKEMAKER section
From: Brandon Casey @ 2008-07-23 23:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy73s89hv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> The perl modules must be copied to blib/lib so they are available for
>> testing.
>
> True, but private-Error needs to be handled a bit more carefully, I
> think.
>
> How about this on top of your patch?
That works. Error.pm is not available on my system and the statements
to copy private-Error.pm to Error.pm are correctly placed in perl.mak.
I should have gotten a clue when a file named _private_-Error.pm was
being copied to Error.pm and taken a look at Makefile.PL.
Thanks.
-brandon
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-23 23:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <200807240130.31649.jnareb@gmail.com>
Hi,
Jakub Narebski wrote:
> Dnia ?roda 23. lipca 2008 16:54, Robin Rosenberg napisa?:
> > onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
> >> On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> >>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >>>>
> >>>>> 04. Which programming languages you are proficient with?
> >>>>> (The choices include programming languages used by git)
> >>>>> (zero or more: multiple choice)
> >>>>> - C, shell, Perl, Python, Tcl/Tk
> >>>>> + (should we include other languages, like C++, Java, PHP,
> >>>>> Ruby,...?)
[...]
>
> The idea is, I think, to know what languages people could contribute
> to Git; see analysis of this question at GitSurvey2007 page on git wiki:
> http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
Oha, is this a Git User's Survey or a Git Potential Contributor's Survey?
I thought this is some kind of demographic question about the "programming
background" of the user.
> And of course "I am not programmer" response...
This doesn't make sense, does it?
I know that there are non-programmer's who use git for there
configuration files and other non-programming track files, but
this looks somehow wrong in this survey.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 23:49 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Git, Miguel Arroz
In-Reply-To: <169F15EC-1A58-4C2A-84FC-3D14F7B4F1C5@yahoo.ca>
Dnia środa 23. lipca 2008 17:14, Jean-François Veillette napisał:
> Le 08-07-22 à 21:25, Jakub Narebski a écrit :
>
> > First there is a question about the form of survey. Should we use web
> > based survey, as the survey before (http://www.survey.net.nz), sending
> > emails with link to this survey, or perhaps do email based survey,
> > with email Reply-To: address put for this survey alone? Should we use
> > the same web survey service as before (found by Paolo Ciarrocchi for
> > first, 2006 survey, and used also for 2007 survey), or is there one
> > better (it would better be free, and without limitations on the number
> > of responses; in 2006 there were around 117 responses, in 2007 there
> > were 683 individual responses).
>
> Consider
> http://www.survs.com
> It is still in beta but already years ahead of the proposed solution.
> I don't know about the specific of the beta (cost, availability,
> etc.) but I had a live presentation of the product and it is an
> amazingly great product !
It certainly _looks_ nice, but it lacks one very important feature
(or at least I was not able to find it): the ability to download *RAW*
data to analyse it off-line using more advanced tools (like for
example Perl script to clean-up responses; spreadsheet like Excel or
Gnumeric, or some statictics tool like R to analyze data, for example
do a correlation between responses to different questions).
http://www.survey.net.nz allows to download raw data in modified
CSV format (modified as it allows for line continuation). See for
example raw data for Git User's Survey 2007 results:
http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=surveydata.csv
There is another nice thing that http://www.survey.net.nz is supposed
to have (but it doesn't unfortunately work; at least downloading
current layout of survey to tweak off-line doesn't/didn't work),
namely ability to create survey off-line using some specified text
format, and upload it, instead of creating it on-line (which might be
much work for large surveys).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: HP-UX issues (WAS: Re: [RFC] Git User's Survey 2008)
From: Miklos Vajna @ 2008-07-23 23:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200807232338.04340.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Wed, Jul 23, 2008 at 11:38:00PM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
> > 2) Have coreutils installed. (But then I think it would be good to list
> > this dependency in INSTALL.)
>
> It would be good idea, although "POSIX-compliant shells" implies
> coreutils somewhat; shell scripts usually do require some utilities,
> like sed, grep, cat, test etc.
Sure, but we already use test_cmp instead of diff -u, avoid grep -a,
etc. These tricks are for running without GNU coreutils, I guess.
> > 3) Patch git to use automake's install-sh. (Would such a patch be ever
> > accepted?)
>
> I think it would. It would allow us also to uncomment the
> AC_PROG_INSTALL line in configure.ac file to find 'install'
> automatically (autoconf requires having install.sh or install-sh
> fallback in the sources).
>
> The problem is coming up with minimal yet portable (at least as
> portable as git itself) fallback install.sh script.
I just checked automake-1.10.1's install-sh script, it works properly
with HP-UX's ksh.
I think it would be possible to:
1) Just use it: in long-term this would mean no additional maintenance
cost, since if any problem occurs, it could be just updated from
automake.
2) Or make it as minimal as possible: As far as I see the current git
build system just uses the -d and -m switches, so the support for the
-c, -C, -g, -o, -s, -t and -T switches could be removed. This way we
would get a minimal install-sh, but then it would have to be maintained
inside git.git.
I think 1) would be better.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Junio C Hamano @ 2008-07-23 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807222235520.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If the user called "rebase -i", marked a commit as "edit", "rebase
> --continue" would automatically amend the commit when there were
> staged changes.
>
> However, this is actively wrong when the current commit is not the
> one marked with "edit". So guard against this.
At what point in what valid workflow sequence does HEAD become different
from dotest/amend?
> @@ -419,7 +419,9 @@ do
> else
> . "$DOTEST"/author-script ||
> die "Cannot find the author identity"
> - if test -f "$DOTEST"/amend
> + if test -f "$DOTEST"/amend &&
> + test $(git rev-parse HEAD) = \
> + $(cat "$DOTEST"/amend)
> then
> git reset --soft HEAD^ ||
> die "Cannot rewind the HEAD"
In what way is this "guarding against it"? It goes on and makes an
unrelated commit without erroring out nor giving indication to the user
what is going on, doesn't it?
I am sure you meant well and the code is good, but I find that the
explanation is a bit lacking...
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 23:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Robin Rosenberg, git
In-Reply-To: <200807240130.31649.jnareb@gmail.com>
Hi,
On Thu, 24 Jul 2008, Jakub Narebski wrote:
> C# for git#/widgit
widgit is _dead_.
> and perhaps Git-Cheetah
C# for Git-Cheetah? Over my dead cold body.
Ciao,
Dscho "who still shakes his head that Jakub could even _think_ that"
^ permalink raw reply
* Re: [PATCH] t9700/test.pl: backwards compatibility improvements
From: Junio C Hamano @ 2008-07-23 23:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <k-pcfapbFwwISYvjf34W3d-E7j-DCb9tf-MW1z8rFObaPKgPJEmD7Q@cipher.nrlssc.navy.mil>
I have applied everything except for this one. I think it is Ok, but
let's hear success or breakage stories from the list first and then remind
me if the patch seems Ok, please?
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 23:30 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, git
In-Reply-To: <200807231654.18019.robin.rosenberg.lists@dewire.com>
Dnia środa 23. lipca 2008 16:54, Robin Rosenberg napisał:
> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>
>>>>> 04. Which programming languages you are proficient with?
>>>>> (The choices include programming languages used by git)
>>>>> (zero or more: multiple choice)
>>>>> - C, shell, Perl, Python, Tcl/Tk
>>>>> + (should we include other languages, like C++, Java, PHP,
>>>>> Ruby,...?)
>>>>
>>>> Yes, I think this should be a long list.
>>>
>>> I'd rather not have a "laundry list" of languages. I have put C++
>>> because QGit uses it, Java because of egit/jgit, PHP for web
>>> interfaces, Ruby because of GitHub and because of Ruby comminity
>>> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
>>> JavaScript here. What other languages should be considered?
>>
>> C# at least, since we had one (pretty unsuccessful) attempt at
>> reimplementing Git in it.
>
> What is the reason for the question? Do we want to know what languages
> people would like to contribute to Git in or do we want to know what "kind"
> of programmers are attracted by Git? Making it a long list should make
> it easier to tabulate the responses.
The idea is, I think, to know what languages people could contribute
to Git; see analysis of this question at GitSurvey2007 page on git wiki:
http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
C++ is for QGit, Java for egit/jgit, C# for git#/widgit and perhaps
Git-Cheetah, PHP for web interfaces, Ruby because of GitHub, Python
because some contrib is in Python, Emacs Lisp for git.el, HTML+CSS
and JavaScript for web interfaces; perhaps we should also add AsciiDoc
for documentation. And of course "I am not programmer" response...
But I'm not too tied to this question; I guess it can be simply
removed if it doesn't offer some important (for us) information.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] perl/Makefile: update NO_PERL_MAKEMAKER section
From: Junio C Hamano @ 2008-07-23 23:29 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <XKT02T_QW2tKLHpR7e3VuZjLXv3RP2E0GD54gXKrdIFm8xQsKvAyjg@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> The perl modules must be copied to blib/lib so they are available for
> testing.
True, but private-Error needs to be handled a bit more carefully, I
think.
How about this on top of your patch?
perl/Makefile | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 2b0d3d5..b8547db 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -25,13 +25,15 @@ $(makfile): ../GIT-CFLAGS Makefile
echo all: private-Error.pm Git.pm > $@
echo ' mkdir -p blib/lib' >> $@
echo ' $(RM) blib/lib/Git.pm; cp Git.pm blib/lib/' >> $@
- echo ' $(RM) blib/lib/Error.pm; \
- cp private-Error.pm blib/lib/Error.pm' >> $@
+ echo ' $(RM) blib/lib/Error.pm' >> $@
+ '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
+ echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
echo install: >> $@
echo ' mkdir -p $(instdir_SQ)' >> $@
echo ' $(RM) $(instdir_SQ)/Git.pm; cp Git.pm $(instdir_SQ)' >> $@
- echo ' $(RM) $(instdir_SQ)/Error.pm; \
- cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
+ echo ' $(RM) $(instdir_SQ)/Error.pm' >> $@
+ '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
+ echo ' cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
echo instlibdir: >> $@
echo ' echo $(instdir_SQ)' >> $@
else
^ permalink raw reply related
* Re: [PATCH] bring description of git diff --cc up to date
From: Junio C Hamano @ 2008-07-23 23:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807222210540.3408@harper.uchicago.edu>
Jonathan Nieder <jrnieder@uchicago.edu> writes:
> On Tue, 22 Jul 2008, Junio C Hamano wrote:
>
> Here's another attempt. I grimace at the sound of it, but it might be
> more clear.
Let's just do this. I think it is clear enough.
Documentation/git-diff-tree.txt | 10 +++++-----
Documentation/rev-list-options.txt | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 0e45b58..8c8f35b 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -93,11 +93,11 @@ include::pretty-options.txt[]
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
and '-p' options and further compresses the patch output
- by omitting hunks that show differences from only one
- parent, or show the same change from all but one parent
- for an Octopus merge. When this optimization makes all
- hunks disappear, the commit itself and the commit log
- message is not shown, just like in any other "empty diff" case.
+ by omitting uninteresting hunks whose the contents in the parents
+ have only two variants and the merge result picks one of them
+ without modification. When all hunks are uninteresting, the commit
+ itself and the commit log message is not shown, just like in any other
+ "empty diff" case.
--always::
Show the commit itself and the commit log message even
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b6f5d87..3aa3809 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -112,9 +112,9 @@ options may be given. See linkgit:git-diff-files[1] for more options.
--cc::
This flag implies the '-c' options and further compresses the
- patch output by omitting hunks that show differences from only
- one parent, or show the same change from all but one parent for
- an Octopus merge.
+ patch output by omitting uninteresting hunks whose contents in
+ the parents have only two variants and the merge result picks
+ one of them without modification.
-r::
^ permalink raw reply related
* [PATCH] bash completion: Add completion for 'git help'
From: Lee Marlow @ 2008-07-23 23:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Renamed cached __git_commandlist to __git_porcelain_commandlist
and added __git_all_commandlist that only filters out *--* helpers.
Completions for 'git help' will use the __git_all_commandlist, while
__git_porcelain_commandlist is used for git command completion.
Users who actually read man pages may want to see help for plumbing
commands.
Options added: --all --info --man --web
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 46 +++++++++++++++++++++++++++-----
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..0e37b71 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -349,10 +349,10 @@ __git_complete_revlist ()
esac
}
-__git_commands ()
+__git_all_commands ()
{
- if [ -n "$__git_commandlist" ]; then
- echo "$__git_commandlist"
+ if [ -n "$__git_all_commandlist" ]; then
+ echo "$__git_all_commandlist"
return
fi
local i IFS=" "$'\n'
@@ -360,6 +360,24 @@ __git_commands ()
do
case $i in
*--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist=
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if [ -n "$__git_porcelain_commandlist" ]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i IFS=" "$'\n'
+ for i in 'help' $__git_all_commands
+ do
+ case $i in
+ *--*) : helper pattern;;
applymbox) : ask gittus;;
applypatch) : ask gittus;;
archimport) : import;;
@@ -427,8 +445,8 @@ __git_commands ()
esac
done
}
-__git_commandlist=
-__git_commandlist="$(__git_commands 2>/dev/null)"
+__git_porcelain_commandlist=
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
@@ -767,6 +785,18 @@ _git_gc ()
COMPREPLY=()
}
+_git_help ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--all --info --man --web"
+ return
+ ;;
+ esac
+ __gitcomp "$(__git_all_commands)"
+}
+
_git_ls_remote ()
{
__gitcomp "$(__git_remotes)"
@@ -1369,7 +1399,8 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|--help|-p|--paginate) ;;
+ --version|-p|--paginate) ;;
+ --help) command="help"; break ;;
*) command="$i"; break ;;
esac
c=$((++c))
@@ -1389,7 +1420,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
esac
return
fi
@@ -1414,6 +1445,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* [PATCH] Make non-static functions, that may be static, static
From: Stephan Beyer @ 2008-07-23 23:09 UTC (permalink / raw)
To: git; +Cc: gitster, Stephan Beyer
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Or are there any reasons against that? :)
builtin-commit.c | 2 +-
builtin-config.c | 2 +-
builtin-for-each-ref.c | 2 +-
builtin-merge.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 97e64de..9d7100c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -877,7 +877,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
}
}
-int git_commit_config(const char *k, const char *v, void *cb)
+static int git_commit_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "commit.template"))
return git_config_string(&template_file, k, v);
diff --git a/builtin-config.c b/builtin-config.c
index 0cf191a..91fdc49 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -145,7 +145,7 @@ free_strings:
return ret;
}
-char *normalize_value(const char *key, const char *value)
+static char *normalize_value(const char *key, const char *value)
{
char *normalized;
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 76282ad..445039e 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -809,7 +809,7 @@ static struct ref_sort *default_sort(void)
return sort;
}
-int opt_parse_sort(const struct option *opt, const char *arg, int unset)
+static int opt_parse_sort(const struct option *opt, const char *arg, int unset)
{
struct ref_sort **sort_tail = opt->value;
struct ref_sort *s;
diff --git a/builtin-merge.c b/builtin-merge.c
index 8825dcf..e78fa18 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -431,7 +431,7 @@ static void merge_name(const char *remote, struct strbuf *msg)
sha1_to_hex(remote_head->sha1), remote);
}
-int git_merge_config(const char *k, const char *v, void *cb)
+static int git_merge_config(const char *k, const char *v, void *cb)
{
if (branch && !prefixcmp(k, "branch.") &&
!prefixcmp(k + 7, branch) &&
--
1.6.0.rc0.102.ga1791
^ permalink raw reply related
* Re: [PATCH] editor.c: Libify launch_editor()
From: Stephan Beyer @ 2008-07-23 23:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807181405510.3932@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> > This patch removes exit()/die() calls and builtin-specific messages from
> > launch_editor(), so that it can be used as a general libgit.a function
> > to launch an editor.
>
> Thanks. Now we have to convince Junio that it is a good idea :-)
Well, I've seen that *a lot* of lib code (15 functions, see below) is in
the builtins.
Cleaning that up seems to be good to have a real separation between
libgit and builtins, but I guess such a change would not find its way
into 1.6.0, would it?
Regards,
Stephan
PS: I've spontaneously decided to make a list:
defined-in func-name - used in builtin-\1.c
builtin-add.c:
add_files_to_cache() - add, checkout, commit
interactive_add() - add, commit
builtin-archive.c:
parse_pathspec_arg() - archive, uploard-archive
builtin-init-db.c:
init_db() - init-db, clone
builtin-ls-files.c:
overlay_tree_on_cache() - ls-files, commit
report_path_error() - ls-files, checkout, commit
builtin-mailsplit.c:
read_line_with_nul() - mailsplit, mailinfo
builtin-merge-recursive.c:
write_tree_from_memory() - merge-recursive, checkout
builtin-prune-packed.c:
prune_packed_objects() - prune-packed, prune
builtin-shortlog.c:
shortlog_add_commit() - shortlog, log
shortlog_init() - shortlog, log
shortlog_output() - shortlog, log
shortlog_init() - shortlog, log
builtin-stripspace.c:
stripspace() - stripspace, commit, tag
And launch_editor() that is handled by the patch in this thread.
Then there are functions that are non-static, but not declined in
any .h file. A patch that makes them static follows in a separate mail.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox