* Re: [PATCH] Grammar fixes for gitattributes documentation
From: Wincent Colaiuta @ 2007-11-14 9:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfxz9kxz3.fsf@gitster.siamese.dyndns.org>
El 14/11/2007, a las 9:55, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> -A `filter` attribute can be set to a string value. This names
>> +A `filter` attribute can be set to a string value which names a
>> filter driver specified in the configuration.
>
> Will we get the canned "which vs that" discussion on this change?
Perhaps. Neither would be incorrect, although technically "that" is a
tighter match.
> I do appreciate the grammar fixes, but I needed to re-wrap and
> swap lines to see the real change. Especially, after this
> re-wrapping, the updated lines with missing "the" fixed still
> fit nicely below 70 columns and the right edge is not too ragged
> to be distractive even for people who read unformatted text.
>
> Could you please avoid this kind of unnecessary re-wrapping in
> the future patches?
Ok, sorry about that. I wasn't sure of the maximum allowed length in
the doc files, and the longest line I could find in that file was 67
chars, so I made sure that nothing exceeded that. Will make a note
that the official limit is 70. Perhaps this could be added to the
style document? Will whip up a patch for that.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Grammar fixes for gitattributes documentation
From: Junio C Hamano @ 2007-11-14 9:27 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <3461FD6E-1C46-4278-9EB0-5D730BB99084@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> El 14/11/2007, a las 9:55, Junio C Hamano escribi> Wincent Colaiuta <win@wincent.com> writes:
>>
>>> -A `filter` attribute can be set to a string value. This names
>>> +A `filter` attribute can be set to a string value which names a
>>> filter driver specified in the configuration.
>>
>> Will we get the canned "which vs that" discussion on this change?
>
> Perhaps. Neither would be incorrect, although technically "that" is a
> tighter match.
Yes, that was what I was getting at, although I do not
particularly find the original wrong nor harder to read, either.
>> Could you please avoid this kind of unnecessary re-wrapping in
>> the future patches?
>
> Ok, sorry about that. I wasn't sure of the maximum allowed length in
> the doc files, and the longest line I could find in that file was 67
> chars, so I made sure that nothing exceeded that. Will make a note
> that the official limit is 70.
I did not mean to say 70 was the official limit. Indeed, there
is no hard official limit (and there shouldn't be any "hard"
limit). But 70 should certainly be lower than the limit anybody
around here would want to impose, and that was why I said 70.
Some considerations:
- Many of us read the unformatted ASCII version, as AsciiDoc
was designed to be very readable, and mixing excessively long
and short lines will make the document harder to read.
- We tend to exchange patches over e-mail and assume everybody
has at least 80-column wide terminals, so although we say a
line should be less than 80-chars, in practice the limit is
somewhat lower. to accomodate diff change marks [-+ ] and
quoting ">> " in e-mails.
- But "80-chars minus a bit of slop" is not a very hard limit.
Please apply some common sense to decide when to re-wrap and
when not to within these constraints.
^ permalink raw reply
* [PATCH] Documentation: Fix man page breakage with DocBook XSL v1.72
From: Jonas Fonseca @ 2007-11-14 9:38 UTC (permalink / raw)
To: git, Junio C Hamano
>From version 1.72 it will replace all dots in roff requests with U+2302
("house" character), and add escaping in output for all instances of dot
that are not in roff requests. This caused the ".ft" hack forcing
monospace font in listingblocks to end up as "\&.ft" and being visible
in the resulting man page.
The fix adds a DOCBOOK_XSL_172 build variable that will disable the
hack. To allow this variable to be defined in config.mak it also moves
build variable handling below the inclusion of config.mak.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 10 +++++++---
Documentation/asciidoc.conf | 3 +++
Makefile | 2 ++
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 39ec0ed..d886641 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -37,9 +37,6 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
-ifdef ASCIIDOC8
-ASCIIDOC_EXTRA += -a asciidoc7compatible
-endif
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
@@ -52,6 +49,13 @@ DOCBOOK2X_TEXI=docbook2x-texi
-include ../config.mak.autogen
-include ../config.mak
+ifdef ASCIIDOC8
+ASCIIDOC_EXTRA += -a asciidoc7compatible
+endif
+ifdef DOCBOOK_XSL_172
+ASCIIDOC_EXTRA += -a docbook-xsl-172
+endif
+
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index af5b155..99d8874 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -23,7 +23,9 @@ ifdef::backend-docbook[]
endif::backend-docbook[]
ifdef::backend-docbook[]
+ifndef::docbook-xsl-172[]
# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+# v1.72 breaks with this because it replaces dots not in roff requests.
[listingblock]
<example><title>{title}</title>
<literallayout>
@@ -36,6 +38,7 @@ ifdef::doctype-manpage[]
endif::doctype-manpage[]
</literallayout>
{title#}</example>
+endif::docbook-xsl-172[]
endif::backend-docbook[]
ifdef::doctype-manpage[]
diff --git a/Makefile b/Makefile
index cd6d469..6936f7c 100644
--- a/Makefile
+++ b/Makefile
@@ -115,6 +115,8 @@ all::
#
# Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
#
+# Define DOCBOOK_XSL_172 if you want to format man pages with DocBook XSL v1.72.
+#
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
--
1.5.3.5.1661.gcbf0-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-14 9:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Brian Gernhardt, Shawn O. Pearce, Junio C Hamano, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711132352340.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But I illustrated that cloning from an empty repository makes no sense.
And I, and others, illustrated the opposite.
> There is a huge difference between calling somebody an idiot on the one
> side, and investing some time to help somebody who has a suboptimal
> workflow on the other one.
You didn't show me where my proposed flow was suboptimal.
> But I fear that you took my help as a personal attack, and as a
> consequence you feel insulted, and I wasted my precious time.
Do you call _that_ "help"?
,----
| Last time I checked, those geneticists did not clone thin air. They
| always waited until they had something to clone.
`----
To me, this classifies either as "totally irrelevant remark", or as
"making fun of someone". Definitely not "help".
--
Matthieu
^ permalink raw reply
* Re: [PATCH] git-clean: consider core.excludesfile
From: Jakub Narebski @ 2007-11-14 9:44 UTC (permalink / raw)
To: git
In-Reply-To: <30046e3b0711132340y2c503dd4laea24b9b1c79a160@mail.gmail.com>
shunichi fuji wrote:
> + core_excl="`git-config core.excludesfile`"
+ core_excl="$(git-config core.excludesfile)"
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: Fix man page breakage with DocBook XSL v1.72
From: Junio C Hamano @ 2007-11-14 9:46 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20071114093846.GA21082@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> From version 1.72 it will replace all dots in roff requests with U+2302
> ("house" character), and add escaping in output for all instances of dot
> that are not in roff requests.
Wasn't this "house" thing brought up on the list earlier? I may
well be recalling things incorrectly, but I somehow thought that
DocBook people realized this was a mistake and the "house" trick
was retracted in later snapshots, or something.
^ permalink raw reply
* Re: [PATCH] Documentation: Fix man page breakage with DocBook XSL v1.72
From: Junio C Hamano @ 2007-11-14 9:47 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20071114093846.GA21082@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> The fix adds a DOCBOOK_XSL_172 build variable that will disable the
> hack. To allow this variable to be defined in config.mak it also moves
> build variable handling below the inclusion of config.mak.
Ah, I misread the patch. Thanks.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-14 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <7vejetr7vn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If your publishing repo is local like the above, then
In my case, it's more often a "backed-up and slow NFS disk" Vs "local
disk" than a matter of publishing, but the result is similar.
> $ mkdir /tmp/junk && cd /tmp/junk
> $ git init; tar xf /tmp/project.tar; git add .; ... populate ...
> $ git commit -m initial
> $ cd /else/where/to/publish
> $ git clone --bare /tmp/junk myproject.git
> $ rm -fr /tmp/junk
>
> would be enough to get your published repository started, isn't
> it? Then wouldn't:
>
> $ cd $HOME
> $ git clone /else/where/to/publish/myproject.git myproject
>
> set up your ~/myproject exactly the same way as other people who
> will work with that published repository?
Sure, it definitely works. But that (creating a temporary repository,
and right after, delete it) also is an extra step. Not a huge one, but
still an extra step.
Take the same with bzr for example:
$ bzr init ~/repo
$ bzr checkout ~/repo ~/local/work/
$ cd ~/local/work/
<put files, bzr add, bzr commit>
<continue working in ~/local/work/, commit, whatever>
(bzr checkout is a bit different from git clone, but the difference it
not totally relevant here).
I litterally have just two bzr commands before I can start working
normally.
--
Matthieu
^ permalink raw reply
* [PATCH] git-clean: honor core.excludesfile
From: Junio C Hamano @ 2007-11-14 9:54 UTC (permalink / raw)
To: shunichi fuji; +Cc: git
In-Reply-To: <30046e3b0711132340y2c503dd4laea24b9b1c79a160@mail.gmail.com>
git-clean did not honor core.excludesfile configuration
variable, although some other commands such as git-add and
git-status did. Fix this inconsistency.
Original report and patch from Shun'ichi Fuji. Rewritten by me
and bugs and tests are mine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* How does this look? It is customary here to add a test
script to t/ to make sure a fix won't get broken in later
changes, so I took the liberty of adding one myself.
git-clean.sh | 9 ++++++++-
t/t7300-clean.sh | 11 +++++++++++
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/git-clean.sh b/git-clean.sh
index 4491738..931d1aa 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -75,15 +75,22 @@ esac
if [ -z "$ignored" ]; then
excl="--exclude-per-directory=.gitignore"
+ excl_info= excludes_file=
if [ -f "$GIT_DIR/info/exclude" ]; then
excl_info="--exclude-from=$GIT_DIR/info/exclude"
fi
+ if cfg_excl=$(git config core.excludesfile) && test -f "$cfg_excl"
+ then
+ excludes_file="--exclude-from=$cfg_excl"
+ fi
if [ "$ignoredonly" ]; then
excl="$excl --ignored"
fi
fi
-git ls-files --others --directory $excl ${excl_info:+"$excl_info"} -- "$@" |
+git ls-files --others --directory \
+ $excl ${excl_info:+"$excl_info"} ${excludes_file:+"$excludes_file"} \
+ -- "$@" |
while read -r file; do
if [ -d "$file" -a ! -L "$file" ]; then
if [ -z "$cleandir" ]; then
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index eb0847a..0ed4ae2 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -177,4 +177,15 @@ test_expect_success 'clean.requireForce and -f' '
'
+test_expect_success 'core.excludesfile' '
+
+ echo excludes >excludes &&
+ echo included >included &&
+ git config core.excludesfile excludes &&
+ output=$(git clean -n excludes included 2>&1) &&
+ expr "$output" : ".*included" >/dev/null &&
+ ! expr "$output" : ".*excludes" >/dev/null
+
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] git-clean: consider core.excludesfile
From: Johannes Sixt @ 2007-11-14 10:02 UTC (permalink / raw)
To: shunichi fuji; +Cc: git, Junio C Hamano
In-Reply-To: <30046e3b0711132340y2c503dd4laea24b9b1c79a160@mail.gmail.com>
shunichi fuji schrieb:
> --- /usr/bin/git-clean 2007-11-14 08:26:20.000000000 +0900
> +++ git-clean 2007-11-14 09:43:03.000000000 +0900
> @@ -81,9 +81,14 @@
> if [ "$ignoredonly" ]; then
> excl="$excl --ignored"
> fi
> + core_excl="`git-config core.excludesfile`"
Please make this
core_excl=$(git-config core.excludesfile)
-- Hannes
^ permalink raw reply
* Re: [PATCH] Bisect visualize: use "for-each-ref" to list all good refs.
From: Johannes Sixt @ 2007-11-14 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7voddxkzzw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Even worse is that bisect_clean_state uses
>
> rm -fr "$GIT_DIR/refs/bisect"
>
> so if you ever pack your refs in the middle of bisection and
> then clean the state, you will still carry the old good set of
> commits that are somewhat hard to cull.
Heh. I think I'd done this once, and couldn't get rid of those refs with
'git-bisect reset'. Now I know why.
-- Hannes
^ permalink raw reply
* [PATCH] Add line-wrapping guidelines to the coding style documentation
From: Wincent Colaiuta @ 2007-11-14 10:19 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio Hamano
Help new contributors by providing some advice about line-wrapping; the
advice basically boils down to "use 80-characters minus some slop as a
rule of thumb", but also "use common sense", and "avoid gratuitous
rewrapping".
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
The advice is based on the following post by Junio:
El 14/11/2007, a las 10:27, Junio C Hamano escribió:
> I did not mean to say 70 was the official limit. Indeed, there
> is no hard official limit (and there shouldn't be any "hard"
> limit). But 70 should certainly be lower than the limit anybody
> around here would want to impose, and that was why I said 70.
>
> Some considerations:
>
> - Many of us read the unformatted ASCII version, as AsciiDoc
> was designed to be very readable, and mixing excessively long
> and short lines will make the document harder to read.
>
> - We tend to exchange patches over e-mail and assume everybody
> has at least 80-column wide terminals, so although we say a
> line should be less than 80-chars, in practice the limit is
> somewhat lower. to accomodate diff change marks [-+ ] and
> quoting ">> " in e-mails.
>
> - But "80-chars minus a bit of slop" is not a very hard limit.
>
> Please apply some common sense to decide when to re-wrap and
> when not to within these constraints.
I also whipped up this quick Ruby script to print a histogram of line
widths in the tree. You would run it like this to get a feel for the
typical line lengths of the different types of file in the tree:
check-column-widths.rb *.c *.h
check-column-widths.rb *.sh
check-column-widths.rb *.perl
check-column-widths.rb Documentation/*.txt
A statistician could probably make some interesting comments about the
results, but the basic trend is that, while there are plenty of
examples of isolated long lines in the source tree (the longest is a
287-character line in one of the perl scripts), the frequency starts
to drop off pretty rapidly once you pass 70 columns and start climbing
towards 80.
#!/usr/bin/env ruby
extensions = {}
# count frequency of line widths
ARGV.each do |arg|
f = File.new arg
extname = File.extname arg
unless file_type = extensions[extname]
extensions[extname] = file_type = {}
end
f.readlines.each do |line|
len = line.chomp.length
count = (file_type[len] or 0)
file_type[len] = count + 1
end
end
# print results
extensions.each do |file_type, frequencies|
puts "Frequencies for #{file_type} files"
# find longest line, most frequent line width, total line count
longest = frequencies.max { |a, b| a[0] <=> b[0] }[0]
most_frequent = frequencies.max { |a, b| a[1] <=> b[1] }[1]
total_lines = frequencies.inject(0) { |sum, a| sum + a[1] }
# draw histogram
for i in 0..longest
next if frequencies[i].nil?
puts "%4d [%4d]: %s" % [i, frequencies[i], '.' * (frequencies[i]
* 60 / most_frequent)]
end
puts "Maximum length: #{longest}"
puts " Total lines: #{total_lines}"
end
Documentation/CodingGuidelines | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/
CodingGuidelines
index 3b042db..3fd698e 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -110,3 +110,25 @@ For C programs:
used in the git core command set (unless your command is clearly
separate from it, such as an importer to convert random-scm-X
repositories to git).
+
+Line wrapping:
+
+ - While there are no official hard limits for line wrapping, we
+ generally try to keep shell scripts, C source files and AsciiDoc
+ documentation within the range of "80-characters minus some
+ slop".
+
+ - We assume that everyone has terminals that are at least 80
+ columns wide.
+
+ - In practice, we try to keep lines somewhat narrower than 80
+ columns to accommodate diff change marks [-+ ] and quoting ">> "
+ in emails.
+
+ - In the case of documentation, mixing excessively long and short
+ lines may make the AsciiDoc source harder to read, so try to
+ keep line lengths consistent.
+
+ - When submitting patches use common sense to decide whether to
+ rewrap, avoiding gratuitous changes.
+
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Add line-wrapping guidelines to the coding style documentation
From: Junio C Hamano @ 2007-11-14 10:37 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <56A87A65-3C2E-4E10-84D4-4470879EE466@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> A statistician could probably make some interesting comments about the
> results, but the basic trend is that, while there are plenty of
> examples of isolated long lines in the source tree (the longest is a
> 287-character line in one of the perl scripts), the frequency starts
> to drop off pretty rapidly once you pass 70 columns and start climbing
> towards 80.
Gaah. 287???
> + - In the case of documentation, mixing excessively long and short
> + lines may make the AsciiDoc source harder to read, so try to
> + keep line lengths consistent.
> +
> + - When submitting patches use common sense to decide whether to
> + rewrap, avoiding gratuitous changes.
Hmph. The last item applies only to the documentation because
it uses the word "rewrap", but otherwise applies equally well to
the sources (re-indenting). So probably "whether to rewrap or
reindent" would be a good change there.
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Junio C Hamano @ 2007-11-14 11:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1194984306-3181-1-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> This is a series of smallish, unrelated changes that were necessary
> for the MinGW port.
I was _VERY_ afraid of reviewing this series.
> [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
> [PATCH 06/11] Move #include <sys/select.h> and <sys/ioctl.h> to
> git-compat-util.h.
>
> These two are certainly undisputed.
Except on esoteric/broken systems there might be some dependency
on the order the system include files are included, so 06/11
needs some testing. But it is a change in the right direction.
> [PATCH 07/11] builtin run_command: do not exit with -1.
>
> Replaces exit(-1) by exit(255). I don't know if this has any bad
> consequences on *nix.
Linux manual page says "the value of status & 0377 is returned
to the parent", which agrees with POSIX's "only the least
significant 8 bits(that is, status & 0377) shall be available to
a waiting parent process". So I think we are safe on conforming
platforms.
> [PATCH 08/11] Close files opened by lock_file() before unlinking.
>
> This one was authored by Dscho. It is a definite MUST on Windows.
This was something we've talked about doing a few times on the
list but did not. It is good that this saw some testing in the
field, as it is easy to get wrong while moving the call site of
close(2) around.
> [PATCH 09/11] Allow a relative builtin template directory.
> [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> of ETC_GITCONFIG.
> [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
>
> These need probably some discussion. They avoid that $(prefix) is
> hardcoded and so allows that an arbitrary installation directory.
I had to worry a bit about bootstrapping issues in 11/11. We
need to ensure that anybody who wants to read the configuration
data first does setup_path() because git_exec_path() reads from
argv_exec_path and setup_path() is what assigns to that
variable.
But other than that and 08/11, I found everything is trivially
correct and it was a pleasant read.
Thanks.
^ permalink raw reply
* [PATCH v2] Add line-wrapping guidelines to the coding style documentation
From: Wincent Colaiuta @ 2007-11-14 11:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <A18FC90C-5874-445A-93CE-9E05D02C614F@wincent.com>
Help new contributors by providing some advice about line-wrapping; the
advice basically boils down to "use 80-characters minus some slop as a
rule of thumb", but also "use common sense", and "avoid gratuitous
rewrapping".
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
El 14/11/2007, a las 11:37, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> A statistician could probably make some interesting comments about
>> the
>> results, but the basic trend is that, while there are plenty of
>> examples of isolated long lines in the source tree (the longest is a
>> 287-character line in one of the perl scripts), the frequency starts
>> to drop off pretty rapidly once you pass 70 columns and start
>> climbing
>> towards 80.
>
> Gaah. 287???
Actually, not true. The longest line in a perl script is 209 chars
(217 columns if you expand the leading tab), in file git-
cvsexportcommit.perl.
The 287-char line was actually in builtin-update-index.c; this and
most of the other really huge lines are usage strings.
>> + - In the case of documentation, mixing excessively long and short
>> + lines may make the AsciiDoc source harder to read, so try to
>> + keep line lengths consistent.
>> +
>> + - When submitting patches use common sense to decide whether to
>> + rewrap, avoiding gratuitous changes.
>
> Hmph. The last item applies only to the documentation because
> it uses the word "rewrap", but otherwise applies equally well to
> the sources (re-indenting). So probably "whether to rewrap or
> reindent" would be a good change there.
Updated patch follows.
Documentation/CodingGuidelines | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/
CodingGuidelines
index 3b042db..3eecb64 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -110,3 +110,25 @@ For C programs:
used in the git core command set (unless your command is clearly
separate from it, such as an importer to convert random-scm-X
repositories to git).
+
+Line wrapping:
+
+ - While there are no official hard limits for line wrapping, we
+ generally try to keep shell scripts, C source files and AsciiDoc
+ documentation within the range of "80-characters minus some
+ slop".
+
+ - We assume that everyone has terminals that are at least 80
+ columns wide.
+
+ - In practice, we try to keep lines somewhat narrower than 80
+ columns to accommodate diff change marks [-+ ] and quoting ">> "
+ in emails.
+
+ - In the case of documentation, mixing excessively long and short
+ lines may make the AsciiDoc source harder to read, so try to
+ keep line lengths consistent.
+
+ - When submitting patches use common sense to decide whether to
+ rewrap (or reindent), avoiding gratuitous changes.
+
--
1.5.3.5
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Sergei Organov @ 2007-11-14 12:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <7v4pfr2kmh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
>>>> >
>>>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>> >>
>>>> >> > So you need to populate the repository before starting _anyway_.
>>>> >>
>>>> >> Last time I checked, the thread was talking about bare repository.
>>>
>>> Look at the subject. "Cloning empty repositories."
>>
>> Look at the content. "cloning a empty bare repository".
>
> But both of Johannes's points apply equally well to an empty
> bare repository and to an empty non bare repository. IOW,
> bareness does not matter to the suggestion Johannes gave.
>
> But you are acting as if the bareness of the target repository
> makes his point irrelevant. I am a bit confused.
>
> About his point 1, I'd just stop at saying that "it is not so
> hard" does not mean "we do not have to make it even easier".
>
> His second point is also a real issue. If you allowed cloning
> an empty repo (either bare or non-bare), then you and Bill can
> both clone from it, come up with an initial commit each. Bill
> pushes his initial commit first. Your later attempt to push
> will hopefully fail with "non fast forward", if you know better
> than forcing such a push, but then what? You need to fetch, and
> merge (or rebase) your change on top of Bill's initial commit,
> and at that point the history you are trying to merge does not
> have any common ancestor with his history.
Just a wild idea. Doesn't it make sense to introduce perfect ultimate
common ancestor of the universe, probably calling it "the NULL commit"?
At first glance it seems that it can help to avoid corner cases
automagically.
--
Sergei.
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: Sergei Organov @ 2007-11-14 12:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J Bruce Fields
In-Reply-To: <7vlk91mgz6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Signed-off-by: Sergei Organov <osv@javad.com>
>> ---
>> Documentation/user-manual.txt | 8 ++++----
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index d99adc6..a169ef0 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
>> If you run "git branch" at this point, you'll see that git has
>> temporarily moved you to a new branch named "bisect". This branch
>> points to a commit (with commit id 65934...) that is reachable from
>> -v2.6.19 but not from v2.6.18. Compile and test it, and see whether
>> +"master" but not from v2.6.18. Compile and test it, and see whether
>> it crashes. Assume it does crash. Then:
>>
>> -------------------------------------------------
>
> Thanks.
>
> This hunk and the last hunk I do not have any problem with.
>
>> @@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
>> fundamentally different ways to fix the problem:
>>
>> 1. You can create a new commit that undoes whatever was done
>> - by the previous commit. This is the correct thing if your
>> + by the old commit. This is the correct thing if your
>> mistake has already been made public.
>>
>> 2. You can go back and modify the old commit. You should
>
> But is this an improvement or just a churn?
I believe this is an improvement. It's more precise. With this change
it's crystal clear that both (1) and (2) above mean the same commit by
calling it "the old commit". Before the change, when I read this the
first time, I've got the term "previous" here literally, i.e., as the
last commit made, and I thought that if the commit in question is the
last one, I should do (1), otherwise -- (2). This confusion admittedly
vanished rather quickly, but it did happen.
If I didn't manage to express my first impression clearly (English is
not my mothers' tongue), try to read this to get similar impression:
1. You can create a new commit that undoes whatever was done
by the previous commit.
2. You can go back and modify the old commit.
Do you see the problem?
--
Sergei.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Jakub Narebski @ 2007-11-14 13:41 UTC (permalink / raw)
To: git
In-Reply-To: <87myth58r5.fsf@osv.gnss.ru>
Sergei Organov wrote:
> Just a wild idea. Doesn't it make sense to introduce perfect ultimate
> common ancestor of the universe, probably calling it "the NULL commit"?
> At first glance it seems that it can help to avoid corner cases
> automagically.
No. Sometimes you want unrelated branches in repository ('html', 'man',
'todo' branches in git.git), sometimes multiple roots are natural (merging
in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-14 14:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhettp$rtk$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Sergei Organov wrote:
>
>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate
>> common ancestor of the universe, probably calling it "the NULL commit"?
>> At first glance it seems that it can help to avoid corner cases
>> automagically.
>
> No. Sometimes you want unrelated branches in repository ('html', 'man',
> 'todo' branches in git.git), sometimes multiple roots are natural (merging
> in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).
There's no contradiction IMHO. At least bzr and Mercurial have the
notion of "null revision" that is a kind of virtual ancestor of the
first revision of a project, and AFAICT, they supprot having unrelated
branches in the same repository, and merging originally unrelated
projects together (not sure for Mercurial, but bzr can do it).
It just depends on the definition of "starting a project". Either you
say you start the project with "init", in which case all projects
start with the same thing, or you say you start with the first
"commit" in which case every project start with something different.
Anyway, we can't modify existing git projects now (adding an ancestor
to the initial revision would change each sha1 sum), so adding this
concept to git now would probably break all of it :-\.
--
Matthieu
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Sergei Organov @ 2007-11-14 14:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhettp$rtk$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Sergei Organov wrote:
>
>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate
>> common ancestor of the universe, probably calling it "the NULL commit"?
>> At first glance it seems that it can help to avoid corner cases
>> automagically.
>
> No. Sometimes you want unrelated branches in repository ('html', 'man',
> 'todo' branches in git.git), sometimes multiple roots are natural (merging
> in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).
Sorry, I fail to see how does it interfere with the idea of the NULL
commit. What if "unrelated" is defined as "the only common
ancestor is the NULL commit"?
Anyway, I'm not going do defend the idea further. I just recalled I
heard about it somewhere, probably in Bazaar-NG, and I thought I'd
mention it here as it appeared very natural to me.
--
Sergei.
^ permalink raw reply
* How to change a submodue as a subdirectory?
From: Ping Yin @ 2007-11-14 14:37 UTC (permalink / raw)
To: Git Mailing List
I have a super project superA, and a submodue subB. Now i decide to
switch subB from submodule to sub directory. Any good way to do that
and not losing any history?
--
Ping Yin
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Schindelin @ 2007-11-14 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vir45hyyn.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 14 Nov 2007, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
> > This is a series of smallish, unrelated changes that were necessary
> > for the MinGW port.
>
> I was _VERY_ afraid of reviewing this series.
Why? Because we get closer to MinGW integration into git.git for real?
;-)
> > [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
> > [PATCH 06/11] Move #include <sys/select.h> and <sys/ioctl.h> to
> > git-compat-util.h.
> >
> > These two are certainly undisputed.
>
> Except on esoteric/broken systems there might be some dependency
> on the order the system include files are included, so 06/11
> needs some testing. But it is a change in the right direction.
The safe thing, of course, would be to move them at the end of the include
list in git-compat-util.h, since they are now included after cache.h,
(which includes git-compat-util.h and only strbuf.h, the sha1 header and
zlib.h).
This way it should be really certainly undisputed.
> > [PATCH 08/11] Close files opened by lock_file() before unlinking.
> >
> > This one was authored by Dscho. It is a definite MUST on Windows.
>
> This was something we've talked about doing a few times on the
> list but did not. It is good that this saw some testing in the
> field, as it is easy to get wrong while moving the call site of
> close(2) around.
Note that we are not strictly _moving_ it around. In fact, we are _adding_
more close() calls... And even ignoring the errors when close() was
already called, so it feels a tad hacky. But it does the job.
> > [PATCH 09/11] Allow a relative builtin template directory.
> > [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> > of ETC_GITCONFIG.
> > [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
> >
> > These need probably some discussion. They avoid that $(prefix) is
> > hardcoded and so allows that an arbitrary installation directory.
>
> I had to worry a bit about bootstrapping issues in 11/11. We
> need to ensure that anybody who wants to read the configuration
> data first does setup_path() because git_exec_path() reads from
> argv_exec_path and setup_path() is what assigns to that
> variable.
Just to be safe in the future, we could check for that condition (by
introducing a static variable setup_path_called) and die() should anybody
introduce a code path where the order of calls is not maintained.
> But other than that and 08/11, I found everything is trivially correct
> and it was a pleasant read.
Me, too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-commit: Clean up an unused variable and a debug fprintf().
From: Kristian Høgsberg @ 2007-11-14 15:31 UTC (permalink / raw)
To: gitster; +Cc: git, Kristian Høgsberg
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7a8cb57..7841310 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -514,7 +514,7 @@ static const char commit_utf8_warn[] =
int cmd_commit(int argc, const char **argv, const char *prefix)
{
- int header_len, parent_count = 0;
+ int header_len;
struct strbuf sb;
const char *index_file, *reflog_msg;
char *nl;
@@ -550,7 +550,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Determine parents */
if (initial_commit) {
reflog_msg = "commit (initial)";
- parent_count = 0;
} else if (amend) {
struct commit_list *c;
struct commit *commit;
@@ -591,10 +590,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Get the commit message and validate it */
header_len = sb.len;
- if (!no_edit) {
- fprintf(stderr, "launching editor, log %s\n", logfile);
+ if (!no_edit)
launch_editor(git_path(commit_editmsg), &sb);
- } else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0)
+ else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0)
die("could not read commit message\n");
if (run_hook(index_file, "commit-msg", commit_editmsg))
exit(1);
--
1.5.3.5.1822.g11971-dirty
^ permalink raw reply related
* Re: [PATCH] Improved and extended t5404
From: Johannes Schindelin @ 2007-11-14 17:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20071114071929.GA2942@steel.home>
Hi,
On Wed, 14 Nov 2007, Alex Riesen wrote:
> Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > Alex Riesen <raa.lkml@gmail.com> writes:
> >
> > > Ignore exit code of git push in t5404, as it is not relevant for the
> > > test
> >
> > This proposed log message solicits a "Huh? -- Since when ignoring exit
> > code is an improvement?" reaction. If this push is expected to error
> > out, then wouldn't you want to make sure it errors out as expected?
> > If the problem is that the exit status is unreliable, maybe we need to
> > make it reliable instead?
>
> Well, it is kind of undefined. git push just updated some remote
> references and failed on the others. It has had some failures, so it
> returns non-0. And as I said, it really is not about the operation, but
> about if the tracking and remote branches are set as we want them.
If you know it should fail, why not make the test dependent on that
failure? I mean, should git-push have a bug and not fail, it would be
nice to catch this early...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add line-wrapping guidelines to the coding style documentation
From: Johannes Schindelin @ 2007-11-14 17:19 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List, Junio Hamano
In-Reply-To: <56A87A65-3C2E-4E10-84D4-4470879EE466@wincent.com>
Hi,
On Wed, 14 Nov 2007, Wincent Colaiuta wrote:
> Help new contributors by providing some advice about line-wrapping; the
> advice basically boils down to "use 80-characters minus some slop as a
> rule of thumb", but also "use common sense", and "avoid gratuitous
> rewrapping".
We already have this:
- We try to keep to at most 80 characters per line.
Besides, is it really necessary to be as explicit as you word it? IOW is
this patch needed?
Because if we go down that road, we might very well end up with a
CodingGuidelines document that is larger than git's source code.
Ciao,
Dscho
^ 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