* Re: how to remove unreachable objects?
From: Jeff King @ 2011-09-19 19:53 UTC (permalink / raw)
To: dieter; +Cc: git
In-Reply-To: <20110919110831.ewq03vnqos4w8cs8@webmail.edis.at>
On Mon, Sep 19, 2011 at 11:08:31AM +0200, dieter@schoen.or.at wrote:
> 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).
It will still be referenced by the HEAD reflog, won't it?
> git checkout master
> git branch -D $DEAD
> git show $dead_commit
> git fsck --unreachable --full --verbose
This shows it reachable, because it is connected from the HEAD reflog.
> git fsck --unreachable HEAD \
> $(git for-each-ref --format="%(objectname)" refs/heads)
And this shows it as unreachable, because you are asking git to only
look at the branch tips and HEAD (by default, it looks at all refs and
reflogs).
I suspect you copied this straight from the git-fsck manpage. That
advice is a bit outdated, I think. It blames (in some form) all the way
back to the original documentation added in c64b9b8 (2005-05-05, only a
few weeks after git was born). A few weeks later, fsck learned to
default to looking at all refs (1024932, 2005-05-18). And then other
sane defaults like reflogs got tacked on later (reflogs came around the
1.4.x era, in 2006).
> 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 really want to make it unreachable, you should expire the
reflogs, too:
git reflog expire --expire=now --all
# will now report unreachable
git fsck --unreachable
# will now actually delete objects
git prune -v
# gives "bad object ..."
git show $dead_commit
git-gc will do this for you, but of course the default expiration time
is much longer (I think something like 90 days).
-Peff
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Joshua Jensen @ 2011-09-19 19:44 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4E6A7167.6070408@workspacewhiz.com>
----- Original Message -----
From: Joshua Jensen
Date: 9/9/2011 2:04 PM
> This may be an msysGit 1.7.6 issue, as that is what I am using. It
> also occurs in msysGit 1.7.5, but I am almost certain it did not
> happen in msysGit 1.7.2.
>
> Given an untracked file in the working directory that has been added
> to an alternate branch, when switching to that alternate branch, 'git
> checkout' exits with an error code but does not print anything to the
> console. It should print an untracked file error.
>
> I have been trying to track this down in code. The point where the
> error messages are printed, display_error_msgs, is never hit.
Okay, so I've tracked this down, but I am unsure what the correct fix is.
In unpack-trees.c's unpack_trees() function, there are some lines that read:
if (ce->ce_flags & CE_ADDED &&
verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
return -1;
If the 'return -1' is changed to 'goto return_failed', then a proper
error message appears:
error: The following untracked working tree files would be
overwritten by checkout:
one/file/listed/here.txt
Please move or remove them before you can switch branches.
Aborting
The thing is, there are multiple files that would be overwritten by
checkout, and I believe an older version of Git showed me the entire
list before aborting.
What would be the proper fix here? What am I doing wrong?
Thanks.
Josh
^ permalink raw reply
* Re: Branching strategies
From: gitlist @ 2011-09-19 18:51 UTC (permalink / raw)
To: git
In-Reply-To: <CAH5451kn5WD4+S3_SGMarGyoUs6NA6Xvz9Pb8Wdpt9v0nY+Uow@mail.gmail.com>
On 10/09/2011 02:18, Andrew Ardill wrote:
> On 10 September 2011 09:01, robert mena<robert.mena@gmail.com> wrote:
>> Hi,
>>
>> <snip>
>> Since some of those can touch the same files how can I make this a
>> little bit better (manageable)?
>>
> A very interesting read is
> http://nvie.com/posts/a-successful-git-branching-model/
>
> It may not be perfect for you, however it does discuss some very
> interesting issues, particularly how workflow is just as important as
> the branching model.
I came across the nvie post some time and it was very useful, but it
doesn't address handling of feature branches, especially where there is
overlap.
I have a website where people can register. They can also buy things. If
they haven't registered when they come to checkout, the checkout process
includes registration. Users can also create "sponsorship" pages where
they ask friends to sponsor them in a marathon etc. If someone setting
up a sponsorship page is not already registered, it's included in the
process.
So there are three strands (to avoid using the word "branch") -
registration, buying, and sponsorship - which end up affecting the same
bits of code. Registration was done a year ago but recently needed
updating; buying was started some months ago but got held up;
sponsorship started recently, has been completed, and has "overtaken"
buying.
How should I use branches in this scenario? Or if I've got the concept
wrong, how should I change my workflow?
Thanks
Roddie Grant
^ permalink raw reply
* Re: [PATCH] t4014: remove Message-Id/timestamp before comparing patches
From: Jeff King @ 2011-09-19 19:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: Pang Yan Han, Junio C Hamano, git
In-Reply-To: <6b2cb6ebec907342a02d56a36ddc58715efabc00.1316414731.git.trast@student.ethz.ch>
On Mon, Sep 19, 2011 at 08:45:43AM +0200, Thomas Rast wrote:
> 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.
Hmph. I was confused at first reading this, because git format-patch
doesn't produce message-ids. Usually.
But it does if you turn on threading, which obviously requires it. And
earlier tests set format.thread without bothering to clean up after
themselves.
So perhaps this is a better solution:
-- >8 --
Subject: [PATCH] t4014: clean up format.thread config after each test
The threading tests turn on format.thread, but never clean
up after themselves, meaning that later tests will also have
format.thread set.
This is more annoying than most leftover config, too,
because not only does it impact the results of other tests,
but it does so non-deterministically. Threading requires the
generation of message-ids, which incorporate the current
time, meaning a slow-running test script may generate
different results from run to run.
Signed-off-by: Jeff King <peff@peff.net>
---
This uses the test_color helper I introduced recently in d960c47. This
should be OK, because ph/format-patch-no-color (which introduces the
problem) is built on top of jk/color-and-pager (which introduces
test_config).
There are several other places in the script that could use the same
cleanup, but I didn't bother as they are more complex (e.g., using
"--add" to build up multi-value header config) and don't actually cause
problems (because they're deterministic, and don't clutter the output in
a meaningful way)
t/t4014-format-patch.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 7e405d7..6797512 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -457,22 +457,22 @@ test_expect_success 'thread deep cover-letter in-reply-to' '
'
test_expect_success 'thread via config' '
- git config format.thread true &&
+ test_config format.thread true &&
check_threading expect.thread master
'
test_expect_success 'thread deep via config' '
- git config format.thread deep &&
+ test_config format.thread deep &&
check_threading expect.deep master
'
test_expect_success 'thread config + override' '
- git config format.thread deep &&
+ test_config format.thread deep &&
check_threading expect.thread --thread master
'
test_expect_success 'thread config + --no-thread' '
- git config format.thread deep &&
+ test_config format.thread deep &&
check_threading expect.no-threading --no-thread master
'
--
1.7.7.rc1.3.gb95be
^ permalink raw reply related
* 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
* 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: 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: [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: [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: [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: 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: 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: [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: 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] 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: [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: 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: 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: 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
* 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
* [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
* 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
* 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
* [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] 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
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