prepare_shell_cmd() executes /bin/sh with superfluous arguments on all but
single-word shell commands.
For example, if .git/config has this alias (the sleep is to leave time to
examine output from ps, &c.):
[alias]
tryme = "!echo $PWD;sleep 600"
running "git tryme" in one console and che
On Thu, Oct 20, 2016 at 9:14 PM, Lars Schneider
wrote:
> Hi,
>
> on TravisCI I see these weird "Tests out of sequence" errors with prove
> and they seem to not go away. I assume the reason that they not go away
> is that the ".prove" file is carried over from on build to another (but I
> can't
>
Am 20.10.2016 um 23:38 schrieb Jeff King:
test_cmp () {
# optimize for common "they are the same" case
# without any subshells or subprograms
We do this already on Windows; it's the function mingw_test_cmp in our
test suite:
https://github.com/git/git/b
Hi,
on TravisCI I see these weird "Tests out of sequence" errors with prove
and they seem to not go away. I assume the reason that they not go away
is that the ".prove" file is carried over from on build to another (but I can't
look into this file on TravisCI).
Has anyone an idea where these err
Ramsay Jones writes:
> I have started seeing unexpected passes in this test (am I the
> only one?) on the next and pu branch, which seems to be caused
> by commit e3fdbcc8 ("parse_mailboxes: accept extra text after
> <...> address", 13-10-2016). Thus:
>
> $ tail -15 ntest-out
> [15:17:44]
>
Jeff King writes:
> On Fri, Oct 21, 2016 at 12:40:09AM +0100, Philip Oakley wrote:
>
>> The doc-tool stack does not always respect the 'tab = 8 spaces' rule,
>> particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base
>> and the Git generated html pages.
>
> Hmm, I thought git-s
Philip Oakley writes:
> The doc-tool stack does not always respect the 'tab = 8 spaces' rule,
> particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base
> and the Git generated html pages.
Sorry, but I do not understand this change.
https://git.github.io/htmldocs/git-merge-bas
I recently started using lt/abbrev-auto via 'next'. This is the fetch
output I saw today:
$ git fetch
remote: Counting objects: 332, done.
remote: Compressing objects: 100% (237/237), done.
remote: Total 332 (delta 182), reused 64 (delta 64), pack-reused 31
Receiving objects: 100% (332/332), 351.5
Hi Matthieu,
I have started seeing unexpected passes in this test (am I the
only one?) on the next and pu branch, which seems to be caused
by commit e3fdbcc8 ("parse_mailboxes: accept extra text after
<...> address", 13-10-2016). Thus:
$ tail -15 ntest-out
[15:17:44]
All tests successful.
On Fri, Oct 21, 2016 at 12:40:09AM +0100, Philip Oakley wrote:
> The doc-tool stack does not always respect the 'tab = 8 spaces' rule,
> particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base
> and the Git generated html pages.
Hmm, I thought git-scm.com was fixed by:
http
Jonathan Tan writes:
> That is true - I think we can take the allowed separators as an
> argument (meaning that we can have different behavior for file parsing
> and command line parsing), and since we already have that string, we
> can use strcspn. I'll try this out in the next reroll.
Sounds g
On Thu, Oct 20, 2016 at 4:29 PM, Aaron Schrab wrote:
> I was working with a fresh clone of a repository where I'd forgotten that
> one of the directories was setup as a submodule, so I hadn't initialized it.
>
> I tried to add a symlink to a location outside the repository and this
> failed with a
The doc-tool stack does not always respect the 'tab = 8 spaces' rule,
particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base
and the Git generated html pages.
Use just spaces within the block of the ascii art.
Noticed when reviewing Junio's suggested update to `git merge-base`
I was working with a fresh clone of a repository where I'd forgotten
that one of the directories was setup as a submodule, so I hadn't
initialized it.
I tried to add a symlink to a location outside the repository and this
failed with an assertion (exact text in comment below). When looking
in
On Thu, Oct 20, 2016 at 05:00:13PM -0400, Jeff King wrote:
> > I am not an expert on perl nor tracing, but is it feasible to find out
> > how many internal calls there are? i.e. either some shell script (rebase,
> > submodule) calling git itself a couple of times or even from compile/git/git
> > i
> Thanks. So I do not completely get what you are suggesting: args or kept
> it the way it is? Since in the end you are saying it is ok here ;) I
> mainly chose this name because I am substituting the argv variable which
> is already called 'argv' with this array. That might also be the reason
> wh
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The last batch of topics before -r
On 10/20/2016 03:45 PM, Junio C Hamano wrote:
Jonathan Tan writes:
If we do that, there is also the necessity of creating a string that
combines the separators and '=' (I guess '\n' is not necessary now,
since all the lines are null terminated). I'm OK either way.
(We could cache that string,
Jonathan Tan writes:
> If we do that, there is also the necessity of creating a string that
> combines the separators and '=' (I guess '\n' is not necessary now,
> since all the lines are null terminated). I'm OK either way.
>
> (We could cache that string, although I would think that if we did
>
On 10/20/2016 03:40 PM, Jonathan Tan wrote:
On 10/20/2016 03:14 PM, Junio C Hamano wrote:
Stefan Beller writes:
+static int find_separator(const char *line)
+{
+ const char *c;
+ for (c = line; ; c++) {
+ if (!*c || *c == '\n')
+ return -1;
+
On 10/20/2016 03:14 PM, Junio C Hamano wrote:
Stefan Beller writes:
+static int find_separator(const char *line)
+{
+ const char *c;
+ for (c = line; ; c++) {
+ if (!*c || *c == '\n')
+ return -1;
+ if (*c == '=' || strchr(separator
Stefan Beller writes:
>> +static int find_separator(const char *line)
>> +{
>> + const char *c;
>> + for (c = line; ; c++) {
>> + if (!*c || *c == '\n')
>> + return -1;
>> + if (*c == '=' || strchr(separators, *c))
>> +
Jeff King writes:
> On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote:
>
>> > By the way, do you know who is managing the service on our end
>> > (e.g. approving new people to be "defect viewer")?
>>
>> I do it most of the time, but I did not start managing it.
>> And I have been pre
On Thu, Oct 20, 2016 at 2:39 PM, Jonathan Tan wrote:
> The parse_trailer function has a few modes of operation, all depending
> on whether the separator is present in its input, and if yes, the
> separator's position. Some of these modes are failure modes, and these
> failure modes are handled dif
On Thu, Oct 20, 2016 at 02:53:36PM -0700, Stefan Beller wrote:
> >> That said I really like the idea of having a helper that would eliminate
> >> the cat
> >> for you, e.g. :
> >>
> >> git_test_helper_equal_stdin_or_diff_and_die -C super_repo status
> >> --porcelain=v2 --branch --untracked-files=
On Thu, Oct 20, 2016 at 05:38:03PM -0400, Jeff King wrote:
> I think that helper still ends up using "cat" and "diff" under the hood,
> unless you write those bits in pure shell. But at that point, I suspect
> we could "cat" and "test_cmp" in pure shell, something like:
> [...]
> Those are both co
On Thu, Oct 20, 2016 at 2:38 PM, Jeff King wrote:
> On Thu, Oct 20, 2016 at 12:54:32PM -0700, Stefan Beller wrote:
>
>> Maybe we should stop introducing un-optimized tests.
>> [...]
>> * heavy use of the "git -C " pattern. When applying that
>> thouroughly we'd save spanning the subshells.
>
> Y
On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote:
> > By the way, do you know who is managing the service on our end
> > (e.g. approving new people to be "defect viewer")?
>
> I do it most of the time, but I did not start managing it.
> And I have been pretty lax/liberal about handin
On Thu, Oct 20, 2016 at 10:05:38AM -0700, Stefan Beller wrote:
> Not sure what triggered the new finding of coverity as seen below as the
> parse_commit() was not touched. Junios series regarding the merge base
> optimization touches a bit of code nearby though.
I have noticed that "old" problems
Improve type safety by making arguments (whether from configuration or
from the command line) have their own "struct arg_item" type, separate
from the "struct trailer_item" type used to represent the trailers in
the buffer being manipulated.
This change also prepares "struct trailer_item" to be fu
Currently, creation and addition (to a list) of trailer items are spread
across multiple functions. Streamline this by only having 2 functions:
one to parse the user-supplied string, and one to add the parsed
information to a list.
Signed-off-by: Jonathan Tan
---
trailer.c | 130
Currently, interpret-trailers requires all lines of a trailer block to
be trailers (or comments) - if not it would not identify that block as a
trailer block, and thus create its own trailer block, inserting a blank
line. For example:
echo -e "\nSigned-off-by: x\nnot trailer" |
git interpret-
Replace the existing handwritten implementation of a doubly-linked list
in trailer.c with the functions and macros from list.h. This
significantly simplifies the code.
Signed-off-by: Jonathan Tan
Signed-off-by: Ramsay Jones
---
trailer.c | 258 ++-
Currently, interpret-trailers allows leading whitespace in trailer
lines. This leads to false positives, especially for quoted lines or
bullet lists.
Forbid leading whitespace in trailers.
Signed-off-by: Jonathan Tan
---
Documentation/git-interpret-trailers.txt | 2 +-
t/t7513-interpret-traile
Currently, interpret-trailers requires that a trailer be only on 1 line.
For example:
a: first line
second line
would be interpreted as one trailer line followed by one non-trailer line.
Make interpret-trailers support RFC 822-style folding, treating those
lines as one logical trailer.
Signe
The parse_trailer function has a few modes of operation, all depending
on whether the separator is present in its input, and if yes, the
separator's position. Some of these modes are failure modes, and these
failure modes are handled differently depending on whether the trailer
line was sourced fro
Main changes are:
- implemented the previously discussed trailer block recognizing rule
(recognized trailer + 25% trailers or 100% trailers)
- forbidding leading whitespace in trailers to avoid false positives
Once the recognized trailer + 25% trailers rule is implemented,
implementing the 10
Change "const char *" to "char *" in struct trailer_item and in the
return value of apply_command (since those strings are owned strings).
Change "struct conf_info *" to "const struct conf_info *" (since that
struct is not modified).
Signed-off-by: Jonathan Tan
---
trailer.c | 14 +++---
On Thu, Oct 20, 2016 at 12:57:01PM -0400, Santiago Torres wrote:
> > I think you'd really just squash the various bits of this into your
> > series at the right spots, though I don't mind it on top, either.
> >
> > The big question is to what degree we should care about the verify-tag
> > case. I
On Thu, Oct 20, 2016 at 12:54:32PM -0700, Stefan Beller wrote:
> Maybe we should stop introducing un-optimized tests.
> [...]
> * heavy use of the "git -C " pattern. When applying that
> thouroughly we'd save spanning the subshells.
Yeah, I imagine with some style changes we could drop quite a
On Wed, Oct 19, 2016 at 05:13:34PM -0700, Kyle J. McKay wrote:
>
> The project page with detailed help and many screen shots is located at:
>
> https://mackyle.github.io/git-log-compact/
>
> Alternatively the repository can be cloned from:
>
> https://github.com/mackyle/git-log-compact.git
On Thu, Oct 20, 2016 at 10:38:23PM +0200, Johannes Sixt wrote:
> Am 20.10.2016 um 14:31 schrieb Jeff King:
> > Close to 1/3 of those processes are just invoking the bin-wrapper
> > script to set up the EXEC_PATH, etc. I imagine it would not be too hard
> > to just do that in the test script. In fa
On Thu, Oct 20, 2016 at 09:30:27AM -0700, Stefan Beller wrote:
> On Thu, Oct 20, 2016 at 5:31 AM, Jeff King wrote:
>
> >
> > $ perl -lne '/execve\("(.*?)"/ and print $1' /tmp/foo.out | sort | uniq -c
> > | sort -rn | head
> > 152271 /home/peff/compile/git/git
> > 57340 /home/peff/compile/git
From: Jacob Keller
When adding support for prefixing output of log and other commands using
--line-prefix, commit 660e113ce118 ("graph: add support for
--line-prefix on all graph-aware output", 2016-08-31) accidentally
broke rev-list --header output.
In order to make the output appear with a lin
On Thu, 2016-10-20 at 08:31 -0400, Jeff King wrote:
> I'm also not entirely convinced that the test suite being a shell script
> is the main culprit for its slowness. We run git a lot of times, and
> that's inherent in testing it. I ran the whole test suite under
> "strace -f -e execve". There are
Am 20.10.2016 um 14:31 schrieb Jeff King:
Close to 1/3 of those processes are just invoking the bin-wrapper
script to set up the EXEC_PATH, etc. I imagine it would not be too hard
to just do that in the test script. In fact, it looks like:
make prefix=/wherever install
GIT_TEST_INSTALLED=/wh
From: Jacob Keller
When adding support for prefixing output of log and other commands using
--line-prefix, commit 660e113ce118 ("graph: add support for
--line-prefix on all graph-aware output", 2016-08-31) accidentally
broke rev-list --header output.
In order to make the output appear with a lin
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> This makes the code consistent by fixing quite a couple of error messages.
>>
>> Suggested by Jakub Narębski.
>>
>> Signed-off-by: Johannes Schindelin
>> ---
>
> These finishing touches in 21-23 look all sensible to me.
Make that 21-25.
Johannes Schindelin writes:
> This makes the code consistent by fixing quite a couple of error messages.
>
> Suggested by Jakub Narębski.
>
> Signed-off-by: Johannes Schindelin
> ---
These finishing touches in 21-23 look all sensible to me.
Junio C Hamano writes:
> If I were doing this, I would make this into three separate steps:
>
> - move the strbuf_release(msgbuf) to the caller in
> do_pick_commit();
>
> - add the missing rollback_lock_file(), which is a bugfix; and
> then finally
>
> - allow the helper t
Johannes Schindelin writes:
> The write_message() function safely writes an strbuf to a file.
> Sometimes it is inconvenient to require an strbuf, though: the text to
> be written may not be stored in a strbuf, or the strbuf should not be
> released after writing.
>
> Let's refactor "safely writi
Johannes Schindelin writes:
> The return value of do_recursive_merge() may be positive (indicating merge
> conflicts), or 0 (indicating success). It also may be negative, indicating
> a fatal error that requires us to abort.
>
> Now, if the return value indicates that there are merge conflicts, w
Johannes Schindelin writes:
> The run_git_commit() function already knows how to amend commits, and
> with this new option, it can also clean up commit messages (i.e. strip
> out commented lines). This is needed to implement rebase -i's 'fixup'
> and 'squash' commands as sequencer commands.
>
> S
On Thu, Oct 20, 2016 at 11:54 AM, Junio C Hamano wrote:
>
> The main part of the patch looks good. For "passing NUL to sed",
> I'd probably work it around like so:
>
Yep. I wasn't sure on the test as it was, because of the portability concern.
> t/t6000-rev-list-misc.sh | 19 +++---
On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>>> I am not sure if that is OK. I think it is less not-OK than the use
>>> case I mentioned in my earlier message, in that this is not a case
>>> that "please don't do it" breaks. It however is an inconvenience
>>
On Thu, Oct 20, 2016 at 3:50 AM, Johannes Schindelin
wrote:
> Hi peff,
>
> On Wed, 19 Oct 2016, Jeff King wrote:
>
>> On Wed, Oct 19, 2016 at 10:32:12AM -0700, Junio C Hamano wrote:
>>
>> > > Maybe we should start optimizing the tests...
>> >
Maybe we should stop introducing un-optimized tests.
F
Stefan Beller writes:
> My thought was to fix it nevertheless, such that the url recorded as
> remote.origin.url is always the first case (no l or /. at the end).
>
> If we were to add this fix to clone, then it may be easier to debug
> submodule url schemes for users as the submodule url would t
On Thu, Oct 20, 2016 at 12:26 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Do we actually want to fix git-clone as well?
>
> If I understand correctly, the point of this fix is to make it not
> to matter whether the original URL the end user gives or recorded as
> the remote by "git clo
Stefan Beller writes:
> Do we actually want to fix git-clone as well?
If I understand correctly, the point of this fix is to make it not
to matter whether the original URL the end user gives or recorded as
the remote by "git clone" in the repository is any one of:
$any_leading_part/path
On Tue, Oct 18, 2016 at 7:05 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> I am not sure. Certainly we would want to make sure that the normal
>>> case (i.e. no funny trailing junk) to work correctly, but we do want
>>> to protect the fix from future breakage as well, no?
>>
>> Exactly
Jacob Keller writes:
> diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh
> index 3e752ce03280..e8c6979baf59 100755
> --- a/t/t6000-rev-list-misc.sh
> +++ b/t/t6000-rev-list-misc.sh
> @@ -4,6 +4,12 @@ test_description='miscellaneous rev-list tests'
>
> . ./test-lib.sh
>
> +test
On Thu, 2016-10-20 at 11:19 -0700, Jacob Keller wrote:
> Here's my solution, with an updated test using a helper function based
> on using sed (which I think is more portable than tail -n1 ?). The
> change actually is very simple. I ran the test suite and it appears to
> be not breaking anyone else
Jacob Keller writes:
> I did some searching, and we do use sed so I replaced it with sed \$!d
> which appears to work. I think we should probably implement a
> test_ends_with_nul or something.
As it is "a stream editor that shall read one or more text files", I
do not think "sed" is any better (
Jacob Keller writes:
>> I am not sure if that is OK. I think it is less not-OK than the use
>> case I mentioned in my earlier message, in that this is not a case
>> that "please don't do it" breaks. It however is an inconvenience
>> that the user has to say "git add file" before the "git commit
From: Jacob Keller
When adding support for prefixing output of log and other commands using
--line-prefix, commit 660e113ce118 ("graph: add support for
--line-prefix on all graph-aware output", 2016-08-31) accidentally
broke rev-list --header output.
In order to make the output appear with a lin
On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> I still think we're misunderstanding. I want git commit to complain
>> *only* under the following circumstance:
>>
>> I run "git add -p" and put a partial change into the index in .
>> There are still other parts
On Thu, Oct 20, 2016 at 11:05 AM, Junio C Hamano wrote:
>
> Good to know that you have been managing it; I was mostly worried
> about not having anybody managing it (i.e. imagining Coverity
> nominated/volunteered me as manager with everybody else as viewers)
> and the new viewer requests get tota
On Thu, Oct 20, 2016 at 11:04 AM, Dennis Kaarsemaker
wrote:
> On Wed, 2016-10-19 at 15:41 -0700, Junio C Hamano wrote:
>> Dennis Kaarsemaker writes:
>>
>> > + touch expect &&
>> > + printf "\0" > expect &&
>>
>>
>> What's the point of that "touch", especially if you are going to
>> overwrite
The reason parse_commit() would fail at these points would be because
the repository is corrupt.
This was noticed by coverity.
Signed-off-by: Stefan Beller
---
developed on pu as that's where coverity spotted it.
I have no overview if these areas are being worked on. (It may clash
with at le
Stefan Beller writes:
> I do it most of the time, but I did not start managing it.
> And I have been pretty lax/liberal about handing out rights to do stuff,
> because I did not want to tip on anyone's toes giving to few rights
> and thereby annoying them.
Good to know that you have been managin
On Wed, 2016-10-19 at 15:41 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > + touch expect &&
> > + printf "\0" > expect &&
>
>
> What's the point of that "touch", especially if you are going to
> overwrite it immediately after?
Leftover debugging crud. I tried various ways
On Wed, 2016-10-19 at 15:39 -0700, Junio C Hamano wrote:
> Jacob Keller writes:
>
> > Hi,
> >
> > On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker
> > wrote:
> > > Commit 660e113 (graph: add support for --line-prefix on all graph-aware
> > > output) changed the way commits were shown. Unfort
On Thu, Oct 20, 2016 at 10:50 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Not sure what triggered the new finding of coverity as seen below as the
>> parse_commit() was not touched. Junios series regarding the merge base
>> optimization touches a bit of code nearby though.
>>
>> Do we
Stefan Beller writes:
> Not sure what triggered the new finding of coverity as seen below as the
> parse_commit() was not touched. Junios series regarding the merge base
> optimization touches a bit of code nearby though.
>
> Do we want to replace the unchecked places of parse_commit with
> parse
Jacob Keller writes:
> I still think we're misunderstanding. I want git commit to complain
> *only* under the following circumstance:
>
> I run "git add -p" and put a partial change into the index in .
> There are still other parts which were not added to the index yet.
> Thus, the index version
On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>>> I still think it's worth while to add a check for git-commit which
>>> does something like check when we say "git commit " and if the
>>> index already has those files marked as being changed, compare them
>>> with t
Junio C Hamano writes:
> Are you proposing to replace the tests written as shell scripts with
> scripts in another language or framework that run equivalent
> sequences of git commands that is as portable as, if not more,
> Bourne shell?
The language (/bin/sh) is probably not the biggest issue.
Vasco Almeida writes:
> A Seg, 10-10-2016 às 12:54 +, Vasco Almeida escreveu:
>> @@ -70,6 +72,8 @@ Git::I18N - Perl interface to Git's Gettext localizations
>>
>> printf __("The following error occurred: %s\n"), $error;
>>
>> + printf __n("commited %d file", "commited %d fil
Not sure what triggered the new finding of coverity as seen below as the
parse_commit() was not touched. Junios series regarding the merge base
optimization touches a bit of code nearby though.
Do we want to replace the unchecked places of parse_commit with
parse_commit_or_die ?
Thanks,
Stefan
__
On Wed, Oct 19, 2016 at 04:39:44PM -0400, Jeff King wrote:
> The ref-filter code generally expects to see fully qualified
> refs, so that things like "%(refname)" and "%(refname:short)"
> work as expected. We can do so easily from git-tag, which
> always works with refnames in the refs/tags namespa
Am 20.10.2016 um 13:02 schrieb Duy Nguyen:
> On Wed, Oct 19, 2016 at 4:18 PM, Johannes Schindelin
> wrote:
>> Hi Junio,
>>
>> I know you are a fan of testing things thoroughly in the test suite, but I
>> have to say that it is getting out of hand, in particular due to our
>> over-use of shell scri
A Seg, 10-10-2016 às 12:54 +, Vasco Almeida escreveu:
> @@ -70,6 +72,8 @@ Git::I18N - Perl interface to Git's Gettext localizations
>
> printf __("The following error occurred: %s\n"), $error;
>
> + printf __n("commited %d file", "commited %d files", $files), $files;
> +
I fo
Jeff King writes:
>> I still think it's worth while to add a check for git-commit which
>> does something like check when we say "git commit " and if the
>> index already has those files marked as being changed, compare them
>> with the current contents of the file as in the checkout and quick
>>
On Thu, Oct 20, 2016 at 5:31 AM, Jeff King wrote:
>
> $ perl -lne '/execve\("(.*?)"/ and print $1' /tmp/foo.out | sort | uniq -c |
> sort -rn | head
> 152271 /home/peff/compile/git/git
> 57340 /home/peff/compile/git/t/../bin-wrappers/git
> 16865 /bin/sed
> 12650 /bin/rm
> 11257 /bin/cat
Jeff King writes:
> I usually just try to recreate the actual environment (e.g., run the
> tests as root, run them on a loopback case-insensitive fs, etc) as that
> gives a more realistic recreation.
True. I just do not want to run the tests as root myself ;-) I
wonder if fakeroot would give u
A Qua, 19-10-2016 às 11:40 -0700, Junio C Hamano escreveu:
> Vasco Almeida writes:
>
> >
> > @@ -669,12 +669,18 @@ sub status_cmd {
> > sub say_n_paths {
> > my $did = shift @_;
> > my $cnt = scalar @_;
> > - print "$did ";
> > - if (1 < $cnt) {
> > - print "$cnt paths\n";
Vasco Almeida writes:
>> Not a big deal, but this makes me wonder if we want to do this
>> instead ...
For future reference (for others as well), when I say "makes me
wonder" or "I wonder", I am never demanding to change what the
original author wrote. I just am trying to see that pros-and-cons
A Qua, 19-10-2016 às 11:14 -0700, Junio C Hamano escreveu:
> Vasco Almeida writes:
>
> >
> > } else {
> > - print "No untracked files.\n";
> > + print __("No untracked files.\n");
> > }
>
> Not a big deal, but this makes me wonder if we want to do this
> instead
>
>
Johannes Schindelin writes:
> Of course, if you continue to resist (because the problem is obviously not
> affecting you personally, so why would you care), I won't even try to find
> the time to start on that project.
Sorry, but I did not know I was resisting, as I didn't see any
proposal to re
On Wed, 2016-10-19 at 15:39 -0700, Junio C Hamano wrote:
> Jacob Keller writes:
>
> >
> > Hi,
> >
> > On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker
> > wrote:
> > >
> > > Commit 660e113 (graph: add support for --line-prefix on all
> > > graph-aware
> > > output) changed the way commits
Manuel Reimer writes:
> I have the following branches on my remote repo:
>
> new_version
> master
>
> I now want the "new_version" branch to be the "master" and the old
> "master" has to be renamed to the old version number (in my case
> 0.2.0).
>
> How to do this?
I assume you have "git push"
Younes Khoudli writes:
> This is the only place in the documentation that the traditional layout
> is mentioned, and it is confusing. Remove it.
Yeah, the information is not incorrect per-se, but certainly is out
of place and immaterial to what this part of the documentation tries
to teach.
Wil
Hello,
I have the following branches on my remote repo:
new_version
master
I now want the "new_version" branch to be the "master" and the old
"master" has to be renamed to the old version number (in my case 0.2.0).
How to do this? Currently this causes me much trouble as I can't delete
the
This is the only place in the documentation that the traditional layout
is mentioned, and it is confusing. Remove it.
* Documentation/git-tag.txt: Here.
Signed-off-by: Younes Khoudli
---
Documentation/git-tag.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documenta
On Thu, Oct 20, 2016 at 12:17:33PM +0200, Johannes Schindelin wrote:
> If you want to know just how harmful this reliance on shell scripting is
> to our goal of keeping Git portable: already moving from Linux to MacOSX
> costs you roughly 3x as long to run the build & test (~12mins vs ~36mins
> fo
Hi Junio,
On Tue, 18 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> > To remedy that, we now take custody of the option values in question,
> >> > requiring those values to be malloc()ed or strdup()ed
> >>
> >> That is the approach this patch takes, so "eventually release
Hi Junio,
On Tue, 18 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > In the meantime, I'd be happy to just add a comment that this function is
> > intended for oneliners, but that it will also read multi-line files and
> > only strip off the EOL marker from the last line.
>
The following changes since commit 4498b3a50a0e839788682f672df267cbc1ba9292:
git-gui: set version 0.20 (2015-04-18 12:15:32 +0100)
are available in the git repository at:
git://repo.or.cz/git-gui.git tags/gitgui-0.21.0
for you to fetch changes up to ccc985126f23ff5d9ac610cb820bca48405ff5ef:
On Thu, Oct 20, 2016 at 12:50:32PM +0200, Johannes Schindelin wrote:
> That reflects my findings, too. I want to add that I found preciously
> little difference between running slow-to-fast and running in numeric
> order, so I gave up on optimizing on that front.
Interesting. It makes a 10-15% di
On Wed, Oct 19, 2016 at 4:18 PM, Johannes Schindelin
wrote:
> Hi Junio,
>
> I know you are a fan of testing things thoroughly in the test suite, but I
> have to say that it is getting out of hand, in particular due to our
> over-use of shell script idioms (which really only run fast on Linux, not
1 - 100 of 102 matches
Mail list logo
