Hi,
[if you comment on just a small portion of the text, could you please
quote only that? Thank you]
On Wed, 4 Jul 2007, Frank Lichtenheld wrote:
> General note: All the stuff in all uppercase should probably also
> have some asciidoc emphasis.
I do not understand. I grepped through all the docs for uppercase words
emphasized in any way, and could not find one.
> On Tue, Jul 03, 2007 at 05:47:44PM +0100, Johannes Schindelin wrote:
>
> > +Note that since this operation is extensively I/O expensive, it might
> > +be a good idea to redirect the temporary directory it off-disk, e.g. on
> ^^^^^^
> The "it" probably doesn't belong there.
Right.
> > +The filters are applied in the order as listed below. The <command>
> > +argument is always evaluated in shell using the 'eval' command.
> > +The $GIT_COMMIT environment variable is permanently set to contain
> ^^^^^^^^^^^
> I find the use of this word in this context odd and a little confusing.
> Maybe better "always" or "each time"?
How about
Prior to that, the $GIT_COMMIT environment variable will be set to
contain the id of the commit being rewritten.
> > +the id of the commit being rewritten. The author/committer environment
> > +variables are set before the first filter is run.
>
> Maybe give the actual names of the environment variables here?
If you think so:
Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE,
GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and GIT_COMMITTER_DATE is
set according to the current commit.
> > + is then used as-is (new files are auto-added, disappeared files
> > + are auto-removed - .gitignore files nor any other ignore rules
> > + HAVE NO EFFECT!).
>
> Is "nor" correct here? Not just "or"?
Do you like
neither .gitignore files nor any other ignore rules HAVE ANY
EFFECT!
> [...]
> > +--subdirectory-filter <directory>::
> > + Only regard the history, as seen by the given subdirectory. The
> ^^^
> Does this comma belong there?
This is my bad English. What I meant was this:
Only ever look at the history, which touches the given
subdirectory. The result will contain that directory as its
project root.
> > +-------------------------------------------------------------------------------
> > +git filter-branch --index-filter 'git update-index --remove filename' newbranch
> > +-------------------------------------------------------------------------------
>
> Even if your code goes beyond 80 chars, the surrounding "---" doesn't
> have to and makes it even harder to read when reading the original
> asciidoc text.
I personally read the .txt files, and use asciidoc only when I am forced
to. So it makes a difference for me.
> > +----------------------------------------------------------------------
> > +git filter-branch --parent-filter sed\ 's/^$/-p <graft-id>/' newbranch
> > +----------------------------------------------------------------------
>
> Wouldn't have 'sed s/^$/-p <graft-id>/' exactly the same effect, since
> the quotes are interpreted by the original shell anyway and not the
> filter shell? Just wondering why it uses such a complicated way to
> express it.
Probably not. Since the shell would interpret "s/^$/-p" and "<graft-id>/"
as two arguments to sed.
Besides, like Pasky, I am used to quote the argument, and not the whole
line, that's why the line is still there as it is.
Thanks,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
