* Re: [BUG] Git bisect not finding the right commit
From: Johannes Sixt @ 2012-01-19 8:23 UTC (permalink / raw)
To: Andreas J. Koenig; +Cc: git
In-Reply-To: <87r4yw8j4i.fsf@franz.ak.mind.de>
Am 1/19/2012 4:29, schrieb Andreas J. Koenig:
> - A -> B -> C - D ->
> \ /
> - E - F -
>
> A v5.15.5
> B v5.15.5-20-gfd76d40
> C v5.15.5-81-gcfe287a
> D v5.15.5-159-ga71d67b
> E v5.15.4-110-g27b29ec
> F v5.15.4-169-g3582575
I haven't looked at the actual history, but given the names of the commits
as produced by git-describe, I doubt that your history graph sketched
above is correct. Doesn't it look more like this:
A -- B -- C -- D --
/ /
-- X -- E -- F
where X is v5.15.4?
To find a commit between A and B, you must declare F as "good".
-- Hannes
^ permalink raw reply
* Re: [BUG] Git bisect not finding the right commit
From: Junio C Hamano @ 2012-01-19 8:20 UTC (permalink / raw)
To: Andreas J. Koenig; +Cc: git
In-Reply-To: <87r4yw8j4i.fsf@franz.ak.mind.de>
andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:
> A v5.15.5
> B v5.15.5-20-gfd76d40
> C v5.15.5-81-gcfe287a
> D v5.15.5-159-ga71d67b
> E v5.15.4-110-g27b29ec
> F v5.15.4-169-g3582575
>
> The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A
> and B. Bisect did not find it, it returned me E instead. Here the wrong
> bisect output:
Just for the sake of simplicity, I'll call ff0cf12 "Q" (the Questionable
one).
> % git bisect start v5.15.5-159-ga71d67b v5.15.5
You start by telling Git that D is bad and A is good.
I can see that D does contain Q (i.e. "git log D..Q" gives nothing), which
you should read as "D is _contaminated_ by the breakage Q introduced", so
D is indeed bad.
On the other hand, A does _not_ contain Q (i.e. "git log A..Q" gives
output), which you should read as "A is _not_ contaminated by the breakage
Q introduced", so A is indeed good.
So far so good...
> Already on 'blead'
> Bisecting: 77 revisions left to test after this (roughly 6 steps)
> [cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead
> % git describe
> v5.15.5-81-gcfe287a
This is your "C", and "git log C..Q" does not give anything. C is
contaminated by Q, hence it is bad.
> % git bisect bad
> Bisecting: 40 revisions left to test after this (roughly 5 steps)
> [baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html
> % git describe
> v5.15.4-149-gbaf7658
Here, baf7658 does not contain Q, so you are supposed to answer it is
GOOD.
> % git bisect bad
But you answered that it is BAD.
Why?
What caused you to say "bad" here to a commit that could not possibly have
inherited the breakage Q introduced?
One plausible explanation is that whatever symptom you are seeing in Perl
at version Q that you call "bad" may not be caused by a single root cause,
and a similar (or the same) symptom somehow appears at this version that
is _NOT_ contaminated by Q.
Another plausible scenario is that the symptom you are chasing may not be
reliably reproducible.
"bisection" by nature is an optimization technique applicable only when
you are chasing a reliably reproducible symptom that is caused by a single
cause, a breakage that existed in a single old version that is inherited
to all its descendants, and the "bad" symptom did not appear in any
version that does not inherit the breakage from that single problematic
commit. If you have a history A--B--C--D--E, in which B breaks something,
C fixes its breakage and then D reintroduces another breakage that shows
the same symptom, you can not optimize the search for a problem using
bisect. You need to check each and every version.
Of course, people sometimes simply get confused and mistakenly say BAD
when they wanted to say GOOD. That may be a simpler explanation of what
happened to your bisection.
Anyway, the remainder of your bisect sequence is GiGo, so I'll snip them
and will not quote.
^ permalink raw reply
* Re: Unexpected "clean -Xd" behavior
From: Nguyen Thai Ngoc Duy @ 2012-01-19 7:31 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Pete Harlan, Git Mailing List, Shawn Bohrer
In-Reply-To: <20120119002904.GA14107@burratino>
2012/1/19 Jonathan Nieder <jrnieder@gmail.com>:
> Pete Harlan wrote:
>
>> When a directory contains nothing but an ignored subdirectory, that
>> subdirectory does not get removed by "git clean -Xdf".
>>
>> For example, in a new directory:
>>
>> # git init
>> Initialized empty Git repository in /tmp/foo/.git/
>> # echo a/ >.gitignore
>> # git add .gitignore
>> # git commit -m "Initial commit"
>> [master (root-commit) c3af24c] Initial commit
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>> create mode 100644 .gitignore
>> # mkdir -p foo/a
>> # touch foo/a/junk.o
>> # git status
>> # On branch master
>> nothing to commit (working directory clean)
>> # git clean -Xdn # <--- DOES NOT MENTION foo/a
-X is to remove ignored files _only_ (DIR_SHOW_IGNORED flag). And
"foo" is not ignored according to .gitignore, so it cuts short there
and never gets to "foo/a". -x works. May be intentional, may be not
(we hit a corner case). I don't know. Commit message b991625 might
help:
dir.c: Omit non-excluded directories with dir->show_ignored
This makes "git-ls-files --others --directory --ignored" behave
as documented and consequently also fixes "git-clean -d -X".
Previously, git-clean would remove non-excluded directories
even when using the -X option.
--
Duy
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Johannes Sixt @ 2012-01-19 7:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Alex Riesen,
Git Mailing List
In-Reply-To: <7vfwfclf4v.fsf@alter.siamese.dyndns.org>
Am 1/19/2012 1:17, schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
>> ...
>>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>>> whether it works, or not.
>>
>> That's not what NO_GETTEXT means, and not what it *should* mean. It
>> means that your output won't be translated, but we might still make
>> use of a locally installed library to provide the gettext() and
>> eval_gettext() functions.
>
> You are right.
Sorry to disagree: We have, e.g., NO_MMAP, and I can set it to request
that some alternative is used, even if I have a working mmap(). The option
name "NO_GETTEXT" is in exactly the same spirit.
> In the current approach we take for shell scripts, we cannot have "No i18n
> whatsoever and messages are emit with printf and echo". We always have to
> go through gettext/eval_gettext even though they may be an implementation
> that does not do i18n at all.
Just like we go through _() in C code, even though there may be an
implementation that does not do i18n at all, right?
gettext/eval_gettext annotations are the shell equivalent of _()
annotations in C code, aren't they? Neither go away just by defining
NO_GETTEXT. It is just a quality-of-implementation issue that those
annotations have as little overhead as possible if NO_GETTEXT is defined.
In C, it is easy, in shell code it may be more involved.
-- Hannes
^ permalink raw reply
* [BUG] Git bisect not finding the right commit
From: Andreas J. Koenig @ 2012-01-19 3:29 UTC (permalink / raw)
To: git
My git versions
---------------
1.7.9.rc2 and 1.7.8.3 and 1.7.2.5
The example output below was produced with 1.7.8.3 as provided by debian
"git/unstable uptodate 1:1.7.8.3-1"
The result looks the same on all three versions. I did not do a
byte-by-byte comparison, but the outcome is the same.
The repository
--------------
http://perl5.git.perl.org/perl.git
Problem description
-------------------
After v5.15.5-20-gfd76d40 a merge happened and v5.15.4-110-g27b29ec
through v5.15.4-169-g3582575 were inserted. The code was developed
before v5.15.5 but merged after v5.15.5.
- A -> B -> C - D ->
\ /
- E - F -
A v5.15.5
B v5.15.5-20-gfd76d40
C v5.15.5-81-gcfe287a
D v5.15.5-159-ga71d67b
E v5.15.4-110-g27b29ec
F v5.15.4-169-g3582575
The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A
and B. Bisect did not find it, it returned me E instead. Here the wrong
bisect output:
% git bisect start v5.15.5-159-ga71d67b v5.15.5
Already on 'blead'
Bisecting: 77 revisions left to test after this (roughly 6 steps)
[cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead
% git describe
v5.15.5-81-gcfe287a
% git bisect bad
Bisecting: 40 revisions left to test after this (roughly 5 steps)
[baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html
% git describe
v5.15.4-149-gbaf7658
% git bisect bad
Bisecting: 19 revisions left to test after this (roughly 4 steps)
[fbf24e084f7e43d3caa066f3520b4c32ebbb2e3a] Start modifying test cases to suit new Pod::Html
% git describe
v5.15.4-129-gfbf24e0
% git bisect bad
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[9949917516c8bca1036187e3e878ed8869558a65] Finish skeleton version of Pod::Html
% git describe
v5.15.4-119-g9949917
% git bisect bad
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[953c3c52c300d440cb8e0811a812e78c12d45695] Remove spurious code after start of parser switch
% git describe
v5.15.4-114-g953c3c5
% git bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)
[2618a74b5307cde59d3b3111031637fbe4bfe0cf] Remove cache feature for simplicity
% git describe
v5.15.4-111-g2618a74
% git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[27b29ec338b08496d21538c0db7377d446529f8b] Remove deprecated --netscape flag
% git describe
v5.15.4-110-g27b29ec
% git bisect bad
27b29ec338b08496d21538c0db7377d446529f8b is the first bad commit
commit 27b29ec338b08496d21538c0db7377d446529f8b
Author: Marc Green <marcgreen@cpan.org>
Date: Mon May 16 23:46:07 2011 -0400
deprecated --netscape flag
:040000 040000 6759c516ef91450c73a01c5695051f31b787171e 080d58438a5c00aaaa6464f4c3a42c2ffd5f7ee0 M ext
% git version
git version 1.7.8.3
What I expected
---------------
The above result is wrong, git should have found v5.15.5-13-gff0cf12.
Git seemingly did not consider the revisions between v5.15.5 and
v5.15.5-20-gfd76d40.
Let me know if you need further informations. (I'm not subscribed to the
mailing list.)
Thanks && Regards,
--
andreas
^ permalink raw reply
* Re: Cannot push a commit
From: Jeff King @ 2012-01-19 2:09 UTC (permalink / raw)
To: Matthias Fechner; +Cc: git
In-Reply-To: <4F170E7E.9000804@fechner.net>
On Wed, Jan 18, 2012 at 07:25:02PM +0100, Matthias Fechner wrote:
> Am 17.01.2012 08:35, schrieb Matthias Fechner:
> > So the problem has something to do with windows as client. I will do
> > some additional test this evening.
> >
> > Where can we continue to search?
> [...]
> Then I opened the git bash and inserted:
> export GIT_SSH=plink.exe
> git push
> [...]
Thanks for following up on this. It does seem like openssh is dropping
your connection in a half-duplex way, though we don't know why. A bug in
openssh sounds like a reasonable candidate...
> The currently installed version is OpenSSH_4.6p1, OpenSSL 0.9.8e 23
> Feb 2007. Maybe an updated openssh version in the git bin folder will
> solve the problem?
Especially given how old your version is. Certainly I would try with a
more recent version. If it clears up the problem, I'm willing to assume
it's an openssh bug that's been fixed. If it doesn't, then it may be an
open openssh bug, or perhaps there is some problem in the way we're
invoking it on Windows. We can investigate that path if need be.
-Peff
^ permalink raw reply
* [ANNOUNCE] Git 1.7.9.rc2
From: Junio C Hamano @ 2012-01-19 1:16 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.9.rc2 is available for testing.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4eeaaf8a73006f797e6c23455097684664bf256e git-1.7.9.rc2.tar.gz
22aad76c146abe04e8f9bd89b2fbf4b575f434ce git-htmldocs-1.7.9.rc2.tar.gz
8565f64f6227fcfba3f768dabdcd9d6037f08842 git-manpages-1.7.9.rc2.tar.gz
Also the following public repositories all have a copy of the v1.7.9.rc2
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.9 Release Notes (draft)
========================
Updates since v1.7.8
--------------------
* gitk updates accumulated since early 2011.
* git-gui updated to 0.16.0.
* git-p4 (in contrib/) updates.
* Git uses gettext to translate its most common interface messages
into the user's language if translations are available and the
locale is appropriately set. Distributors can drop in new PO files
in po/ to add new translations.
* The code to handle username/password for HTTP transaction used in
"git push" & "git fetch" learned to talk "credential API" to
external programs to cache or store them, to allow integration with
platform native keychain mechanisms.
* The prompted input in the terminal use our own getpass() replacement
when possible. HTTP transactions used to ask username without echoing
back what was typed, but with this change you will see it as you type.
* The internal of "revert/cherry-pick" has been tweaked to prepare
building more generic "sequencer" on top of the implementation that
drives them.
* "git rev-parse FETCH_HEAD" after "git fetch" without specifying
what to fetch from the command line will now show the commit that
would be merged if the command were "git pull".
* "git add" learned to stream large files directly into a packfile
instead of writing them into individual loose object files.
* "git checkout -B <current branch> <elsewhere>" is a more intuitive
way to spell "git reset --keep <elsewhere>".
* "git checkout" and "git merge" learned "--no-overwrite-ignore" option
to tell Git that untracked and ignored files are not expendable.
* "git commit --amend" learned "--no-edit" option to say that the
user is amending the tree being recorded, without updating the
commit log message.
* "git commit" and "git reset" re-learned the optimization to prime
the cache-tree information in the index, which makes it faster to
write a tree object out after the index entries are updated.
* "git commit" detects and rejects an attempt to stuff NUL byte in
the commit log message.
* "git commit" learned "-S" to GPG-sign the commit; this can be shown
with the "--show-signature" option to "git log".
* fsck and prune are relatively lengthy operations that still go
silent while making the end-user wait. They learned to give progress
output like other slow operations.
* The set of built-in function-header patterns for various languages
knows MATLAB.
* "git log --format='<format>'" learned new %g[nNeE] specifiers to
show information from the reflog entries when warlking the reflog
(i.e. with "-g").
* "git pull" can be used to fetch and merge an annotated/signed tag,
instead of the tip of a topic branch. The GPG signature from the
signed tag is recorded in the resulting merge commit for later
auditing.
* "git log" learned "--show-signature" option to show the signed tag
that was merged that is embedded in the merge commit. It also can
show the signature made on the commit with "git commit -S".
* "git branch --edit-description" can be used to add descriptive text
to explain what a topic branch is about.
* "git fmt-merge-msg" learned to take the branch description into
account when preparing a merge summary that "git merge" records
when merging a local branch.
* "git request-pull" has been updated to convey more information
useful for integrators to decide if a topic is worth merging and
what is pulled is indeed what the requestor asked to pull,
including:
- the tip of the branch being requested to be merged;
- the branch description describing what the topic is about;
- the contents of the annotated tag, when requesting to pull a tag.
* "git pull" learned to notice 'pull.rebase' configuration variable,
which serves as a global fallback for setting 'branch.<name>.rebase'
configuration variable per branch.
* "git tag" learned "--cleanup" option to control how the whitespaces
and empty lines in tag message are cleaned up.
* "gitweb" learned to show side-by-side diff.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.7.8
------------------
Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
releases are contained in this release (see release notes to them for
details).
----------------------------------------------------------------
Changes since v1.7.9-rc1 are as follows:
Jakub Narebski (2):
gitweb: Fix file links in "grep" search
gitweb: Harden "grep" search against filenames with ':'
Jeff King (3):
unix-socket: handle long socket pathnames
credential-cache: report more daemon connection errors
credential-cache: ignore "connection refused" errors
Jonathan Nieder (1):
unix-socket: do not let close() or chdir() clobber errno during cleanup
Junio C Hamano (4):
pulling signed tag: add howto document
Git 1.7.7.6
Git 1.7.8.4
Git 1.7.9-rc2
Michael Haggerty (2):
git-show-ref: fix escaping in asciidoc source
git-show-ref doc: typeset regexp in fixed width font
Nguyễn Thái Ngọc Duy (3):
Document limited recursion pathspec matching with wildcards
diff-index: enable recursive pathspec matching in unpack_trees
diff-index: enable recursive pathspec matching in unpack_trees
Thomas Rast (1):
word-diff: ignore '\ No newline at eof' marker
^ permalink raw reply
* [ANNOUNCE] Git 1.7.8.4
From: Junio C Hamano @ 2012-01-19 1:15 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.7.8.4 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
add7b05f26216181d1b148dde298432132552b0f git-1.7.8.4.tar.gz
ac2b89d8d4418c7633ee2344e89eb7dfcb81522a git-htmldocs-1.7.8.4.tar.gz
4372c423a0d2f7df33b5b39727a81f0a7b40669d git-manpages-1.7.8.4.tar.gz
Also the following public repositories all have a copy of the v1.7.8.4
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.8.4 Release Notes
==========================
Fixes since v1.7.8.3
--------------------
* The code to look up attributes for paths reused entries from a wrong
directory when two paths in question are in adjacent directories and
the name of the one directory is a prefix of the other.
* A wildcard that matches deeper hierarchy given to the "diff-index" command,
e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
matching files even when there is no change.
* When producing a "thin pack" (primarily used in bundles and smart
HTTP transfers) out of a fully packed repository, we unnecessarily
avoided sending recent objects as a delta against objects we know
the other side has.
* "git send-email" did not properly treat sendemail.multiedit as a
boolean (e.g. setting it to "false" did not turn it off).
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.8.3 are as follows:
Jeff King (5):
send-email: multiedit is a boolean config option
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Junio C Hamano (11):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Prepare for 1.7.8.4
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Update draft release notes to 1.7.8.4
Git 1.7.7.6
Git 1.7.8.4
Nguyễn Thái Ngọc Duy (2):
t2203: fix wrong commit command
diff-index: enable recursive pathspec matching in unpack_trees
^ permalink raw reply
* [ANNOUNCE] Git 1.7.7.6
From: Junio C Hamano @ 2012-01-19 1:14 UTC (permalink / raw)
To: git
An maintenance release Git 1.7.7.6 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
483dc95de0e26f0154fb23444589266b59848cfe git-1.7.7.6.tar.gz
8bcbd0a53fd3b937a9991aa096220a1a0eb2f771 git-htmldocs-1.7.7.6.tar.gz
0fd7452c88d0b3ccb08d9b2b91b552680b0209e0 git-manpages-1.7.7.6.tar.gz
Also the following public repositories all have a copy of the v1.7.7.6
tag and the maint-1.7.7 branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.7.6 Release Notes
==========================
Fixes since v1.7.7.5
--------------------
* The code to look up attributes for paths reused entries from a wrong
directory when two paths in question are in adjacent directories and
the name of the one directory is a prefix of the other.
* A wildcard that matches deeper hierarchy given to the "diff-index" command,
e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
matching files even when there is no change.
* When producing a "thin pack" (primarily used in bundles and smart
HTTP transfers) out of a fully packed repository, we unnecessarily
avoided sending recent objects as a delta against objects we know
the other side has.
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.7.5 are as follows:
Clemens Buchacher (1):
Documentation: read-tree --prefix works with existing subtrees
Jack Nagel (1):
Add MYMETA.json to perl/.gitignore
Jeff King (4):
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Jens Lehmann (1):
docs: describe behavior of relative submodule URLs
Junio C Hamano (8):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Git 1.7.7.6
Nguyễn Thái Ngọc Duy (2):
t2203: fix wrong commit command
diff-index: enable recursive pathspec matching in unpack_trees
Thomas Rast (1):
Documentation: rerere.enabled is the primary way to configure rerere
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Junio C Hamano @ 2012-01-19 1:00 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Neal Kreitzinger, git
In-Reply-To: <4F1764B9.90907@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
>> Have you checked where in the filesystem hierarchy that script is run
>> (hint: pwd)?
>>
> echo pwd in post-update echoes /path/WORKTREE/.git in git-push stdout.
> ...
> 'git-checkout -f' works manually, but in post-update hook...
Stronger hint. Did you run "git checkout -f" in /path/WORKTREE/.git to
back that "works manually" claim?
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-19 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vwr8oljq7.fsf@alter.siamese.dyndns.org>
On 1/18/2012 4:38 PM, Junio C Hamano wrote:
> Neal Kreitzinger<nkreitzinger@gmail.com> writes:
>
>> hooks/post-update is:
>>
>> git stash save
>> echo "worktree+index of non-bare remote current branch stashed for safety"
>> git reset --hard
>> echo "git-reset --hard on current remote branch to ensure clean state"
>>
>> message is echoed, but git-reset --hard does not appear to have really
>> worked. (git 1.7.1)
>
> Have you checked where in the filesystem hierarchy that script is run
> (hint: pwd)?
>
echo pwd in post-update echoes /path/WORKTREE/.git in git-push stdout.
> Also it is unclear why you keep saying "stash". What kind of changes are
> you expecting to be saved to the stash? Will they be changes that are not
> source controlled that you would rather not to see? In other words, after
> running "stash" every time somebody pushes and having accumulated many
> stash entries, when do you plan to pop these stashed changes?
>
good point. rejection of dirty worktree is a cleaner safety.
> I would have expect that such a repository to reject a push if the working
> tree is dirty, and run checkout in post-update, though.
>
'git-checkout -f' works manually, but in post-update hook it leaves
behind dirty worktree, ie. index and HEAD match, but worktree still
matches HEAD@{1}. This is the same undesired result git-stash and
git-reset --hard leave behind when executed in post-update hook.
v/r,
neal
^ permalink raw reply
* Re: Unexpected "clean -Xd" behavior
From: Jonathan Nieder @ 2012-01-19 0:29 UTC (permalink / raw)
To: Pete Harlan
Cc: Git Mailing List, Nguyễn Thái Ngọc Duy,
Shawn Bohrer
In-Reply-To: <4F1384AE.1050209@pcharlan.com>
(+cc: Duy, Shawn)
Hi,
Pete Harlan wrote:
> When a directory contains nothing but an ignored subdirectory, that
> subdirectory does not get removed by "git clean -Xdf".
>
> For example, in a new directory:
>
> # git init
> Initialized empty Git repository in /tmp/foo/.git/
> # echo a/ >.gitignore
> # git add .gitignore
> # git commit -m "Initial commit"
> [master (root-commit) c3af24c] Initial commit
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 .gitignore
> # mkdir -p foo/a
> # touch foo/a/junk.o
> # git status
> # On branch master
> nothing to commit (working directory clean)
> # git clean -Xdn # <--- DOES NOT MENTION foo/a
> # touch foo/x.c
> # git clean -Xdn # <--- DITTO WITH UNTRACKED IN foo
> # git add foo/x.c
> # git clean -Xdn # <--- WITH TRACKED IN foo, WILL REMOVE a/
> Would remove foo/a/
> #
>
> Is this intentional? It's interfering with my using "git clean" to
> remove built objects, which happen to be in a dedicated temporary
> subdirectory.
Sounds like a bug. Duy, Shawn, any hints?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-19 0:17 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <CACBZZX4tB6DGV-1tiuOamq7ACPk0a-=1Pb9Vk1SgyDqAq-EFOw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
> ...
>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>> whether it works, or not.
>
> That's not what NO_GETTEXT means, and not what it *should* mean. It
> means that your output won't be translated, but we might still make
> use of a locally installed library to provide the gettext() and
> eval_gettext() functions.
You are right.
In the current approach we take for shell scripts, we cannot have "No i18n
whatsoever and messages are emit with printf and echo". We always have to
go through gettext/eval_gettext even though they may be an implementation
that does not do i18n at all.
> Now I haven't done exhaustive tests but this is the sort of slowdown
> we might be looking at on Linux for output,...
I think we judged that it is OK not to worry about the performance of
message generation, back when we decided to take the current approach.
> Anyway speed is the least of the issues here, it's not like we're very
> constrained by spewing out gettext output.
>
> I just think we should consider portability more carefully than "it
> doesn't work on one obscure setup, let's change it everywhere", when
> actually it's working just fine in most places.
> ...
> But in summary: We shouldn't be *always* using fallback functions
> whether they're the C stuff in compat/* or the gettext fallbacks in
> git-sh-i18n.sh just because there's some version out there of the
> system-supplied functions that's broken.
>
> It makes sense to prefer the system functions by default in both
> cases, but when the OS one can be broken or lacking we can just add
> probes or Makefile options like we do for fnmatch() with the
> NO_FNMATCH_CASEFOLD switch.
So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext
in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is
that correct?
If that is the case, should we do something like
LANG=C LC_ALL=C
export LANG LC_ALL
in our shell scripts, when building for NO_GETTEXT target?
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Jonathan Nieder @ 2012-01-19 0:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Alex Riesen, Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4tB6DGV-1tiuOamq7ACPk0a-=1Pb9Vk1SgyDqAq-EFOw@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> That's not what NO_GETTEXT means, and not what it *should* mean. It
> means that your output won't be translated, but we might still make
> use of a locally installed library to provide the gettext() and
> eval_gettext() functions.
>
> This approach has worked everywhere so far (Linux, OSX, *BSD etc.),
> and you want to change *everywhere* because you have some completely
> broken Cygwin install.
I thought NO_GETTEXT meant either "I'm aware that there is this new
translation feature, and it may or may not be useful to me some day,
but no thanks for now, since I cannot tolerate the possibility of
regressions" (i.e., opting out of a new feature) or "my platform does
not have suitable gettext infrastructure so please do not use it"
(i.e., reducing build-time dependencies by making some optional).
"I don't want localized messages" is spelled as "LC_MESSAGES=C; export
LC_MESSAGES", not as "make NO_GETTEXT=YesPlease".
I guess I am wondering, does the approach in Alex's patch have the
potential to cause actual problems? If it doesn't, I don't see what
there is to complain about.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Jonathan Nieder @ 2012-01-19 0:12 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20120118195438.GA18892@blimp.dmz>
Hi,
Alex Riesen wrote:
> [Subject: i18n: disable i18n for shell scripts if NO_GETTEXT define]
>
> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
> It is very unexpected.
Sounds like a good idea. Quick comments:
[...]
> --- a/git-sh-i18n.sh
> +++ b/git-sh-i18n.sh
> @@ -16,61 +16,44 @@ else
> fi
> export TEXTDOMAINDIR
>
> -if test -z "$GIT_GETTEXT_POISON"
> +GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
> +if test -n "@@NO_GETTEXT@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
> +then
> + : no probing necessary
> +elif test -n "$GIT_GETTEXT_POISON"
> then
> - if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
> - then
> +elif test -n type gettext.sh >/dev/null 2>&1
> +then
I like the unindenting. Alas, I get
1: test: type: unexpected operator
I suspect this should just say "elif type gettext.sh >/dev/null 2>&1".
The rest looks good. Thanks for writing it.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Ævar Arnfjörð Bjarmason @ 2012-01-18 23:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CALxABCadHdvR02Br9e6STy0w+EPoycUKr62RiSUSP_EPF-TH3g@mail.gmail.com>
On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Wed, Jan 18, 2012 at 16:22, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> On Tue, Jan 17, 2012 at 14:42, Alex Riesen <raa.lkml@gmail.com> wrote:
>>> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
>>> It is very unexpected.
>>
>> So the reason it's like that is that I was assuming that gettext.sh
>> wouldn't be FUBAR anywhere, but the translations shouldn't kick in
>> since we haven't installed them during "make install".
>>
>> But I wonder if this negatively affects some systems, now we now:
>>
>> * Don't use gettext.sh, which means that we're using our fallback
>> shell function instead of the binary gettext(1), which is probably
>> faster.
>>
>> * Use our own eval_gettext() instead of using the system one, which
>> uses the GNU binary which is more likely to be in the FS cache
>> already since other programs are probably using it.
>>
>> Which is why I didn't do something like this to begin with.
>
> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
> whether it works, or not.
That's not what NO_GETTEXT means, and not what it *should* mean. It
means that your output won't be translated, but we might still make
use of a locally installed library to provide the gettext() and
eval_gettext() functions.
This approach has worked everywhere so far (Linux, OSX, *BSD etc.),
and you want to change *everywhere* because you have some completely
broken Cygwin install.
How did you even get that install? Is it a known issue? Some ancient
now-fixed bug? What version of Cygwin / gettext etc.
Now I'm not saying that we shouldn't fix this, I just don't think that
this is the right way to go about it.
Now I haven't done exhaustive tests but this is the sort of slowdown
we might be looking at on Linux for output, both with warm cache:
$ cat our-eval_gettext.sh
#!/bin/bash
eval_gettext () {
printf "%s" "$1" | (
export PATH $(git sh-i18n--envsubst --variables "$1");
git sh-i18n--envsubst "$1"
)
}
for i in {1..1000}
do
some_variable="for speed"
eval_gettext "benchmark this \$some_variable"
done
$ time bash our-eval_gettext.sh >/dev/null
real 0m3.336s
user 0m0.052s
sys 0m0.128s
Compared to using the system eval_gettext, which for me is much
faster:
$ cat system-eval_gettext.sh
#!/bin/bash
. gettext.sh
for i in {1..1000}
do
some_variable="for speed"
eval_gettext "benchmark this \$some_variable"
done
$ time bash system-eval_gettext.sh >/dev/null
real 0m1.671s
user 0m0.048s
sys 0m0.140s
And then we have the gettext() function itself:
$ cat our-gettext.sh
#!/bin/bash
gettext () {
printf "%s" "$1"
}
for i in {1..1000}
do
gettext "benchmark this"
done
$ cat system-gettext.sh
#!/bin/bash
for i in {1..1000}
do
gettext "benchmark this"
done
Where our fallback is faster, because printf() is a bash built-in:
$ time bash system-gettext.sh >/dev/null
real 0m0.534s
user 0m0.016s
sys 0m0.084s
$ time bash our-gettext.sh >/dev/null
real 0m0.018s
user 0m0.016s
sys 0m0.000s
Anyway speed is the least of the issues here, it's not like we're very
constrained by spewing out gettext output.
I just think we should consider portability more carefully than "it
doesn't work on one obscure setup, let's change it everywhere", when
actually it's working just fine in most places.
I think a better fix would be to add probes for whether the system
functions actually work in the autoconf script.
I'd also love to be able to use C macros in the git-*.sh scripts, it
would make the code in git-sh-i18n.sh much nicer since we can
determine what functions we want at compile time.
Another option would be to pipe our shellscripts through some
pre-processor that would completely remove the gettext and
eval_gettext calls. Then we'd be doing the same thing we're doing on
the C-Level, and we wouldn't have the previously cited command-call
overhead or Win32.
But in summary: We shouldn't be *always* using fallback functions
whether they're the C stuff in compat/* or the gettext fallbacks in
git-sh-i18n.sh just because there's some version out there of the
system-supplied functions that's broken.
It makes sense to prefer the system functions by default in both
cases, but when the OS one can be broken or lacking we can just add
probes or Makefile options like we do for fnmatch() with the
NO_FNMATCH_CASEFOLD switch.
^ permalink raw reply
* Re: Checking out orphans with -f
From: Junio C Hamano @ 2012-01-18 23:12 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201201181550.23792.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> Actually, no I can't. I can check out some other branch
> (assuming I have one), but I cannot then delete a, it
> appears to already be deleted by virtue of checking out
> another branch. I like that since I never checked it in,
> better to clean up the garbage.
Good.
> ...but why can't I then
> checkout another orphan to do the same thing?
I am not surprised if the original contributor who wanted to add --orphan
did not address corner cases. It is very plausible that we did not try as
hard to nitpick the code for complete support of such corner cases as I
and other contributors usually do for more important features.
So... Patches welcome ;-)
Having said that, there are many things to consider to fill the corner
case you seem to be interested to add support for.
The "orphaned" state is like immediately after "git init". Because you do
not have any current commit, you cannot create an orphan branch based the
state immediately after "git init", either. You are nominally on your
'master' branch, but it does not have anything yet; you are expected to
turn it into a real branch by creating a commit soon, but until you do so,
you are kind of in-limbo. It is understandable that there will be many
operations that will not make any sense until you first get out of this
in-limbo state. For example, you cannot (and do not have to) delete the
branch and if you have a commit (e.g. you can fetch one from another
place) you can check it out and the 'master' will be gone, because you
never created it in the first place.
^ permalink raw reply
* Interesting behavior in git mergetool with no BASE revision
From: Jason Wenger @ 2012-01-18 23:05 UTC (permalink / raw)
To: git
Doing a git merge on 1.7.4.3, on a case where both branches have a
file created, and the base does not. Per git-mergetool:
"the configured command line will be invoked with $BASE set to the
name of a temporary file containing the common base for the merge, if
available;"
So testing in this case, I set my mergetool cmd as "echo $MERGED
$LOCAL $REMOTE $BASE", and I get the following:
cio/.cproject ./cio/.cproject.LOCAL.9029.cproject
./cio/.cproject.REMOTE.9029.cproject
./cio/.cproject.BASE.9029.cproject
ls -a cio shows the following files:
.cproject
.cproject.LOCAL.9325.cproject
.cproject.BACKUP.9325.cproject
.cproject.REMOTE.9325.cproject
So the lack of base file makes sense -- There is no base to start
from. However, $BASE evaluates to ./cio/.cproject.BASE.9029.cproject,
which is a nonexistent file. This makes my actual mergetool upset to
no end. Intuitively from documents, I would expect $BASE to evaluate
to an empty string in this case.
Is this intended behavior?
--Jason C. Wenger
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-18 22:56 UTC (permalink / raw)
To: Dieter Plaetinck; +Cc: git
In-Reply-To: <1326923544-8287-1-git-send-email-dieter@plaetinck.be>
Dieter Plaetinck <dieter@plaetinck.be> writes:
> There is no need to restrict use of --ignore-missing to dry runs,
> it can be useful to ignore missing files during normal operation as
> well.
>
> Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
Sorry, but for this kind of change, we would want to see a justification
that is much better than that. The default around here is not to change an
established behaviour without a good reason.
Have you dug into the list archive to see _why_ we decided not to allow
this option in the real run in the first place? You would need to find "By
letting the command ignore missing paths, the user can get into X and Y
situations and we would want to avoid it. We however need to give users a
way to see if there is something missing, hence we add it when we are
under dry-run option." and refute that previous justification, arguing why
X and Y is something we should _not_ be worrying about, to make a good
case for this change.
In this particular case, my gut feeling is that this might a change in the
good direction (but I strongly suspect that I am not recalling the real
reason why we didn't allow it when we introduced this option).
If somebody is writing a script using "git add" (which is not recommended
to begin with), it is tempting to say 'git add $list_of_possible_files' in
such a script when the script _knows_ that the list it is giving to "git
add" may contain a path that does not exist, and wants to ignore missing
ones.
But then the script could easily filter what does not exist before
compiling such a list, so that is not a very strong reason to advocate
it.
^ permalink raw reply
* Re: Checking out orphans with -f
From: Martin Fick @ 2012-01-18 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjcljmj.fsf@alter.siamese.dyndns.org>
On Wednesday, January 18, 2012 03:40:36 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> > I am trying to write some scripts which do various
> > things to a git repo and I have run into a issue where
> > I think that git behavior with respect to orphan
> > branches is potentially
> >
> > undesirable. If I type:
> > git checkout --orphan a
> >
> > I cannot easily abandon this state
>
> What do you mean by "abandon"?
>
> If you want to remove a branch "a" because you do not
> need it, you can check out some other branch and say
> "git branch -D a", no?
Actually, no I can't. I can check out some other branch
(assuming I have one), but I cannot then delete a, it
appears to already be deleted by virtue of checking out
another branch. I like that since I never checked it in,
better to clean up the garbage, but why can't I then
checkout another orphan to do the same thing?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: found some code...
From: Holger Hellmuth @ 2012-01-18 22:45 UTC (permalink / raw)
To: Ron Eggler; +Cc: Andrew Ardill, git
In-Reply-To: <CAHxBh_QiZzJP2jS6rMpC1c=P8uXSbFWumbcnHj3ArkQB4sXyPQ@mail.gmail.com>
Mmh, your reply here didn't make it to the mailing list, maybe because
it was multipart with html(??) or it just got lost.
Am 18.01.2012 18:57, schrieb Ron Eggler:
> Try "git update-index --refresh", more info in this recent thread
> "http://comments.gmane.org/__gmane.comp.version-control.__git/188291
> <http://comments.gmane.org/gmane.comp.version-control.git/188291>"
>
>
> I got this outputand nothing really changed(generally using TortoiseGit
> on Windows but did this in the provided bash shell):
> $ git update-index --refresh
> MCU2.COF.txt: needs update
> MCU2.bak: needs update
> MCU2.c: needs update
> MCU2.esym: needs update
> MCU2.h: needs update
> MCU2.hex: needs update
> MCU2.lst: needs update
> MCU2.mcp: needs update
[...]
Ok, "needs update" seems to be the non-porcelain version of 'M' (why 'M'
is more porcelain than "needs update" is a mystery to me ;-) respective
"Changes not staged for commit" in git status.
Well, what does it say when you do "git diff MCU2.h" ? There are 2
possibilities:
1) You see code differences. In that case you should be able to
recognize where and when these changes were comitted or not.
2) You see no difference or every line is listed as different even
though they seem to be equal. Possible reason is a mixup of line endings
as git on windows has to convert \r\n line endings to \n line endings
when it checks data in. This is controlled by config variables, and
maybe your config is slightly wrong.
In that case I would create a new repo with git init in bash (not
tortoise git!), and look at .git/config. Compare that with .git/config
of your mixed up repo. Also compare with .git/config of the repo on your
usb stick. As far as I know you should have core.autocrlf set to true on
Windows.
Alternatively or for a complete picture you could do "git config -l"
which gives you also global and system configuration variables if they
exist.
Another possible reason would be file names with same name but different
case. I mention this because there is a parallel thread on this mailing
list with a problem with tortoise git and windows. See
http://git.661346.n2.nabble.com/Bug-Git-checkout-fails-with-a-wrong-error-message-td7181244.html.
As suggested in that thread you should have the option core.ignorecase set.
> Ok ,let's see:
> I "found" the piece of code on my thumbdrive and it ultimately is copied
> from my "old" working directory from the computer i don't have
> anymore... "get create new local folders" means that I actually created
> a new folder on my new machine and cloned the repo from git into it so
> this would be my new working directory... now i have the code that
> should be in there seperatetely in the directory from the thumb drive....
> Does that make any more ssense?
>
^ permalink raw reply
* Re: Checking out orphans with -f
From: Martin Fick @ 2012-01-18 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjcljmj.fsf@alter.siamese.dyndns.org>
On Wednesday, January 18, 2012 03:40:36 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> > I am trying to write some scripts which do various
> > things to a git repo and I have run into a issue where
> > I think that git behavior with respect to orphan
> > branches is potentially
> >
> > undesirable. If I type:
> > git checkout --orphan a
> >
> > I cannot easily abandon this state
>
> What do you mean by "abandon"?
>
> If you want to remove a branch "a" because you do not
> need it, you can check out some other branch and say
> "git branch -D a", no?
By abandon, I simply mean to check out another branch, which
as you point, I can almost do. I just can't do it by
checking out another orphaned branch! Why not, this seems
inconsistent? In both cases I loose what the original
orphaned branch (a) is, so why prevent me from doing it in
the one case and not the other?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: Checking out orphans with -f
From: Junio C Hamano @ 2012-01-18 22:40 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201201181207.05967.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> I am trying to write some scripts which do various things to
> a git repo and I have run into a issue where I think that
> git behavior with respect to orphan branches is potentially
> undesirable. If I type:
>
> git checkout --orphan a
>
> I cannot easily abandon this state
What do you mean by "abandon"?
If you want to remove a branch "a" because you do not need it, you can
check out some other branch and say "git branch -D a", no?
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Junio C Hamano @ 2012-01-18 22:38 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Neal Kreitzinger, git
In-Reply-To: <4F1714AD.4090706@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
> hooks/post-update is:
>
> git stash save
> echo "worktree+index of non-bare remote current branch stashed for safety"
> git reset --hard
> echo "git-reset --hard on current remote branch to ensure clean state"
>
> message is echoed, but git-reset --hard does not appear to have really
> worked. (git 1.7.1)
Have you checked where in the filesystem hierarchy that script is run
(hint: pwd)?
Also it is unclear why you keep saying "stash". What kind of changes are
you expecting to be saved to the stash? Will they be changes that are not
source controlled that you would rather not to see? In other words, after
running "stash" every time somebody pushes and having accumulated many
stash entries, when do you plan to pop these stashed changes?
I would have expect that such a repository to reject a push if the working
tree is dirty, and run checkout in post-update, though.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Marc Branchaud @ 2012-01-18 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uqwmyt6.fsf@alter.siamese.dyndns.org>
On 12-01-18 05:27 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> It might be better to just move the footnote to the end of the next sentence.
>
> Ok. How does this version look? The highlights are:
>
> * remove footnotes and spell them out inline, like "Note that..."
>
> * "a single liner" -> "a one-liner"
IMO "one-liner" should be "one-line", but toMAYto toMAHto...
The rest looks good.
M.
^ 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