[PATCH] doc: status, remove leftover statement about '#' prefix
This hasn't been true since 2556b9962e7c0353d562b7bf70eed11d8f29d0b0 Signed-off-by: Dirk Wallenstein hals...@t-online.de --- Documentation/git-status.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index a4acaa0..def635f 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -97,7 +97,7 @@ configuration variable documented in linkgit:git-config[1]. OUTPUT -- The output from this command is designed to be used as a commit -template comment, and all the output lines are prefixed with '#'. +template comment. The default, long format, is designed to be human readable, verbose and descriptive. Its contents and format are subject to change at any time. -- 1.9.0.1.g16216b6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Remove tabs from howto documents
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] howto: Suppress indentation with tabs
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 hals...@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 000..fecc113 --- /dev/null +++ b/Documentation/howto/.gitattributes @@ -0,0 +1 @@ +* whitespace=tab -- 1.8.3.3.2.g85103ba -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] howto: Eliminate all tabs
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 hals...@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 gits...@pobox.com -To:git@vger.kernel.org -Cc:Petr Baudis pa...@suse.cz, Linus Torvalds torva...@osdl.org +From:Junio C Hamano gits...@pobox.com +To: git@vger.kernel.org +Cc: Petr Baudis pa...@suse.cz, Linus Torvalds torva...@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 ca442d313d86dc67e0a2e5d584b465bd382cbf5cCOPYING - 100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453CREDITS - 04 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6Documentation - 100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32Kbuild - 100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9MAINTAINERS - ... +100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8.gitignore +100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883.mailmap +100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5cCOPYING +100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453CREDITS +04 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6Documentation +100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32Kbuild +100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9MAINTAINERS +... 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
Re: [PATCH 2/2] howto: Eliminate all tabs
Junio C Hamano gits...@pobox.com wrote (Wed, Jul 31, 2013 at 10:03:15AM -0700): Dirk Wallenstein hals...@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 gits...@pobox.com -To:git@vger.kernel.org -Cc:Petr Baudis pa...@suse.cz, Linus Torvalds torva...@osdl.org +From:Junio C Hamano gits...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] request-pull: improve error message for invalid revision args
Currently, when an invalid revision is specified, the error message is: fatal: Needed a single revision This is misleading because, you might think there is something wrong with the command line as a whole. Now the user gets a more meaningful error message, showing the invalid revision. Signed-off-by: Dirk Wallenstein hals...@t-online.de --- On Wed, Jul 17, 2013 at 10:06:21AM -0700, Junio C Hamano wrote: Dirk Wallenstein hals...@t-online.de writes: +baserev=$(git rev-parse --verify $base^0 2/dev/null) Use --quiet instead? Oh, of course. git-request-pull.sh | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/git-request-pull.sh b/git-request-pull.sh index d566015..ebf1269 100755 --- a/git-request-pull.sh +++ b/git-request-pull.sh @@ -51,8 +51,18 @@ fi tag_name=$(git describe --exact $head^0 2/dev/null) test -n $base test -n $url || usage -baserev=$(git rev-parse --verify $base^0) -headrev=$(git rev-parse --verify $head^0) || exit + +baserev=$(git rev-parse --verify --quiet $base^0) +if test -z $baserev +then +die fatal: Not a valid revision: $base +fi + +headrev=$(git rev-parse --verify --quiet $head^0) +if test -z $headrev +then +die fatal: Not a valid revision: $head +fi merge_base=$(git merge-base $baserev $headrev) || die fatal: No commits in common between $base and $head -- 1.8.3.3.2.g85103ba -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] howto: Use all-space indentation in ASCII art
On Mon, Jul 15, 2013 at 03:00:17PM -0700, Junio C Hamano wrote: Dirk Wallenstein hals...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] request-pull: improve error message for invalid revision args
When an invalid revision is specified, the error message is: fatal: Needed a single revision This is misleading because, you might think there is something wrong with the command line as a whole. Now the user gets a more meaningful error message, showing the invalid revision. Signed-off-by: Dirk Wallenstein hals...@t-online.de --- Notes: I assume, it is not worth the trouble to even try to change the message from rev-parse for this. People might parse the messages, which is probably why this message still exists. git-request-pull.sh | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/git-request-pull.sh b/git-request-pull.sh index d566015..f38f0f9 100755 --- a/git-request-pull.sh +++ b/git-request-pull.sh @@ -51,8 +51,18 @@ fi tag_name=$(git describe --exact $head^0 2/dev/null) test -n $base test -n $url || usage -baserev=$(git rev-parse --verify $base^0) -headrev=$(git rev-parse --verify $head^0) || exit + +baserev=$(git rev-parse --verify $base^0 2/dev/null) +if test -z $baserev +then +die fatal: Not a valid revision: $base +fi + +headrev=$(git rev-parse --verify $head^0 2/dev/null) +if test -z $headrev +then +die fatal: Not a valid revision: $head +fi merge_base=$(git merge-base $baserev $headrev) || die fatal: No commits in common between $base and $head -- 1.8.3.2.51.g8658a4c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] howto: Use all-space indentation in ASCII art
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] howto: Use all-space indentation in ASCII art
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] howto: Use all-space indentation in ASCII art
Keep the sketch aligned independent of the tabstop width used. Signed-off-by: Dirk Wallenstein hals...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
