All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] howto: Use all-space indentation in ASCII art
@ 2013-07-15 16:46 Dirk Wallenstein
  2013-07-15 22:00 ` Junio C Hamano
  0 siblings, 1 reply; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-15 16:46 UTC (permalink / raw)
  To: git; +Cc: Nanako Shiraishi, Thomas Ackermann

Keep the sketch aligned independent of the tabstop width used.

Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
---
 Documentation/howto/revert-a-faulty-merge.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 075418e..4b75bfc 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like
 this:
 
  ---o---o---o---M---x---x---W
-	       /
+               /
        ---A---B
 
 where A and B are on the side development that was not so good, M is the
@@ -47,7 +47,7 @@ After the developers of the side branch fix their mistakes, the history
 may look like this:
 
  ---o---o---o---M---x---x---W---x
-	       /
+               /
        ---A---B-------------------C---D
 
 where C and D are to fix what was broken in A and B, and you may already
@@ -81,7 +81,7 @@ In such a situation, you would want to first revert the previous revert,
 which would make the history look like this:
 
  ---o---o---o---M---x---x---W---x---Y
-	       /
+               /
        ---A---B-------------------C---D
 
 where Y is the revert of W.  Such a "revert of the revert" can be done
@@ -93,14 +93,14 @@ This history would (ignoring possible conflicts between what W and W..Y
 changed) be equivalent to not having W nor Y at all in the history:
 
  ---o---o---o---M---x---x-------x----
-	       /
+               /
        ---A---B-------------------C---D
 
 and merging the side branch again will not have conflict arising from an
 earlier revert and revert of the revert.
 
  ---o---o---o---M---x---x-------x-------*
-	       /                       /
+               /                       /
        ---A---B-------------------C---D
 
 Of course the changes made in C and D still can conflict with what was
@@ -111,13 +111,13 @@ faulty A and B, and redone the changes on top of the updated mainline
 after the revert, the history would have looked like this:
 
  ---o---o---o---M---x---x---W---x---x
-	       /                 \
+               /                 \
        ---A---B                   A'--B'--C'
 
 If you reverted the revert in such a case as in the previous example:
 
  ---o---o---o---M---x---x---W---x---x---Y---*
-	       /                 \         /
+               /                 \         /
        ---A---B                   A'--B'--C'
 
 where Y is the revert of W, A' and B' are rerolled A and B, and there may
@@ -129,7 +129,7 @@ lot of overlapping changes that result in conflicts.  So do not do "revert
 of revert" blindly without thinking..
 
  ---o---o---o---M---x---x---W---x---x
-	       /                 \
+               /                 \
        ---A---B                   A'--B'--C'
 
 In the history with rebased side branch, W (and M) are behind the merge
-- 
1.8.3.2.50.g531c8dd

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-15 16:46 [PATCH] howto: Use all-space indentation in ASCII art Dirk Wallenstein
@ 2013-07-15 22:00 ` Junio C Hamano
  2013-07-16  8:24   ` Dirk Wallenstein
  0 siblings, 1 reply; 16+ messages in thread
From: Junio C Hamano @ 2013-07-15 22:00 UTC (permalink / raw)
  To: Dirk Wallenstein; +Cc: git, Nanako Shiraishi, Thomas Ackermann

Dirk Wallenstein <halsmit@t-online.de> writes:

> Keep the sketch aligned independent of the tabstop width used.

Thanks.

This is a source text to be formatted into HTML, isn't it?

In our sources, a HT indents to multiple of 8 columns.  As long as
the output HTML produced from the source can be seen on a terminal
with any tab-width correctly, I do not see any reason to apply this
patch.

Am I missing something???

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-15 22:00 ` Junio C Hamano
@ 2013-07-16  8:24   ` Dirk Wallenstein
  2013-07-16 17:13     ` Junio C Hamano
  2013-07-16 18:26     ` [PATCH] howto: Use all-space indentation in ASCII art Jonathan Nieder
  0 siblings, 2 replies; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-16  8:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nanako Shiraishi, Thomas Ackermann

On Mon, Jul 15, 2013 at 03:00:17PM -0700, Junio C Hamano wrote:
> Dirk Wallenstein <halsmit@t-online.de> writes:
> 
> > Keep the sketch aligned independent of the tabstop width used.
> 
> Thanks.
> 
> This is a source text to be formatted into HTML, isn't it?
> 
> In our sources, a HT indents to multiple of 8 columns.  As long as
> the output HTML produced from the source can be seen on a terminal
> with any tab-width correctly, I do not see any reason to apply this
> patch.
> 
> Am I missing something???
> 

Those text files are installed as documentation (at least on my distribution).
They have a *.txt suffix, which tells me that they are meant to be read.  If those
would ever be opened with a text editor where the user has set the default
tabstop width to something other than 8 it would teach something nonsensical.
Not to mention if those files would have been printed with the wrong setting.

Why would you want to limit those files to be source for HTML only?

The HTML after this patch is still fine.

-- 
Cheers,
  Dirk

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-16  8:24   ` Dirk Wallenstein
@ 2013-07-16 17:13     ` Junio C Hamano
  2013-07-16 18:01       ` Dirk Wallenstein
  2013-07-16 18:26     ` [PATCH] howto: Use all-space indentation in ASCII art Jonathan Nieder
  1 sibling, 1 reply; 16+ messages in thread
From: Junio C Hamano @ 2013-07-16 17:13 UTC (permalink / raw)
  To: Dirk Wallenstein; +Cc: git, Nanako Shiraishi, Thomas Ackermann

> Why would you want to limit those files to be source for HTML only?
>
> The HTML after this patch is still fine.

Have you thought the reason why the formatted result _before_ the patch is good?

These *.txt files are asciidoc formatted source files. They are meant
to be easy to read and edit without distracting mark-ups (unlike roff
and html), but with one big precondition: your tab-width ought to be
8. That is how asciidoc expands the tab when producing the formatted
output, and that is why the formatted result _before_ the patch is
good.

Expanding these tabs to all spaces do not buy us anything, other than
source code bloat, and with one downside.

It would give a false impression that it somehow is OK to open these
*.txt files with a wrong tab-width setting, and even worse, edit them.
You may even type a new tab yourself to indent by 4 places, and
formatted result will be broken by such a person.

It would signal that your tab-width setting is not suitable to
view/edit these files if the elements in the illustration do not line
up. View it as a bonus safety feature ;-)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-16 17:13     ` Junio C Hamano
@ 2013-07-16 18:01       ` Dirk Wallenstein
  2013-07-31 16:54         ` [PATCH 0/2] Remove tabs from howto documents Dirk Wallenstein
       [not found]         ` <cover.1375288760.git.halsmit@t-online.de>
  0 siblings, 2 replies; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-16 18:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nanako Shiraishi, Thomas Ackermann

On Tue, Jul 16, 2013 at 10:13:28AM -0700, Junio C Hamano wrote:
> > Why would you want to limit those files to be source for HTML only?
> >
> > The HTML after this patch is still fine.
> 
> Have you thought the reason why the formatted result _before_ the patch is good?
No, as I said, *.txt suffixes tell me there is text in there and not
source code.  But what is more important is that they are installed (by
Git) as is (obviously) into share/doc.  I'm happy to learn about the
conversion through these posts, but the installation is flawed.

> These *.txt files are asciidoc formatted source files. They are meant
> to be easy to read and edit without distracting mark-ups (unlike roff
> and html), but with one big precondition: your tab-width ought to be
> 8. That is how asciidoc expands the tab when producing the formatted
> output, and that is why the formatted result _before_ the patch is
> good.
asciidoc replaces the other spaces in the sketch with spaces in the
result.  Hard to believe it stops doing that if it is accidentally a
sequence of 8 spaces.  And spaces are invisible by design.  Whitespace
only distracts if it leads to a wrong result.
> 
> Expanding these tabs to all spaces do not buy us anything, other than
> source code bloat, and with one downside.
Correctness maybe, if you open them in an editor to read them.  Imagine
the code bloat when the installation procedure expands the tabs so that
the final installation is correct.

> It would give a false impression that it somehow is OK to open these
> *.txt files with a wrong tab-width setting, and even worse, edit them.
> You may even type a new tab yourself to indent by 4 places, and
> formatted result will be broken by such a person.
Luckily there are whitespace checks for mixed space and/or tab-indent.
The right approach would probably be to have no tabs indent in any of
these files.  I'm happy to assist ;)
> 
> It would signal that your tab-width setting is not suitable to
> view/edit these files if the elements in the illustration do not line
> up. View it as a bonus safety feature ;-)
gitattributes could solve that much more reliable if there wasn't any
tab indentation allowed.

In the end, this is installed as documentation with a requirement on the
tab-width of any reader application used.  The easiest and most foolproof
solution without introducing errors is to simply expand these tabs.
Again, the current installation is flawed.

-- 
Cheers,
  Dirk

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-16  8:24   ` Dirk Wallenstein
  2013-07-16 17:13     ` Junio C Hamano
@ 2013-07-16 18:26     ` Jonathan Nieder
  2013-07-16 18:38       ` Dirk Wallenstein
  2013-07-16 18:42       ` A Large Angry SCM
  1 sibling, 2 replies; 16+ messages in thread
From: Jonathan Nieder @ 2013-07-16 18:26 UTC (permalink / raw)
  To: Dirk Wallenstein; +Cc: Junio C Hamano, git, Nanako Shiraishi, Thomas Ackermann

Dirk Wallenstein wrote:

> Those text files are installed as documentation (at least on my distribution).

That's probably a distribution bug (or a git makefile bug, depending
on how you look at it).  It would be better to ship the HTML
documentation, converted to text, instead of keeping the version with
markup including occasional random \ signs, linkgit:, ``, etc.

What distribution do you use?  (As maintainer of packaging for a Linux
distro, I know at least one that is guilty of this.)

Thanks,
Jonathan

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-16 18:26     ` [PATCH] howto: Use all-space indentation in ASCII art Jonathan Nieder
@ 2013-07-16 18:38       ` Dirk Wallenstein
  2013-07-16 18:42       ` A Large Angry SCM
  1 sibling, 0 replies; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-16 18:38 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Junio C Hamano, git, Nanako Shiraishi, Thomas Ackermann

On Tue, Jul 16, 2013 at 11:26:27AM -0700, Jonathan Nieder wrote:
> Dirk Wallenstein wrote:
> 
> > Those text files are installed as documentation (at least on my distribution).
> 
> That's probably a distribution bug (or a git makefile bug, depending
> on how you look at it).  It would be better to ship the HTML
> documentation, converted to text, instead of keeping the version with
> markup including occasional random \ signs, linkgit:, ``, etc.
They are also installed if I only use Git's makefile.
> 
> What distribution do you use?  (As maintainer of packaging for a Linux
> distro, I know at least one that is guilty of this.)

Ubuntu.
As an aside, I had to run manual creation as root.  Otherwise it did hang
(XMLTO).  Is that an Ubuntu bug?  Sorry, just because you seem to know
about this.

-- 
Cheers,
  Dirk

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] howto: Use all-space indentation in ASCII art
  2013-07-16 18:26     ` [PATCH] howto: Use all-space indentation in ASCII art Jonathan Nieder
  2013-07-16 18:38       ` Dirk Wallenstein
@ 2013-07-16 18:42       ` A Large Angry SCM
  1 sibling, 0 replies; 16+ messages in thread
From: A Large Angry SCM @ 2013-07-16 18:42 UTC (permalink / raw)
  To: Jonathan Nieder
  Cc: Dirk Wallenstein, Junio C Hamano, git, Nanako Shiraishi,
	Thomas Ackermann

>
>> Those text files are installed as documentation (at least on my distribution).
>
> That's probably a distribution bug (or a git makefile bug, depending
> on how you look at it).  It would be better to ship the HTML
> documentation, converted to text, instead of keeping the version with
> markup including occasional random \ signs, linkgit:, ``, etc.
>
> What distribution do you use?  (As maintainer of packaging for a Linux
> distro, I know at least one that is guilty of this.)
>

 From the AcsiiDoc Home Page:

=begin quote=
You write an AsciiDoc document the same way you would write a normal 
text document, there are no markup tags or weird format notations. 
AsciiDoc files are designed to be viewed, edited and printed directly or 
translated to other presentation formats using the asciidoc(1) command.
=end quote=

So, the asciidoc "source" files should be readable in their unprocessed 
form. And, not using tabs in ASCII art doesn't appear to have any downside.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH 0/2] Remove tabs from howto documents
  2013-07-16 18:01       ` Dirk Wallenstein
@ 2013-07-31 16:54         ` Dirk Wallenstein
  2013-07-31 17:01           ` Fredrik Gustafsson
       [not found]         ` <cover.1375288760.git.halsmit@t-online.de>
  1 sibling, 1 reply; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-31 16:54 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Thomas Ackermann

I really think that tabs are generally bad here.  So, this will
remove all tabs from the howto folder and prevent indenting with tabs
through gitattributes.

Dirk Wallenstein (2):
  howto: Suppress indentation with tabs
  howto: Eliminate all tabs

 Documentation/howto/.gitattributes                 |  1 +
 .../howto/rebase-from-internal-branch.txt          |  8 ++--
 Documentation/howto/rebuild-from-update-hook.txt   |  4 +-
 .../howto/recover-corrupted-blob-object.txt        | 50 +++++++++++-----------
 Documentation/howto/revert-a-faulty-merge.txt      | 16 +++----
 Documentation/howto/revert-branch-rebase.txt       |  2 +-
 Documentation/howto/update-hook-example.txt        |  8 ++--
 Documentation/howto/use-git-daemon.txt             | 10 ++---
 8 files changed, 50 insertions(+), 49 deletions(-)
 create mode 100644 Documentation/howto/.gitattributes

-- 
1.8.3.3.2.g85103ba

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH 1/2] howto: Suppress indentation with tabs
       [not found]         ` <cover.1375288760.git.halsmit@t-online.de>
@ 2013-07-31 16:54           ` Dirk Wallenstein
       [not found]           ` <4d37bfa3326469ab5b7cdbf0018f7aa671c2d74a.1375288760.git.halsmit@t-online.de>
  1 sibling, 0 replies; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-31 16:54 UTC (permalink / raw)
  To: git; +Cc: junio, Thomas Ackermann

The AsciiDoc files in the 'howto' folder are installed as documentation
and AsciiDoc files are meant to be read and printed as is.  To quote the
AsciiDoc Home Page:

    AsciiDoc files are designed to be viewed, edited and printed
    directly or translated to other presentation formats using the
    asciidoc(1) command.

Tabs have the property of a configurable width and can thereby skew the
layout of a page and distort the meaning.  This is particularly a
problem when mixing lines with different indentation (space vs tab) in
code examples and ASCII art.

Prevent such a mix-up by prohibiting tab indentation entirely.

Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
---
 Documentation/howto/.gitattributes | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 Documentation/howto/.gitattributes

diff --git a/Documentation/howto/.gitattributes b/Documentation/howto/.gitattributes
new file mode 100644
index 0000000..fecc113
--- /dev/null
+++ b/Documentation/howto/.gitattributes
@@ -0,0 +1 @@
+* whitespace=tab
-- 
1.8.3.3.2.g85103ba

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH 2/2] howto: Eliminate all tabs
       [not found]           ` <4d37bfa3326469ab5b7cdbf0018f7aa671c2d74a.1375288760.git.halsmit@t-online.de>
@ 2013-07-31 16:54             ` Dirk Wallenstein
  2013-07-31 17:03               ` Junio C Hamano
  0 siblings, 1 reply; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-31 16:54 UTC (permalink / raw)
  To: git; +Cc: junio, Thomas Ackermann

Because tabs have a variable width, the layout can diverge from what the
author intended.  Replace all tabs with spaces to the next column that
is a multiple of 8.

This fixes several ascii art sketches and a code example where viewing
it with a tab-width other than 8 lead to wrong indentation.

Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
---
 .../howto/rebase-from-internal-branch.txt          |  8 ++--
 Documentation/howto/rebuild-from-update-hook.txt   |  4 +-
 .../howto/recover-corrupted-blob-object.txt        | 50 +++++++++++-----------
 Documentation/howto/revert-a-faulty-merge.txt      | 16 +++----
 Documentation/howto/revert-branch-rebase.txt       |  2 +-
 Documentation/howto/update-hook-example.txt        |  8 ++--
 Documentation/howto/use-git-daemon.txt             | 10 ++---
 7 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index 19ab604..aefe5b1 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -1,8 +1,8 @@
-From:	Junio C Hamano <gitster@pobox.com>
-To:	git@vger.kernel.org
-Cc:	Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
+From:Junio C Hamano <gitster@pobox.com>
+To:     git@vger.kernel.org
+Cc:     Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
 Subject: Re: sending changesets from the middle of a git tree
-Date:	Sun, 14 Aug 2005 18:37:39 -0700
+Date:   Sun, 14 Aug 2005 18:37:39 -0700
 Abstract: In this article, JC talks about how he rebases the
  public "pu" branch using the core Git tools when he updates
  the "master" branch, and how "rebase" works.  Also discussed
diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt
index 25378f6..97365ff 100644
--- a/Documentation/howto/rebuild-from-update-hook.txt
+++ b/Documentation/howto/rebuild-from-update-hook.txt
@@ -19,8 +19,8 @@ when I took over Git maintainership from Linus.
 
 The directories relevant to this how-to are these two:
 
-    /pub/scm/git/git.git/	The public Git repository.
-    /pub/software/scm/git/docs/	The HTML documentation page.
+    /pub/scm/git/git.git/       The public Git repository.
+    /pub/software/scm/git/docs/ The HTML documentation page.
 
 So I made a repository to generate the documentation under my
 home directory over there.
diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt
index 1b3b188..6a8cc49 100644
--- a/Documentation/howto/recover-corrupted-blob-object.txt
+++ b/Documentation/howto/recover-corrupted-blob-object.txt
@@ -62,22 +62,22 @@ we now know which tree points to it!
 
 Now you can do
 
-	git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+        git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
 
 which will show something like
 
-	100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8    .gitignore
-	100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883    .mailmap
-	100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c    COPYING
-	100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453    CREDITS
-	040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6    Documentation
-	100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32    Kbuild
-	100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9    MAINTAINERS
-	...
+        100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8    .gitignore
+        100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883    .mailmap
+        100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c    COPYING
+        100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453    CREDITS
+        040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6    Documentation
+        100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32    Kbuild
+        100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9    MAINTAINERS
+        ...
 
 and you should now have a line that looks like
 
-	10064 blob 4b9458b3786228369c63936db65827de3cc06200	my-magic-file
+        10064 blob 4b9458b3786228369c63936db65827de3cc06200     my-magic-file
 
 in the output. This already tells you a *lot* it tells you what file the
 corrupt blob came from!
@@ -87,7 +87,7 @@ Now, it doesn't tell you quite enough, though: it doesn't tell what
 lucky, and it may be the version that you already have checked out in your
 working tree, in which case fixing this problem is really simple, just do
 
-	git hash-object -w my-magic-file
+        git hash-object -w my-magic-file
 
 again, and if it outputs the missing SHA-1 (4b945..) you're now all done!
 
@@ -96,26 +96,26 @@ version that was broken. How do you tell which version it was?
 
 The easiest way to do it is to do
 
-	git log --raw --all --full-history -- subdirectory/my-magic-file
+        git log --raw --all --full-history -- subdirectory/my-magic-file
 
 and that will show you the whole log for that file (please realize that
 the tree you had may not be the top-level tree, so you need to figure out
 which subdirectory it was in on your own), and because you're asking for
 raw output, you'll now get something like
 
-	commit abc
-	Author:
-	Date:
-	  ..
-	:100644 100644 4b9458b... newsha... M  somedirectory/my-magic-file
+        commit abc
+        Author:
+        Date:
+          ..
+        :100644 100644 4b9458b... newsha... M  somedirectory/my-magic-file
 
 
-	commit xyz
-	Author:
-	Date:
+        commit xyz
+        Author:
+        Date:
 
-	  ..
-	:100644 100644 oldsha... 4b9458b... M	somedirectory/my-magic-file
+          ..
+        :100644 100644 oldsha... 4b9458b... M   somedirectory/my-magic-file
 
 and this actually tells you what the *previous* and *subsequent* versions
 of that file were! So now you can look at those ("oldsha" and "newsha"
@@ -125,13 +125,13 @@ newer versions!
 
 If you can do that, you can now recreate the missing object with
 
-	git hash-object -w <recreated-file>
+        git hash-object -w <recreated-file>
 
 and your repository is good again!
 
 (Btw, you could have ignored the fsck, and started with doing a
 
-	git log --raw --all
+        git log --raw --all
 
 and just looked for the sha of the missing object (4b9458b..) in that
 whole thing. It's up to you - Git does *have* a lot of information, it is
@@ -141,4 +141,4 @@ Trying to recreate trees and especially commits is *much* harder. So you
 were lucky that it's a blob. It's quite possible that you can recreate the
 thing.
 
-			Linus
+                        Linus
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 075418e..4b75bfc 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like
 this:
 
  ---o---o---o---M---x---x---W
-	       /
+               /
        ---A---B
 
 where A and B are on the side development that was not so good, M is the
@@ -47,7 +47,7 @@ After the developers of the side branch fix their mistakes, the history
 may look like this:
 
  ---o---o---o---M---x---x---W---x
-	       /
+               /
        ---A---B-------------------C---D
 
 where C and D are to fix what was broken in A and B, and you may already
@@ -81,7 +81,7 @@ In such a situation, you would want to first revert the previous revert,
 which would make the history look like this:
 
  ---o---o---o---M---x---x---W---x---Y
-	       /
+               /
        ---A---B-------------------C---D
 
 where Y is the revert of W.  Such a "revert of the revert" can be done
@@ -93,14 +93,14 @@ This history would (ignoring possible conflicts between what W and W..Y
 changed) be equivalent to not having W nor Y at all in the history:
 
  ---o---o---o---M---x---x-------x----
-	       /
+               /
        ---A---B-------------------C---D
 
 and merging the side branch again will not have conflict arising from an
 earlier revert and revert of the revert.
 
  ---o---o---o---M---x---x-------x-------*
-	       /                       /
+               /                       /
        ---A---B-------------------C---D
 
 Of course the changes made in C and D still can conflict with what was
@@ -111,13 +111,13 @@ faulty A and B, and redone the changes on top of the updated mainline
 after the revert, the history would have looked like this:
 
  ---o---o---o---M---x---x---W---x---x
-	       /                 \
+               /                 \
        ---A---B                   A'--B'--C'
 
 If you reverted the revert in such a case as in the previous example:
 
  ---o---o---o---M---x---x---W---x---x---Y---*
-	       /                 \         /
+               /                 \         /
        ---A---B                   A'--B'--C'
 
 where Y is the revert of W, A' and B' are rerolled A and B, and there may
@@ -129,7 +129,7 @@ lot of overlapping changes that result in conflicts.  So do not do "revert
 of revert" blindly without thinking..
 
  ---o---o---o---M---x---x---W---x---x
-	       /                 \
+               /                 \
        ---A---B                   A'--B'--C'
 
 In the history with rebased side branch, W (and M) are behind the merge
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
index 0d5419e..bad54a1 100644
--- a/Documentation/howto/revert-branch-rebase.txt
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -154,7 +154,7 @@ $ git pull . master
 Packing 0 objects
 Unpacking 0 objects
 
-* committish: e3a693c...	refs/heads/master from .
+* committish: e3a693c...        refs/heads/master from .
 Trying to merge e3a693c... into 8c1f5f0... using 10d781b...
 Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
  cache.h        |    8 ++++----
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index a5193b1..40a35b1 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -51,19 +51,19 @@ verbose=false
 GLOBIGNORE=*
 
 function grant {
-  $verbose && echo >&2 "-Grant-		$1"
+  $verbose && echo >&2 "-Grant-         $1"
   echo grant
   exit 0
 }
 
 function deny {
-  $verbose && echo >&2 "-Deny-		$1"
+  $verbose && echo >&2 "-Deny-          $1"
   echo deny
   exit 1
 }
 
 function info {
-  $verbose && echo >&2 "-Info-		$1"
+  $verbose && echo >&2 "-Info-          $1"
 }
 
 # Implement generic branch and tag policies.
@@ -83,7 +83,7 @@ case "$1" in
       mb=$(git-merge-base "$2" "$3")
       case "$mb,$2" in
         "$2,$mb") info "Update is fast-forward" ;;
-	*)	  noff=y; info "This is not a fast-forward update.";;
+        *)        noff=y; info "This is not a fast-forward update.";;
       esac
     fi
     ;;
diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt
index 7af2e52..6b33d85 100644
--- a/Documentation/howto/use-git-daemon.txt
+++ b/Documentation/howto/use-git-daemon.txt
@@ -12,11 +12,11 @@ things do not go according to plan (e.g. a socket could not be bound).
 
 Another word of warning: if you run
 
-	$ git ls-remote git://127.0.0.1/rule-the-world.git
+        $ git ls-remote git://127.0.0.1/rule-the-world.git
 
 and you see a message like
 
-	fatal: The remote end hung up unexpectedly
+        fatal: The remote end hung up unexpectedly
 
 it only means that _something_ went wrong. To find out _what_ went wrong,
 you have to ask the server. (Git refuses to be more precise for your
@@ -25,8 +25,8 @@ Sorry, not allowed -- who knows what you planned to do with them?)
 
 With these two caveats, let's see an example:
 
-	$ git daemon --reuseaddr --verbose --base-path=/home/gitte/git \
-	  --export-all -- /home/gitte/git/rule-the-world.git
+        $ git daemon --reuseaddr --verbose --base-path=/home/gitte/git \
+          --export-all -- /home/gitte/git/rule-the-world.git
 
 (Of course, unless your user name is `gitte` _and_ your repository is in
 ~/rule-the-world.git, you have to adjust the paths. If your repository is
@@ -49,6 +49,6 @@ a good practice to put the paths after a "--" separator.
 
 Now, test your daemon with
 
-	$ git ls-remote git://127.0.0.1/rule-the-world.git
+        $ git ls-remote git://127.0.0.1/rule-the-world.git
 
 If this does not work, find out why, and submit a patch to this document.
-- 
1.8.3.3.2.g85103ba

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH 0/2] Remove tabs from howto documents
  2013-07-31 16:54         ` [PATCH 0/2] Remove tabs from howto documents Dirk Wallenstein
@ 2013-07-31 17:01           ` Fredrik Gustafsson
  0 siblings, 0 replies; 16+ messages in thread
From: Fredrik Gustafsson @ 2013-07-31 17:01 UTC (permalink / raw)
  To: Dirk Wallenstein; +Cc: git, Junio C Hamano, Thomas Ackermann

On Wed, Jul 31, 2013 at 06:54:07PM +0200, Dirk Wallenstein wrote:
> I really think that tabs are generally bad here.  So, this will
> remove all tabs from the howto folder and prevent indenting with tabs
> through gitattributes.
> 
> Dirk Wallenstein (2):
>   howto: Suppress indentation with tabs
>   howto: Eliminate all tabs
> 
>  Documentation/howto/.gitattributes                 |  1 +
>  .../howto/rebase-from-internal-branch.txt          |  8 ++--
>  Documentation/howto/rebuild-from-update-hook.txt   |  4 +-
>  .../howto/recover-corrupted-blob-object.txt        | 50 +++++++++++-----------
>  Documentation/howto/revert-a-faulty-merge.txt      | 16 +++----
>  Documentation/howto/revert-branch-rebase.txt       |  2 +-
>  Documentation/howto/update-hook-example.txt        |  8 ++--
>  Documentation/howto/use-git-daemon.txt             | 10 ++---
>  8 files changed, 50 insertions(+), 49 deletions(-)
>  create mode 100644 Documentation/howto/.gitattributes
> 

How about adding a line about this in Documentation/CodingGuidelines?

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 2/2] howto: Eliminate all tabs
  2013-07-31 16:54             ` [PATCH 2/2] howto: Eliminate all tabs Dirk Wallenstein
@ 2013-07-31 17:03               ` Junio C Hamano
  2013-07-31 17:34                 ` Dirk Wallenstein
                                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Junio C Hamano @ 2013-07-31 17:03 UTC (permalink / raw)
  To: Dirk Wallenstein; +Cc: git, junio, Thomas Ackermann

Dirk Wallenstein <halsmit@t-online.de> writes:

> diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
> index 19ab604..aefe5b1 100644
> --- a/Documentation/howto/rebase-from-internal-branch.txt
> +++ b/Documentation/howto/rebase-from-internal-branch.txt
> @@ -1,8 +1,8 @@
> -From:	Junio C Hamano <gitster@pobox.com>
> -To:	git@vger.kernel.org
> -Cc:	Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
> +From:Junio C Hamano <gitster@pobox.com>

Why does this patch have to break the e-mail headers like this?

These are copies of old e-mails; keep them as close to the original
as they were.

Besides, the tab width of our source is 8, period.  Get over it.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 2/2] howto: Eliminate all tabs
  2013-07-31 17:03               ` Junio C Hamano
@ 2013-07-31 17:34                 ` Dirk Wallenstein
  2013-08-03 20:20                 ` Piotr Krukowiecki
       [not found]                 ` <CAA01CsqW1FWm8ExK7hypHp1_Jm0-kc1REQeuPYjbzU=aUQ+L9g@mail.gmail.com>
  2 siblings, 0 replies; 16+ messages in thread
From: Dirk Wallenstein @ 2013-07-31 17:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, junio, Thomas Ackermann

Junio C Hamano <gitster@pobox.com> wrote (Wed, Jul 31, 2013 at 10:03:15AM -0700):
> Dirk Wallenstein <halsmit@t-online.de> writes:
> 
> > diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
> > index 19ab604..aefe5b1 100644
> > --- a/Documentation/howto/rebase-from-internal-branch.txt
> > +++ b/Documentation/howto/rebase-from-internal-branch.txt
> > @@ -1,8 +1,8 @@
> > -From:	Junio C Hamano <gitster@pobox.com>
> > -To:	git@vger.kernel.org
> > -Cc:	Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
> > +From:Junio C Hamano <gitster@pobox.com>
> 
> Why does this patch have to break the e-mail headers like this?
> 
> These are copies of old e-mails; keep them as close to the original
> as they were.
> 
> Besides, the tab width of our source is 8, period.  Get over it.
> 

I will try.  It just doesn't make sense to me at all.

-- 
  Dirk

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 2/2] howto: Eliminate all tabs
  2013-07-31 17:03               ` Junio C Hamano
  2013-07-31 17:34                 ` Dirk Wallenstein
@ 2013-08-03 20:20                 ` Piotr Krukowiecki
       [not found]                 ` <CAA01CsqW1FWm8ExK7hypHp1_Jm0-kc1REQeuPYjbzU=aUQ+L9g@mail.gmail.com>
  2 siblings, 0 replies; 16+ messages in thread
From: Piotr Krukowiecki @ 2013-08-03 20:20 UTC (permalink / raw)
  To: Junio C Hamano, Dirk Wallenstein; +Cc: git, junio, Thomas Ackermann

Junio C Hamano <gitster@pobox.com> napisał:
>Besides, the tab width of our source is 8, period.  Get over it.

Isn't the howto documentation intended (mainly/also) for the users of git, not the developers?


-- 
Piotr Krukowiecki 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 2/2] howto: Eliminate all tabs
       [not found]                 ` <CAA01CsqW1FWm8ExK7hypHp1_Jm0-kc1REQeuPYjbzU=aUQ+L9g@mail.gmail.com>
@ 2013-08-05 15:32                   ` Junio C Hamano
  0 siblings, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2013-08-05 15:32 UTC (permalink / raw)
  To: Piotr Krukowiecki
  Cc: Dirk Wallenstein, Git Mailing List, Thomas Ackermann, junio

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

> Isn't the howto documentation intended (mainly/also) for the users of git,
> not the developers?

And they have *.html version for that exact version, no?

We used not to bother running asciidoc to Documentation/howto, so
the *.txt versions had to be exposed to the end users because there
was no other variant. That is no longer true, and *.txt versions are
sources.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2013-08-05 15:32 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-15 16:46 [PATCH] howto: Use all-space indentation in ASCII art Dirk Wallenstein
2013-07-15 22:00 ` Junio C Hamano
2013-07-16  8:24   ` Dirk Wallenstein
2013-07-16 17:13     ` Junio C Hamano
2013-07-16 18:01       ` Dirk Wallenstein
2013-07-31 16:54         ` [PATCH 0/2] Remove tabs from howto documents Dirk Wallenstein
2013-07-31 17:01           ` Fredrik Gustafsson
     [not found]         ` <cover.1375288760.git.halsmit@t-online.de>
2013-07-31 16:54           ` [PATCH 1/2] howto: Suppress indentation with tabs Dirk Wallenstein
     [not found]           ` <4d37bfa3326469ab5b7cdbf0018f7aa671c2d74a.1375288760.git.halsmit@t-online.de>
2013-07-31 16:54             ` [PATCH 2/2] howto: Eliminate all tabs Dirk Wallenstein
2013-07-31 17:03               ` Junio C Hamano
2013-07-31 17:34                 ` Dirk Wallenstein
2013-08-03 20:20                 ` Piotr Krukowiecki
     [not found]                 ` <CAA01CsqW1FWm8ExK7hypHp1_Jm0-kc1REQeuPYjbzU=aUQ+L9g@mail.gmail.com>
2013-08-05 15:32                   ` Junio C Hamano
2013-07-16 18:26     ` [PATCH] howto: Use all-space indentation in ASCII art Jonathan Nieder
2013-07-16 18:38       ` Dirk Wallenstein
2013-07-16 18:42       ` A Large Angry SCM

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.