* [PATCH] t4014: remove Message-Id/timestamp before comparing patches
From: Thomas Rast @ 2011-09-19 6:45 UTC (permalink / raw)
To: Pang Yan Han; +Cc: Jeff King, Junio C Hamano, git
The test introduced in 787570c (format-patch: ignore ui.color,
2011-09-13) has a race condition: if the two format-patch invocations
do not ask for the current time in the same second, their Message-Id
headers will disagree.
Normally this would be a pretty unlikely occurrence. However, under
valgrind format-patch runs so slowly that the race triggers every
time, with a time difference of 2-3s on my hardware.
To avoid this problem, replace the contents of the Message-Id header
with a dummy before comparing.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t4014-format-patch.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 7e405d7..8700089 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -886,11 +886,18 @@ test_expect_success 'empty subject prefix does not have extra space' '
test_cmp expect actual
'
+strip_msgid () {
+ sed 's#\(Message-Id: *\)<[^>]*>#\1<MESSAGE@ID>#' "$1" >"$1+" &&
+ mv "$1+" "$1"
+}
+
test_expect_success 'format patch ignores color.ui' '
test_unconfig color.ui &&
git format-patch --stdout -1 >expect &&
+ strip_msgid expect &&
test_config color.ui always &&
git format-patch --stdout -1 >actual &&
+ strip_msgid actual &&
test_cmp expect actual
'
--
1.7.7.rc1.366.ge210a6
^ permalink raw reply related
* Re: Problem with submodule merge
From: Nicolas Morey-Chaisemartin @ 2011-09-19 7:55 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20110916145724.GA2782@book.hvoigt.net>
Hi,
You're right, this fixes the issue:
$ git merge origin/prerelease/0.3-0
warning: Failed to merge submodule db (merge following commits not found)
Auto-merging db
CONFLICT (submodule): Merge conflict in db
Automatic merge failed; fix conflicts and then commit the result.
Thanks for the help
Nicolas
On 09/16/2011 04:57 PM, Heiko Voigt wrote:
> Hi,
>
> this looks like you have hit a codepath where the submodules object
> database is not added to the object database. I am not sure why.
>
> Could you try my patch that moves the merge search into a forked process:
>
> 3dcb369b allow multiple calls to submodule merge search for the same path
>
> That should solve the issue as a side effect. Its currently in Junio's
> pu branch.
>
> Cheers Heiko
>
> On Fri, Sep 16, 2011 at 02:48:02PM +0200, Nicolas Morey-Chaisemartin wrote:
>> Hi,
>>
>> We have meet an issue few times at work with submodule merge.
>> I'm running git 1.7.7-rc1 build from master on FC15 x86_64 but I've seen the issue on other ditro with older (stable) versions
>>
>> I still haven't figured out exactly when it happends but here are the symptoms:
>>
>> 1) I commited some updates for a submodule in our integration repo.
>> 2) I pulled a remote branch of the integration repo which had an update on the same submodule (but different SHAs)
>> 3) When the merge driver try to find a following commit for the submodule, I get some (sometimes many) error messages about refs that point to invalid objects:
>>
>> [nmorey@sat:SigmaCToolchain (user/nmorey/dev/0.3.0 *%>)]$ git merge origin/prerelease/0.3-0
>> error: refs/heads/user/nmorey/master does not point to a valid object!
>> error: refs/remotes/origin/dev/cpp does not point to a valid object!
>> error: refs/remotes/origin/dev/scuk does not point to a valid object!
>> error: refs/remotes/origin/dev/sys_agents does not point to a valid object!
>> error: refs/remotes/origin/user/bbodin/cea does not point to a valid object!
>> error: refs/remotes/origin/user/borgogoz/master does not point to a valid object!
>> warning: Failed to merge submodule db (merge following commits not found)
>> Auto-merging db
>> CONFLICT (submodule): Merge conflict in db
>> Automatic merge failed; fix conflicts and then commit the result.
>>
>>
>> I checked and the object really exists in the submodule but is in a pack.
>>
>> >From checking the strace, git looks for a the object in db/.git/objects/... whch does not exists
>> And from what I could figure it, the issue seems to be coming from find_pack_entry which does not return 1 so git goes looking for loose object
>> and cannot find any (as expected).
>> This is not a big issue as it just outputs errors about refs and does not block the user but it gets quite scary when there are a few hundreds of them !
>>
>>
>> I kept a tarball of the repo so I can provide more info/logs/trace if needed.
>>
>> Nicolas
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Where is information of "git read-tree" stored?
From: Manuel Reimer @ 2011-09-19 8:46 UTC (permalink / raw)
To: git
Hello,
following situation:
- Project hosted on GIT. Have a local copy and push to remote server.
- Small addon is hosted on a remote SVN server
- I now cloned the SVN to a local GIT (svn git clone)
- Then I used the instructions from here:
<http://git-mirror.googlecode.com/git-history/7444c60/howto/using-merge-subtree.html>
to get the local SVN copy merged into a subdirectory on my project GIT. Anything
worked well.
To test the worst case, I cloned my project GIT to a new local repository. The
remote connection to the local SVN copy was lost, so I recreated it.
Now, for some reason, I can immediately call
git pull -s subtree Bproject master
to pull changes from the SVN copy to the subdir... I didn't have to call "git
read-tree" again. Where is this information stored? Why does GIT know where the
remote repository data has to be placed to? Can I view this information? Can I
edit it?
Is there some information available somewhere on which data is pushed to server
and which is only in my local repo?
What will happen if my SVN checkout to local GIT repo gets lost? Can I just
clone this from SVN again, connect this to my project GIT and it will work just
well without problems? Or should I keep a copy of this GIT repo on server just
to be sure nothing bad happens?
Thanks in advance
Yours
Manuel
^ permalink raw reply
* 群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-09-19 9:01 UTC (permalink / raw)
To: ginni, giovanni.delfranco, girishpal, girl.in.the.d,
giroussens.ceramique, gis45, gisc
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万广交会买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: Remove diff tool examples
From: Ramkumar Ramachandra @ 2011-09-19 9:23 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
In-Reply-To: <1316383901-17580-1-git-send-email-srabbelier@gmail.com>
Hi,
Sverre Rabbelier writes:
> This uses the subject Ramkumar suggested. Since the subject no
> longer references Cogito, I've added a reference to the reason
> for this removal as the first line of the description.
Too late: see v1.7.6.3~12.
-- Ram
^ permalink raw reply
* [RFC/PATCHv2] git-web--browse: avoid the use of eval
From: Chris Packham @ 2011-09-19 9:26 UTC (permalink / raw)
To: git; +Cc: Chris Packham, peff, chriscool, jepler
In-Reply-To: <20110918183846.GA31176@sigill.intra.peff.net>
Using eval causes problems when the URL contains an appropriately
escaped ampersand (\&). Dropping eval from the built-in browser
invocation avoids the problem.
Cc: peff@peff.net
Cc: chriscool@tuxfamily.org
Cc: jepler@unpythonic.net
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
Here's an updated patch which drops the uses of eval when invoking a
supported browser. The default case still uses eval but adds some extra
quoting which also fixes the problem. I've avoided touching the 'start'
case because I don't have access to a windows system to test with.
I've replaced my tests With the test suggested by Peff (should I be
giving him credit in the copyright line or something?). I've grabbed
t9901 but if there is a better set of miscellaneous minor tests that I
should be using let me know.
git-web--browse.sh | 10 +++++-----
t/t9901-git-web--browse.sh | 21 +++++++++++++++++++++
2 files changed, 26 insertions(+), 5 deletions(-)
create mode 100755 t/t9901-git-web--browse.sh
diff --git a/git-web--browse.sh b/git-web--browse.sh
index e9de241..ee05f10 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -156,7 +156,7 @@ firefox|iceweasel|seamonkey|iceape)
;;
google-chrome|chrome|chromium|chromium-browser)
# No need to specify newTab. It's default in chromium
- eval "$browser_path" "$@" &
+ "$browser_path" "$@" &
;;
konqueror)
case "$(basename "$browser_path")" in
@@ -164,10 +164,10 @@ konqueror)
# It's simpler to use kfmclient to open a new tab in konqueror.
browser_path="$(echo "$browser_path" | sed -e 's/konqueror$/kfmclient/')"
type "$browser_path" > /dev/null 2>&1 || die "No '$browser_path' found."
- eval "$browser_path" newTab "$@"
+ "$browser_path" newTab "$@" &
;;
kfmclient)
- eval "$browser_path" newTab "$@"
+ "$browser_path" newTab "$@" &
;;
*)
"$browser_path" "$@" &
@@ -175,7 +175,7 @@ konqueror)
esac
;;
w3m|elinks|links|lynx|open)
- eval "$browser_path" "$@"
+ "$browser_path" "$@"
;;
start)
exec "$browser_path" '"web-browse"' "$@"
@@ -185,7 +185,7 @@ opera|dillo)
;;
*)
if test -n "$browser_cmd"; then
- ( eval $browser_cmd "$@" )
+ ( eval $browser_cmd \""$@"\" )
fi
;;
esac
diff --git a/t/t9901-git-web--browse.sh b/t/t9901-git-web--browse.sh
new file mode 100755
index 0000000..141ed17
--- /dev/null
+++ b/t/t9901-git-web--browse.sh
@@ -0,0 +1,21 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 Chris Packham
+#
+
+test_description='git web--browse basic tests
+
+This test checks that git web--browse can handle various valid URLs.'
+
+. ./test-lib.sh
+
+test_expect_success \
+ 'accepts a URL with an ampersand in it' '
+ echo http://example.com/foo\&bar/ >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo\&bar/ >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.7.7.rc1.4.g47f23.dirty
^ permalink raw reply related
* Re: [PATCH] Prevent users from adding the file that has all-zero SHA-1
From: Nguyen Thai Ngoc Duy @ 2011-09-19 9:26 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: git
In-Reply-To: <CAHYJk3TRHu0whbdPQXzs2ELpoiEqZPxeWmz_V4HQzj5XfAJDBA@mail.gmail.com>
2011/9/19 Mikael Magnusson <mikachu@gmail.com>:
> Bad things will happen if you get an object with the same hash as any
> already existing one, and AFAIK, there are no checks for this.
Right. Forgot this, thanks.
--
Duy
^ permalink raw reply
* how to remove unreachable objects?
From: dieter @ 2011-09-19 9:08 UTC (permalink / raw)
To: git
hi,
i am relatively new to git, and am currently trying to get used to it.
at the moment i am exploring how to remove unneeded objects, this
should be possible with prune, gc and/or fsck.
maybe i have not found the right combination or something in my
understand is not correct.
this is my use case:
i create a repository and produce several commits on master.
then i go back to a certain tag and create a new branch, where i also
commit.
then i switch back to master and delete (-D) the other branch.
it should now be unreachable from within git (to prove its existence,
i remember a commit SHA1 on the dead branch).
then i try to get rid of the unreachable objects with a series of
prune, fsck and gc.
-------------
schoen.d@ax:~/projects/gitFeatures$ cat mk_dead_end.sh
#!/bin/sh
DEAD=dead_end
rm -rf $DEAD
mkdir $DEAD
cd $DEAD
git init
echo "first commit" > A
git add A
git commit -m "first commit"
git tag first_commit
echo "second commit" >> A
git add A
git commit -m "second commit"
git checkout first_commit
echo "commit in dead end" >> A
git add A
git commit -m "changed A in dead end"
git checkout -b $DEAD
dead_commit=`git log -1 --format="%H"`
git checkout master
git branch -D $DEAD
git show $dead_commit
git fsck --unreachable --full --verbose
git fsck --unreachable HEAD \
$(git for-each-ref --format="%(objectname)" refs/heads)
git fsck --lost-found
git prune -v $dead_commit
git prune $(git rev-parse --all)
git repack
git prune-packed
git gc --prune=now
git gc --aggressive
git show $dead_commit
------
if you look at the output of this script then you see that git knows
that there
are unreachable/dangling objects, but they remain.
thankful for any pointer,
dieter
^ permalink raw reply
* [PATCH] abspath: increase array size of cwd variable to PATH_MAX
From: Wang Hui @ 2011-09-19 9:51 UTC (permalink / raw)
To: gitster, git
From: Hui Wang <Hui.Wang@windriver.com>
If the name length of working dir exceeds 1024 characters, neither git
clone nor git init can succeed under the working dir.
E.G. %>for ((i=1;i<300;i++));do mkdir 1234567890;cd 1234567890;done
%>git clone ~/git
fatal: Could not get current working directory: Numerical result
out of range
This is because both git clone and git init will call
abspath.c:real_path(), in the real_path(), it will call getcwd()
to get and save current working dir, here we passed a 1024 char size
array to the parameter, if the name length of current working dir
exceeds 1024, this function will fail.
The purpose of calling getcwd() is to save current working dir, then
before the real_path() return, restore to the saved dir. We should use
PATH_MAX instead of 1024 for the array size.
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
abspath.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/abspath.c b/abspath.c
index f04ac18..2ce1db9 100644
--- a/abspath.c
+++ b/abspath.c
@@ -24,7 +24,7 @@ int is_directory(const char *path)
const char *real_path(const char *path)
{
static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
- char cwd[1024] = "";
+ char cwd[PATH_MAX] = "";
int buf_index = 1;
int depth = MAXDEPTH;
--
1.6.3.1
^ permalink raw reply related
* upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Mikaël @ 2011-09-19 12:30 UTC (permalink / raw)
To: git
Dear All,
I am working for a company where several hundreds of people are working with
GIT ; in other words, GIT is a central tool for us since our working
processes are based on it.
Today, it is the time for us to upgrade from version 1.7.0.4 to 1.7.6.1 (the
latest stable).
It is important for us to work with the latest version since it corrects
defects that are very impacting for us.
The difficulty of this migration is that we can't afford migrations problems
(in order to maintain productivity and work).
That is the reason why I have a couple of questions:
1- Is it possible to have two GIT installations pointing on the same
repositories?
One of this installation would be GIT 1.7.6.1 used by a restricted number of
people (these people could be called 'beta-testers' of the new GIT version).
The other installation would be GIT 1.7.0.4 used by the other users (the
majority of users) with no impact on their productivity.
Once the beta-tests will be finished and successful, all the users will move
to GIT 1.7.6.1.
2- Do you have any suggestions, trips, hints and best practices in order to
upgrade GIT in such a context?
Thanks a lot for your answers.
Best Regards,
Mikaël Donini.
--
View this message in context: http://git.661346.n2.nabble.com/upgrading-GIT-from-version-1-7-0-4-to-1-7-6-1-tp6808156p6808156.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Sverre Rabbelier @ 2011-09-19 12:43 UTC (permalink / raw)
To: Mikaël; +Cc: git
In-Reply-To: <1316435430491-6808156.post@n2.nabble.com>
Heya,
On Mon, Sep 19, 2011 at 14:30, Mikaël <mikael.donini@gmail.com> wrote:
> 1- Is it possible to have two GIT installations pointing on the same
> repositories?
Yes, knowing how deeply Junio cares about backwards compatability,
there will have been no backwards-incompatible changes to the
repository format (none at all actually, IIRC) since 1.7.0 was
released.
> 2- Do you have any suggestions, trips, hints and best practices in order to
> upgrade GIT in such a context?
You should read the following documents that are in git.git:
Documentation/RelNotes/1.7.1.txt
Documentation/RelNotes/1.7.2.txt
Documentation/RelNotes/1.7.3.txt
Documentation/RelNotes/1.7.4.txt
Documentation/RelNotes/1.7.5.txt
Documentation/RelNotes/1.7.6.txt
And make sure that none of the changes mentioned there will affect you
negatively.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Andreas Ericsson @ 2011-09-19 12:49 UTC (permalink / raw)
To: Mikaël; +Cc: git
In-Reply-To: <1316435430491-6808156.post@n2.nabble.com>
On 09/19/2011 02:30 PM, Mikaël wrote:
>
> 1- Is it possible to have two GIT installations pointing on the same
> repositories?
>
The core structure and layout of a git repository hasn't changed
since may 2005, so it should work just fine provided you use any
git version that actually has a version number.
We've upgraded in a hodge-podge fashion at $dayjob. One of our
servers is still running 1.4.something. We've never even come close
to anything resembling a problem. It's actually a bit weird, since
we started using git in late 2005 and it's so far been the most
reliable and backwards-compatible piece of software we have in the
company pretty much ever since.
>
> 2- Do you have any suggestions, trips, hints and best practices in
> order to upgrade GIT in such a context?
>
Since you have such high demands on problem-free migration, I suggest
setting up a repo server running the new git (on the server side) and
having some people test against the new git with both old and new git,
as well as testing new git against the old servers.
Just get a backup first. I'm 99.9999999999999% sure you won't need it
because of anything git does, but better safe than sorry, eh?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Jakub Narebski @ 2011-09-19 12:55 UTC (permalink / raw)
To: Mikaël; +Cc: git
In-Reply-To: <1316435430491-6808156.post@n2.nabble.com>
Mikaël <mikael.donini@gmail.com> writes:
> Today, it is the time for us to upgrade from version 1.7.0.4 to
> 1.7.6.1 (the latest stable). It is important for us to work with
> the latest version since it corrects defects that are very impacting
> for us.
>
> The difficulty of this migration is that we can't afford migrations problems
> (in order to maintain productivity and work).
>
> That is the reason why I have a couple of questions:
>
> 1- Is it possible to have two GIT installations pointing on the same
> repositories?
>
> One of this installation would be GIT 1.7.6.1 used by a restricted number of
> people (these people could be called 'beta-testers' of the new GIT version).
> The other installation would be GIT 1.7.0.4 used by the other users (the
> majority of users) with no impact on their productivity.
>
> Once the beta-tests will be finished and successful, all the users will move
> to GIT 1.7.6.1.
Git is forward and backward compatibile, meaning that old clients can
connect to new servers (perhaps not using new features), and new
clients can connect to old servers.
The exceptions are few (submodules, packed refs), are always announced
long in advance, with a long transition period: first a configuration
variable is added to switch to new incompatibile behavior defaulting
to old behavior, only after a time there is switch to new improved
incompatibile version.
--
Jakub Narębski
^ permalink raw reply
* Re: [RFC/PATCH] Configurable hyperlinking in gitk
From: Marc Branchaud @ 2011-09-19 15:05 UTC (permalink / raw)
To: Chris Packham; +Cc: Jeff Epler, git
In-Reply-To: <4E752E32.2010208@gmail.com>
On 11-09-17 07:33 PM, Chris Packham wrote:
>
> Hmm no joy with \&. Seems to upset the invocation of git web-browse
>
> git config gitk.linkify.bugtracker.sub \
> 'https://internalhost/code\&stuff/bugs.php?id=\1'
>
> gitk
> /home/chrisp/libexec/git-core/git-web--browse: line 167:
> stuff/bugs.php?id=bug123: No such file or directory
> fatal: 'web--browse' appears to be a git command, but we were not
> able to execute it. Maybe git-web--browse is broken?
>
> Using the following works as expected with no error with your updated patch.
>
> git config gitk.linkify.bugtracker.sub \
> 'https://internalhost/code%26stuff/bugs.php?id=\1'
Jeff: This is great -- thanks!
I still had problems with using an & in the URL, even with the updated patch.
I had to apply Chris's git-web--browse patch to get it to work.
M.
^ permalink raw reply
* Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX
From: Junio C Hamano @ 2011-09-19 16:43 UTC (permalink / raw)
To: Wang Hui; +Cc: git
In-Reply-To: <1316425872-30457-1-git-send-email-Hui.Wang@windriver.com>
Wang Hui <Hui.Wang@windriver.com> writes:
> diff --git a/abspath.c b/abspath.c
> index f04ac18..2ce1db9 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -24,7 +24,7 @@ int is_directory(const char *path)
> const char *real_path(const char *path)
> {
> static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
> - char cwd[1024] = "";
> + char cwd[PATH_MAX] = "";
Thanks.
This does not make things worse but in the longer term we should move away
from using PATH_MAX in general.
^ permalink raw reply
* Re: gitk: 'j' and 'k' keyboard shortcuts backward
From: Jonathan Nieder @ 2011-09-19 16:49 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Josh Triplett, Pat Thoyts, Robert Suetterlin, Paul Mackerras, git
In-Reply-To: <CA+Jd1rFzOOxL+-JVeovTiOwM5cmyyis65Y1+xiDmG=tkJ3b2Xw@mail.gmail.com>
(+cc: Josh and upstream)
Hi,
Clemens Buchacher wrote:
> The key bindings are not related to vi. See Help -> Key
> bindings in gitk:
>
> k Move down one commit
> j Go back in history list
>
> I know this has confused me too. But I don't think it's worth changing,
> unless you can think of a solution that would confuse neither vi nor non-vi
> users.
Eh, I think it's worth changing and that the non-vi users are probably
just using arrow keys. :) The commit that introduced those key
bindings says:
| commit 6e2dda35
| Author: Robert Suetterlin <robert@mpe.mpg.de>
| Date: Thu Sep 22 10:07:36 2005 +1000
|
| [PATCH] Add new keybindings
|
| This adds several new keybindings to allow history and selectline
| navigation. I basically added Opera-like history traversal, as well
| as left-right-cursor history traversal and vi-like motion commands.
|
| Signed-off-by: Robert Suetterlin <robert@mpe.mpg.de>
| Signed-off-by: Paul Mackerras <paulus@samba.org>
How about this patch?
-- >8 --
Subject: gitk: Make vi-style keybindings more vi-like
When commit 6e2dda35 (Add new keybindings, 2005-09-22) added vi-style
keybindings to gitk (an excellent idea!), instead of adopting the
usual "hjkl = left, down, up, right" bindings used by less, vi, rogue,
and many other programs, it used "ijkl = up, left, down, right" to
mimic the inverted-T formation of the arrow keys on a qwerty keyboard,
in the style of Lode runner. So using 'j' and 'k' to scroll through
commits produces utterly confusing results to the vi user, as 'k'
moves down and 'j' moves to the previous commit.
Luckily most non-vi-users are probably using an alternate set of keys
(cursor keys or z/x + n/p) anyway. Switch to the expected vi/nethack
convention.
Requested-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
gitk | 12 ++++++------
po/de.po | 12 ++++++------
po/es.po | 12 ++++++------
po/fr.po | 12 ++++++------
po/hu.po | 12 ++++++------
po/it.po | 12 ++++++------
po/ja.po | 12 ++++++------
po/ru.po | 12 ++++++------
po/sv.po | 12 ++++++------
9 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/gitk b/gitk
index 1b0e09a5..ac3fb7d4 100755
--- a/gitk
+++ b/gitk
@@ -2411,9 +2411,9 @@ proc makewindow {} {
bindkey n "selnextline 1"
bindkey z "goback"
bindkey x "goforw"
- bindkey i "selnextline -1"
- bindkey k "selnextline 1"
- bindkey j "goback"
+ bindkey k "selnextline -1"
+ bindkey j "selnextline 1"
+ bindkey h "goback"
bindkey l "goforw"
bindkey b prevfile
bindkey d "$ctext yview scroll 18 units"
@@ -2822,9 +2822,9 @@ proc keys {} {
[mc "<%s-W> Close window" $M1T]
[mc "<Home> Move to first commit"]
[mc "<End> Move to last commit"]
-[mc "<Up>, p, i Move up one commit"]
-[mc "<Down>, n, k Move down one commit"]
-[mc "<Left>, z, j Go back in history list"]
+[mc "<Up>, p, k Move up one commit"]
+[mc "<Down>, n, j Move down one commit"]
+[mc "<Left>, z, h Go back in history list"]
[mc "<Right>, x, l Go forward in history list"]
[mc "<PageUp> Move up one page in commit list"]
[mc "<PageDown> Move down one page in commit list"]
diff --git a/po/de.po b/po/de.po
index bd194a3d..e4cf661a 100644
--- a/po/de.po
+++ b/po/de.po
@@ -371,16 +371,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<Ende>\t\tZur ältesten Version springen"
#: gitk:2819
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Hoch>, p, i\tNächste neuere Version"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Hoch>, p, k\tNächste neuere Version"
#: gitk:2820
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Runter>, n, k\tNächste ältere Version"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Runter>, n, j\tNächste ältere Version"
#: gitk:2821
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Links>, z, j\tEine Version zurückgehen"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Links>, z, h\tEine Version zurückgehen"
#: gitk:2822
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/es.po b/po/es.po
index 0471dd06..9c8bcd29 100644
--- a/po/es.po
+++ b/po/es.po
@@ -319,16 +319,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\tIr a la última revisión"
#: gitk:2522
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Up>, p, i\tSubir una revisión"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Up>, p, k\tSubir una revisión"
#: gitk:2523
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Down>, n, k\tBajar una revisión"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Down>, n, j\tBajar una revisión"
#: gitk:2524
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Left>, z, j\tRetroceder en la historia"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Left>, z, h\tRetroceder en la historia"
#: gitk:2525
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/fr.po b/po/fr.po
index 5370ddc3..ff476191 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -372,16 +372,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<Fin>\t\tAller au dernier commit"
#: gitk:2691
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Haut>, p, i\t Aller au commit suivant"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Haut>, p, k\t Aller au commit suivant"
#: gitk:2692
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Bas>, n, k\t Aller au commit précédent"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Bas>, n, j\t Aller au commit précédent"
#: gitk:2693
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Gauche>, z, j\tReculer dans l'historique"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Gauche>, z, h\tReculer dans l'historique"
#: gitk:2694
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/hu.po b/po/hu.po
index 7262b610..af0ddda2 100644
--- a/po/hu.po
+++ b/po/hu.po
@@ -370,16 +370,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<Ende>\t\tUtolsó commithoz"
#: gitk:2816
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Hoch>, p, i\tEgy committal feljebb"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Hoch>, p, k\tEgy committal feljebb"
#: gitk:2817
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Runter>, n, k\tEgy committal lejjebb"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Runter>, n, j\tEgy committal lejjebb"
#: gitk:2818
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Links>, z, j\tVissza a history listába"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Links>, z, h\tVissza a history listába"
#: gitk:2819
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/it.po b/po/it.po
index a730d63a..5f562109 100644
--- a/po/it.po
+++ b/po/it.po
@@ -372,16 +372,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\tVai all'ultima revisione"
#: gitk:2819
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Su>, p, i\tVai più in alto di una revisione"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Su>, p, k\tVai più in alto di una revisione"
#: gitk:2820
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Giù>, n, k\tVai più in basso di una revisione"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Giù>, n, j\tVai più in basso di una revisione"
#: gitk:2821
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Sinistra>, z, j\tTorna indietro nella cronologia"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Sinistra>, z, h\tTorna indietro nella cronologia"
#: gitk:2822
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/ja.po b/po/ja.po
index 4f470516..249ec150 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -372,16 +372,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\t最後のコミットに移動"
#: gitk:2693
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Up>, p, i\t一つ上のコミットに移動"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Up>, p, k\t一つ上のコミットに移動"
#: gitk:2694
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Down>, n, k\t一つ下のコミットに移動"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Down>, n, j\t一つ下のコミットに移動"
#: gitk:2695
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Left>, z, j\t履歴の前に戻る"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Left>, z, h\t履歴の前に戻る"
#: gitk:2696
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/ru.po b/po/ru.po
index c3d0285b..e7e6e9ef 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -350,16 +350,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\tПерейти к последнему состоянию"
#: gitk:2646
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Up>, p, i\tПерейти к следующему состоянию"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Up>, p, k\tПерейти к следующему состоянию"
#: gitk:2647
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Down>, n, k\tПерейти к предыдущему состоянию"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Down>, n, j\tПерейти к предыдущему состоянию"
#: gitk:2648
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Left>, z, j\tПоказать ранее посещённое состояние"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Left>, z, h\tПоказать ранее посещённое состояние"
#: gitk:2649
msgid "<Right>, x, l\tGo forward in history list"
diff --git a/po/sv.po b/po/sv.po
index 386763ad..8bd72f3d 100644
--- a/po/sv.po
+++ b/po/sv.po
@@ -371,16 +371,16 @@ msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\tGå till sista incheckning"
#: gitk:2819
-msgid "<Up>, p, i\tMove up one commit"
-msgstr "<Upp>, p, i\tGå en incheckning upp"
+msgid "<Up>, p, k\tMove up one commit"
+msgstr "<Upp>, p, k\tGå en incheckning upp"
#: gitk:2820
-msgid "<Down>, n, k\tMove down one commit"
-msgstr "<Ned>, n, k\tGå en incheckning ned"
+msgid "<Down>, n, j\tMove down one commit"
+msgstr "<Ned>, n, j\tGå en incheckning ned"
#: gitk:2821
-msgid "<Left>, z, j\tGo back in history list"
-msgstr "<Vänster>, z, j\tGå bakåt i historiken"
+msgid "<Left>, z, h\tGo back in history list"
+msgstr "<Vänster>, z, h\tGå bakåt i historiken"
#: gitk:2822
msgid "<Right>, x, l\tGo forward in history list"
--
1.7.7.rc1
^ permalink raw reply related
* Re: [PATCH] t4014: remove Message-Id/timestamp before comparing patches
From: Junio C Hamano @ 2011-09-19 17:08 UTC (permalink / raw)
To: Thomas Rast; +Cc: Pang Yan Han, Jeff King, git
In-Reply-To: <6b2cb6ebec907342a02d56a36ddc58715efabc00.1316414731.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> +strip_msgid () {
> + sed 's#\(Message-Id: *\)<[^>]*>#\1<MESSAGE@ID>#' "$1" >"$1+" &&
> + mv "$1+" "$1"
> +}
> +
As this is munging the contents of the line, if future versions of
format-patch start coloring the message ID values for some mistake, the
test using strip_msgid won't catch them anyway, so I'll amend the
stripping to actually strip the message id, like this:
sed '/^Message-Id: /d' <"$1" >"$1+"
before applying.
Thanks.
^ permalink raw reply
* Re: gitk: 'j' and 'k' keyboard shortcuts backward
From: Josh Triplett @ 2011-09-19 17:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Clemens Buchacher, Pat Thoyts, Robert Suetterlin, Paul Mackerras,
git
In-Reply-To: <20110919164950.GB2861@elie>
On Mon, Sep 19, 2011 at 11:49:50AM -0500, Jonathan Nieder wrote:
> How about this patch?
>
> -- >8 --
> Subject: gitk: Make vi-style keybindings more vi-like
>
> When commit 6e2dda35 (Add new keybindings, 2005-09-22) added vi-style
> keybindings to gitk (an excellent idea!), instead of adopting the
> usual "hjkl = left, down, up, right" bindings used by less, vi, rogue,
> and many other programs, it used "ijkl = up, left, down, right" to
> mimic the inverted-T formation of the arrow keys on a qwerty keyboard,
> in the style of Lode runner. So using 'j' and 'k' to scroll through
> commits produces utterly confusing results to the vi user, as 'k'
> moves down and 'j' moves to the previous commit.
>
> Luckily most non-vi-users are probably using an alternate set of keys
> (cursor keys or z/x + n/p) anyway. Switch to the expected vi/nethack
> convention.
>
> Requested-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
This looks perfect to me.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Thanks!
- Josh Triplett
^ permalink raw reply
* Re: Where is information of "git read-tree" stored?
From: Junio C Hamano @ 2011-09-19 17:36 UTC (permalink / raw)
To: Manuel Reimer; +Cc: git
In-Reply-To: <loom.20110919T103707-867@post.gmane.org>
Manuel Reimer <manuel.spam@nurfuerspam.de> writes:
> Hello,
>
> following situation:
>
> - Project hosted on GIT. Have a local copy and push to remote server.
> - Small addon is hosted on a remote SVN server
> - I now cloned the SVN to a local GIT (svn git clone)
> - Then I used the instructions from here:
>
> <http://git-mirror.googlecode.com/git-history/7444c60/howto/using-merge-subtree.html>
>
> to get the local SVN copy merged into a subdirectory on my project GIT. Anything
> worked well.
>
> To test the worst case, I cloned my project GIT to a new local repository. The
> remote connection to the local SVN copy was lost, so I recreated it.
It is unclear to me what you meant by "connection" "lost" and "recreated"
above, but I am guessing I can ignore them, as long as I take it that you
mean by that local mirror from the subversion repository "Bproject" below.
> Now, for some reason, I can immediately call
>
> git pull -s subtree Bproject master
>
> to pull changes from the SVN copy to the subdir... I didn't have to call "git
> read-tree" again.
That "how to" may be badly written and this may have been unclear to you
but the first four steps are to be done _only once_ to set things up, and
after that you need to run only the fifth step whenever you want to update
from the Bproject. Could you suggest a better wording to update the doc?
The very first "subtree merge" (the one that is recorded with the commit
after the read-tree) records all paths from Bproject renamed to elsewhere
in the merge result (you can view it with "git show -M
$that_merge_commit"), and that is what allows "pull -s" (both the initial
one and subsequent ones; indeed the fifth step in the initial round is not
any more special than the subsequent round) notice where changes from the
Bproject ought to go.
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Junio C Hamano @ 2011-09-19 17:57 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Packham, git, chriscool, jepler
In-Reply-To: <20110918183846.GA31176@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmm. Actually, the one for custom browser commands might need it,
> because that one is expected to be a shell snippet. I suspect the
> simplest thing is to do something like:
>
> eval "$browser_cmd \"\$@\""
Yeah, I agree, and the dq around $browser_cmd is kind of important, too,
for that to work and be readable.
> If you want to make a test, I think you would do better with something
> like:
>
> echo someurl_with_&_in_it >expect &&
> git config browser.custom.cmd echo &&
> git web--browse --browser=custom someurl_with_&_in_it >actual &&
> test_cmp expect actual
>
> That won't test that we are invoking kfmclient correctly, obviously, but
> you can confirm at least that URLs are making it through to the browser
> script intact.
Hmm, isn't '&' somewhat an unusual in URL? ...ah, not really, if it is in
the query parameter part it is quite common.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Jeff King @ 2011-09-19 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Packham, git, chriscool, jepler
In-Reply-To: <7vvcso9zzi.fsf@alter.siamese.dyndns.org>
On Mon, Sep 19, 2011 at 10:57:37AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Hmm. Actually, the one for custom browser commands might need it,
> > because that one is expected to be a shell snippet. I suspect the
> > simplest thing is to do something like:
> >
> > eval "$browser_cmd \"\$@\""
>
> Yeah, I agree, and the dq around $browser_cmd is kind of important, too,
> for that to work and be readable.
Oops, good catch. Probably the most readable version would be:
eval "\"$browser_cmd\"" '"$@"'
-Peff
^ permalink raw reply
* Re: [RFC/PATCHv2] git-web--browse: avoid the use of eval
From: Jeff King @ 2011-09-19 18:34 UTC (permalink / raw)
To: Chris Packham; +Cc: Junio C Hamano, git, chriscool, jepler
In-Reply-To: <1316424415-11156-1-git-send-email-judge.packham@gmail.com>
On Mon, Sep 19, 2011 at 09:26:55PM +1200, Chris Packham wrote:
> Using eval causes problems when the URL contains an appropriately
> escaped ampersand (\&). Dropping eval from the built-in browser
> invocation avoids the problem.
>
> Cc: peff@peff.net
> Cc: chriscool@tuxfamily.org
> Cc: jepler@unpythonic.net
Although other projects do use "cc" in the commit message, I think we
don't usually bother adding this noise in the git project. The cc
headers in your email are enough.
> I've replaced my tests With the test suggested by Peff (should I be
> giving him credit in the copyright line or something?).
For a minor bit of help, usually mentioning the person in the commit
message (with a "Helped-by", or indicating which parts they contributed
to) is plenty. Personally, I don't even care much about that. My
contributions to git are thoroughly documented in the commit history and
the mailing list at this point. :)
I also find the "Copyright ..." lines in the files to be overkill, too.
They end up becoming out-of-date as other people work on the file. The
commit history is the best way to get the right answer, and a comment in
the file is at best redundant with what's there. But that is just my
opinion; I don't know that we have a particular policy for such
things[1].
-Peff
[1] Once upon a time, I think I saw the advice that every file should
have a copyright notice and mention the license at the top of the file,
but I don't know that it has ever been tested in court. I suppose the
distributed tarballs of a particular version would lack the copyright
attribution, but in that case, my solution would be to generate it from
the commit history at packaging time.
^ permalink raw reply
* Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Jeff King @ 2011-09-19 19:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Mikaël, git
In-Reply-To: <4E773A71.6020905@op5.se>
On Mon, Sep 19, 2011 at 02:49:53PM +0200, Andreas Ericsson wrote:
> On 09/19/2011 02:30 PM, Mikaël wrote:
> >
> > 1- Is it possible to have two GIT installations pointing on the same
> > repositories?
> >
>
> The core structure and layout of a git repository hasn't changed
> since may 2005, so it should work just fine provided you use any
> git version that actually has a version number.
>
> We've upgraded in a hodge-podge fashion at $dayjob. One of our
> servers is still running 1.4.something. We've never even come close
> to anything resembling a problem. It's actually a bit weird, since
> we started using git in late 2005 and it's so far been the most
> reliable and backwards-compatible piece of software we have in the
> company pretty much ever since.
This is not completely true. Any two versions should be able to
interoperate over the network using the git:// protocol. However, the
disk format has changed slightly over time.
Since v1.6.0 (August 2008), git defaults to using delta base offsets in
packfiles and version 2 of the pack index format. These features are not
understood by versions before v1.5.2 (May 2007) or v1.4.4.5 (July 2008).
A very old git accessing those repositories directly on disk (or by a
dumb protocol like rsync or non-smart http) would have problems[1].
So it has happened[2], but it's important to note that:
1. We waited a year to flip the default for the code supporting it to
become more pervasive.
2. The switch happened on a major version boundary (1.5 -> 1.6),
was already supported by versions in the prior major series (1.5),
and we released a maintenance version for the series before that
(1.4.4.x).
3. The change, along with the affected versions, was mentioned
prominently in the 1.6.0 release notes.
So no, I wouldn't expect any disk format issues moving from v1.7.0.4 to
v1.7.6.1. But it never hurts to read the release notes if you're unsure.
-Peff
[1] I do very occasionally run into this while bisecting some ancient
code on a modern repository.
[2] I suspect a similar thing happened with turning on packed refs
(around the v1.4.4 era?), but I didn't dig around for details.
^ permalink raw reply
* Re: gitk: 'j' and 'k' keyboard shortcuts backward
From: Clemens Buchacher @ 2011-09-19 18:04 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Josh Triplett, Pat Thoyts, Robert Suetterlin, Paul Mackerras, git
In-Reply-To: <20110919164950.GB2861@elie>
On Mon, Sep 19, 2011 at 11:49:50AM -0500, Jonathan Nieder wrote:
>
> How about this patch?
>
> -- >8 --
> Subject: gitk: Make vi-style keybindings more vi-like
Fine by me.
Clemens
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2011
From: Jakub Narebski @ 2011-09-19 19:10 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E648953.5080606@drmicha.warpmail.net>
On Mon, 5 Sep 2011, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 05.09.2011 02:43:
> > We would like to ask you a few questions about your use of the Git
> > version control system. This survey is mainly to understand who is
> > using Git, how and why.
> >
> > The results will be published to the Git wiki on the GitSurvey2011
> > page (https://git.wiki.kernel.org/index.php/GitSurvey2011) and
> > discussed on the git mailing list.
>
> Jakub, thanks for your work!
>
> I've made a few last minute minor edits on the wiki (language-wise) and
> linked to it from identi.ca, twitter and g+. Hope that's alright.
Thank you for announcing it via microblogging / social network sites.
I really appreciate spreading the word about Git User's Survey 2011.
Unfortunately when I had free time and got to correcting the survey,
Git Wiki was down already, and it stays unfortunately down till now.
When it is up, I'll review your corrections and fix survey
appropriately... well, if it will get up before survey closing.
> Let the results come in!
3500+ responses and counting...
--
Jakub Narebski
Poland
^ 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