On Tue, May 30, 2017 at 03:08:25PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, May 30, 2017 at 03:03:18PM +0900, Junio C Hamano wrote:
> >
> >> > +test_expect_success 'generate builtin list' '
> >> > +git --list-builtins >builtins
> >> > +'
> >> > +
> >> > +while read
Jeff King writes:
> On Tue, May 30, 2017 at 03:03:18PM +0900, Junio C Hamano wrote:
>
>> > +test_expect_success 'generate builtin list' '
>> > + git --list-builtins >builtins
>> > +'
>> > +
>> > +while read builtin
>> > +do
>> > + test_expect_success "$builtin can handle -h" '
>> > + t
On Tue, May 30, 2017 at 03:03:18PM +0900, Junio C Hamano wrote:
> > +test_expect_success 'generate builtin list' '
> > + git --list-builtins >builtins
> > +'
> > +
> > +while read builtin
> > +do
> > + test_expect_success "$builtin can handle -h" '
> > + test_expect_code 129 git $bui
Jeff King writes:
> This patch just tests that "git foo -h" works for every
> builtin, where we see a 129 exit code (the normal code for
> our usage() helper), and that the word "usage" appears in
> the output.
>
> Signed-off-by: Jeff King
> ---
> t/t0012-help.sh | 12
> 1 file cha
The series was pretty straight-forward. Thanks for working on this.
Jeff King writes:
> We can't easily move that setup to after the parse_options()
> call; the point is to set up defaults that are overwritten
> by the option parsing. Instead, we'll detect the "-h" case
> early and show the usage then. This matches the behavior of
> other builtins which have a si
Stefan Beller writes:
> v2:
> * A reroll of sb/submodule-blanket-recursive.
> * This requires ab/grep-preparatory-cleanup
2/8 seems to be more stale than sb/checkout-recurse-submodules that
was merged at f1101cef to 'master'. I'll try to merge Ævar's series
to 'master' before that merge, queue
Since commit 99caeed05 (Let 'git -h' show usage
without a git dir, 2009-11-09), the git wrapper handles "-h"
specially, skipping any repository setup but still calling
the builtin's cmd_foo() function. This means that every
cmd_foo() must be ready to handle this case, but we don't
have any systema
It can be useful in the test suite to be able to iterate
over the list of builtins. We could do this with some
Makefile magic. But since the authoritative list is in the
commands array inside git.c, and since this could also be
handy for debugging, let's add a hidden command-line option
to dump tha
The "git version" command didn't traditionally accept any
options, and in fact ignores any you give it. When we added
simple option parsing for "--build-options" in 6b9c38e14, we
didn't improve this; we just loop over the arguments and
pick out the one we recognize.
Instead, let's move to a real p
Normal users shouldn't ever call submodule--helper, but it
doesn't hurt to give them a normal usage message if they try
"-h".
Signed-off-by: Jeff King
---
The usage message isn't that helpful _either_, and I admit
my ulterior motive is just to make the test at the end of
this series pass. :)
I w
We just say "Expected two arguments" when we get a different
number of arguments, but we can be slightly friendlier.
People shouldn't generally be running remote helpers
themselves, but curious users might say "git remote-ext -h".
Signed-off-by: Jeff King
---
According to remote-curl.c, we should
Normally upload-archive forks off upload-archive--writer to
do the real work, and relays any errors back over the
sideband channel. This is a good thing when the command is
properly invoked remotely via ssh or git-daemon. But it's
confusing to curious users who try "git upload-archive -h".
Let's c
The git-credential command only takes one argument: the
operation to perform. If we don't have one, we complain
immediately. But if we have one that we don't recognize, we
don't notice until after we've read the credential from
stdin. This is likely to confuse a user invoking "git
credential -h", a
If the user provides "-h" on the command line, then our
parse_options() invocation will show a usage message and
quit. But if "-h" is the only argument, the git wrapper
behaves specially: it ignores our RUN_SETUP flag and calls
cmd_am() without having done repository setup at all. This
is due to 9
On Mon, May 29, 2017 at 11:32:50AM -0400, Jeff King wrote:
> I'll try to put together patches in the next day or so. Comments welcome
> in the meantime.
So here they are. For those just joining us, the immediate problem is
that "git am -h" is broken (whether you're in a repo or not). That's
fixed
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 29 May 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > diff --git a/sequencer.c b/sequencer.c
>> > index 130cc868e51..88819a1a2a9 100644
>> > --- a/sequencer.c
>> > +++ b/sequencer.c
>> > @@ -2388,3 +2388,52 @@ void append
Johannes Sixt writes:
>> Doesn't this need test_i18ngrep?:
>
> Good catch! It would be this one in warn_on_inaccessible:
>
>> wrapper.c:581: warning_errno(_("unable to access '%s'"), path);
>
> But actually, I'm more worried about the unholy mix of
> one-test-first-then-skip_all-later that
Will queue; thanks.
Andreas Heiduk writes:
> First: `git rev-parse --short` without a number does use a fixed default but
> `core.abbrev` which in turn uses `find_unique_abbrev` internally.
... hence the value gives mere minumum. I like your updated text that
clarifies this point.
> Second: `--short` implies `--v
On Tue, May 30, 2017 at 12:53:47PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, May 26, 2017 at 12:04:03PM +0200, SZEDER Gábor wrote:
> >
> >> Unfortunately, putting the default refspec into this temporary
> >> configuration environment breaks a few submodule tests
> >> (t5614-
Jeff King writes:
> On Fri, May 26, 2017 at 12:04:03PM +0200, SZEDER Gábor wrote:
>
>> Unfortunately, putting the default refspec into this temporary
>> configuration environment breaks a few submodule tests
>> (t5614-clone-submodules or t5614-clone-submodules-shallow (it's got
>> renamed between
Junio C Hamano writes:
> If you are depending on a single topic in 'next', it is better to
> build on the tip of that topic, not on 'next', if you can figure out
> where the tip is. In practice, while we are exchanging patches via
> e-mail, there should be no noticeable difference either way [*1
Laszlo Ersek writes:
> would it be possible to
>
> - increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128?
>
> - Or else to introduce a new git-config knob for it?
It's open source, so both are "possible", but you are interested in
learning if these are acceptable project-wide.
> I hav
Lars Schneider writes:
>> That's right. There might be some code sharing opportunity with Ben's
>> code that is already in "next":
>> https://github.com/git/git/blob/next/convert.c#L660-L677
>>
>> Would it be useful for you if I send v5 with the changes rebased
>> onto "next"?
>
> Hi Junio,
>
>
Duy Nguyen writes:
>> * Add a new config variable `core.version`. E.g. `core.version =
>>2.14.0` With this the user can specify that they'd like
>>new/experimental features introduced in that version (and below),
>>as well as immediately getting new deprecations added in that
>>v
"Philip Oakley" writes:
> If I now understand correctly, the merge process flow is:
>
> * canonicalise content (eol, smudge-clean, $id, renormalise, etc)
> * diff the content (internal, or GIT_EXTERNAL_DIFF)
> * apply the diff
> * if conflicts, only then use merge-driver/tool
>
> Would that be a
Samuel Lijin writes:
> "git status --ignored" previously did not list ignored files in
> untracked directories without -uall, contrary to the documented
> behavior of the --ignored flag (that all ignored files would be
> listed). This has also been corrected.
It's a balancing act to decide w
Using the is_missing_file_error() helper introduced in the previous
step, update all hits from
$ git grep -e ENOENT --and -e ENOTDIR
There are codepaths that only check ENOENT, and it is possible that
some of them should be checking both. Updating them is kept out of
this step deliberately, as
Our code often opens a path to an optional file, to work on its
contents when we can successfully open it. We can ignore a failure
to open if such an optional file does not exist, but we do want to
report a failure in opening for other reasons (e.g. we got an I/O
error, or the file is there, but w
Johannes Sixt writes:
> I would prefer to catch the case in the compatibility layer. Here is
> a two patch series that would replace your 12/13 and 13/13.
Thanks. It is good that I can drop that last one. Will replace
(with a SQUASH??? for 1/2).
Ramsay Jones writes:
> See commit c7018be509 ("test: allow skipping the remainder", 18-05-2017)
> which is currently merged to the 'next' branch (merge 03b8a61e47 of the
> 'jc/skip-test-in-the-middle' branch).
>
> (see also http://testanything.org)
>
> If you look at http://testanything.org//tap-
Johannes Sixt writes:
> Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason:
>> On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote:
>>> diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh
>>> index b195f71ea9..fd719a209e 100755
>>> --- a/t/t5580-clone-push-unc.sh
>>> +++ b/t
On Mon, May 29, 2017 at 10:50 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, May 29, 2017 at 10:41 PM, Sahil Dua wrote:
>> On Mon, May 29, 2017 at 1:30 AM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> On Mon, May 29, 2017 at 12:56 AM, Sahil Dua wrote:
New feature - copying a branch along with its c
On 29/05/17 22:02, Johannes Sixt wrote:
> Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason:
>> On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote:
>>> diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh
>>> index b195f71ea9..fd719a209e 100755
>>> --- a/t/t5580-clone-push-
Am 29.05.2017 um 13:20 schrieb Mathias Artus:
Hi,
Today i've tried to set up a template directory. I added in the system wide
gitconfig the following lines:
[init]
templatedir = "//OurServer/SomeDirectory/GitTemplate"
Where //Ourserver is a Network Path.
With th
Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason:
On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote:
diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh
index b195f71ea9..fd719a209e 100755
--- a/t/t5580-clone-push-unc.sh
+++ b/t/t5580-clone-push-unc.sh
@@ -1,13 +1,19 @@
On Mon, May 29, 2017 at 10:41 PM, Sahil Dua wrote:
> On Mon, May 29, 2017 at 1:30 AM, Ævar Arnfjörð Bjarmason
> wrote:
>> On Mon, May 29, 2017 at 12:56 AM, Sahil Dua wrote:
>>> New feature - copying a branch along with its config section.
>>>
>>> Aim is to have an option -c for copying a branch
On Mon, May 29, 2017 at 1:30 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, May 29, 2017 at 12:56 AM, Sahil Dua wrote:
>> New feature - copying a branch along with its config section.
>>
>> Aim is to have an option -c for copying a branch just like -m option for
>> renaming a branch.
>>
>> This com
On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt wrote:
> Am 26.05.2017 um 05:35 schrieb Junio C Hamano:
>> When asked to open/fopen a path, e.g. "a/b:/c", which does not exist
>> on the filesystem, Windows (correctly) fails to open it but sets
>> EINVAL to errno because the pathname has characters
SUMMARY OF MY PROJECT:
Git submodule subcommands are currently implemented by using shell script
'git-submodule.sh'. There are several reasons why we'll prefer not to
use the shell script. My project intends to convert the subcommands into
C code, thus making them builtins. This will increase Git'
On Windows, certain characters are prohibited in file names, most
prominently the colon. When fopen() is called with such an invalid file
name, the underlying Windows API actually reports a particular error,
but since there is no suitable errno value, this error is translated
to EINVAL. Detect the
Am 26.05.2017 um 05:35 schrieb Junio C Hamano:
> When asked to open/fopen a path, e.g. "a/b:/c", which does not exist
> on the filesystem, Windows (correctly) fails to open it but sets
> EINVAL to errno because the pathname has characters that cannot be
> stored in its filesystem.
>
> As this is a
Thanks, Junio for raising all these important questions.
Indeed, showing tests in order to explain my thinking about the
feature was a bad idea. I realise that I should have explained the
feature first instead of getting the tests reviewed without any
elaboration of the intentions. I will explain
On Mon, May 29, 2017 at 8:18 PM, Joel Teichroeb wrote:
> Once I have all those leaks fixed, is there a way to make sure I'm not
> missing any? I tried using valgrind with leak-check enabled, but there
> are too many leaks from other git commands.
I just used:
valgrind --leak-check=full ./git
Once I have all those leaks fixed, is there a way to make sure I'm not
missing any? I tried using valgrind with leak-check enabled, but there
are too many leaks from other git commands.
Joel
On Mon, May 29, 2017 at 03:01:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 29, 2017 at 1:45 PM, Zero King wrote:
> > After upgrading to Git 2.13.0, I'm seeing the following error message
> > when running `git am -h`.
> >
> >$ git am -h
> >fatal: BUG: setup_git_env called witho
On Mon, May 29, 2017 at 01:20:02PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> * Add a new config variable `core.version`. E.g. `core.version =
> >>2.14.0` With this the user can specify that they'd like
> >>new/experimental features introduced in that version (and below),
> >>as well
On Mon, May 29, 2017 at 1:45 PM, Zero King wrote:
> After upgrading to Git 2.13.0, I'm seeing the following error message
> when running `git am -h`.
>
>$ git am -h
>fatal: BUG: setup_git_env called without repository
>
> And with Git built from the next branch:
>
>$ git am -h
>BUG
From: "Junio C Hamano"
"Philip Oakley" writes:
So I do not think this is not limited to "new file". Anything that
a tree-level three-way merge would resolve cleanly without having to
consult the content-level three-way merge will complete without
consulting the merge.ours.driver; per-file co
On Mon, May 29, 2017 at 12:51 PM, Johannes Schindelin
wrote:
> Hi René,
>
> On Sat, 27 May 2017, René Scharfe wrote:
>
>> Am 26.05.2017 um 05:15 schrieb Liam Beguin:
>> > I tried to time the execution on an interactive rebase (on Linux) but
>> > I did not notice a significant change in speed.
>> >
Hi,
After upgrading to Git 2.13.0, I'm seeing the following error message
when running `git am -h`.
$ git am -h
fatal: BUG: setup_git_env called without repository
And with Git built from the next branch:
$ git am -h
BUG: environment.c:172: setup_git_env called without repository
On Mon, May 29, 2017 at 6:23 PM, Ævar Arnfjörð Bjarmason
wrote:
>>> That said, even if we never reached the point where we could handle all
>>> submodule requests in-process, I think sticking the repo-related global
>>> state in a struct certainly could not hurt general readability. So it's
>>> a
Hi,
Today i've tried to set up a template directory. I added in the system wide
gitconfig the following lines:
[init]
templatedir = "//OurServer/SomeDirectory/GitTemplate"
Where //Ourserver is a Network Path.
With this line i can create a new Repository and the te
Hi Liam,
On Thu, 25 May 2017, Liam Beguin wrote:
> Johannes Schindelin writes:
> [...]
> > + if (rearranged) {
> > + struct strbuf buf = STRBUF_INIT;
> > +
> > + for (i = 0; i < todo_list.nr; i++) {
> > + enum todo_command command = todo_list.items[i].comm
On Mon, May 29, 2017 at 12:36 PM, Duy Nguyen wrote:
> On Tue, May 23, 2017 at 2:35 AM, Jeff King wrote:
>> On Thu, May 18, 2017 at 04:21:11PM -0700, Brandon Williams wrote:
>>
>>> When I first started working on the git project I found it very difficult to
>>> understand parts of the code base be
Hi Liam,
On Thu, 25 May 2017, Liam Beguin wrote:
> Johannes Schindelin writes:
>
> > diff --git a/builtin/rebase--helper.c b/builtin/rebase--helper.c
> > index 821058d452d..9444c8d6c60 100644
> > --- a/builtin/rebase--helper.c
> > +++ b/builtin/rebase--helper.c
> > @@ -24,6 +24,10 @@ int cmd_re
On Mon, May 29, 2017 at 12:23 PM, Duy Nguyen wrote:
> On Sat, May 27, 2017 at 6:10 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> This is the WIP start of a deprecation & experimental interface to
>> git. The goal is to formalize the workflow around deprecating
>> features, or around introducing new exp
On Thu, May 11, 2017 at 3:24 AM, taylor, david wrote:
> The Git documentation in describing worktrees says that one reason
> why you might want to lock a worktree is to prevent it from being pruned
> if it is on a removable media that isn't currently mounted.
>
> So, my expectation was that if the
> On 23 May 2017, at 10:43, Lars Schneider wrote:
>
>
>> On 23 May 2017, at 07:22, Junio C Hamano wrote:
>>
>> Lars Schneider writes:
>>
> + sigchain_pop(SIGPIPE);
> +
> + if (err || errno == EPIPE) {
This looks strange, at first glance.
Do we set errno to 0 befo
On Mon, May 29, 2017 at 3:09 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
>> index 4f94fc7574..c76bbedf86 100755
>> --- a/GIT-VERSION-GEN
>> +++ b/GIT-VERSION-GEN
>> @@ -37,4 +37,5 @@ fi
>> test "$VN" = "$VC" || {
>> echo
Hi Liam,
On Thu, 25 May 2017, Liam Beguin wrote:
> Johannes Schindelin writes:
>
> > diff --git a/sequencer.c b/sequencer.c
> > index 130cc868e51..88819a1a2a9 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -2388,3 +2388,52 @@ void append_signoff(struct strbuf *msgbuf, int
> > ignore_
Hi Liam,
On Thu, 25 May 2017, Liam Beguin wrote:
> Johannes Schindelin writes:
> > This patch series reimplements the expensive pre- and post-processing of
> > the todo script in C.
> >
> > [...]
I see that you used git-send-email to send this. It did look a bit funny
not to have "Re: " prefixe
Hi Junio,
On Mon, 29 May 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/sequencer.c b/sequencer.c
> > index 130cc868e51..88819a1a2a9 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -2388,3 +2388,52 @@ void append_signoff(struct strbuf *msgbuf, int
> > ig
Hi René,
On Sat, 27 May 2017, René Scharfe wrote:
> Am 26.05.2017 um 05:15 schrieb Liam Beguin:
> > I tried to time the execution on an interactive rebase (on Linux) but
> > I did not notice a significant change in speed.
> > Do we have a way to measure performance / speed changes between version
On Tue, May 23, 2017 at 2:35 AM, Jeff King wrote:
> On Thu, May 18, 2017 at 04:21:11PM -0700, Brandon Williams wrote:
>
>> When I first started working on the git project I found it very difficult to
>> understand parts of the code base because of the inherently global nature of
>> our code. It a
On Sat, May 27, 2017 at 6:10 PM, Ævar Arnfjörð Bjarmason
wrote:
> This is the WIP start of a deprecation & experimental interface to
> git. The goal is to formalize the workflow around deprecating
> features, or around introducing new experimental features.
>
> This is much more idea than code at
On Tue, May 16, 2017 at 5:43 AM, Junio C Hamano wrote:
> "taylor, david" writes:
>
>> The original report was against Git v2.12.2. I have since tried v2.12.3,
>> v2.13.0,
>> and the next branch. All exhibit the same symptoms.
>>
>> Even if you ignore the original scenario for creating the prob
_3qpавсmвyйme! Bас инmepeсyюm kлиeнmсkиe 6азы qанныx?
`._..
Glad to write to you this message,
I seek for your kind help in setting up a charitable organization to
help the less privileged people and also the elderly people under
your care,
I was diagnosed of breast cancer and the doctors told me that i may
not live long due to the bad stage of my
Hi,
would it be possible to
- increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128?
- Or else to introduce a new git-config knob for it?
I have a small review-helper / interdiff script that matches patches
from adjacent versions of a series against each other, based on subject
line. (U
Johannes Schindelin writes:
> This patch series reimplements the expensive pre- and post-processing of
> the todo script in C.
>
> And it concludes the work I did to accelerate rebase -i.
>
I took another look at the series (as "What's cooking" report was
listing this in the "Needs review" state
Witam,
Czy potrzebujesz zatwierdzony biznes i prywatnego kredytu / Finansowanie w
maksymalnej wysokosci 3% w skali roku? Skontaktuj sie z nami po wiecej
szczególów w razie zainteresowania.
Dziekuje.
BSN Capital Partners Ltd (London)
Zarzadzanie.
--
Angielska wersja
On Mon, May 29, 2017 at 2:23 AM, Junio C Hamano wrote:
> * sl/clean-d-ignored-fix (2017-05-24) 6 commits
> (merged to 'next' on 2017-05-29 at 837c255ae8)
> + clean: teach clean -d to preserve ignored paths
> + dir: expose cmp_name() and check_contains()
> + dir: hide untracked contents of unt
On Mon, May 29, 2017 at 2:54 AM, Junio C Hamano wrote:
> Thanks. Did you run "sort | uniq -c" on it or something ;-)?
I've been writing a new backend for wildmatch(). Was wondering what
the difference in these two failing tests was, turns out there was
none.
> Will apply.
Thanks.
Joel Teichroeb writes:
> +int untracked_files(struct strbuf *out, int include_untracked,
> + const char **argv)
Does this need to be public?
For a caller that wants to learn if there is _any_ untracked file,
having a strbuf that holds all output is overkill. For a caller
that wan
76 matches
Mail list logo
