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 script, means that we are wasting
> two
> 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 f
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
---
Documentation/git-rev-parse.txt | 3 +++
builtin/rev-parse.c
Pasting text into Gmail's web interface is not conducive to sending tabs
through the intertubes. But you get the idea..
Øsse
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
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 AM, Jeff King wrote:
>>
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 with
kn/ref-filter
s not exist or an empty string otherwise, analogous
to git branch -vv.
Signed-off-by: Øystein Walle
---
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-each-re
s not exist or an empty string otherwise, analogous
to git branch -vv.
Signed-off-by: Øystein Walle
---
Documentation/git-for-each-ref.txt | 5 +++--
ref-filter.c | 10 +-
t/t6300-for-each-ref.sh| 12
3 files changed, 24 insertions(+), 3 deletions(
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 las
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
---
Thanks for the quick feed
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
---
This is scratching a itch I
St. Blind 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 equivalent is
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 "
f test "$1" = amend; then
...
else
...
fi
to handle these situations.
Signed-off-by: Øystein Walle
---
Documentation/githooks.txt | 3 ++-
builtin/commit.c | 3 ++-
t/t7503-pre-commit-hook.sh | 11 +++
3 files changed, 15 insertions(+),
Signed-off-by: Øystein Walle
---
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-hook.sh
ommit_hook(use_editor, index_file, "pre-commit", hook_arg1, NULL);
or create 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/githoo
can do e.g.
if test "$1" = amend
then
...
else
...
fi
to handle these situations.
Signed-off-by: Øystein Walle
---
Documentation/githooks.txt | 3 ++-
builtin/commit.c | 3 ++-
t/t7503-pre-commit-hook.sh | 14 ++
3 files changed,
Brandon Turner brandonturner.net> writes:
>
> On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano 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) a
Brandon Turner 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
> +
Junio C Hamano pobox.com> writes:
>
> Øystein Walle gmail.com> writes:
>
> > Brandon Turner brandonturner.net> writes:
> >
> >>
> >> Software, such as RVM (ruby version manager), may set chpwd functions
> >> that result in an endless
Brandon Turner 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 -q
Junio C Hamano pobox.com> writes:
>
> Junio C Hamano pobox.com> writes:
>
> > I would suspect that this may be fine.
> >
> > "rev-parse --verify" makes sure the named object exists, but in this
> > case {u} does not even name any object, does it?
>
> Hmph, but "rev-parse --verify no-such-br
Hi,
I noticed this while writing a small script for myself:
$ git rev-parse --verify --quiet '@{u}'
fatal: No upstream configured for branch 'local'
The functions that get run when rev-parse does its thing all return a
pointer to a strbuf, return the length of the modified buf or somethi
brian m. carlson 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
migdol.net> wrote:
> > > I recently upgraded from Ubun
David Turner 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 unsubs
David Turner 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 already
Jeff King 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 no
git_config_string() does not handle '~' and '~user' as part of the
value. Using git_config_pathname() fixes this.
Signed-off-by: Øystein Walle
---
config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 314d8ee..ec7af5f 100644
Junio C Hamano 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
Junio C Hamano 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
for-each-ref
Junio C Hamano 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 wh
Øystein Walle 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 m
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
---
I was somewhat surprised by this behaviour; I expected to be in full control
Carlos Pereira 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 this library, ver
Signed-off-by: Øystein Walle
---
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 for the fir
Junio C Hamano pobox.com> writes:
>
> Thomas Rast thomasrast.ch> writes:
>
> > Junio C Hamano 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 th
ake use 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
Signed-off-by: Øystein Walle
---
v3 uses the same eval/--sq technique as v2, suggested by Thoma
Andreas Schwab 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)
Jonathan Nieder gmail.com> writes:
>
> Hi,
>
> Thomas Ackermann wrote:
>
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > -1,5 +1,5
> > -Git User Manual
> > +Git User Manual
>
> Why?
>
> Puzzled,
> Jonathan
>
That's a Unicode Byte Order Mark. I
Duy Nguyen 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* honor
t
Aaron Brooks 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
> g
Thomas Rast 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 exp
ake use 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
Signed-off-by: Øystein Walle
---
Many thanks to Thomas Rast for helping me with this approach.
tead shift 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
---
This is perhaps an esoteric use case but it's stil
Ville Walveranta 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.
Signed-off-by: Øystein Walle
---
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 wo
Eduardo R. D'Avila 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 c_l
This is for consistency with other porcelain commands such as 'log'.
Signed-off-by: Øystein Walle
---
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 fu
This is for consistency with other porcelain commands such as 'log'.
Signed-off-by: Øystein Walle
---
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.
Junio C Hamano 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 (3973cbd)
doe
Karsten Blees gmail.com> writes:
> Ø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
> -821,6 +821,9 static void prep_exclude(struct
dir_struct *dir, c
may be a separate issue. I've also gotten the impression that this
is intentional. In any case I cannot create a .gitignore that achieves
the same for both older 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
53 matches
Mail list logo
