Re: [RFC] Questions for Git User's Survey 2011
Jakub Narębski jna...@gmail.com writes: Second, the situation is more complicated: one can be actively involved in 1 distributed project with 200+ contributors via Gerrit, often contribute to 1 centralized project with 15-25 contributors, and rarely interact with distributed project using blessed repository workflow where number of contributors range from few to few hundred. We're doing a user survey, so if a project has 200 contributors, it will statistically have 10 times more survey participants than a 20 contributors project. Sure, statistics don't always work, but if we don't trust statistics, we shouldn't do a survey. Third, no other in matrix form. Well, forcing the user to chose between existing options is not necessarily bad IMHO. It at least avoids free-form answers like I'm doing almost exactly option b) but I don't call it this way so I didn't tick b). -- 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
[RFC] Questions for Git User's Survey 2011
[I'm sorry for breaking the chain, but I have accidentally hit Reply, instead of Reply To All, and missed sending reply to git mailing list] On Tue, Sep 25, 2012 at 8:17 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jakub Narębski jna...@gmail.com writes: Second, the situation is more complicated: one can be actively involved in 1 distributed project with 200+ contributors via Gerrit, often contribute to 1 centralized project with 15-25 contributors, and rarely interact with distributed project using blessed repository workflow where number of contributors range from few to few hundred. We're doing a user survey, so if a project has 200 contributors, it will statistically have 10 times more survey participants than a 20 contributors project. Sure, statistics don't always work, but if we don't trust statistics, we shouldn't do a survey. I always worry if the set of survey participants is representative... Third, no other in matrix form. Well, forcing the user to chose between existing options is not necessarily bad IMHO. It at least avoids free-form answers like I'm doing almost exactly option b) but I don't call it this way so I didn't tick b). There is another issue: there are many, many questions which are currently in multiple answers form (e.g. transports, or tools), some of them with other, please specify, which are in the same boat wrt. precision / accuracy as discussed workflow question. So, NAK for this year survey, we can think about and discuss it for the next one (if there would be interest in having one). -- Jakub Narebski -- Jakub Narebski -- 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 6/5] side-step a make rule that builds t3070-wildmatch
From: Johannes Sixt j...@kdbg.org
Running make t3070-wildmatch aborts with this error:
$ make t3070-wildmatch
*** t3070-wildmatch.sh ***
# passed all 11 test(s)
1..11
cat t3070-wildmatch.sh t3070-wildmatch
/bin/sh.exe: t3070-wildmatch: File exists
make: *** [t3070-wildmatch] Error 1
It seems that there is a make rule that attempts to transform a *.sh file
into a file without the extension. The rule fails because t3070-wildmatch
is a directory. Rename it to t3070.
Of course, nobody would run exactly make t3070-wildmatch. But it is
common (at least for me) to run make t[3-9]* or similar, which would
include t3070-wildmatch. With this patch, it includes t3070, but that does
not hurt because make just skips it with Nothing to be done for `t3070'.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Feel free to squash this patch if you re-roll the series.
t/t3070-wildmatch.sh | 2 +-
t/{t3070-wildmatch = t3070}/wildtest.txt | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename t/{t3070-wildmatch = t3070}/wildtest.txt (100%)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 7fb63ff..c4da26c 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -6,7 +6,7 @@ test_description='wildmatch tests'
test_wildmatch() {
test_expect_success wildmatch $*
- test-wildmatch $* ../t3070-wildmatch/wildtest.txt actual
+ test-wildmatch $* ../t3070/wildtest.txt actual
echo 'No wildmatch errors found.' expected
test_cmp expected actual
diff --git a/t/t3070-wildmatch/wildtest.txt b/t/t3070/wildtest.txt
similarity index 100%
rename from t/t3070-wildmatch/wildtest.txt
rename to t/t3070/wildtest.txt
--
1.7.12.1.1626.gf25df0e
--
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: Quickly searching for a note
Jeff King venit, vidit, dixit 25.09.2012 02:42: On Sun, Sep 23, 2012 at 05:07:04PM +0200, Michael J Gruber wrote: If we linked with an embeddable scripting language interpreter (e.g. lua, tcl, guile, ...), it may be a more practical enhancement, though. Yes, the idea is extend, don't embed the other way round, so to say. I still think extending git log so that it can call a script with commit info already in the environment gives a more convenient approach then embedding git rev-list into your own script. It's not more performant, of course. I think Junio is going the other way than you think. That is, you still run rev-list, but rather than call a sub-program, you call a snippet of an embeddable script. Which is the same idea as yours, but theoretically way faster. I just see many more requests of the type grep notes coming, i.e. limitting based on other commit info, or in a different way then already possible. Just image you want to find out who's responsible for those commits in git.git with subject lengths 100 ;) Like this: git log --lua-filter='return subject().len 100' ? :) Like this! :) 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: [RFC/PATCH] git: expand user path in --git-dir
Jan Engelhardt venit, vidit, dixit 25.09.2012 07:33: On Monday 2012-09-24 14:57, Michael J Gruber wrote: Currently, all paths in the config file are subject to tilde expansion for user paths while the argument to --git-dir is not expanded, and neither are paths in the environment such as GIT_DIR. From the user perspective, though, the two commands GIT_DIR=~user/foo git command git --git-dir=~user/foo command currently behave differently because in the first case the shell would perform tilde expansion, but not in the second. If git uses a standardized option logic (getopt-like) which accepts both '=' and (new argument) for long options, you could easily do git --git-dir ~user/foo command Of course, but wouldn't it be even more confusing if tilde expansion is done for --git-dir ~user/foo but not --git-dir=~user/foo? That confusion is all bash's fault since is done == is done by bash (or not), but still. 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: Can git pull from a mercurial repository?
On 09/18/2012 02:40 PM, Joachim Schmitz wrote: From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google git remote helpers and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... Install a newer python and hg Are you really sure, that python 2.5 doesn't exist for your machine? Most non embedded devices should offer python 2.5 or newer (for some distros you just have to add 'alternative' repositories) -- 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] mergetool--lib: Allow custom commands to override built-ins
Allow users to override the default commands provided by the
mergetools/* scriptlets.
Users occasionally run into problems where they expect to be
able to override the built-in tool names. The documentation
does not explicitly mention that built-ins cannot be overridden,
so it's easy to assume that it should work.
Lift this restriction so that built-in tools are handled the
same way as user-configured tools. Add tests to guarantee this
behavior.
A nice benefit of this change is that it protects users from
having future versions of git trump their custom configuration
with a new built-in tool.
C.f.:
http://stackoverflow.com/questions/7435002/mergetool-from-gitconfig-being-ignored
http://thread.gmane.org/gmane.comp.version-control.msysgit/13188
http://thread.gmane.org/gmane.comp.version-control.git/148267
Signed-off-by: David Aguilar dav...@gmail.com
---
The Cc: list includes folks who were involved in the above threads.
Hopefully we can do without the workarounds now ;-)
git-mergetool--lib.sh | 40 ++--
mergetools/defaults | 28 ++--
t/t7610-mergetool.sh | 13 +
t/t7800-difftool.sh | 11 +++
4 files changed, 64 insertions(+), 28 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 54cb708..f013a03 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -104,13 +104,49 @@ run_merge_tool () {
if merge_mode
then
- merge_cmd $1
+ run_merge_cmd $1
else
- diff_cmd $1
+ run_diff_cmd $1
fi
return $status
}
+# Run a either a configured or built-in diff tool
+run_diff_cmd () {
+ merge_tool_cmd=$(get_merge_tool_cmd $1)
+ if test -n $merge_tool_cmd
+ then
+ ( eval $merge_tool_cmd )
+ status=$?
+ return $status
+ else
+ diff_cmd $1
+ fi
+}
+
+# Run a either a configured or built-in merge tool
+run_merge_cmd () {
+ merge_tool_cmd=$(get_merge_tool_cmd $1)
+ if test -n $merge_tool_cmd
+ then
+ trust_exit_code=$(git config --bool \
+ mergetool.$1.trustExitCode || echo false)
+ if test $trust_exit_code = false
+ then
+ touch $BACKUP
+ ( eval $merge_tool_cmd )
+ status=$?
+ check_unchanged
+ else
+ ( eval $merge_tool_cmd )
+ status=$?
+ fi
+ return $status
+ else
+ merge_cmd $1
+ fi
+}
+
list_merge_tool_candidates () {
if merge_mode
then
diff --git a/mergetools/defaults b/mergetools/defaults
index 1d8f2a3..21e63ec 100644
--- a/mergetools/defaults
+++ b/mergetools/defaults
@@ -8,36 +8,12 @@ can_diff () {
}
diff_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
- if test -z $merge_tool_cmd
- then
- status=1
- break
- fi
- ( eval $merge_tool_cmd )
- status=$?
+ status=1
return $status
}
merge_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
- if test -z $merge_tool_cmd
- then
- status=1
- break
- fi
- trust_exit_code=$(git config --bool \
- mergetool.$1.trustExitCode || echo false)
- if test $trust_exit_code = false
- then
- touch $BACKUP
- ( eval $merge_tool_cmd )
- status=$?
- check_unchanged
- else
- ( eval $merge_tool_cmd )
- status=$?
- fi
+ status=1
return $status
}
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 6fa0c70..bc38737 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -509,4 +509,17 @@ test_expect_success 'file with no base' '
git reset --hard master /dev/null 21
'
+test_expect_success 'custom commands override built-ins' '
+git checkout -b test14 branch1
+git config mergetool.defaults.cmd cat \\$REMOTE\ \\$MERGED\
+git config mergetool.defaults.trustExitCode true
+test_must_fail git merge master
+git mergetool --no-prompt --tool defaults -- both
+echo master both added expected
+test_cmp both expected
+git config --unset mergetool.defaults.cmd
+git config --unset mergetool.defaults.trustExitCode
+git reset --hard master /dev/null 21
+'
+
test_done
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 9c3e997..eb1d3f8 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -76,6 +76,17 @@ test_expect_success PERL 'custom commands' '
test $diff = branch
'
+# Ensures that a custom difftool.tool.cmd overrides built-ins
+test_expect_success PERL 'custom commands override built-ins' '
+ restore_test_defaults
+
Re: [RFC/PATCH 0/3] git log --pretty=lua
On Tue, Sep 25, 2012 at 7:23 AM, Jeff King p...@peff.net wrote:
We've talked off and on about extending the --pretty=format specifiers
to something more flexible. There's also been talk recently of more
flexible commit-filtering (e.g., grepping individual notes). Rather
than invent a new Turing-complete language, I thought I'd try building
on somebody else's work by embedding an existing language.
Why Lua? I don't especially like it as a language. But it's designed for
this purpose, which makes it very lightweight and relatively simple to
embed.
Personally I'd prefer a Scheme variant.
The syntax, on the other hand...yuck.
Oops. Scheme is out then.
One thing that makes Lua
horrible for this use is that it does not have interpolated strings.
However, there are template libraries for Lua, so maybe there's
something there.
For --pretty, the first thing I looked up was utf-8 support and Lua
does not seem to have that built in. Libraries can help but it'll be
more verbose than native language support.
And a 4/3 patch would probably add --lua-filter as a revision option
for limiting commits.
I was thinking of nearly the same thing, except that I hide the
filters behind sha-1 extended syntax. Users can link sha-1@{foo} to
a lua function, for example.
I wonder what areas in git might benefit from such a scripting
language, and whether someday we would convert some of git builtin
commands to $NEWLANG, if $NEWLANG proves easier to maintain for
complex logic commands. grep and rev-list (searching in general) are
probably where $NEWLANG shines. But for really complex searches, one
may want to go with libgit2 or other bindings to their favourite
language than one git may provide. gitignore and gitattributes can
make use of $NEWLANG but it has to be really fast. There was talk
about conditionals in config file, which $NEWLANG might also help.
In general I'm quite happy with what git provides. There are many
advanced features that I have never used/or even aware of.
--
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: [RFC/PATCH 0/3] git log --pretty=lua
- Original Message - From: Nguyen Thai Ngoc Duy pclo...@gmail.com Sent: Tuesday, September 25, 2012 7:22:49 AM Subject: Re: [RFC/PATCH 0/3] git log --pretty=lua On Tue, Sep 25, 2012 at 7:23 AM, Jeff King p...@peff.net wrote: We've talked off and on about extending the --pretty=format specifiers to something more flexible. There's also been talk recently of more flexible commit-filtering (e.g., grepping individual notes). Rather than invent a new Turing-complete language, I thought I'd try building on somebody else's work by embedding an existing language. Why Lua? I don't especially like it as a language. But it's designed for this purpose, which makes it very lightweight and relatively simple to embed. Personally I'd prefer a Scheme variant. Scheme only brings up bad memories for me ;) And while we use Lua at $dayjob, I, like Peff, am not a huge fan of the syntax. So turning to the internet to solve my problem, a quick Google search for embeddable scripting languages (assuming the heavyweights like Perl and Python are already out) produces Lua, JavaScript or specifically SpiderMonkey [1] (yay buzzword compliance!), Ch [2] (unfortunately closed source), and AngelScript [3]. From a brief read of the webpage, AngelScript looks pretty interesting. I'm much better with (and thus preferential to) Python and Perl myself, but I can understand anyone's reservation in bundling/depending on libraries of that size. [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey [2] http://www.softintegration.com/ [3] http://angelcode.com/angelscript/ Thanks, Stephen -- 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: Can git pull from a mercurial repository?
Gelonida N wrote: On 09/18/2012 02:40 PM, Joachim Schmitz wrote: From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google git remote helpers and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... Install a newer python and hg Are you really sure, that python 2.5 doesn't exist for your machine? Yes, I am sure. Python 2.4 had been ported more than 5 years ago by a former workmate, otherwise we wouldn't even have that. Most non embedded devices should offer python 2.5 or newer (for some distros you just have to add 'alternative' repositories) For this platform (HP NonStop) basically nothing is available from any repository on the web but ITUGLIB (http://ituglib.connect-community.org) and that's the machine I'm working on/for ;-) We're currently trying to port Python-2.7, but it ain't easy... Bye, Jojo -- 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: Can git pull from a mercurial repository?
Hi there, On 18.09.2012, at 14:40, Joachim Schmitz wrote: From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google git remote helpers and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) I think there is a lot of demand for a git-hg bridge, a way to seemlessly access a Mercurial repository as if it was a git repository. A converse to hg-git http://hg-git.github.com/ As you discovered, there are several attempts to this. A recent overview over some of them can be found here: https://github.com/dubiousjim/yagh/blob/master/README.md Another remark: It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... This is mine, and I am sorry that it causes confusion -- but in fact, my goal it is kind of a continuation of the https://github.com/SRabbelier/git code. OR rather, it collects code others wrote to improve that codebase, and I just added a few fixes that made it work for me. In particular, I tried to figure out the reasons for why it never made it into git, and in the process, created this Wiki page: https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg. Which attempts to document how to use this code, and what needs to be done. My hope was that perhaps more people would be interested in this, and in helping out with it, but so far no such luck. My goals were noble, but you are the second person who considers this work to be confusing, so if that is what the majority thinks, I am willing to remove that text again (or rather, hide it away in some private repository). Cheers, Max-- 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: Can git pull from a mercurial repository?
From: Max Horn [mailto:post...@quendi.de] Sent: Tuesday, September 25, 2012 4:15 PM To: Joachim Schmitz Cc: 'Andreas Ericsson'; git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? Hi there, On 18.09.2012, at 14:40, Joachim Schmitz wrote: From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google git remote helpers and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) I think there is a lot of demand for a git-hg bridge, a way to seemlessly access a Mercurial repository as if it was a git repository. A converse to hg-git http://hg-git.github.com/ As you discovered, there are several attempts to this. A recent overview over some of them can be found here: https://github.com/dubiousjim/yagh/blob/master/README.md Another remark: It seems https://github.com/rfk/git-remote-hg requires Python 2.5 (and I only have 2.4), also I have no idea how to get it installed https://github.com/SRabbelier/git is 3 years old, apparently never made it into git, guess for a reason? Then I found https://github.com/fingolfin/git/commits/remote-hg, looks very confusing to me... This is mine, and I am sorry that it causes confusion -- but in fact, my goal it is kind of a continuation of the https://github.com/SRabbelier/git code. OR rather, it collects code others wrote to improve that codebase, and I just added a few fixes that made it work for me. In particular, I tried to figure out the reasons for why it never made it into git, and in the process, created this Wiki page: https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg. Which attempts to document how to use this code, and what needs to be done. My hope was that perhaps more people would be interested in this, and in helping out with it, but so far no such luck. Ah, with that pages it gets much clearer! Only how should anyone know that https://github.com/fingolfin/git/commits/remote-hg is related in any form or shape with https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg? I'm afraid it still won't help me much though, as I guess it too requites Python 2.5 or later, as it uses the Mercuroal Python API (and that actually may be the reason why it never made it into git? I believe to have read somewhere that git tries to restrict itself to Python 2.4) My goals were noble, but you are the second person who considers this work to be confusing, so if that is what the majority thinks, I am willing to remove that text again (or rather, hide it away in some private repository). No, please don't. Rather make that clear on https://github.com/fingolfin/git/commits/remote-hg ... Bye, Jojo -- 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: [RFC/PATCH 0/3] git log --pretty=lua
Jeff King p...@peff.net writes: We've talked off and on about extending the --pretty=format specifiers to something more flexible. There's also been talk recently of more flexible commit-filtering (e.g., grepping individual notes). Mercurial has a similar thing, which can be a source of inspiration: http://www.selenic.com/hg/help/revsets On the one hand, if find it a bit overkill to have a full language for this, but on the other hand, it allows expressing easily and explicitely boolean operators. I would find git log 'grep(foo) or grep(bar)' very intuitive and elegant, while I never know whether git log --grep=foo --grep=bar is a OR or a AND (there was a patch recently to clarify the doc). Note that Mercurial's version seem to really act on sets of commits, not just individual commits, as it allows things like hg log -r 'sort(date(May 2008), user)' or the equivalent of git's negative revision argument : x - y Changesets in x but not in y. So it would be more a new git log --filter='some expression', not a --pretty=lua. -- 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: Quickly searching for a note
Jeff King p...@peff.net writes: Agreed. I just posted a patch series that gives you --pretty lua support, though I haven't convinced myself it's all that exciting yet. I think it would be nicer for grepping, where the conditionals read more like regular code. Something like: git log --lua-filter=' return author().name.match(Junio) note(p4).match(1234567) ' reads OK to me. Yeah, except for me and p4??? ;-) -- 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: [RFC/PATCH 0/3] git log --pretty=lua
Matthieu Moy matthieu@grenoble-inp.fr writes: Jeff King p...@peff.net writes: We've talked off and on about extending the --pretty=format specifiers to something more flexible. There's also been talk recently of more flexible commit-filtering (e.g., grepping individual notes). Mercurial has a similar thing, which can be a source of inspiration: http://www.selenic.com/hg/help/revsets On the one hand, if find it a bit overkill to have a full language for this, but on the other hand, it allows expressing easily and explicitely boolean operators. I would find git log 'grep(foo) or grep(bar)' very intuitive and elegant,... You have to be careful with grep, though. It would be unclear what and there would mean if you replaced your or with. Peff's earlier examples e.g. git log --lua-filter=' return author().name.match(Junio) note(p4).match(1234567) ' git log --lua-filter='return subject().len 100' are clearly good ones that illustrate the power of filtering. -- 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] pathspec.c: Fix some sparse warnings
Sparse issues a warning for all six external symbols defined in this
file. In order to suppress the warnings, we include the 'pathspec.h'
header file, which contains the relevant extern declarations for these
symbols.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Adam,
When you re-roll your 'as/check-ignore' branch could you please squash
this patch into commit a1080211 (pathspec.c: move reusable code from
builtin/add.c, 20-09-2012).
Thanks!
ATB,
Ramsay Jones
pathspec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/pathspec.c b/pathspec.c
index 9525c7c..5dba000 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -1,5 +1,6 @@
#include cache.h
#include dir.h
+#include pathspec.h
void validate_path(const char *prefix, const char *path)
{
--
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: problem with setlocale trick in gettext.c
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: I think the setlocale() trick in init_gettext_charset() messes up locale support from library. Currently I get fatal: Could not switch to '/foo/': Kh?ng c? t?p tin ho?c th? m?c nh? v?y That pretty much matches what the big comment before your patch disables, doesn't it? Could it be that newer/older libc differ in the behaviour around this 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] pathspec.c: Fix some sparse warnings
On Tue, Sep 25, 2012 at 6:15 PM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote: Sparse issues a warning for all six external symbols defined in this file. In order to suppress the warnings, we include the 'pathspec.h' header file, which contains the relevant extern declarations for these symbols. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Adam, When you re-roll your 'as/check-ignore' branch could you please squash this patch into commit a1080211 (pathspec.c: move reusable code from builtin/add.c, 20-09-2012). Will do, thanks a lot! -- 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] graph: avoid infinite loop in graph_show_commit()
Junio C Hamano gits...@pobox.com writes: Has either of you tried the patch with the problematic case the other patch tries to solve? Michal's old patch does smell like it is going in the better direction in that it stops looping when we know we would only be showing the padding, which is a sign that we are done with showing the commit. I think this should suffice. I do not know if Michal's patch is the right fix, though. It appears to me that --graph assumes one commit is shown only once, but diff-tree -m and friends want to show a merge commit twice and is fundamentally incompatible with the assumption. We might be off either fixing that in the graph code (not with a band-aid like patches from you two to make it punt), or forbidding the combination altogether. t/t4202-log.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t4202-log.sh b/t/t4202-log.sh index 71be59d..14f73e3 100755 --- a/t/t4202-log.sh +++ b/t/t4202-log.sh @@ -264,6 +264,16 @@ test_expect_success 'log --graph with merge' ' test_cmp expect actual ' +test_expect_success 'log --raw --graph -m with merge' ' + git log --raw --graph --oneline -m master | head -n 500 actual + grep initial actual +' + +test_expect_success 'diff-tree --graph' ' + git diff-tree --graph master^ | head -n 500 actual + grep one actual +' + cat expect \EOF * commit master |\ Merge: A B -- 1.7.12.1.451.gb433296 -- 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
A generalization of git blame
Hi, I have been developing my git tool (based on the git internal API) that can find out all the commits that have changed a line for better authorship. The reason is for my binary code authorship research, I use machine learning to classify code authorship. To produce training data, I start with a source code repository with well-known author labels for each line and then compiling the project into binary. So, I am able to know the authorship for binary code and then apply some machine learning techniques. To get ground truth of authorship for each line, I start with git-blame. But later I find this is not sufficient because the last commit may only add comments or may only change a small part of the line, so that I shouldn't attribute the line of code to the last author. Of course, there must be some debates on who can be the representative of a line of code. So what I would like to do is find out all the commits that have ever changed a line, then I can try different approaches to summarize over all these commits to produce my final authorship label (or even tuple). I was wondering whether there have been similar debates over accurate authorship in this community before and whether there may be other people interested in this work. Thanks --Xiaozhu -- 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] git-web--browse: Fix open HTML help pages from iTerm
iTerm is an alternative to the default terminal emulation program on Mac OS X. git-web--browse wasn't aware of iTerm and failed to open HTML help pages when used in a shell session running in iTerm, reporting No known browser available. Now it works as expected. Signed-off-by: Steffen Prohaska proha...@zib.de --- git-web--browse.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-web--browse.sh b/git-web--browse.sh index 1e82726..95ecf65 100755 --- a/git-web--browse.sh +++ b/git-web--browse.sh @@ -120,7 +120,8 @@ if test -z $browser ; then fi # SECURITYSESSIONID indicates an OS X GUI login session if test -n $SECURITYSESSIONID \ - -o $TERM_PROGRAM = Apple_Terminal ; then + -o $TERM_PROGRAM = Apple_Terminal \ + -o $TERM_PROGRAM = iTerm.app ; then browser_candidates=open $browser_candidates fi # /bin/start indicates MinGW -- 1.7.12.1.403.g14e83b4 -- 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/2] gitweb: tags feed
The idea of this small patchset is to generate feeds listing only tags. This is useful to allow users to follow only the ‘stable’ (i.e. tagged, not in-progress) releases of the project from its gitweb (e.g. because the project doesn't have an actual website, or whatever). It's a draft implementation, comments welcome. Giuseppe Bilotta (2): gitweb: infrastructure for tags feed gitweb: expose tags feed in appropriate places gitweb/gitweb.perl | 126 ++--- 1 file changed, 91 insertions(+), 35 deletions(-) -- 1.7.12.1.577.gff9625d -- 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/2] gitweb: infrastructure for tags feed
Signed-off-by: Giuseppe Bilotta giuseppe.bilo...@gmail.com
---
gitweb/gitweb.perl | 79 +++---
1 file changed, 58 insertions(+), 21 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7f8c187..6cb51f7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3711,6 +3711,7 @@ sub git_get_tags_list {
if ($type eq tag || $type eq commit) {
$ref_item{'epoch'} = $epoch;
+ $ref_item{'tz'} = $tz;
if ($epoch) {
$ref_item{'age'} = age_string(time -
$ref_item{'epoch'});
} else {
@@ -8004,6 +8005,10 @@ sub git_shortlog {
sub git_feed {
my $format = shift || 'atom';
+
+ # feed context: log, tags
+ my $ctx = shift || 'log';
+
my $have_blame = gitweb_check_feature('blame');
# Atom: http://www.atomenabled.org/developers/syndication/
@@ -8012,9 +8017,19 @@ sub git_feed {
die_error(400, Unknown web feed format);
}
+ if ($ctx ne 'log' $ctx ne 'tags') {
+ die_error(400, Unknown web feed context);
+ }
+ my $tags = $ctx eq 'tags' ? 1 : 0;
+
# log/feed of current (HEAD) branch, log of given branch, history of
file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150, 0, $file_name);
+ my @commitlist;
+ if ($tags) {
+ @commitlist = git_get_tags_list(15);
+ } else {
+ @commitlist = parse_commits($head, 150, 0, $file_name);
+ }
my %latest_commit;
my %latest_date;
@@ -8026,9 +8041,12 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- my $latest_epoch = $latest_commit{'committer_epoch'};
+ my $latest_epoch = $tags ? $latest_commit{'epoch'} :
+ $latest_commit{'committer_epoch'};
exit_if_unmodified_since($latest_epoch);
- %latest_date = parse_date($latest_epoch,
$latest_commit{'comitter_tz'});
+ %latest_date = parse_date($latest_epoch,
+ $tags ? $latest_commit{'tz'} :
+ $latest_commit{'committer_tz'});
}
print $cgi-header(
-type = $content_type,
@@ -8043,7 +8061,9 @@ sub git_feed {
# header variables
my $title = $site_name - $project/$action;
my $feed_type = 'log';
- if (defined $hash) {
+ if ($tags) {
+ $feed_type = 'tags';
+ } elsif (defined $hash) {
$title .= - '$hash';
$feed_type = 'branch log';
if (defined $file_name) {
@@ -8060,6 +8080,7 @@ sub git_feed {
$descr = esc_html($descr);
} else {
$descr = $project .
+($tags ? 'tags ' : '') .
($format eq 'rss' ? 'RSS' : 'Atom') .
feed;
}
@@ -8068,7 +8089,9 @@ sub git_feed {
#header
my $alt_url;
- if (defined $file_name) {
+ if ($tags) {
+ $alt_url = href(-full=1, action=tags);
+ } elsif (defined $file_name) {
$alt_url = href(-full=1, action=history, hash=$hash,
file_name=$file_name);
} elsif (defined $hash) {
$alt_url = href(-full=1, action=log, hash=$hash);
@@ -8132,9 +8155,15 @@ XML
}
# contents
+ my $co_action = $tags ? 'tag' : 'commitdiff';
for (my $i = 0; $i = $#commitlist; $i++) {
+ my %clco; # commit info from commitlist, only used for tags
my %co = %{$commitlist[$i]};
my $commit = $co{'id'};
+ if ($tags) {
+ %clco = %co;
+ %co = parse_tag($commit);
+ }
# we read 150, we always show 30 and the ones more recent than
48 hours
if (($i = 20) ((time - $co{'author_epoch'}) 48*60*60)) {
last;
@@ -8142,44 +8171,52 @@ XML
my %cd = parse_date($co{'author_epoch'}, $co{'author_tz'});
# get list of changed files
- open my $fd, -|, git_cmd(), diff-tree, '-r', @diff_opts,
- $co{'parent'} || --root,
- $co{'id'}, --, (defined $file_name ? $file_name : ())
- or next;
- my @difftree = map { chomp; $_ } $fd;
- close $fd
- or next;
+ my @difftree;
+ unless ($tags) {
+ open my $fd, -|, git_cmd(), diff-tree, '-r',
@diff_opts,
+ $co{'parent'} || --root,
+ $co{'id'}, --, (defined $file_name ?
$file_name : ())
+
[PATCH 2/2] gitweb: expose tags feed in appropriate places
Signed-off-by: Giuseppe Bilotta giuseppe.bilo...@gmail.com
---
gitweb/gitweb.perl | 47 +--
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6cb51f7..9ac28aa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -804,6 +804,8 @@ our %actions = (
summary = \git_summary,
tag = \git_tag,
tags = \git_tags,
+ tags_rss = \git_tags_rss,
+ tags_atom = \git_tags_atom,
tree = \git_tree,
snapshot = \git_snapshot,
object = \git_object,
@@ -2518,7 +2520,7 @@ sub get_feed_info {
return unless (defined $project);
# some views should link to OPML, or to generic project feed,
# or don't have specific feed yet (so they should use generic)
- return if (!$action || $action =~ /^(?:tags|heads|forks|tag|search)$/x);
+ return if (!$action || $action =~ /^(?:heads|forks|search)$/x);
my $branch;
# branches refs uses 'refs/heads/' prefix (fullname) to differentiate
@@ -2528,8 +2530,10 @@ sub get_feed_info {
$branch = $1;
}
# find log type for feed description (title)
- my $type = 'log';
- if (defined $file_name) {
+ my $type = log;
+ if ($action eq 'tag' || $action eq 'tags') {
+ $type = tags;
+ } elsif (defined $file_name) {
$type = history of $file_name;
$type .= / if ($action eq 'tree');
$type .= on '$branch' if (defined $branch);
@@ -3907,6 +3911,7 @@ sub print_feed_meta {
$href_params{'-title'} = 'log';
}
+ my $tag_view = $href_params{-title} eq 'tags';
foreach my $format (qw(RSS Atom)) {
my $type = lc($format);
my %link_attr = (
@@ -3916,7 +3921,7 @@ sub print_feed_meta {
);
$href_params{'extra_options'} = undef;
- $href_params{'action'} = $type;
+ $href_params{'action'} = ($tag_view ? 'tags_' : '') .
$type;
$link_attr{'-href'} = href(%href_params);
print link .
rel=\$link_attr{'-rel'}\ .
@@ -3925,15 +3930,17 @@ sub print_feed_meta {
type=\$link_attr{'-type'}\ .
/\n;
- $href_params{'extra_options'} = '--no-merges';
- $link_attr{'-href'} = href(%href_params);
- $link_attr{'-title'} .= ' (no merges)';
- print link .
- rel=\$link_attr{'-rel'}\ .
- title=\$link_attr{'-title'}\ .
- href=\$link_attr{'-href'}\ .
- type=\$link_attr{'-type'}\ .
- /\n;
+ unless ($tag_view) {
+ $href_params{'extra_options'} = '--no-merges';
+ $link_attr{'-href'} = href(%href_params);
+ $link_attr{'-title'} .= ' (no merges)';
+ print link .
+ rel=\$link_attr{'-rel'}\ .
+ title=\$link_attr{'-title'}\ .
+ href=\$link_attr{'-href'}\ .
+ type=\$link_attr{'-type'}\ .
+ /\n;
+ }
}
} else {
@@ -4115,8 +4122,9 @@ sub git_footer_html {
}
$href_params{'-title'} ||= 'log';
+ my $tag_view = $href_params{-title} eq 'tags';
foreach my $format (qw(RSS Atom)) {
- $href_params{'action'} = lc($format);
+ $href_params{'action'} = ($tag_view ? 'tags_' : '') .
lc($format);
print $cgi-a({-href = href(%href_params),
-title = $href_params{'-title'} $format
feed,
-class = $feed_class}, $format).\n;
@@ -8280,10 +8288,18 @@ sub git_rss {
git_feed('rss');
}
+sub git_tags_rss {
+ git_feed('rss', 'tags')
+}
+
sub git_atom {
git_feed('atom');
}
+sub git_tags_atom {
+ git_feed('atom', 'tags')
+}
+
sub git_opml {
my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
@@ -8328,6 +8344,9 @@ XML
my $rss = href('project' = $proj{'path'}, 'action' = 'rss',
-full = 1);
my $html = href('project' = $proj{'path'}, 'action' =
'summary', -full = 1);
print outline type=\rss\ text=\$path\ title=\$path\
xmlUrl=\$rss\ htmlUrl=\$html\/\n;
+ # and now the tags rss feed
+
Re: [PATCH] submodule: configure submodule.name.path on add and init
Am 24.09.2012 22:43, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Am 24.09.2012 21:30, schrieb Orgad Shaneh: In order to read diff options for a submodule, its path must be configured --- git-submodule.sh |2 ++ 1 file changed, 2 insertions(+) diff --git a/git-submodule.sh b/git-submodule.sh index 3e2045e..f97bb62 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -359,6 +359,7 @@ Use -f if you really want to add it. 2 esac ) || die $(eval_gettext Unable to checkout submodule '\$sm_path') fi + git config submodule.$sm_path.path $sm_path git config submodule.$sm_path.url $realrepo git add $force $sm_path || @@ -476,6 +477,7 @@ cmd_init() url=$(resolve_relative_url $url) || exit ;; esac + git config submodule.$name.path $name || git config submodule.$name.url $url || die $(eval_gettext Failed to register url for submodule path '\$sm_path') Nack. The path must only be configured in .gitmodules or we'll never be able to rename the submodule directory. That sounds sensible on the surface, and the rejection of this is probably the right thing to do, but then how would the name/path mapping work without .gitmodules? Historically, you did not have to have a .gitmodules in-tree at all in order to use submodules locally, but if discovery of submodule.$name.ignore depends on having the in-tree .gitmodules file, that sounds like a minor regression to me. AFAIK the name/path mapping was added to enable moving submodules around in the work tree without having to adapt its $GITDIR/config entries every time you checkout a commit where the submodule's work tree is moved someplace else inside the superproject's work tree. Nowadays we also use that to consistently store the submodule's .git directory under modules/name inside the superproject's .git directory no matter what its current path is. You still don't need a .gitmodules file to use submodules locally, but then moving around these submodules is not - and has never been - that easy. To use the ignore setting without a .gitmodules file you'll just have to set both submodule.$name.ignore and submodule.$name.path (to provide the mapping, in most cases path and name will simply be the same) in your $GITDIR/config and everything will work just fine. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] add basic lua infrastructure
Jeff King p...@peff.net writes: On Tue, Sep 25, 2012 at 03:21:10AM +, Robin H. Johnson wrote: On Mon, Sep 24, 2012 at 08:25:12PM -0400, Jeff King wrote: +ifdef USE_LUA + BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2` + EXTLIBS += `pkg-config --libs lua5.2` +endif Can you please hoist the packagename out to a variable? It's just plain lua on Gentoo. Yeah. I mentioned these patches were very rough, but I didn't go into detail on all the bad points. That is definitely one of them. I have no idea what the normal name is; my debian system sticks the version number in to allow multiple concurrent versions. Yeah, there is no point nitpicking yet. Even the choice of lua is not all that interesting; embedding _any_ reasonable interpreter, and figuring out which operations and codepaths in us benefit most from such embedding, are of bigger interest at this early stage. How about doing this on top at the minimum? You can let pkg-config to tell you where -Idirectory and what -llib is, or you can set it yourself. $ make USE_LUA=YesPlease \ LUA_INCLUDE_ARG=-I/usr/include/lua5.2 \ LUA_LINK_ARG=-llua5.2 or $ make USE_LUA=lua5.2 Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git i/Makefile w/Makefile index 620df89..90335ba 100644 --- i/Makefile +++ w/Makefile @@ -1898,8 +1898,14 @@ ifdef USE_NED_ALLOCATOR endif ifdef USE_LUA - BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2` - EXTLIBS += `pkg-config --libs lua5.2` + # You can say + # $ make USE_LUA=YesPlease LUA_INCLUDE_ARG=-I/usr/include + # or + # $ make USE_LUA=lua5.2 + LUA_INCLUDE_ARG ?= $(shell pkg-config --cflags $(USE_LUA)) + LUA_LINK_ARG ?= $(shell pkg-config --libs $(USE_LUA)) + BASIC_CFLAGS += -DUSE_LUA $(LUA_INCLUDE_ARG) + EXTLIBS += $(LUA_LINK_ARG) endif ifdef GIT_TEST_CMP_USE_COPIED_CONTEXT -- 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: A generalization of git blame
From: xm...@cs.wisc.edu I have been developing my git tool (based on the git internal API) that can find out all the commits that have changed a line for better authorship. The reason is for my binary code authorship research, I use machine learning to classify code authorship. To produce training data, I start with a source code repository with well-known author labels for each line and then compiling the project into binary. So, I am able to know the authorship for binary code and then apply some machine learning techniques. To get ground truth of authorship for each line, I start with git-blame. But later I find this is not sufficient because the last commit may only add comments or may only change a small part of the line, so that I shouldn't attribute the line of code to the last author. I would suggest there is: - White space adjustment - Comment or documentation (assumes you can parse the 'code' to decide that it isn't executable code) - word changes within expressions - complete replacement of line (whole statement?) Custom practice is the likely decider. Of course, there must be some debates on who can be the representative of a line of code. So what I would like to do is find out all the commits that have ever changed a line, then I can try different approaches to summarize over all these commits to produce my final authorship label (or even tuple). I was wondering whether there have been similar debates over accurate authorship in this community before and whether there may be other people interested in this work. I'd suggest looking at the various 'diff' formats, such as character diff, word diff, and line diff for discussions. Thanks --Xiaozhu Philip -- 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] Revert completion: fix shell expansion of items
On Tue, Sep 25, 2012 at 12:31:19AM -0400, Jeff King wrote:
Yeah, doing git checkout jk/tab is not working at all, and I noticed
the buggy commit is on the maint track, but has not yet been released.
I'm not sure of the solution, but I think we should do this in the
meantime:
-- 8 --
Subject: Revert completion: fix shell expansion of items
I agree with the revert, too.
I looked into this issue, but quickly got lost in quoting-escaping
hell. Ideally we could do some quoting in __gitcomp_nl(), so it would
work for all kinds of input, but I couldn't come up with anything
working. Alternatively, we could modify __gitcomp_nl()'s callers, or
rather the helper functions supplying input to __gitcomp_nl() to do
the quoting or escaping themselves. Actually, that's quite easy for
local refs, at least, because for-each-ref's builtin quoting support
does the trick:
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c48cd19f..3dc1ec8c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -313,7 +313,7 @@ __git_refs ()
refs=refs/tags refs/heads refs/remotes
;;
esac
- git --git-dir=$dir for-each-ref --format=%($format) \
+ git --git-dir=$dir for-each-ref --shell --format=%($format)
\
$refs
if [ -n $track ]; then
# employ the heuristic used by git checkout
With this change completion of local refs works well, even in the
presence of branches ${foo.bar} and foo'bar.
Unfortunately, there are many callsites for __gitcomp_nl(), and it is
invoked with refs from remote repos, heads, tags, refspecs, remotes,
config variables, symbols from ctags, or output from stash or
ls-tree... although some of these are OK as they are now (remotes,
config variables).
Best,
Gábor
--
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: Problem completing remotes when .git/remotes exits
Hi,
On Wed, Sep 19, 2012 at 09:55:28PM +0200, Johannes Sixt wrote:
I have an empty .git/remotes directory. Trying to complete the name of
a remote always reports an error:
git@master:1023 git fetch TABls: invalid option -- ' '
Try `ls --help' for more information.
I have these:
alias ls='ls $LS_OPTIONS'
and
LS_OPTIONS='-N --color=tty -T 0'
I instrumented __git_remotes with set -x, which shows:
git@master:1006 git fetch TAB+++ __gitdir
+++ '[' -z '' ']'
+++ '[' -n '' ']'
+++ '[' -n '' ']'
+++ '[' -d .git ']'
+++ echo .git
++ local i 'IFS=
' d=.git
++ test -d .git/remotes
++ ls '-N --color=tty -T 0' -1 .git/remotes
ls: invalid option -- ' '
Try `ls --help' for more information.
...
Notice that the expansion of $LS_OPTIONS is not split at the blanks,
obviously, because $IFS does not contain a blank at that moment.
The patch below helps, but it looks like a work-around rather than a
solution. Ideas?
I've got two alternative solutions for this issue.
The first one is less intrusive: use the 'command' builtin to tell
the shell to ignore shell functions and aliases and just run the ls
command.
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e09..bcde9472 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -370,7 +370,7 @@ __git_refs_remotes ()
__git_remotes ()
{
local i IFS=$'\n' d=$(__gitdir)
- test -d $d/remotes ls -1 $d/remotes
+ test -d $d/remotes command ls -1 $d/remotes
for i in $(git --git-dir=$d config --get-regexp 'remote\..*\.url'
2/dev/null); do
i=${i#remote.}
echo ${i/.url*/}
But then it got me thinking... Notice how much effort we spend just
to get the list of remotes? We could just run 'git remote' directly
instead...
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e09..1daeaccf 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -369,12 +369,8 @@ __git_refs_remotes ()
__git_remotes ()
{
- local i IFS=$'\n' d=$(__gitdir)
- test -d $d/remotes ls -1 $d/remotes
- for i in $(git --git-dir=$d config --get-regexp 'remote\..*\.url'
2/dev/null); do
- i=${i#remote.}
- echo ${i/.url*/}
- done
+ local d=$(__gitdir)
+ git --git-dir=$d remote
}
__git_list_merge_strategies ()
I prefer the second one ;)
Best,
Gábor
--
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: A generalization of git blame
Philip Oakley philipoak...@iee.org writes:
To get ground truth of authorship for each line, I start with
git-blame.
But later I find this is not sufficient because the last commit may
only
add comments or may only change a small part of the line, so that I
shouldn't attribute the line of code to the last author.
I would suggest there is:
- White space adjustment
- Comment or documentation (assumes you can parse the 'code' to decide
that it isn't executable code)
- word changes within expressions
- complete replacement of line (whole statement?)
You are being generous by listing easier cases ;-) I'd add a couple
more that are more problematic if your approach does not consider
semantics.
- A function gained a new parameter, to which pretty much everbody
passes the same default value.
-void fn(int a, int b, int c)
+void fn(int a, int b, int c, int d)
{
+ if (d) {
+ ...
+ return;
+ }
...
}
void frotz(void)
{
...
- fn(a, b, c);
+ fn(a, b, c, 0);
...
- fn(a, b, d);
+ fn(a, b, d, 1);
...
The same commit that changed the above call site must have
changed the definition of function fn and defined what the new
fourth parameter means. It is likely that, when the default
value most everybody passes (perhaps 0) is given, fn does
what it used to do, and a different value may trigger a new
behaviour of fn. It could be argued that the former call
should not be blamed for this commit, while the latter callsite
should.
- A variable was renamed, and the meaning of a line suddenly
changed, even though the text of that line did not change at all.
static int foo;
...
-int xyzzy(int foo)
+int xyzzy(int bar)
{
... some complex computation that
... involves foo and bar, resulting in
... updating of foo comes here ...
return foo * 2;
}
Whom to blame the behaviour of (i.e. returned value from) the
function? The return foo * 2 never changed with this patch,
but the patch _is_ responsible for changing the behaviour.
As the OP is interested in tracking the origin of the _binary_,
this case is even more interesting, as the generated machine code
to compute the foo * 2 would likely to be very different before
and after the patch.
--
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: /* in .gitignore
Hilco Wijbenga hilco.wijbe...@gmail.com writes: Naturally, this behaviour makes perfect sense: /* means everything. Still, I was wondering whether it might be a good idea to make an exception for '.gitignore' itself? Then if somebody *really* wanted to ignore '.gitignore' they could add /.gitignore to '.gitignore'? If somebody is sick enough to ignore everything, he can add /* to the .gitignore file and in order to make sure he knows what he is doing and he is doing what he thinks is doing, he would check with git diff --stat HEAD etc. before committing, and double check with git show --stat etc. after committing. .gitignore (or .gitattributes for that matter) shouldn't be any different from your ordinary tracked contents. If you have *.o in the ignored pattern list, you would need an extra care to defeat the pattern to add vendor-supplied binary-only object file with add -f and live with the fact that a new vendor-supplied binary-only object file not appearing on untracked list. It is exactly the same deal. Having said that, I guess you could add !.git* to your $GIT_DIR/info/exclude and see if it gives an improved user experience. -- 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 14/14] Add git-check-ignore sub-command
Johannes Sixt j.s...@viscovery.net writes: Am 9/20/2012 21:46, schrieb Adam Spiers: test_expect_success 'general options plus command' ' -test_completion git --version check checkout -test_completion git --paginate check checkout -test_completion git --git-dir=foo check checkout -test_completion git --bare check checkout +test_completion git --version checko checkout +test_completion git --paginate checko checkout +test_completion git --git-dir=foo checko checkout +test_completion git --bare checko checkout ... I find this worrysome. Is check-ignore, being a debugging aid, so important that it must be autocompleted? The shell function __git_list_porcelain_commands in contrib/completion/ starts from git help -a and filters plumbing commands and helpers via a blacklist. At least, check-ignore needs to be added there. These days, we do not add random subcommands willy-nilly (I still doubt if check-ignore needs to be a separate debugging command, or a new mode of operation of ls-files or something), so the approach to use a blacklist makes more sense. help -a is designed to show whatever the users throw in their ~/bin (assuming that is on $PATH) under git-whatever name, and we _do_ want to complete git whTAB to that custom command, so a whitelist-based solution is unwieldy to construct. -- 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] Revert completion: fix shell expansion of items
SZEDER Gábor sze...@ira.uka.de writes:
On Tue, Sep 25, 2012 at 12:31:19AM -0400, Jeff King wrote:
Yeah, doing git checkout jk/tab is not working at all, and I noticed
the buggy commit is on the maint track, but has not yet been released.
I'm not sure of the solution, but I think we should do this in the
meantime:
-- 8 --
Subject: Revert completion: fix shell expansion of items
I agree with the revert, too.
I looked into this issue, but quickly got lost in quoting-escaping
hell. Ideally we could do some quoting in __gitcomp_nl(), so it would
work for all kinds of input, but I couldn't come up with anything
working. Alternatively, we could modify __gitcomp_nl()'s callers, or
rather the helper functions supplying input to __gitcomp_nl() to do
the quoting or escaping themselves. Actually, that's quite easy for
local refs, at least, because for-each-ref's builtin quoting support
does the trick:
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c48cd19f..3dc1ec8c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -313,7 +313,7 @@ __git_refs ()
refs=refs/tags refs/heads refs/remotes
;;
esac
- git --git-dir=$dir for-each-ref --format=%($format) \
+ git --git-dir=$dir for-each-ref --shell --format=%($format)
\
$refs
if [ -n $track ]; then
# employ the heuristic used by git checkout
With this change completion of local refs works well, even in the
presence of branches ${foo.bar} and foo'bar.
Unfortunately, there are many callsites for __gitcomp_nl(), and it is
invoked with refs from remote repos, heads, tags, refspecs, remotes,
config variables, symbols from ctags, or output from stash or
ls-tree... although some of these are OK as they are now (remotes,
config variables).
Whatever you do, please make the first step of that endeavour an
addition to the t/t9902 to prevent the same breakage from happening
again.
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: Problem completing remotes when .git/remotes exits
SZEDER Gábor sze...@ira.uka.de writes: - test -d $d/remotes ls -1 $d/remotes + test -d $d/remotes command ls -1 $d/remotes Yuck. For normal scripts, nobody sane would define alias for non-interactive environments, but because these things work in an interactive environment, we have to protect ourselves from user aliases. Not just ls, but test we see above may misbehave X-. -- 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: /* in .gitignore
On 25 September 2012 16:13, Junio C Hamano gits...@pobox.com wrote: Hilco Wijbenga hilco.wijbe...@gmail.com writes: Naturally, this behaviour makes perfect sense: /* means everything. Still, I was wondering whether it might be a good idea to make an exception for '.gitignore' itself? Then if somebody *really* wanted to ignore '.gitignore' they could add /.gitignore to '.gitignore'? If somebody is sick enough to ignore everything, he can add /* to the .gitignore file and in order to make sure he knows what he is doing and he is doing what he thinks is doing, he would check with git diff --stat HEAD etc. before committing, and double check with git show --stat etc. after committing. Ignoring everything is not quite so sick. :-) My use case is Eclipse's .metadata directory. This directory is *huge* but only .metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs is really of interest (and not even all of those files). The subset of *.prefs that we are interested in will allow us to share Eclipse configuration settings (things like formatting settings and which warnings we care about). So I have several '.gitignore' files with /* + !/some-dir/. [To make things even more interesting, the .settings directory should be ignored in all other places (so it's in our top level '.gitignore').] I would be very happy to find out better ways to handle this particular scenario. I had quite a struggle getting it to work. .gitignore (or .gitattributes for that matter) shouldn't be any different from your ordinary tracked contents. If you have *.o in the ignored pattern list, you would need an extra care to defeat the pattern to add vendor-supplied binary-only object file with add -f and live with the fact that a new vendor-supplied binary-only object file not appearing on untracked list. It is exactly the same deal. I do not entirely agree. I think '.gitignore' *is* different. This file is special and affects Git's behaviour. And it does so *before* it has been committed. Or even added. The fact that '.gitignore' itself is not listed in the output of, e.g., git status is easy to miss. I have not really used '.gitattributes' but I assume the same applies. Having said that, I guess you could add !.git* to your $GIT_DIR/info/exclude and see if it gives an improved user experience. Mmm, that does not seem to help. I did git init touch file.txt echo '/*'.gitignore echo '!.gitignore' .git/info/exclude git status it lists nothing (Git 1.7.12). I had expected to see '.gitignore'. Did I misunderstand you? Even so, this would only improve *my* user experience, wouldn't it? This would not get pushed to the central repository so it would not help anyone else. -- 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] Teach git-completion about git p4
etao...@gmail.com wrote on Fri, 21 Sep 2012 14:51 -0700:
git p4 was moved out of contrib in 1.7.11 but it git-completion didn't
know about it. Add git p4 completion based on the existing SVN
completion. It covers all known subcommands and options except for the
-/ option for clone which doesn't use the standard -- prefix.
Very nice, thank you. A couple nits.
+_git_p4 ()
+{
+ local subcommands=
+ clone sync rebase submit
+
+ local subcommand=$(__git_find_on_cmdline $subcommands)
+ if [ -z $subcommand ]; then
+ __gitcomp $subcommands
+ else
+ local common_opts=--git-dir= --verbose
+ local sync_opts=
+ --branch= --detect-branches --changes-file=
It's --changesfile (no dash), weird, but true.
+ --silent --detect-labels --import-labels
+ --import-local --max-changes= --keep-path
+ --use-client-spec $common_opts
+
+ local clone_opts=
+ --destination= --bare $sync_opts
+
+ local submit_opts=
+ --origin= -M --preserve-user --export-labels
+ $common_opts
+
Very recently we added --dry-run and --prepare-p4-only and
--conflict to submit. Follow 8db3865^2 to see the patches
for those.
+ case $subcommand,$cur in
+ clone,--*)
+ __gitcomp $clone_opts
+ ;;
+ sync,--*)
+ __gitcomp $sync_opts
+ ;;
+ rebase,--*)
+ __gitcomp $common_opts --import-labels
This would be prettier if it had its own local rebase_opts.
+ submit,--*)
+ __gitcomp $submit_opts
+ ;;
+ submit,*)
+ __gitcomp $(__git_refs)
+ ;;
+ esac
+ fi
+}
+
_git_pull ()
{
__git_complete_strategy return
--
1.7.12.1
--
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
--
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: Problem completing remotes when .git/remotes exits
On Wed, Sep 26, 2012 at 01:00:45AM +0200, SZEDER Gábor wrote: But then it got me thinking... Notice how much effort we spend just to get the list of remotes? We could just run 'git remote' directly instead... Actually, we can't, because 'git remote' doesn't seem to list remotes stored under .git/remotes. Is that intentional? Anyway, we could still use 'git remote' to replace at least the config query and the for loop to spare a few lines of code and a subshell. -- 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: Problem completing remotes when .git/remotes exits
On Wed, Sep 26, 2012 at 03:09:38AM +0200, SZEDER Gábor wrote: On Wed, Sep 26, 2012 at 01:00:45AM +0200, SZEDER Gábor wrote: But then it got me thinking... Notice how much effort we spend just to get the list of remotes? We could just run 'git remote' directly instead... Actually, we can't, because 'git remote' doesn't seem to list remotes stored under .git/remotes. Is that intentional? Looks like a bug, as it seems to have been lost in translation in 211c8968 (Make git-remote a builtin, 2008-02-29). list_remote() in git-remote.perl looks for remotes in config and in .git/remotes/, too. The builtin implementation uses remote.c:for_each_remote() from the start, which only looks at the config. -- 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
DWIM .git repository discovery
Hi, I often find myself attempting to examine another repository, especially in projects that are closely related but put in different git repos. It's usually just a diff or log command git log --patch ../path/to/another/repo/path/to/file.c cd'ing out is nuisance for one-shot commands, even setting --git-dir is because i'd need to repeat the path. I think when we detect paths outside repository, we could try to discover new repository that contain those paths, the adjust $GIT_DIR internally to the new repository. We can't do that now because .git repository and path outside repository check occur in two separate stages, the latter after .git is discovered and .git can't be moved once discovered. We might be able to move path outside repo check up to discovery phase. But that could be big change. Does anybody want such a feature, or it's just my itch? It's probably not worth doing because few people need it. -- 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] t/test-lib.sh: do not trust $SHELL
Hi Junio, Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: Here's a patch. -- 8 -- From: Ramkumar Ramachandra artag...@gmail.com Date: Sat, 22 Sep 2012 10:25:10 +0530 Subject: [PATCH] test-lib: do not trust $SHELL Do not trust $SHELL to be a bourne-compatible shell. Instead, use the Makefile variable $SHELL_PATH. This fixes a bug: when a test was run with --tee and $SHELL was set to ZSH, $PATH on line 479 was not getting split due to ZSH not respecting $IFS. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- The part that this starts letting run, which the original Re-run the command under tee as early as possible wanted to avoid running, does not affect anything that would affect how we run that tee magic (e.g. mkdir -p test-results will still create it directly inside the directory the test script was started in), so I think this patch is safe _for now_. However, it forces people who need to update earlier parts of this script to be extra careful; it has been true before the patch, and the patch makes it even more so. I am not opposed to queuing this as an interim solution, but I wonder if we can get rid of that double-launch altogether. I see you've queued it in `pu` after rewriting the commit message. Instead of re-launching the script with its output piped to tee, can't we do the same by redirecting our standard output to the file in the file, and spawn a tail -f that reads from the file and outputs to our original output? Something along the lines of: mkdir -p test-results tee_base=test-results/$(basename $0 .sh) # empty the file and start tail -f on it ... : $tee_base.out ( tail -f $tee_base.out ) tee_pid=$! trap 'kill $tee_pid; exit' 0 1 2 3 # ... and then redirect our output to it exec $tee_base.out and wrap it in a shell helper function that is called from where the parsing of the command line arguments for --tee happens, and don't forget to kill $tee_pid when we exit. Hrm? Good idea. I'll write a patch to do this once the interim solution graduates to `master`. 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
Bug in Submodule add
I believe I have found an issue with the way `submodule add` detects a submodule that already exists in the repository. To reproduce 1) add a git submodule in a specific location (we'll say it's at `./submodule/location`) 2) go through the normal steps of removing a submodule, as listed here - https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial 3) Now the submodule is completely removed and there is no reference to it in .gitmodules or .git/config 4) Re-add a different repository at the same location (`./submodule/location`) Expected - The new submodule repository will be set up at ./submodule/location and have the new repository as its origin What Actually Happens - The new submodule uses the existing `$gitdir` (old repository) as the actual backing repository to the submodule, but the new repository is reflected in .gitmodules and .git/config. So to recap, the result is that `git remote show origin` in the submodule shows a different origin than is in .gitmodules and .git/config One simple step to remedy this would be to add the deletion of the backing repository from the .git/modules directory, but again, I think an actual command to take care of all of these steps is in order anyways. Not sure you want to encourage people poking around in the .git directory. If this is already resolved in the newest versions, please disregard Thanks! Jonathan Johnson http://jondavidjohn.com | m...@jondavidjohn.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
Re: DWIM .git repository discovery
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: I often find myself attempting to examine another repository, especially in projects that are closely related but put in different git repos. It's usually just a diff or log command git log --patch ../path/to/another/repo/path/to/file.c I personally do not think it is _too_ bad to internally do (cd ../path/to/another/repo/path/to git log --patch file.c) but I doubt it is worth the numerous implications (I am not talking about implementation complexity at all, but the conceptual burden). For example, where in the working tree of the other project should the command run? The output from log -p happens to be always relative to the top of the working tree, but that does not necessarily hold true for other subcommands. A worse thing is that there is an oddball case diff[ --no-index] that changes behaviour depending on the pathspec points at inside or outside the repository. I think that this is a road to insanity; anybody who thinks along this line is already on the other side of the line, I would have to say ;-). -- 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 14/14] Add git-check-ignore sub-command
Am 9/26/2012 1:25, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: Am 9/20/2012 21:46, schrieb Adam Spiers: test_expect_success 'general options plus command' ' - test_completion git --version check checkout - test_completion git --paginate check checkout - test_completion git --git-dir=foo check checkout - test_completion git --bare check checkout + test_completion git --version checko checkout + test_completion git --paginate checko checkout + test_completion git --git-dir=foo checko checkout + test_completion git --bare checko checkout ... I find this worrysome. Is check-ignore, being a debugging aid, so important that it must be autocompleted? The shell function __git_list_porcelain_commands in contrib/completion/ starts from git help -a and filters plumbing commands and helpers via a blacklist. At least, check-ignore needs to be added there. These days, we do not add random subcommands willy-nilly (I still doubt if check-ignore needs to be a separate debugging command, or a new mode of operation of ls-files or something), so the approach to use a blacklist makes more sense. help -a is designed to show whatever the users throw in their ~/bin (assuming that is on $PATH) under git-whatever name, and we _do_ want to complete git whTAB to that custom command, so a whitelist-based solution is unwieldy to construct. We already have 'git check-attr', but it is obviously not among the autocompleted commands, otherwise the above test would not have passed. IMO, 'git check-ignore' falls into the same category as 'git check-attr' with regard to completion. -- Hannes -- 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
