Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
* git grep learned to use a non-standard pattern type by
default if a configuration variable tells it to.
This addition makes
git grep -e
On Wed, Oct 3, 2012 at 1:34 AM, Jeremy Morton ad...@game-point.net wrote:
Junio C Hamano gitster at pobox.com writes:
Jeremy Morton admin at game-point.net writes:
I've noticed that the p4merge shell script could do with some
improvement when it comes to merging. Because p4merge throws
Junio C Hamano gits...@pobox.com writes:
Call init_revisions() first to prepare the revision traversal
parameters and pass it to git_log_config(), so that necessary bits
in the traversal parameters can be tweaked before we call the
command line parsing infrastructure setup_revisions() from
Hi Philip and all,
let me explain in full what is the problem that I tried to solve, and
how along the way I stumbled in something that seems to me a git bug
(at least a documentation one).
There is an RD team developing software using a workflow that is
similar to the integerator-manager one
On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the wildmatch code may not be what we want X-.
When I imported wildmatch I was hoping to make minimum changes to it.
But wildmatch is probably the only practical way to support ** even
if we later need to change it
We're going to add more attributes to u.pattern so it'll become bigger
in size than a pointer. There's no point in sharing the same room with
u.attr.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to .gitattributes. Basically it
tries to avoid
** can match slashes, not like *. ab**ef should be able to match
ab/cd/ef, or ab/c/d/ef and so on. Turn off the EXC_FLAG_NODIR in
this case otherwise the pattern is only checked against the base
name. This behavior is in sync with rsync.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
** currently matches any characters including slashes. It's probably
too powerful. A more sensible definition may be match any characters
that the but the whole match must be wrapped by slashes. So ** can
match none, /, /aaa/, /aa/bb/ and so on but not aa/bb.
Note it in the test suite.
On Thu, Oct 04, 2012 at 01:54:47AM +0200, Ævar Arnfjörð Bjarmason wrote:
Hmm. It seems like we should not need to open the tags at all. The main
reason is to produce the peeled advertisement just after it. But for a
packed ref with a modern version of git that supports the peeled
When we are asked to peel a ref to a sha1, we internally call
deref_tag, which will recursively parse each tagged object
until we reach a non-tag. This has the benefit that we will
verify our ability to load and parse the pointed-to object.
However, there is a performance downside: we may not
The idea of the peel_ref function is to dereference tag
objects recursively until we hit a non-tag, and return the
sha1. Conceptually, it should return 0 if it is successful
(and fill in the sha1), or -1 if there was nothing to peel.
However, the current behavior is much more confusing. For a
The point of peel_ref is to dereference tags; if the base
object is not a tag, then we can return early without even
loading the object into memory.
This patch accomplishes that by checking sha1_object_info
for the type. For a packed object, we can get away with just
looking in the pack index.
When upload-pack advertises refs, we attempt to peel tags
and advertise the peeled version. We currently hand-roll the
tag dereferencing, and use as many optimizations as we can
to avoid loading non-tag objects into memory.
Not only has peel_ref recently learned these optimizations,
too, but it
On Thu, Oct 04, 2012 at 03:56:09AM -0400, Jeff King wrote:
[1/4]: peel_ref: use faster deref_tag_noverify
[2/4]: peel_ref: do not return a null sha1
[3/4]: peel_ref: check object type before loading
[4/4]: upload-pack: use peel_ref for ref advertisements
I included my own timings in
On Wed, Oct 03, 2012 at 06:33:36PM -0700, Junio C Hamano wrote:
diff --git a/revision.c b/revision.c
index a09e60b..7f5e53b 100644
--- a/revision.c
+++ b/revision.c
@@ -1604,12 +1604,12 @@ static int handle_revision_opt(struct rev_info *revs,
int argc, const char **arg
} else if
On Wed, Oct 03, 2012 at 06:33:37PM -0700, Junio C Hamano wrote:
When we added the --perl-regexp option (or -P) to git grep, we
should have done the same for the commands in the git log family,
but somehow we forgot to do so. This corrects it.
Also introduce the --basic-regexp option for
On Wed, Oct 03, 2012 at 06:33:39PM -0700, Junio C Hamano wrote:
Read grep.extendedregexp, grep.patterntype, etc. from the
configuration so that log --grep='pcre' honors the user
preference without an explicit -P from the command line.
Now that the callback parameter, which was so far
On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote:
* fa/remote-svn (2012-09-19) 16 commits
- Add a test script for remote-svn
- remote-svn: add marks-file regeneration
- Add a svnrdump-simulator replaying a dump file for testing
- remote-svn: add incremental import
-
David Michael Barr wrote:
On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote:
* fa/remote-svn (2012-09-19) 16 commits
- Add a test script for remote-svn
- remote-svn: add marks-file regeneration
- Add a svnrdump-simulator replaying a dump file for testing
- remote-svn: add
On Thu, Oct 4, 2012 at 10:04 AM, Jeff King p...@peff.net wrote:
On Thu, Oct 04, 2012 at 03:56:09AM -0400, Jeff King wrote:
[1/4]: peel_ref: use faster deref_tag_noverify
[2/4]: peel_ref: do not return a null sha1
[3/4]: peel_ref: check object type before loading
[4/4]: upload-pack:
On 10/03/2012 08:17 PM, Junio C Hamano wrote:
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
There's an interesting case: **foo. According to our rules, that
pattern does not contain slashes therefore is basename match. But some
might find that confusing because ** can match slashes,...
On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On Thu, Oct 4, 2012 at 4:34 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
Given that there is no obvious interpretation for what a construct like
x**y would mean, and many plausible guesses (most of which sound
On Thu, Oct 4, 2012 at 5:01 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
$ time (echo | ~/g/git/git-upload-pack . | pv /dev/null)
Totally off-topic, but ...
Thanks for making me look up what pv is. I remember checking it out
quiet sometime
ago and have forgotten about it
- Original Message -
From: Jonathan Nieder jrnie...@gmail.com
Sent: Thursday, October 4, 2012 4:30:01 AM
Subject: Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01;
Tue, 2))
* fa/remote-svn (2012-09-19) 16 commits
- Add a test script for remote-svn
-
On Thu, Oct 4, 2012 at 3:07 AM, Angelo Borsotti
angelo.borso...@gmail.com wrote:
...
The operation that caused problems was nr. 4. In all the cases
enlisted above, a git commit creates a brand new and unique commit
because either it has a parent that is different from that of any
other commit,
Hi,
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version 1.7.12 is much quicker:
markus@x4 linux % time git pull
Already up-to-date.
git pull 0.10s user 0.02s
Hi,
Is it normal that git commit --amen actually works ?
(it does like --amend)
version 1.7.10.4
®om
--
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
On Thu, Oct 4, 2012 at 12:35 AM, John Whitney j...@emsoftware.com wrote:
I just ran into a problem that I'm pretty sure is a bug in git. Just read
and run this (fairly trivial) shell script to replicate.
When you added * text=auto in the .gitattributes file, you changed
what git considers to be
Is it normal that git commit --amen actually works ?
(it does like --amend)
version 1.7.10.4
Yes. From Documentation/technical/api-parse-options.txt:
* Long options may be 'abbreviated', as long as the abbreviation
is unambiguous.
Apparently since 2008-06-22.
So 'git commit
On Thu, Oct 4, 2012 at 4:38 PM, Romain Vimont (®om) r...@rom1v.com wrote:
Great !
Thank you for your answer ;-)
It does not seem to work with git diff:
git diff --cache #missing d
git diff --cumulativ #missing e
This is because git-diff doesn't yet use the parse-options API, but
instead
On 10/03/2012 06:35 PM, Alexander Kostikov wrote:
That allows you can go back to the pre-rebase state by
rebase --abort.
rebase --abort command were not available. I guess rebase file was not created.
I meant rebase --abort would be available *if* the error was caught by
rebase. But in your
Andrew,
Thanks for checking this on your machine.
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and
David Michael Barr b...@rr-dav.id.au writes:
On Wednesday, 3 October 2012 at 9:20 AM, Junio C Hamano wrote:
* fa/remote-svn (2012-09-19) 16 commits
...
A GSoC project.
Waiting for comments from mentors and stakeholders.
I have reviewed this topic and am happy with the design and
Andrew,
I forgot to say that all of the config settings
are not changed from the default.
---John
On 10/4/12 11:16 AM, John Whitney wrote:
Andrew,
Thanks for checking this on your machine.
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my
Stephen Bash b...@genarts.com writes:
I seemed to have missed the GSoC wrap up conversation... (links happily
accepted).
I also seem to have missed such conversation, if anything like that
happened. It certainly would have been nice for the mentors and the
student for each project to give us
Michael Haggerty mhag...@alum.mit.edu writes:
On 10/03/2012 08:17 PM, Junio C Hamano wrote:
What is the semantics of ** in the first place? Is it described to
a reasonable level of detail in the documentation updates? For
example does **foo match afoo, a/b/foo, a/bfoo, a/foo/b,
a/bfoo/c?
Jeff King p...@peff.net writes:
Hmm. So I think this is a nice feature for some people, but I wonder if
we would run into any plumbing compatibility issues. People do tend to
use log as plumbing (since rev-list is not as capable). On the other
hand, I'd think most internal uses of log --grep
Phil Hord phil.h...@gmail.com writes:
Is it normal that git commit --amen actually works ?
(it does like --amend)
version 1.7.10.4
Yes. From Documentation/technical/api-parse-options.txt:
* Long options may be 'abbreviated', as long as the abbreviation
is unambiguous.
Erik Faye-Lund kusmab...@gmail.com writes:
On Thu, Oct 4, 2012 at 4:38 PM, Romain Vimont (®om) r...@rom1v.com wrote:
Great !
Thank you for your answer ;-)
It does not seem to work with git diff:
git diff --cache #missing d
git diff --cumulativ #missing e
This is because git-diff
On 10/04/2012 12:16 PM, John Whitney wrote:
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and run
Junio C Hamano gits...@pobox.com writes:
Phil Hord phil.h...@gmail.com writes:
Is it normal that git commit --amen actually works ?
(it does like --amend)
version 1.7.10.4
Yes. From Documentation/technical/api-parse-options.txt:
* Long options may be 'abbreviated', as long as the
My `.git/config` can be corrupted if I try to get a local branch with
an extremely long name to track a remote branch.
Here is a (contrived) example to reproduce the issue:
$ cd /tmp
$ mkdir buggyrepo otherrepo
$ cd buggyrepo/ git init cd -
$ cd otherrepo/ git init cd -
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
On Thu, Oct 4, 2012 at 1:01 PM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the wildmatch code may not be what we want X-.
When I imported wildmatch I was hoping to make minimum changes to it.
But wildmatch is probably the only practical way
From: Simon Ruderich si...@ruderich.org
Signed-off-by: Simon Ruderich si...@ruderich.org
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 14 +++---
1 Datei geändert, 7 Zeilen hinzugefügt(+), 7 Zeilen entfernt(-)
diff --git a/po/de.po b/po/de.po
index a3cf695..9e9f2da
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
- if (!strchr(p, '/'))
+ if (!strchr(p, '/') !strstr(p, **))
Doesn't wildmatch allow these to be quoted, similar to the way usual
glob works, e.g.
$ ff
$ \?f
$ echo ??
?f ff
$ echo
On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Hmm. So I think this is a nice feature for some people, but I wonder if
we would run into any plumbing compatibility issues. People do tend to
use log as plumbing (since rev-list is not as
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
** currently matches any characters including slashes. It's probably
too powerful. A more sensible definition may be match any characters
that the but the whole match must be wrapped by slashes. So ** can
match none, /, /aaa/, /aa/bb/ and so on
In particular, gcc complains thus:
CC pretty.o
pretty.c: In function 'format_commit_item':
pretty.c:1282: warning: 'offset' might be used uninitialized in \
this function
In order to suppress the warning we simply initialize the 'offset'
variable in it's declarartion.
Jeff King p...@peff.net writes:
When we are asked to peel a ref to a sha1, we internally call
deref_tag, which will recursively parse each tagged object
until we reach a non-tag. This has the benefit that we will
verify our ability to load and parse the pointed-to object.
However, there is
On Thu, Oct 04, 2012 at 01:15:25PM -0400, Ben Olive wrote:
My `.git/config` can be corrupted if I try to get a local branch with
an extremely long name to track a remote branch.
Here is a (contrived) example to reproduce the issue:
$ cd /tmp
$ mkdir buggyrepo otherrepo
$
Jeff King p...@peff.net writes:
The idea of the peel_ref function is to dereference tag
objects recursively until we hit a non-tag, and return the
sha1. Conceptually, it should return 0 if it is successful
(and fill in the sha1), or -1 if there was nothing to peel.
However, the current
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version 1.7.12 is much quicker:
Hi Phil,
\
And why is this a problem?
Is there a process or person watching the server for a new commit?
Is it not enough to notice that the pushed-to branch has a new HEAD?
Yes, the developers use the git gui to see the graph of branches and commits.
The simpler and uniform it is, the
Jeff King p...@peff.net writes:
The point of peel_ref is to dereference tags; if the base
object is not a tag, then we can return early without even
loading the object into memory.
This patch accomplishes that by checking sha1_object_info
for the type. For a packed object, we can get away
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Hmm. So I think this is a nice feature for some people, but I wonder if
we would run into any plumbing compatibility issues. People do tend to
use log as
Ben Olive sionid...@gmail.com writes:
My `.git/config` can be corrupted if I try to get a local branch with
an extremely long name to track a remote branch.
Here is a (contrived) example to reproduce the issue:
Don't do that, then ;-)
I think we have a change that is already cooking.
Ben
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version
On Thu, Oct 04, 2012 at 12:06:16PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The point of peel_ref is to dereference tags; if the base
object is not a tag, then we can return early without even
loading the object into memory.
This patch accomplishes that by
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version
I'm not sure to follow everything... But looks like:
$ git add -p
or
$ git add -i
should do what you want, no?
You select the hunks to commit, let over the hacks and then
$ git commit
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
Jeff King p...@peff.net writes:
[1] One thing I've been toying is with external alternates; dumping
your large objects in some realtively slow data store (e.g., a
RESTful HTTP service). You could cache and cheaply query a list of
sha1 / size / type for each object from the store,
Sorry, I didn't realize that there is a display mode where the
list of files is empty, not even showing a Comments entry.
Here's a patch that fixes it, plus another patch that is only related
in so far as the bug that it fixes was introduced by the same commit.
[PATCH 1/2] gitk: Fix error
When clicking on the line that connects two commit nodes, gitk
would bring up an error dialog saying can't read cflist_top:
no such variable.
This fixes a regression that was introduced with b967135 (gitk:
Synchronize highlighting in file view when scrolling diff).
Signed-off-by: Stefan Haller
This fixes another regression that was introduced in b967135 (gitk:
Synchronize highlighting in file view when scrolling diff): when
searching for a string in tree mode, jumping to the next search hit
would highlight the Comments entry in the file list.
Signed-off-by: Stefan Haller
Having the
last page of that output should give us enough context as to where it's
failing.
Full script is uploaded to
https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
---[code]
if test -s $dotest/rewritten; then
git notes copy
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user
Am Mittwoch, 3. Oktober 2012, 16:13:16 schrieb Jeff King:
On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote:
Out of curiosity, how are you thinking about triggering such a new
behavior in a backwards-compatible way? Invoke git-upload-pack2, and
fall back to reconnecting to
On Thu, Oct 04, 2012 at 01:41:40PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[1] One thing I've been toying is with external alternates; dumping
your large objects in some realtively slow data store (e.g., a
RESTful HTTP service). You could cache and cheaply
ignore on commit
I'm not sure to follow everything... But looks like:
$ git add -p
or
$ git add -i
should do what you want, no?
You select the hunks to commit, let over the hacks and then
$ git commit
Similar but not quite; the idea is that you know that there is some
code
Hi Philip,
This has the developers having a full copy/history of the integrators
relevant branches, so that when the pull of the developers branch occurs
there is a proper link to the integrators history.
True.
There are other ways to create a branch which has all the developers feature
From: Angelo Borsotti angelo.borso...@gmail.com
Sent: Thursday, October 04, 2012 8:07 AM
Hi Philip and all,
let me explain in full what is the problem that I tried to solve, and
how along the way I stumbled in something that seems to me a git bug
(at least a documentation one).
There is an RD
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
From: Angelo Borsotti angelo.borso...@gmail.com
Sent: Thursday, October 04, 2012 11:09 PM
A reasonable solution. You can also create a sentinel (--root) commit
for
any time that you need to create the source branch, just so it (the
real
source code commit) has a different parent when on source
On 10/04/2012 05:09 PM, Alexander Kostikov wrote:
Full script is uploaded to
https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
Judging from that log, I'm pretty sure rebase is failing at
format-patch. I was able to reproduce the issue you're having:
rebase finished and
On 10/04/2012 05:20 PM, Marco Craveiro wrote:
Similar but not quite; the idea is that you know that there is some
code (I'm just talking about files here, so lets ignore hunks for the
moment) which is normally checked in but for a period of time you want
it ignored. So you don't want it git
Hi Phil,
Another technique could be to simply switch to the sources branch, and then
use a 'git clean -x' with an updated .gitignore ('reset' the file from the
source branch)[or use the exclude file] to remove those now ignored
binaries, before doing the commit.
Actually, the first time I
Thanks, Andrew!
I'm looking forward for the patch.
On Thu, Oct 4, 2012 at 3:52 PM, Andrew Wong andrew.k...@gmail.com wrote:
On 10/04/2012 05:09 PM, Alexander Kostikov wrote:
Full script is uploaded to
https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
Judging from that
On Thu, Oct 04, 2012 at 11:52:13PM +0200, Sascha Cunz wrote:
Would it be possible to use this workflow:
- Every client connects per default to v1
- If server is capable of v2, it sends a flag along with the usual response
(A v1 server will obviously not send that flag)
That is more or
On Thu, Oct 04, 2012 at 12:28:39PM -0700, Junio C Hamano wrote:
Ben Olive sionid...@gmail.com writes:
My `.git/config` can be corrupted if I try to get a local branch with
an extremely long name to track a remote branch.
Here is a (contrived) example to reproduce the issue:
Don't do
Op 03-10-12 18:52, Andreas Schwab schreef:
Geoffrey De Smet ge0ffrey.s...@gmail.com writes:
Suppose this case:
git clone .../blessedRepo.git
// do changes
git commit -mbad1
// do changes
git commit -mbad2
git reset --hard HEAD^4 // Why does it let me do this?
Because there is nothing wrong
Op 03-10-12 18:40, Phil Hord schreef:
But I feel your pain. I think the solution lies in relegating 'reset'
to the plumbing or the power-user realm of commands since I feel it is
quite overloaded and sometimes dangerous. There was a thread some
months back heading in this direction, but I
On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote:
On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote:
...
Similar but not quite; the idea is that you know that there is some
code (I'm just talking about files here, so lets ignore hunks for the
moment)
On Fri, Oct 5, 2012 at 7:05 AM, demerphq demer...@gmail.com wrote:
On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote:
On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote:
...
Similar but not quite; the idea is that you know that there is some
code (I'm
Sitaram Chamarty sitar...@gmail.com writes:
Git ignore doesn't ignore tracked files.
would 'git update-index --assume-unchanged' work in this case? Didn't
see it mentioned in any of the replies so far (but I have never used
it myself)
The assume-unchanged bit is *not* an instruction to
On 5 October 2012 12:20, Sitaram Chamarty sitar...@gmail.com wrote:
On Fri, Oct 5, 2012 at 7:05 AM, demerphq demer...@gmail.com wrote:
On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote:
On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote:
...
Similar but
Geoffrey De Smet ge0ffrey.s...@gmail.com writes:
Op 03-10-12 18:40, Phil Hord schreef:
But I feel your pain. I think the solution lies in relegating 'reset'
to the plumbing or the power-user realm of commands since I feel it is
quite overloaded and sometimes dangerous. There was a thread
88 matches
Mail list logo