Re: [PATCH] Improve user-manual html and pdf formatting

Jonathan Nieder jrnieder at gmail.com writes: Hi, Thomas Ackermann wrote: --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt at at -1,5 +1,5 at at -Git User Manual +#65279;Git User Manual Why? Puzzled, Jonathan That's a Unicode Byte Order

Re: [PATCH] Improve user-manual html and pdf formatting

Andreas Schwab schwab at linux-m68k.org writes: That's a Unicode Byte Order Mark. No, its an ampersand, a hash, a number and a semicolon. Definitely not a BOM. Andreas. You're right, of course :) I was a bit hasty. #65279; is a HTML entity (or at least something like looks like one)

[PATCH v3] stash: handle specifying stashes with spaces

of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast t...@thomasrast.ch Signed-off-by: Øystein Walle oys...@gmail.com --- v3 uses the same eval/--sq technique as v2

Re: [PATCH v3] stash: handle specifying stashes with spaces

Junio C Hamano gitster at pobox.com writes: Thomas Rast tr at thomasrast.ch writes: Junio C Hamano gitster at pobox.com writes: This is brittle. If new tests are added before this, the test_tick will give you different timestamp and this test will start failing. Perhaps grab

[PATCH] Documentation: fix typos in man pages

Signed-off-by: Øystein Walle oys...@gmail.com --- In July I sent in some typo fixes but it halted in a discussion on UK vs. US English and so forth ($gmane/231331). There were some actual typo fixes in there though (in addition to the opinionated typo fixes). Powering up my old laptop

Re: git best strategy for two version development

Carlos Pereira jose.carlos.pereira at ist.utl.pt writes: Hello, I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses

[PATCH] for-each-ref: add option to omit newlines

Even when having specified a format string for-each-ref still prints a newline after printing each ref according to the format. This breaks splitting the output on newlines, for example. Signed-off-by: Øystein Walle oys...@gmail.com --- I was somewhat surprised by this behaviour; I expected

Re: [PATCH] for-each-ref: add option to omit newlines

Øystein Walle oystwa at gmail.com writes: splitting the output on newlines, for example. Ugh, I mean on null bytes, naturally. Øsse. -- 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

Re: [PATCH] for-each-ref: add option to omit newlines

Junio C Hamano gitster at pobox.com writes: I would rather see us go in the direction to add -z output option, which is what everybody else that produces NUL terminated entries in our suite of subcommands does. I agree that -z would help in this case and I very much appreciate that option

Re: [PATCH] for-each-ref: add option to omit newlines

Junio C Hamano gitster at pobox.com writes: I very well understand that. All other commands that support -z to give you NUL terminated output do not consider that a downside. Why should for-each-ref be special? After I discovered log also has this there is nothing special about

Re: [PATCH v7 00/11] Add interpret-trailers builtin

Junio C Hamano gitster at pobox.com writes: ... is easier to read and maintain if written like so (with using HT properly---our MUAs may damage it and turn the indentation into spaces): ... sed -e s/ Z$/ / expect -\EOF Fixes: Z Acked-by= Z

Re: [BUG (maybe)] git rev-parse --verify --quiet isn't quiet

Junio C Hamano gitster at pobox.com writes: Junio C Hamano gitster at pobox.com writes: I would suspect that this may be fine. rev-parse --verify makes sure the named object exists, but in this case at {u} does not even name any object, does it? Hmph, but rev-parse --verify

Re: [PATCH v3] completion: ignore chpwd_functions when cding on zsh

Brandon Turner bt at brandonturner.net writes: Software, such as RVM (ruby version manager), may set chpwd functions that result in an endless loop when cding. chpwd functions should be ignored. Now that it has moved to the zsh-specific script you can achieve this more simply by using cd

Re: [PATCH v3] completion: ignore chpwd_functions when cding on zsh

Junio C Hamano gitster at pobox.com writes: Øystein Walle oystwa at gmail.com writes: Brandon Turner bt at brandonturner.net writes: Software, such as RVM (ruby version manager), may set chpwd functions that result in an endless loop when cding. chpwd functions should

Re: [PATCH v4] completion: ignore chpwd_functions when cding on zsh

Brandon Turner bt at brandonturner.net writes: +__git_ls_files_helper () +{ + ( + test -n ${CDPATH+set} unset CDPATH + cd -q $1 + if [ $2 == --committable ]; then + git diff-index --name-only --relative HEAD + else

Re: [PATCH v4] completion: ignore chpwd_functions when cding on zsh

Brandon Turner bt at brandonturner.net writes: On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano gitster at pobox.com wrote: Actually the patch was slightly wrong. It did not quite matter as cd '' is a no-op, but git -C '' cmd is not that lenient (which may be something we may want to fix)

[PATCH] Documentation: fix typos in man pages

Signed-off-by: Øystein Walle oys...@gmail.com --- I thought I'd take part in the typo fixing frenzy :) I have some other potential typos lines up. Right now the docs refer to both 'filesystem' and 'file system', as well as both 'testsuite' and 'test suite'. I think words like these are generally

Re: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?

and newer versions of Git. Best regards, Øystein Walle -- 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: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?

Karsten Blees karsten.blees at gmail.com writes: at Øystein: in the meantime, could you check if this fixes the problem for you? --- 8 --- diff --git a/dir.c b/dir.c index a5926fb..13858fe 100644 --- a/dir.c +++ b/dir.c at at -821,6 +821,9 at at static void prep_exclude(struct

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

Junio C Hamano gitster at pobox.com writes: * kb/status-ignored-optim-2 (2013-05-29) 1 commit - dir.c: fix ignore processing within not-ignored directories Fix 1.8.3 regressions in the .gitignore path exclusion logic. Hi, I see that the Tested-by line in kb/status-ignored-optim-2

[PATCH RFC] show-branch: use pager

This is for consistency with other porcelain commands such as 'log'. Signed-off-by: Øystein Walle oys...@gmail.com --- The rationale for this patch I hope is consicely explained in the commit message. I was rather surprised it didn't use a pager as I've gotten used to it for most commands. I

[PATCH v2] show-branch: use pager

This is for consistency with other porcelain commands such as 'log'. Signed-off-by: Øystein Walle oys...@gmail.com --- Hi, Jeff Thanks for the (fast!) feedback and good to hear it won't cause any trouble. I hadn't actually noticed this mechanism of setting up the pager before now but I fully

Re: [PATCH 2/4] git-prompt.sh: refactor colored prompt code

Eduardo R. D'Avila erdavila at gmail.com writes: + local c_red='\[\e[31m\]' + local c_green='\[\e[32m\]' + local c_lblue='\[\e[1;34m\]' + local c_clear='\[\e[0m\]' fi - local c_red='\e[31m' - local c_green='\e[32m' - local

Re: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!

Ville Walveranta walveranta at gmail.com writes: git-rev-parse --is-inside-git-dir outputs fatal: Not a git repository (or any of the parent directories): .git, instead of false when outside of a git directory. --is-inside-work-tree behaves the same way. Both commands work correctly (i.e.

[PATCH] stash: handle specifying stashes with spaces

the positional arguments as the options are processed; the number of arguments left is then the number we're after. Add quotes where necessary. Also add a test that verifies correct behaviour. Signed-off-by: Øystein Walle oys...@gmail.com --- This is perhaps an esoteric use case but it's still

[PATCH v2] stash: handle specifying stashes with spaces

of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast t...@thomasrast.ch Signed-off-by: Øystein Walle oys...@gmail.com --- Many thanks to Thomas Rast for helping me

Re: [PATCH v2] stash: handle specifying stashes with spaces

Thomas Rast tr at thomasrast.ch writes: I wonder what we would lose by dropping the --symbolic in the line I quoted above (which is the second parsing pass), so that it resolves to a SHA1. We would gain some robustness, as I'm not sure $REV: works correctly in the face of weird revision

Re: git stash doesn't honor --work-tree or GIT_WORK_TREE

Aaron Brooks aaron at brooks1.net writes: Unlike other commands, git stash doesn't work outside of the worktree, even when --work-tree is specified: (...) It looks like the require_work_tree function should check the environment variables in addition to the status of the PWD (via

Re: git stash doesn't honor --work-tree or GIT_WORK_TREE

Duy Nguyen pclouds at gmail.com writes: It should. At the beginning of cmd_rev_parse(), setup_git_directory() is called, which will check and follow all GIT_* or their command line equivalent. I'll look into this some time later. I think I was wrong and rev-parse --is-inside-work-tree *does*

[PATCH] config: respect '~' and '~user' in mailmap.file

git_config_string() does not handle '~' and '~user' as part of the value. Using git_config_pathname() fixes this. Signed-off-by: Øystein Walle oys...@gmail.com --- config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.c b/config.c index 314d8ee..ec7af5f 100644

Re: [PATCH] config: respect '~' and '~user' in mailmap.file

Jeff King peff at peff.net writes: Makes sense. Curious if there was a reason we did not use it in the first place, I looked at the history. The reason is that mailmap.file was added in d551a48 (2009-02-08) and git_config_pathname came months later in 395de25 (2009-11-17). Retro-fitting it

Re: Git autocorrect bug

David Turner dturner at twopensource.com writes: $ cd [some existing git repo] $ git git foo WARNING: You called a Git command named 'git', which does not exist. Continuing under the assumption that you meant 'init' in 0.1 seconds automatically... fatal: internal error: work tree has

Re: Git autocorrect bug

David Turner dturner at twopensource.com writes: (I am extremely unlikely to fix this bug myself, since it only arises in very rare circumstances). I see now that `git init foo` and `git git foo` (with git corrected to init) behave differently. Is this the bug you're referring to? -- To

Re: stash-p broken?

brian m. carlson sandals at crustytoothpaste.net writes: On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote: Sorry for error -- I meant: git stash list -p, not git stash -p. On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol michael-spam at migdol.net wrote: I recently

[PATCH] commit: inform pre-commit if --amend is used

. if test $1 = amend then ... else ... fi to handle these situations. Signed-off-by: Øystein Walle oys...@gmail.com --- Documentation/githooks.txt | 3 ++- builtin/commit.c | 3 ++- t/t7503-pre-commit-hook.sh | 14 ++ 3 files changed, 18

[PATCH 0/2] pre-commit hook updates

a hook_amend variable. I'm happy to send a v3. Øystein Walle (2): t7503: use write_script to generate hook scripts commit: inform pre-commit that --amend was used Documentation/githooks.txt | 3 ++- builtin/commit.c | 3 ++- t/t7503-pre-commit-hook.sh | 20 ++-- 3

[PATCH 1/2] t7503: use write_script to generate hook scripts

Signed-off-by: Øystein Walle oys...@gmail.com --- t/t7503-pre-commit-hook.sh | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh index 984889b..99ed967 100755 --- a/t/t7503-pre-commit-hook.sh +++ b/t/t7503-pre-commit

[PATCH 2/2] commit: inform pre-commit that --amend was used

= amend; then ... else ... fi to handle these situations. Signed-off-by: Øystein Walle oys...@gmail.com --- Documentation/githooks.txt | 3 ++- builtin/commit.c | 3 ++- t/t7503-pre-commit-hook.sh | 11 +++ 3 files changed, 15 insertions(+), 2 deletions

[BUG] git rebase -X fails with merge-recursive error

Hi, I discovered this while rebasing a branch after having converted files to use LF line endings. I got around the problem by using --ignore-whitespace but the error still seems strange to me so I'm reporting it. The following script is equivalent: it creates a repo with a CRLF file, creates a

Re: Question on for-each-ref and --contains

St. Blind st.s.blind at gmail.com writes: The git-branch --contains and --merged are not very handy too, because the output is not really flexible, and the --merged works on HEAD only. `git branch --merged foo` will list branches that are merged in the history of 'foo'. And the

[PATCH] fetch: add configuration for making --all default

Fetching from all remotes by default is useful if you're working on a repo with few and/or fast remotes. It also lets you fetch from origin even if the current branch's upstream is elsewhere without specifying it explicitly. Signed-off-by: Øystein Walle oys...@gmail.com --- This is scratching

[PATCH v2] fetch: add configuration for making --all default

Fetching from all remotes by default is useful if you're working on a repo with few and/or fast remotes. It also lets you fetch from origin even if the current branch's upstream is elsewhere without specifying it explicitly. Signed-off-by: Øystein Walle oys...@gmail.com --- Thanks for the quick

Re: [PATCH] Pass amend to pre-commit hook

Jeff King peff.net> writes: > > On Mon, Sep 14, 2015 at 01:14:20PM +0100, Alan Clucas wrote: > > > Pass a single parameter 'amend' to the pre-commit hook when performing a > > commit amend. > > I think this is a sensible thing to want, and it has come up a few > times. I'm not sure why the

[PATCH] for-each-ref: add %(upstream:gone) to mark missing refs

s not exist or an empty string otherwise, analogous to git branch -vv. Signed-off-by: Øystein Walle <oys...@gmail.com> --- Documentation/git-for-each-ref.txt | 5 +++-- ref-filter.c | 10 +- t/t6300-for-each-ref.sh| 12 3 files changed, 24

Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs

On 25 August 2016 at 07:56, Karthik Nayak wrote: > > I'm thinking more on the lines of `%(upstream)` being an atom and the > `:track` being an option under that atom. I like sub-atom though ;) > On second thought maybe "quark" is better :P > On Thu, Aug 25, 2016 at 12:03

Re: [PATCH] stash: allow ref of a stash by index

Pasting text into Gmail's web interface is not conducive to sending tabs through the intertubes. But you get the idea.. Øsse

Re: [PATCH] stash: allow ref of a stash by index

Hi, guys I like this idea. It makes stash easier and quicker to use, and it "hides" the fact that it uses the reflog for keeping track of the made stashes. *Not* to say I discourage interested people from peeking under the hood. I just think it's nice to sometimes think of the stash as a separate

[PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs

s not exist or an empty string otherwise, analogous to git branch -vv. Signed-off-by: Øystein Walle <oys...@gmail.com> --- I took the liberty of sending in a v2 on my own. Removed the last argument to stat_tracking_info() and used test_config instead of test_when_finished. Documentation/git-for-e

Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs

Hi, Peff On 24 August 2016 at 20:07, Jeff King wrote > > Whoops, your v2 spurred me to review, but I accidentally read and > responded to v1. > Thanks for the review! I was worried this patch had been buried :-) In the mean time, however, I have discovered that this conflicts

[PATCH] rev-parse: rev-parse: add --is-shallow-repository

Running `git fetch --unshallow` on a repo that is not in fact shallow produces a fatal error message. Add a helper to rev-parse that scripters can use to determine whether a repo is shallow or not. Signed-off-by: Øystein Walle <oys...@gmail.com> --- Documentation/git-rev-parse.tx

Re: [PATCH] rev-parse: rev-parse: add --is-shallow-repository

> Hm, can you say more about the context? From a certain point of view, > it might make sense for that command to succeed instead: if the repo > is already unshallow, then why should't "fetch --unshallow" complain > instead of declaring victory? A fellow in #git on Freenode was writing a script

Re: [PATCH v2 3/6] generate-cmdlist.sh: keep all information in common-cmds.h

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > > > +category_list () { > > + command_list "$1" | awk '{print $2;}' | sort | uniq > > +} > > Piping output of awk to sort/uniq, instead of processing all inside > awk within the END block of the