but what does mean in the sense of branching and
merging? will i get *precisely* 10 commits of history? and in the
context of merging, *which* 10 commits?
sorry if this should be obvious.
rday
--
================
Robert P. J. Day
t
$ git diff --
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://
On Sat, 16 Mar 2019, Johannes Sixt wrote:
> Am 16.03.19 um 13:22 schrieb Robert P. J. Day:
> > as a working example, i looked at the top-level .gitattributes file
> > in the git source code itself, which opens with:
> >
> > * whitespace=!indent,trail,space
> >
On Sat, 16 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Mar 16 2019, Robert P. J. Day wrote:
>
> > more nitpicking, but i'm working my way through the intricacies of
> > attributes and putting together some (allegedly) simple examples for a
> > class i&#
l,space
does the "!" apply to "indent" or to the entire list? the man page
doesn't say.
just being pedantic again.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
On Sat, 16 Mar 2019, Duy Nguyen wrote:
> On Fri, Mar 15, 2019 at 9:31 PM Robert P. J. Day
> wrote:
> > also, i think "man git-clone" could really use a set of examples for
> > shallow cloning. i'd offer to write it but i'm still figuring it out.
>
>
On Fri, 15 Mar 2019, Duy Nguyen wrote:
> On Fri, Mar 15, 2019 at 8:19 PM Robert P. J. Day
> wrote:
> > this is the first time i've played with this feature, so i'm
> > still working my way through the man page, trying to figure out
> > the various vali
On Fri, 15 Mar 2019, Duy Nguyen wrote:
> On Fri, Mar 15, 2019 at 7:17 PM Robert P. J. Day
> wrote:
> >
> >
> > probably doing something idiotic but i'm enumerating variations of
> > shallow cloning, and tried the following:
> >
> > $ git cl
clearly don't understand
what this option is supposed to do.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
On Thu, 14 Mar 2019, Konstantin Ryabitsev wrote:
> On Wed, 13 Mar 2019 at 16:56, Jeff King wrote:
> > - preferences between Canada and US?
>
> If you're looking at Canada, East coast is generally more affordable
> than West Coast in terms of venues and accommodation. The three main
> tech hubs
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 11:01 AM Robert P. J. Day
> wrote:
> >
> > On Tue, 12 Mar 2019, Bryan Turner wrote:
> >
> > > On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> > > wrote:
> > > >
>
ah, i'm starting to get it. predictably, i think this needs to be
mentioned in a man page. :-) thanks muchly for clearing that up.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> wrote:
> >
> > never noticed this before ... when i do a regular "git commit" and
> > enter my "vi" edit session and change my mind, i can bail with &q
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> wrote:
> >
> > never noticed this before ... when i do a regular "git commit" and
> > enter my "vi" edit session and change my mind, i can bail with &q
quot; that the
revert was cancelled:
Aborting commit due to empty commit message.
that seems ... inconsistent. am i misunderstanding something?
rday
--
Robert P. J. Day Ottawa, Onta
t;all") || !strcmp(date, "now"))
... snip ...
is the preference to simply list both alternatives, or to
*encourage* the more intuitive "now" and "never" values while politely
deprecating the others? the impression i get is the latter.
rday
-
age
collected?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn:
utting in an
extra line or two mentioning this in the man page? that is, as long as
i've understood this correctly.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http
nio's
take on this here:
https://marc.info/?l=git&m=152695527902711&w=2
was to banish the phrase entirely in favour of some combination of
"tracked" and/or "added to the index."
thoughts?
rday
--
================
Correct misspelled ".gitattribute" in comments only, so no functional
change.
Signed-off-by: Robert P. J. Day
---
diff --git a/attr.c b/attr.c
index fdd110bec5..93dc16b59c 100644
--- a/attr.c
+++ b/attr.c
@@ -431,14 +431,14 @@ static struct match_attr *parse_attr_line(const c
On Tue, 5 Mar 2019, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > Currently, all of the examples for "man git-rebase" show rebasing from
> > a branch that has had no further development, which might mislead
> > readers into thinking tha
On Tue, 5 Mar 2019, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > one of the things i've noticed about the examples in "man
> > git-rebase" is that they invariably show rebasing relative to a
> > branch point that has not moved. fo
arify that.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 5629ba4c5d..ba3c44fdaf 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -109,8 +109,8 @@ functionality which is found in 'next'.
before running the rebase, then leaving off that final argument?
everything i've seen suggests those two things are identical, but
i've been fooled before.
rday
--
============
Robert P. J. Day
any further. (yes, i
realize that, if you read carefully, it *should* make it clear, but i
think it would be helpful to at least graphically show that
happening.)
thoughts?
rday
--
================
Robert P. J. Day
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index a7442499f6..a7c1b0f60e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -76,7 +76,7 @@ be performed as well.
--prune=::
Prune loose objects older than
argv_array_push(&repack, "-a");
else {
... snip ...
while the man page does not seem to mention the possible value of
"now".
am i misreading something? should the man page mention the possible
value of "now" as opposed to "all"?
rday
--
On Sat, 23 Feb 2019, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 23 Feb 2019, Johannes Schindelin wrote:
>
> > On Sat, 23 Feb 2019, Junio C Hamano wrote:
> >
> > > "Robert P. J. Day" writes:
> > >
> > > > am i misreading som
On Sat, 23 Feb 2019, Todd Zullinger wrote:
> Hi,
>
> Robert P. J. Day wrote:
> >
> > not so much a git issue as what looks like a fedora packaging
> > issue.
>
> Yeah, it's just a minor packaging issue. The gitweb manpages are
> included in the m
perusing the source code
doesn't seem to show that command checking that config option.
am i misreading something? and if not, is there a reason git clean
does not consult core.excludesFile?
rday
--
============
works fine.
the question is, is it not inconsistent for fedora's basic "git"
package to include the man page for gitweb, without including the
corresponding functionality? is this something i should submit a
fedora bugzilla report for? or am i misunderstanding somethi
esses
those two arguments, as "v4.19" is, of course, a reference to a
specific commit, but "^v4.19^" appears to define all those commits not
reachable from "v4.19^". how should one read this?
rday
--
=
The default pre-commit script checks the config variable
"hooks.allownonascii" to determine whether to allow non-ASCII file
names -- mention this in "man githooks", just as the section on
"update" mentions the use of "hooks.allowunannotated".
Signed-off-
On Tue, 19 Feb 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Feb 19 2019, Robert P. J. Day wrote:
>
> > was just perusing the sample hook scripts, and the sample pre-commit
> > script provided with git does the following check:
> >
> > # If you want to a
was just perusing the sample hook scripts, and the sample pre-commit
script provided with git does the following check:
# If you want to allow non-ASCII filenames set this variable to true.
allownonascii=$(git config --bool hooks.allownonascii)
but that config variable (hooks.allownonascii)
others are to keep up with changes to git. that said, i
definitely have ideas for more wide-ranging changes if i ever get the
time; i think some section re-ordering could be helpful but that's all
in due time.
i do what i can.
rday
--
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
> >
> >
> > from "man git-reset":
> >
> > SYNOPSIS
> > git reset [-q] [] [--] ...
> > git reset (--patch | -p) [] [--] [...]
> >
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+
e valid in that third case (at least for
"--mixed"). thoughts? is that just an oversight in the man page?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
Current "man git-add" emphasizes single letter interactive
shortcut commands with "[]".
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45652fe4a6..ad9bd7c7a6 100644
--- a/Documentation/git-add.txt
+++ b/Docum
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
&
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
&
On Sun, 2 Dec 2018, Kevin Daudt wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
&
patch mode -- certainly "p" doesn't do it. am i stupidly missing
something trivial? is the explanation misleading or inncomplete?
rday
--
Robert P. J. Day
On Sun, 2 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Dec 02 2018, Robert P. J. Day wrote:
>
> > as part of an upcoming git class i'm delivering, i thought it
> > would be amusing to demonstrate the maximum length of colliding
> > SHA-1 prefixes in a repo
as part of an upcoming git class i'm delivering, i thought it would
be amusing to demonstrate the maximum length of colliding SHA-1
prefixes in a repository (in my case, i use the linux kernel git repo
for most of my examples).
is there a way to display the objects in the object database tha
so what is the difference?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/
would display exclusively
objects in the object store corresponding to objects that are suddenly
unreferenced due to the removal of a remote? i was just curious as it
would be neat to demo that in a class.
rday
--
Robert
. i have no idea
what relationship those packages have to official git, or who decides
what goes into them.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
On Tue, 26 Jun 2018, Jeff King wrote:
> On Tue, Jun 26, 2018 at 06:18:26AM -0400, Robert P. J. Day wrote:
>
> >
> > ENVIRONMENT
> > GIT_CONFIG
> > Take the configuration from the given file instead of
> > .git/config. Using
the use of what
are clearly the default files. thoughts?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
git admins can testify really make sense to set in a corporate
environment. does that make sense?
open to thoughts ...
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http:/
On Mon, 11 Jun 2018, Stefan Beller wrote:
> On Fri, Jun 8, 2018 at 10:15 AM Derrick Stolee wrote:
> >
> > On 6/8/2018 9:18 AM, Robert P. J. Day wrote:
> > >for one of my courses, i wanted to write a section about the
> > > various techniques for dealing
Signed-off-by: Robert P. J. Day
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index f466600972..30aad8396d 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -64,7 +64,7 @@ ifndef::git-format-patch[]
endif::git-format-patch
ol,safecrlf,autocrlf}
- i'm sure there are client-side hooks that can be mentioned
etc, etc.
has anyone ever written a doc that collects these things in one
place? if not, i guess i have to write one.
rday
--
============
Use the obvious consensus of hyphenated "remote-tracking branch", and
fix an obvious typo, all in documentation and comments.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 4a5cc38a6f..ef9d9d28a9 10
making it clear what
happens in this case. i see no value in supporting extra options that
simply encourage bad behaviour.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.c
n I run 'git rm path/to/some/file', I expect
> path/to/some/ to exist, *albeit untracked*.
again, why?
> I do NOT expect git to *track* empty directories. But I also do NOT
> expect it to remove untracked directories.
why not?
rday
--
======
On Wed, 6 Jun 2018, Thomas Fischer wrote:
> OVERVIEW
>
> "git rm" will remove more files than specified. This is either a bug or
> undocumented behavior (not in the man pages).
>
> SETUP
>
> 1. In a git repository, create an empty directory OR a chain of empty
> directories
>
> $ mkdir -p path/t
On Tue, 5 Jun 2018, SZEDER Gábor wrote:
> > Change deprecated "--set-upstream" branch option to
> > preferred "--set-upstream-to".
> >
> > Signed-off-by: Robert P. J. Day
> >
> > ---
> >
> > i'm assuming this should us
Change deprecated "--set-upstream" branch option to
preferred "--set-upstream-to".
Signed-off-by: Robert P. J. Day
---
i'm assuming this should use "--set-upstream-to" as do all the
others.
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 69
On Sun, 3 Jun 2018, Philip Oakley wrote:
> From: "Robert P. J. Day"
> > On Sun, 3 Jun 2018, Thomas Gummerer wrote:
> >> --get-regex works as the parse-option API allows abbreviations of
> >> the full option to be specified as long as the abbreviation is
>
On Mon, 4 Jun 2018, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > i realize that, when you "git stash push", stash graciously
> > saves the branch you were on as part of the commit message, but
> > does any subsequent stash operation tec
Fix single misspelling of $GITDIR to correct $GIT_DIR in a comment.
Signed-off-by: Robert P. J. Day
---
updated patch to clarify that the misspelling is only in a comment.
diff --git a/sha1-file.c b/sha1-file.c
index 555e780f4..695e5c627 100644
--- a/sha1-file.c
+++ b/sha1-file.c
@@ -610,7
uing, so no need to resend.
argh, i actually know that, i just screwed up.
> On 06/03, Robert P. J. Day wrote:
> >
> > Even though "--get-regex" appears to work with "git config", the
> > clear standard is to spell out the action in full.
>
> --ge
Fix single misspelling of $GITDIR to correct $GIT_DIR.
Signed-off-by: Robert P. J. Day
---
only occurrence in entire code base that i ran across, so i figured
might as well fix it.
diff --git a/sha1-file.c b/sha1-file.c
index 555e780f4..695e5c627 100644
--- a/sha1-file.c
+++ b/sha1-file.c
On Sun, 3 Jun 2018, SZEDER Gábor wrote:
>
>
> > On Fri, 1 Jun 2018, Jeff King wrote:
> >
> > > On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote:
> > > > ok, so how on earth would i use "git config" at the command line
> > &g
Even though "--get-regex" appears to work with "git config", the
clear standard is to spell out the action in full.
Signed-off-by: Robert P. J. Day
---
this is the only occurrence i saw of this in the entire code base, so
it seemed worth tweaking just for consistency.
Even though "--get-regex" appears to work with "git config", the
standard is to spell out the action in full.
Signed-off-by: Robert P. J. Day
---
this is the only occurrence i saw of this in the entire code base, so
it seemed worth tweaking just for consistency.
diff --
On Fri, 1 Jun 2018, Jeff King wrote:
> On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote:
... snip ...
> > ok, so how on earth would i use "git config" at the command line
> > to set a config variable with some arbitrary level of subsections?
> >
s
the commit that was the basis of that stash to create the new branch.
so, does any stash operation actually need the originating branch
name? (i'm guessing no, but i've been wrong before.)
rday
--
==============
On Fri, 1 Jun 2018, Jeff King wrote:
> On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote:
>
> > $ git config --global a.b.c.d.e rday
> >
> > huh ... seemed to work fine, and added this to my ~/.gitconfig:
> >
> > [a "b.c.d"]
> &g
restrictions as section names.
> This has been deprecated since 2011. Maybe it's time to finally get
> rid of it.
seven years seems sufficient for deprecation.
rday
--
============
Robert P. J. Day
ot at all obvious from
that Doc file, or from "man git-config".
and if a section name can contain periods, how would you specify
that at the command line?
rday
--
================
Robert P. J. Day
On Fri, 1 Jun 2018, Johannes Sixt wrote:
> Am 31.05.2018 um 19:27 schrieb Robert P. J. Day:
> > On Thu, 31 May 2018, Duy Nguyen wrote:
> >> git diff-index is "plumbing", designed for writing scripts. "git
> >> diff" on the other hand is for users and
On Thu, 31 May 2018, Duy Nguyen wrote:
> On Thu, May 31, 2018 at 6:38 PM, Robert P. J. Day
> wrote:
> >
> > was going over some hooks and writing some tutorials for some of
> > the commit-related, client-side hooks, and was wondering (perhaps
> > stupidly) why t
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
On Wed, 30 May 2018, Stefan Beller wrote:
> On Wed, May 30, 2018 at 4:39 AM, Robert P. J. Day
> wrote:
> >
> > willing to submit some patches to standardize the syntax of man
> > pages in terms of rendering "optional" and/or "replaceable"
> >
For consistency, use backquotes when referring to environment
variables, as is done in other man pages.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index b0abe2cb0..004944b3c 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation
Signed-off-by: Robert P. J. Day
---
i am simply assuming that that really should say "inconsistent"; if
it's actually correct, just toss this, of course.
diff --git a/builtin/config.c b/builtin/config.c
index 1e31aa9f8..11c9c501d 100644
--- a/builtin/config.c
+++ b/b
[] --add
... [] --replace-all []
and so on. is that the consensus? i wouldn't try to do it all at once,
maybe just a page at a time to not be too disruptive.
rday
--
================
Robert P. J. Day
am i missing any important features of hooks in the above?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
Signed-off-by: Robert P. J. Day
---
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 2542c5244..ec898f2c6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -117,7 +117,7 @@ static void copy_templates(const char *template_dir)
dir = opendir(template_path.buf
On Mon, 28 May 2018, Sitaram Chamarty wrote:
> On Mon, May 28, 2018 at 09:27:18AM -0400, Robert P. J. Day wrote:
>
> [snipped the rest because I really don't know]
>
> > more to the point, is that actually what the "update" hook does? i
> > just looke
w
#
# To enable this hook, rename this file to "update".
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
t; -- does a selection like that even merit a
"warning" if it's clear that's what i'm trying to do?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
also have to update those, or how does that work?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
ts use that phrase
interchangeably with "working tree", and i doubt that confusion is
ever going away. all one needs to do is:
$ grep -r "working directory" *
in the git code base to see its prevalence. so, what *should* it mean?
or is there any point in even t
Reword "man git-tag" to clarify that a tag can refer directly to an
arbitrary object, not just a commit object.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 1d17101ba..87c4288ff 100644
--- a/Documentation/git-tag
On Fri, 25 May 2018, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > embarrassed to admit i had no idea that you could tag non-commit
> > objects, only realized that when i was reading the man page and saw:
> >
> > SYNOPSIS
> >
On Thu, 24 May 2018, Stefan Beller wrote:
> On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day
> wrote:
> >
> > maybe this is deliberate, but it's confusing that, with git 2.17.0,
> > the output of both "git log -h" and "git show -h" is exactly
The standard for command documentation synopses appears to be:
[...] means optional
<...> means replaceable
[<...>] means both optional and replaceable
So fix a number of doc pages that use incorrect variations of the
above.
Signed-off-by: Robert P. J. Day
---
On Thu, 24 May 2018, Eric Sunshine wrote:
> On Thu, May 24, 2018 at 3:54 PM, Robert P. J. Day
> wrote:
> > The standard for command documentation synopses appears to be:
> >
> > [...] means optional
> > <...> means replaceable
> > [<...>] me
The standard for command documentation synopses appears to be:
[...] means optional
<...> means replaceable
[<...>] means both optional and replaceable
So fix a number of doc pages that use incorrect variations of the
above.
Signed-off-by: Robert P. J. Day
---
;? or is there more in the
man page that needs tweaking?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
ss line range n,m in file, counting from 1
$
is that what's *supposed* to happen?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://cr
sage: git diff [] [ []] [--] [...]
$
but should the man pages be updated similarly? i can whip up a patch
for that unless someone wants to comment on this further.
rday
--
============
Robert P. J. Day Ottawa
1 - 100 of 257 matches
Mail list logo
