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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
= 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
.
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
Ø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
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
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
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
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
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
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)
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*
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
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
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
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
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.
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
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
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
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
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
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
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
52 matches
Mail list logo