* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-24 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: vda.linux, busybox, git
In-Reply-To: <7vocnxajj6.fsf@alter.siamese.dyndns.org>
On Fri, Oct 23, 2009 at 02:26:53PM -0700, Junio C Hamano wrote:
>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>
>> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>>on create, 'o' would be --old-archive.
>>>
>>>FYI this was prompted by:
>>>
>>>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>>>
>>>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>>>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>>>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>>>@@ -50,4 +50,4 @@ clean:
>>> install: all
>>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>>> (cd blt && $(TAR) cf - .) | \
>>>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>>
>> argh, sorry! --no-same-owner of course.
>
>Either way, your change would break non-GNU tar implementations that are
>properly POSIX.1, isn't it?
I suppose xf - -o would work?
^ permalink raw reply
* [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-10-24 9:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael J Gruber, Jonathan Nieder,
Felipe Contreras
This basically introduces the "getting started" section so users get familiar
with the configuration from the get-go, and also, most people prefer to teach
'git config --global' to setup the user name and email. Here are a few
examples:
git tutorial:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
GNOME:
http://live.gnome.org/Git/Developers
SourceForge:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
github:
http://help.github.com/git-email-settings/
v2:
Reworded the getting started section based on comments from Michael J Gruber,
Jonathan Nieder and Junio C Hamano.
Felipe Contreras (2):
user-manual: add global config section
user-manual: simplify the user configuration
Documentation/user-manual.txt | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-24 9:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael J Gruber, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1256377489-16719-1-git-send-email-felipe.contreras@gmail.com>
Comments from Michael J Gruber, Jonathan Nieder and Junio C Hamano.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..3fcbc36 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -40,6 +40,35 @@ without any explanation.
Finally, see <<todo>> for ways that you can help make this manual more
complete.
+[[getting-started]]
+Getting started
+=============
+
+Various configuration options affect how git operates. Some are specific to
+the user (e.g. if you prefer to see the output in colour), while some are
+specific to a repository (e.g. what other repositories it interacts with).
+
+For example, you can tell git to use color in the output of commands such as
+`git diff` by setting the `color.ui` option:
+------------------------------------------------
+$ git config --global color.ui auto
+------------------------------------------------
+
+Note that in this case the option is stored in the 'global' configuration. If
+you don't specify `--global`, then the option will be stored on the local
+(repository) configuration, which is probably not what you want.
+
+The options are stored in plain text files that you can view, or edit manually
+using the `--edit` option, and the format is very simple:
+------------------------------------------------
+$ git config --global --edit
+[color]
+ ui = auto
+------------------------------------------------
+
+This manual covers many configuration options (such as `color.ui`). For
+more details on the `git config` command, as well as all configuration
+options see linkgit:git-config[1].
[[repositories-and-branches]]
Repositories and Branches
--
1.6.5.1
^ permalink raw reply related
* [PATCH v2 2/2] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-10-24 9:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael J Gruber, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1256377489-16719-1-git-send-email-felipe.contreras@gmail.com>
This is shorter, avoids the burder to think about the format of the
configuration file, and git config is already used in other places in
the manual.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 3fcbc36..a0a75af 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1010,13 +1010,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.5.1
^ permalink raw reply related
* Re: confusion with git diff-tree output
From: Jeff King @ 2009-10-24 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Roundy, git
In-Reply-To: <7vvdi58fhw.fsf@alter.siamese.dyndns.org>
On Fri, Oct 23, 2009 at 11:36:59PM -0700, Junio C Hamano wrote:
> >> You're right. I figured I must be overlooking something obvious, and
> >> that was it. What surprised me was that -p implies -r, which is not
> >> documented. Since the -p output was recursive, I incorrectly presumed
> >> that this was the default.
> >
> > It's due to hysterical raisins:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/54078
>
> Just to make sure, the Porcelain "diff" does recurse even with --raw
> and "diff-tree" doesn't for historical reasons, right?
Yes, that's right (and yes, I just checked it to be double sure).
-Peff
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Andreas Schwab @ 2009-10-24 9:49 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <20091024091758.GF4615@mx.loc>
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
> On Fri, Oct 23, 2009 at 02:26:53PM -0700, Junio C Hamano wrote:
>>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>
>>> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>>>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>>>on create, 'o' would be --old-archive.
>>>>
>>>>FYI this was prompted by:
>>>>
>>>>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>>>>
>>>>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>>>>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>>>>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>>>>@@ -50,4 +50,4 @@ clean:
>>>> install: all
>>>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>>>> (cd blt && $(TAR) cf - .) | \
>>>>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>>>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>>>
>>> argh, sorry! --no-same-owner of course.
>>
>>Either way, your change would break non-GNU tar implementations that are
>>properly POSIX.1, isn't it?
>
> I suppose xf - -o would work?
Isn't that the same as 'xfo -'?
(tar isn't specified by POSIX, btw.)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Jakub Narebski @ 2009-10-24 9:56 UTC (permalink / raw)
To: Andreas Schwab
Cc: Bernhard Reutner-Fischer, Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m28wf1unop.fsf@whitebox.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>> On Fri, Oct 23, 2009 at 02:26:53PM -0700, Junio C Hamano wrote:
>>>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>>> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>>>> On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>>>>
>>>>>> GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>>>> on create, 'o' would be --old-archive.
>>>>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>>>>> (cd blt && $(TAR) cf - .) | \
>>>>> - (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>>>> + (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>>>>
>>>> argh, sorry! --no-same-owner of course.
>>>
>>> Either way, your change would break non-GNU tar implementations that are
>>> properly POSIX.1, isn't it?
>>
>> I suppose xf - -o would work?
>
> Isn't that the same as 'xfo -'?
>
> (tar isn't specified by POSIX, btw.)
I don't quite understand why 'o' has to be spelled using long name
--no-same-owner, instead of just correcting the ordering of "old style"
short options to have 'f' last, i.e.
$(TAR) xof -
and not (current)
$(TAR) xfo -
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-24 10:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m28wf1unop.fsf@whitebox.home>
On Sat, Oct 24, 2009 at 11:49:10AM +0200, Andreas Schwab wrote:
>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>
>> On Fri, Oct 23, 2009 at 02:26:53PM -0700, Junio C Hamano wrote:
>>>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>>
>>>> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>>>>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>>>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>>>>on create, 'o' would be --old-archive.
>>>>>
>>>>>FYI this was prompted by:
>>>>>
>>>>>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>>>>>
>>>>>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>>>>>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>>>>>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>>>>>@@ -50,4 +50,4 @@ clean:
>>>>> install: all
>>>>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>>>>> (cd blt && $(TAR) cf - .) | \
>>>>>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>>>>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>>>>
>>>> argh, sorry! --no-same-owner of course.
>>>
>>>Either way, your change would break non-GNU tar implementations that are
>>>properly POSIX.1, isn't it?
>>
>> I suppose xf - -o would work?
>
>Isn't that the same as 'xfo -'?
Not really (if you do not permute the arguments which we don't in
busybox, for size reasons).
f specifies the file so "fo" acts on file "o".
"xof -" would work for me as well as "xf - -o", it's just that
"xfo -" does not work.
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-24 10:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Schwab, Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m38wf1dsjf.fsf@localhost.localdomain>
On Sat, Oct 24, 2009 at 02:56:33AM -0700, Jakub Narebski wrote:
>Andreas Schwab <schwab@linux-m68k.org> writes:
>> Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>> On Fri, Oct 23, 2009 at 02:26:53PM -0700, Junio C Hamano wrote:
>>>>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>>>> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>>>>> On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>>>>>
>>>>>>> GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>>>>> on create, 'o' would be --old-archive.
>
>>>>>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>>>>>> (cd blt && $(TAR) cf - .) | \
>>>>>> - (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>>>>> + (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>>>>>
>>>>> argh, sorry! --no-same-owner of course.
>>>>
>>>> Either way, your change would break non-GNU tar implementations that are
>>>> properly POSIX.1, isn't it?
>>>
>>> I suppose xf - -o would work?
>>
>> Isn't that the same as 'xfo -'?
>>
>> (tar isn't specified by POSIX, btw.)
>
>I don't quite understand why 'o' has to be spelled using long name
>--no-same-owner, instead of just correcting the ordering of "old style"
It doesn't have to be, right.
>short options to have 'f' last, i.e.
>
> $(TAR) xof -
>
>and not (current)
>
> $(TAR) xfo -
any of "xf - -o" or "xof -" would work for me.
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Andreas Schwab @ 2009-10-24 10:06 UTC (permalink / raw)
To: Jakub Narebski
Cc: Bernhard Reutner-Fischer, Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m38wf1dsjf.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> I don't quite understand why 'o' has to be spelled using long name
> --no-same-owner, instead of just correcting the ordering of "old style"
> short options to have 'f' last, i.e.
>
> $(TAR) xof -
>
> and not (current)
>
> $(TAR) xfo -
Both do exactly the same, traditionally. Note the lack of '-' preceding
'xfo', which does not use getopt-style option parsing.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Andreas Schwab @ 2009-10-24 10:44 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <20091024100502.GG4615@mx.loc>
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
> On Sat, Oct 24, 2009 at 11:49:10AM +0200, Andreas Schwab wrote:
>>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>
>>> I suppose xf - -o would work?
>>
>>Isn't that the same as 'xfo -'?
>
> Not really (if you do not permute the arguments which we don't in
> busybox, for size reasons).
There is no argument permutation. The traditional argument parsing of
tar does not cluster option letters with option arguments.
Of course, just using 'xof -' will work around this busybox bug.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Nanako Shiraishi @ 2009-10-24 13:06 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Michael J Gruber, Jonathan Nieder
In-Reply-To: <1256377489-16719-1-git-send-email-felipe.contreras@gmail.com>
Quoting Felipe Contreras <felipe.contreras@gmail.com> writes:
> ...
> Reworded the getting started section based on comments from Michael J Gruber,
> Jonathan Nieder and Junio C Hamano.
I'm surprised that you ignored comments from the original
author of the document you are updating.
Date: Tue, 13 Oct 2009 22:49:40 -0400
Message-ID: <20091014024940.GB9700@fieldses.org>
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Andreas Schwab @ 2009-10-24 13:06 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m2ocnxt6jl.fsf@whitebox.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>
>> On Sat, Oct 24, 2009 at 11:49:10AM +0200, Andreas Schwab wrote:
>>>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>>>
>>>> I suppose xf - -o would work?
>>>
>>>Isn't that the same as 'xfo -'?
>>
>> Not really (if you do not permute the arguments which we don't in
>> busybox, for size reasons).
>
> There is no argument permutation. The traditional argument parsing of
> tar does not cluster option letters with option arguments.
>
> Of course, just using 'xof -' will work around this busybox bug.
Like this.
Andreas.
>From ebadb41b346c305b94f27e3bb787bf0ba6bb8a5b Mon Sep 17 00:00:00 2001
From: Andreas Schwab <schwab@linux-m68k.org>
Date: Sat, 24 Oct 2009 15:01:03 +0200
Subject: [PATCH] Work around option parsing bug in the busybox tar implementation
Traditionally the first argument of the tar command was interpreted a
bundle of letters specifying the mode of operation and additional options,
with any option arguments taken from subsequent words on the command line
as needed. The implementation of tar in busybox apparently treats this
bundle as if preceded by a dash and then parses it by getopt rules, which
mishandles 'tar xfo -'. Use 'tar xof -' instead which is parsed the same
way by both traditional tar implementations and busybox.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
templates/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/templates/Makefile b/templates/Makefile
index a12c6e2..408f013 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -50,4 +50,4 @@ clean:
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
--
1.6.5.1
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] Use fast-forward
From: Nanako Shiraishi @ 2009-10-24 13:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Michael J Gruber
In-Reply-To: <1256373092-15126-1-git-send-email-felipe.contreras@gmail.com>
Quoting Felipe Contreras <felipe.contreras@gmail.com>
> As suggested in the mailing list, now I've replaced all instances of 'fast
> forward' with 'fast-forward'.
I had an impression that the consensus from the previous
discussion was that there is no such consensus that this
is an improvement, because there isn't a clear-cut rule?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-10-24 14:08 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano, Michael J Gruber, Jonathan Nieder
In-Reply-To: <20091024220644.6117@nanako3.lavabit.com>
On Sat, Oct 24, 2009 at 4:06 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> ...
>> Reworded the getting started section based on comments from Michael J Gruber,
>> Jonathan Nieder and Junio C Hamano.
>
> I'm surprised that you ignored comments from the original
> author of the document you are updating.
I did not. His comment was that if we do this, it must be short, and
it is. If it's not, then it would be more productive to suggest ways
to trim it down.
> Date: Tue, 13 Oct 2009 22:49:40 -0400
> Message-ID: <20091014024940.GB9700@fieldses.org>
I've no way of figuring out what is that. Most people use a direct
link to a mail archive.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Björn Steinbrink @ 2009-10-24 14:14 UTC (permalink / raw)
To: Felipe Contreras
Cc: Nanako Shiraishi, git, Junio C Hamano, Michael J Gruber,
Jonathan Nieder
In-Reply-To: <94a0d4530910240708l7cb59b36s8d6ddebd4af48e7f@mail.gmail.com>
On 2009.10.24 17:08:06 +0300, Felipe Contreras wrote:
> On Sat, Oct 24, 2009 at 4:06 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> > Date: Tue, 13 Oct 2009 22:49:40 -0400
> > Message-ID: <20091014024940.GB9700@fieldses.org>
>
> I've no way of figuring out what is that. Most people use a direct
> link to a mail archive.
Having the Message-ID is quite useful, so you can search your local mbox
to find the right message. You can also use gmane's Message-ID search:
http://mid.gmane.org/message_id_here
So: http://mid.gmane.org/20091014024940.GB9700@fieldses.org
Björn
^ permalink raw reply
* Re: [PATCH] Use fast-forward
From: Felipe Contreras @ 2009-10-24 14:17 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano, Michael J Gruber
In-Reply-To: <20091024220709.6117@nanako3.lavabit.com>
On Sat, Oct 24, 2009 at 4:07 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Felipe Contreras <felipe.contreras@gmail.com>
>
>> As suggested in the mailing list, now I've replaced all instances of 'fast
>> forward' with 'fast-forward'.
>
> I had an impression that the consensus from the previous
> discussion was that there is no such consensus that this
> is an improvement, because there isn't a clear-cut rule?
I don't think anyone wants to preserve the current inconsistent use,
and I haven't seen arguments in favor of 'fast forward' either. My
understanding was that the comments were in favor of 'fast-forward'
but making it consistent across the code-base:
http://marc.info/?l=git&m=125532404330701&w=2
http://marc.info/?l=git&m=125535210203730&w=2
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-10-24 14:22 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Nanako Shiraishi, git, Junio C Hamano, Michael J Gruber,
Jonathan Nieder
In-Reply-To: <20091024141445.GA2078@atjola.homenet>
2009/10/24 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.10.24 17:08:06 +0300, Felipe Contreras wrote:
>> On Sat, Oct 24, 2009 at 4:06 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> > Date: Tue, 13 Oct 2009 22:49:40 -0400
>> > Message-ID: <20091014024940.GB9700@fieldses.org>
>>
>> I've no way of figuring out what is that. Most people use a direct
>> link to a mail archive.
>
> Having the Message-ID is quite useful, so you can search your local mbox
> to find the right message.
I don't have a local mbox, and I suspect I'm not the only one.
> You can also use gmane's Message-ID search:
> http://mid.gmane.org/message_id_here
That's a nice trick, but then using the following link would serve
exactly the same purpose, wouldn't it?
> So: http://mid.gmane.org/20091014024940.GB9700@fieldses.org
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: David Roundy @ 2009-10-24 14:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Nanako Shiraishi, Avery Pennarun,
Alex Riesen, git, Jay Soffian
In-Reply-To: <7vzl7h8fjp.fsf@alter.siamese.dyndns.org>
On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> My take on it:
>>
>> 1) --no-porcelain
>>
>> 2) we all are bike-shedding, not being constructive at all
>
> You are right about (2), regarding the option name. I've queued one that
> uses --no-guess.
Perhaps a universal --plumbing flag would be handy? It'd be nice to be
able to pass any command --plumbing and it'll either behave in a
stable, predictable, plumbing-like way, or die with an error message
stating that it isn't a plumbing command. Right now, it's sort of
hard to figure out what is plumbing and what is porcelain. Some
commands are clear, but other commands labelled as plumbing in git(1)
are deprecated in favor of commands labelled as porcelain.
David
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-24 17:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber
In-Reply-To: <1256373092-15126-2-git-send-email-felipe.contreras@gmail.com>
Is this meant to replace the previous one that is already queued: a0c0ecb
(user-manual: use 'fast-forward', 2009-10-11)?
It seems that these mostly match a mechanical token replacement
"s/([fF])ast forward/$1ast-forward/g" in the Documentation area,
but I suspect there may be some manual fixes.
Token-replace is much harder to review than to produce, as the result of
such mechanical substitution needs to be examined to see if each change
makes sense individually.
I suspect the patch would have been much easier to the reviewers it it
stated somewhere in the log message:
(1) how the mechanical change was produced;
(2) what criteria was used to choose between leaving the mechanical
change as-is and rewording them manually; and
(3) where these non-mechanical changes are.
Here are the list of paths I looked at (during this sitting which did
not go til the end of the patch):
> diff --git a/Documentation/config.txt b/Documentation/config.txt
OK
> diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
OK
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
OK, except for two hunks below I am not absolutely sure.
> @@ -60,7 +60,7 @@ EXAMPLES below for details.
> Pushing an empty <src> allows you to delete the <dst> ref from
> the remote repository.
> +
> -The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
> +The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)
> directs git to push "matching" branches: for every branch that exists on
> the local side, the remote side is updated if a branch of the same name
> already exists on the remote side. This is the default operation mode
Hmm, is non-fast-forward a yet another compound word?
> @@ -342,9 +342,9 @@ git push origin :experimental::
Likewise.
> diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
> diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
> diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
> diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
OK, except for this hunk I am not sure about.
> @@ -2115,7 +2115,7 @@ $ git checkout release && git pull
>
> Important note! If you have any local changes in these branches, then
> this merge will create a commit object in the history (with no local
> -changes git will simply do a "Fast forward" merge). Many people dislike
> +changes git will simply do a fast-forward merge). Many people dislike
> the "noise" that this creates in the Linux history, so you should avoid
> doing this capriciously in the "release" branch, as these noisy commits
> will become part of the permanent history when you ask Linus to pull
It may be Ok not to emphasize this word but that is not about "fast
forward" vs "fast-forward". It is more about "in this context, this word
does not have to be emphasized" kind of copy-editing which does not have
to be limited to the case where the "word" is 'fast-forward'.
It is my policy not to look at one patch for more than 30 minutes in one
sitting, because I'll get sloppier toward the end, so I'll stop here for
now. Help in reviewing the rest is appreciated.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-10-24 17:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Michael J Gruber, Jonathan Nieder
In-Reply-To: <1256377489-16719-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Reworded the getting started section based on comments from Michael J Gruber,
> Jonathan Nieder and Junio C Hamano.
Hmm, I thought JBF also had some input...
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-10-24 18:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git, Michael J Gruber, Jonathan Nieder
In-Reply-To: <7vy6n065os.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Reworded the getting started section based on comments from Michael J Gruber,
>> Jonathan Nieder and Junio C Hamano.
>
> Hmm, I thought JBF also had some input...
Ah, nevermind. Yes, he did have input, and I tend to agree with him, and
more importantly trust his judgement on the manual.
I think a "Getting started" section that only covers "git config" looks
way out of place in the beginning of this document.
Manuals by other people that teach "here is how you would do a hello-world
repository" would want to teach user.name before reaching that point, but
because the user-manual is written in such a way that it first introduces
concepts to understand what is going on without changing anything, we do
not have much need user.name until it gets to "Developing with git"
section.
"Many people prefer to teach it this way" does not justify "everybody must
teach it this way" an iota, when teaching "config user.name" upfront will
fit the flow of how they teach but does not fit the flow of how this
manual teaches [*1*].
I'm inclined to to discard the first patch.
The point of the original text the second patch touches was to show how
simple the contents of the configuration file is and give the users that
there is nothing magic there. While I do not like the second patch as-is,
because it destroys that nice property and treats the end users mindless
"cut-and-paste without thinking" sheeples, I think that it is rather vague
and unhelpful to the current target audience to say:
... The easiest way to do so is to make sure the following lines
appear in a file named .gitconfig in your home directory:
and the parts can use some improvement. For example, "home directory"
does not hold true for people on platforms that lack the concept. Keeping
the current "the following lines appear", rewording "in a file named
.gitconfig in your home directory" with "in your per-user configuration
file", keeping the display that shows how the config snippet should look
like, and using "config --global -e" might be a better approach.
[Footnote]
*1* Unless you are changing the flow of how this manual teaches at the
same time, that is. And no, I am not suggesting that we should start from
"let's do a hello-world repository from scratch". I think the current
"start from read-only and then learn how to grow history later" is one
valid way to teach.
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Felipe Contreras @ 2009-10-24 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael J Gruber
In-Reply-To: <7v3a587kc2.fsf@alter.siamese.dyndns.org>
On Sat, Oct 24, 2009 at 8:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Is this meant to replace the previous one that is already queued: a0c0ecb
> (user-manual: use 'fast-forward', 2009-10-11)?
Yes.
> It seems that these mostly match a mechanical token replacement
> "s/([fF])ast forward/$1ast-forward/g" in the Documentation area,
> but I suspect there may be some manual fixes.
>
> Token-replace is much harder to review than to produce, as the result of
> such mechanical substitution needs to be examined to see if each change
> makes sense individually.
I manually replaced each instance, and reviewed the patch myself. Most
of the changes are essentially the same, except a few instances:
"Fast forward" -> fast-forward
Fast Forward Only -> Fast-forward Only
> I suspect the patch would have been much easier to the reviewers it it
> stated somewhere in the log message:
>
> (1) how the mechanical change was produced;
There wasn't such.
> (2) what criteria was used to choose between leaving the mechanical
> change as-is and rewording them manually; and
If it wasn't straight forward. I considered the following straightforward:
fast forward -> fast-forward
fast forwarded -> fast-forwarded
fast forwarding -> fast-forwarding
fast forwardable -> fast-forwardable
non-fast forward -> non-fast-forward
Fast forward -> Fast-forward
Fast forwarding -> Fast-forwarding
> (3) where these non-mechanical changes are.
Mentioned on the second comment.
> Here are the list of paths I looked at (during this sitting which did
> not go til the end of the patch):
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>
> OK
>
>> diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
>
> OK
>
>> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
>
> OK, except for two hunks below I am not absolutely sure.
>
>> @@ -60,7 +60,7 @@ EXAMPLES below for details.
>> Pushing an empty <src> allows you to delete the <dst> ref from
>> the remote repository.
>> +
>> -The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
>> +The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)
>> directs git to push "matching" branches: for every branch that exists on
>> the local side, the remote side is updated if a branch of the same name
>> already exists on the remote side. This is the default operation mode
>
> Hmm, is non-fast-forward a yet another compound word?
Yes. AFAIK.
>> @@ -342,9 +342,9 @@ git push origin :experimental::
>
> Likewise.
>
>> diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
>> diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
>> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
>> diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
>> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
>> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
>> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
>> diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
>> diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
>> diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>
> OK, except for this hunk I am not sure about.
>
>> @@ -2115,7 +2115,7 @@ $ git checkout release && git pull
>>
>> Important note! If you have any local changes in these branches, then
>> this merge will create a commit object in the history (with no local
>> -changes git will simply do a "Fast forward" merge). Many people dislike
>> +changes git will simply do a fast-forward merge). Many people dislike
>> the "noise" that this creates in the Linux history, so you should avoid
>> doing this capriciously in the "release" branch, as these noisy commits
>> will become part of the permanent history when you ask Linus to pull
>
> It may be Ok not to emphasize this word but that is not about "fast
> forward" vs "fast-forward". It is more about "in this context, this word
> does not have to be emphasized" kind of copy-editing which does not have
> to be limited to the case where the "word" is 'fast-forward'.
I couldn't parse that. From what I can see "Fast forward" was
emphasized because the author thought the words didn't make much sense
separated. Now that the word is fast-forward, there's no need to
emphasize.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Junio C Hamano @ 2009-10-24 19:25 UTC (permalink / raw)
To: Andreas Schwab
Cc: Bernhard Reutner-Fischer, Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m2ocnxuej2.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Like this.
Yeah, correct and it beautifly explains the issue. Thanks.
>>From ebadb41b346c305b94f27e3bb787bf0ba6bb8a5b Mon Sep 17 00:00:00 2001
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 24 Oct 2009 15:01:03 +0200
> Subject: [PATCH] Work around option parsing bug in the busybox tar implementation
>
> Traditionally the first argument of the tar command was interpreted a
> bundle of letters specifying the mode of operation and additional options,
> with any option arguments taken from subsequent words on the command line
> as needed. The implementation of tar in busybox apparently treats this
> bundle as if preceded by a dash and then parses it by getopt rules, which
> mishandles 'tar xfo -'. Use 'tar xof -' instead which is parsed the same
> way by both traditional tar implementations and busybox.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
> ---
> templates/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/templates/Makefile b/templates/Makefile
> index a12c6e2..408f013 100644
> --- a/templates/Makefile
> +++ b/templates/Makefile
> @@ -50,4 +50,4 @@ clean:
> install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
> (cd blt && $(TAR) cf - .) | \
> - (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
> + (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
> --
> 1.6.5.1
>
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
^ permalink raw reply
* Re: [PATCH] add tests for git diff --submodule
From: Junio C Hamano @ 2009-10-24 19:25 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <4AE192AD.70603@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Apart from your changes necessary to make the test run again my changes are:
>
> - rename from "t4041-diff-submodule-summary.sh" to "t4041-diff-submodule.sh"
> - corrected all comments still speaking of "summary"
> - added tests to test the behaviour of "--submodule" and "--submodule=short"
Thanks for a nice summary.
^ 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