Am 21.06.2016 um 23:04 schrieb Jeff King:
> On Tue, Jun 21, 2016 at 10:57:43PM +0200, René Scharfe wrote:
>
>> Am 21.06.2016 um 22:42 schrieb René Scharfe:
>>> The value 120 is magic; we need it to pass the tests. That's
>>> because prepare_header() is used for building extended header
>>> record
Am 21.06.2016 um 00:54 schrieb René Scharfe:
Am 16.06.2016 um 06:37 schrieb Jeff King:
2. System tars that cannot handle pax headers.
In t5000 there is a simple interpreter for path headers for systems
whose tar doesn't handle them. Adding one for mtime headers may be
feasible.
It's just
Am 21.06.2016 um 23:02 schrieb Jeff King:
On Tue, Jun 21, 2016 at 10:42:52PM +0200, René Scharfe wrote:
If we could set the limit to a lower value than 8GB for testing then we
could at least check if the extended header is written, e.g. if ustar_size()
could be convinced to return 0 every time
The current logic seems to invert the error message when using verbose messages.
The inversion seems to be indicated by the caller:
if self.inClientSpec(f['path']) and self.hasBranchPrefix(f['path'])]
This behavior has existed since the original commit:
commit 4ae048e67e5f0d786b9febc438433d95f18e5
Before this patch, we used character buffer manipulations to split
messages from the sideband at line breaks and insert "remote: " at the
beginning of each line, using the packet size to determine the end of a
message. However, since it is safe to assume that diagnostic messages
from the sideband n
On Tue, Jun 21, 2016 at 11:44:13AM +, Vasco Almeida wrote:
> --- a/git-difftool.perl
> +++ b/git-difftool.perl
> @@ -451,11 +452,11 @@ sub dir_diff
> }
>
> if (exists $wt_modified{$file} and exists $tmp_modified{$file})
> {
> - my $errmsg = "wa
http://git-htmldocs.googlecode.com/git/git.html says
There was no service found for the uri requested.
Link to the HTML documentation on repo.or.cz instead.
I'd rather use an up-to-date https link for the rendered
documentation, but I wasn't able to find one. According to the 'todo'
branch, pr
On Tue, Jun 21, 2016 at 5:14 PM, Charles Bailey wrote:
> From: Charles Bailey
>
> This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e and adds an
> alternative fix to maintain the -L --cached behavior.
It is common to provide some context along with the (shortened) commit
ID. For instan
Hi Michael,
On Tue, Jun 21, 2016 at 4:06 PM, Michael Eager wrote:
> Hi Stephan!
>
> On 06/19/2016 07:01 PM, Stefan Beller wrote:
>>
>> On Sat, Jun 18, 2016 at 4:20 PM, Michael Eager wrote:
>>>
>>>
>>> Any other ways to do what I want without creating a separate forked
>>> repo for each of the su
Hi Stephan!
On 06/19/2016 07:01 PM, Stefan Beller wrote:
On Sat, Jun 18, 2016 at 4:20 PM, Michael Eager wrote:
Any other ways to do what I want without creating a separate forked
repo for each of the sub-projects? Or have I misunderstood one of
these schemes?
I think forking is the way to
Charles Bailey writes:
> Is "Helped-by" an appropriate attribution in this case?
Sure.
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 462e607..ae73831 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -386,7 +386,7 @@ static int grep_cache(struct grep_opt *opt, const struct
> p
"brian m. carlson" writes:
I was trying to make sure there is no misconversion, but some lines
that got wrapped were distracting. For example:
> @@ -2721,7 +2722,8 @@ static int diff_populate_gitlink(struct diff_filespec
> *s, int size_only)
> if (s->dirty_submodule)
> dirt
"brian m. carlson" writes:
> Apply the set of semantic patches from contrib/examples/coccinelle to
> convert some leftover places using struct object_id's hash member to
> instead use the wrapper functions that take struct object_id natively.
It is somewhat curious how these 'some leftover place
Signed-off-by: Charles Bailey
---
Spotted while testing t7810-grep and grep "i-t-a" fixes.
t/t7810-grep.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 1e72971..c4302ed 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -353,7 +3
From: Charles Bailey
This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e and adds an
alternative fix to maintain the -L --cached behavior.
4d5520053 caused 'git grep' to no longer find matches in new files in
the working tree where the corresponding index entry had the "intent to
add" b
On Tue, Jun 21, 2016 at 10:57:43PM +0200, René Scharfe wrote:
> Am 21.06.2016 um 22:42 schrieb René Scharfe:
> > The value 120 is magic; we need it to pass the tests. That's
> > because prepare_header() is used for building extended header
> > records as well and we don't create extended headers
"brian m. carlson" writes:
> This series is part 4 in a series of conversions to replace instances of
> unsigned char [20] with struct object_id. Most of this series touches
> the merge-recursive code.
I've queued them in 'pu', but please read contrib/examples/README
;-) Tentatively, I used con
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 20 Jun 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > Just like the pretty printing machinery, we should simply ignore empty
>> > lines at the beginning of the commit messages.
>> >
>> > This discrepancy was noticed when
On Tue, Jun 21, 2016 at 10:42:52PM +0200, René Scharfe wrote:
> >> If we could set the limit to a lower value than 8GB for testing then we
> >> could at least check if the extended header is written, e.g. if
> >> ustar_size()
> >> could be convinced to return 0 every time using a hidden command l
Am 21.06.2016 um 17:59 schrieb Jeff King:
> On Tue, Jun 21, 2016 at 12:54:11AM +0200, René Scharfe wrote:
>
>>> Unfortunately, it's quite an expensive test to run. For one
>>> thing, unless your filesystem supports files with holes, it
>>> takes 64GB of disk space (you might think piping straight t
Am 21.06.2016 um 22:42 schrieb René Scharfe:
> The value 120 is magic; we need it to pass the tests. That's
> because prepare_header() is used for building extended header
> records as well and we don't create extended headers for extended
> headers (not sure if that would work anyway), so they si
On Tue, Jun 21, 2016 at 07:44:55PM +, Robin H. Johnson wrote:
> On Thu, Jun 16, 2016 at 12:37:33AM -0400, Jeff King wrote:
> > We could ship just the resulting compressed object data as a
> > loose object, but even that takes 64MB. So sadly, this code
> > path remains untested in the test sui
Am 21.06.2016 um 17:59 schrieb Jeff King:
> On Tue, Jun 21, 2016 at 12:54:11AM +0200, René Scharfe wrote:
>
>>> Unfortunately, it's quite an expensive test to run. For one
>>> thing, unless your filesystem supports files with holes, it
>>> takes 64GB of disk space (you might think piping straight
On Mon, Jun 20, 2016 at 11:32 PM, Istvan Zakar wrote:
> Hi,
>
> Thanks for the answer.
> So it means that it is a setting on the server side which can be
> activated? (I guess it depends on the version of the server)
> I did some reading in the topic. Are you talking about this setting
> "uploadpa
Johannes Schindelin writes:
> Just like the pretty printing machinery, we should simply ignore empty
> lines at the beginning of the commit messages.
Thanks.
>
> This discrepancy was noticed when an early version of the rebase--helper
> produced commit objects with more than one empty line betw
On 06/21/2016 08:39 PM, Junio C Hamano wrote:
Armin Kunaschik writes:
On Tue, May 31, 2016 at 7:51 AM, Junio C Hamano wrote:
Torsten Bögershausen writes:
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 7ce4cd7..905035c 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.s
On Tue, Jun 21, 2016 at 12:38 PM, Jeff King wrote:
> On Tue, Jun 21, 2016 at 12:18:29PM -0700, Junio C Hamano wrote:
>
>> Stefan Beller writes:
>>
>> > Unlike the prior patch we would not want this patch to fall through
>> > to origin/maint fast, but allow cooking?
>>
>> I do not see anything t
On Thu, Jun 16, 2016 at 12:37:33AM -0400, Jeff King wrote:
> We could ship just the resulting compressed object data as a
> loose object, but even that takes 64MB. So sadly, this code
> path remains untested in the test suite.
Additionally compress the object data, and insert it for the purpose of
On Tue, Jun 21, 2016 at 12:18:29PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > Unlike the prior patch we would not want this patch to fall through
> > to origin/maint fast, but allow cooking?
>
> I do not see anything that makes this treated differently from the
> other fix. T
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Johannes Schindelin writes:
>>
>>> We are about to teach the log_tree machinery to reuse the diffopt.file
>>> setting to output to a file stream different from stdout.
>>>
>>> This means that builtin am can no longer ask the diff machinery to
On Fri, May 13, 2016 at 03:25:58PM +0200, Johannes Schindelin wrote:
> This patch makes perf-lib.sh more robust so that it can run correctly
> even inside a worktree. For example, it assumed that $GIT_DIR/objects is
> the objects directory (which is not the case for worktrees) and it used
> the co
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> We are about to teach the log_tree machinery to reuse the diffopt.file
>> setting to output to a file stream different from stdout.
>>
>> This means that builtin am can no longer ask the diff machinery to
>> close the file when actually c
Stefan Beller writes:
> Unlike the prior patch we would not want this patch to fall through
> to origin/maint fast, but allow cooking?
I do not see anything that makes this treated differently from the
other fix. The only difference in behaviour is that "lines" file is
now created at the root
Johannes Schindelin writes:
> Note: there are more places in the builtin am code that ignore
> errors returned from library functions. Fixing those is outside the
> purview of the current patch series, though.
The caller of parse_mail() and parse_mail_rebase() is not prepared
to see an error cod
Lars Schneider writes:
>> On 21 Jun 2016, at 15:53, Andrew Oakley wrote:
>>
>> The logic here was inverted, you got a message saying the file is
>> ignored for each file that is not ignored.
>> ---
>> git-p4.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/git-p4.p
Lars Schneider writes:
>> On 21 Jun 2016, at 15:53, Johannes Schindelin
>> wrote:
>>
> Looks good to me.
Thanks, both, for following thru.
Will apply.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
Armin Kunaschik writes:
> On Tue, May 31, 2016 at 7:51 AM, Junio C Hamano wrote:
>> Torsten Bögershausen writes:
>>
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 7ce4cd7..905035c 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -446,7 +446,7
Nikolaus Rath writes:
> On Jun 20 2016, Nikolaus Rath wrote:
>> On Jun 20 2016, Junio C Hamano wrote:
>>> Nikolaus Rath writes:
>>>
What's the best way to find all commits in a branch A that have not been
cherry-picked from (or to) another branch B?
I think I could format-p
Jeff King writes:
> Junio, this is the jk/big-and-old-archive-tar topic.
>
> The interdiff is:
> ...
> diff --git a/archive-tar.c b/archive-tar.c
> index c7b85fd..ed562d4 100644
> --- a/archive-tar.c
> +++ b/archive-tar.c
> @@ -179,7 +179,7 @@ static size_t get_path_prefix(const char *path, size_
Johannes Schindelin writes:
> We are about to teach the log_tree machinery to reuse the diffopt.file
> setting to output to a file stream different from stdout.
>
> This means that builtin am can no longer ask the diff machinery to
> close the file when actually calling the log_tree machinery (wh
> On 21 Jun 2016, at 15:53, Andrew Oakley wrote:
>
> The logic here was inverted, you got a message saying the file is
> ignored for each file that is not ignored.
> ---
> git-p4.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index b6593cf..b1
> On 21 Jun 2016, at 15:53, Johannes Schindelin
> wrote:
>
> As this developer has no access to MacOSX developer setups anymore,
> Travis becomes the best bet to run performance tests on that OS.
>
> However, on MacOSX /usr/bin/time is that good old BSD executable that
> no Linux user cares ab
On Jun 20 2016, Nikolaus Rath wrote:
> On Jun 20 2016, Junio C Hamano wrote:
>> Nikolaus Rath writes:
>>
>>> What's the best way to find all commits in a branch A that have not been
>>> cherry-picked from (or to) another branch B?
>>>
>>> I think I could format-patch all commits in every branch
Junio C Hamano writes:
> I think you would need something similar to "pwd -W", that is, leave
> "git --exec-path" as a way to give shell scripts people have written
> over the years that allows them to say "git-cmd" as long as they do
> PATH="$(git --exec-path):$PATH" upfront. And for Windows sc
Johannes Schindelin writes:
>> Hmm, I am confused. `git --exec-path` _is_ meant to "spit out" a
>> path that is usable when prepended/appended to $PATH [1], and it
>> does _not_ have to be POSIX-ish path. It is totally up to the port
>> to adjust it to the platform's convention how the $PATH en
Johannes Schindelin writes:
> That is a very convincing argument. So convincing that I wanted to change
> the patch to guard behind `diff_use_color_default == GIT_COLOR_AUTO`.
I actually was expecting, instead of your:
if (output_directory) {
+ rev.diffopt.use_color = 0;
On Sun, Jun 19, 2016 at 12:00 PM, Jeff King wrote:
> Stefan, I think it might be worth revisiting the default set by d22eb04
> to propagate shallowness from the super-project clone. In an ideal
> world, we would be asking each submodule for the actual commit we are
> interested in, and shallowness
Konstantin Khomoutov writes:
> On Thu, 10 Mar 2016 07:28:50 +
> Florian Manschwetus wrote:
>
>> I tried to setup git-http-backend with iis, as iis provides proper
>> impersonation for cgi under windows, which leads to have the
>> filesystem access performed with the logon user, therefore the
On Tue, Jun 21, 2016 at 2:10 PM, Jeff King wrote:
> ...
> So this request actually takes _two_ upload-pack instances to serve
> (which is not uncommon when we need multiple rounds of
> get_common_commits(), though I am a little surprised that would be the
> case for a clone). And the first one see
--
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
The logic here was inverted, you got a message saying the file is
ignored for each file that is not ignored.
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index b6593cf..b123aa2 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2674,7 +2674,7 @@ c
On Tue, Jun 21, 2016 at 12:54:11AM +0200, René Scharfe wrote:
> > Unfortunately, it's quite an expensive test to run. For one
> > thing, unless your filesystem supports files with holes, it
> > takes 64GB of disk space (you might think piping straight to
> > `hash-object --stdin` would be better,
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pat
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
0777, or 1 byte short of 8GB. The correct solution
for a large
On Thu, Jun 16, 2016 at 12:35:23AM -0400, Jeff King wrote:
> The ustar format has some fixed-length numeric fields, and it's possible
> to generate a git tree that can't be represented (namely file size and
> mtime). Since f2f0267 (archive-tar: use xsnprintf for trivial
> formatting, 2015-09-24),
On Tue, Jun 21, 2016 at 11:59:20AM -0400, Jeff King wrote:
> > > + if (ustar_size(size) != size)
> > > + strbuf_append_ext_header_uint(&ext_header, "size", size);
> >
> > It needs "S_ISREG(mode) && " as well, no? In practice it probably doesn't
> > matter (until someone stores a 8GB long
On Tue, May 31, 2016 at 7:51 AM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
>>> index 7ce4cd7..905035c 100755
>>> --- a/t/t7800-difftool.sh
>>> +++ b/t/t7800-difftool.sh
>>> @@ -446,7 +446,7 @@ write_script .git/CHECK_SYMLINKS
Hi Paul,
On Tue, 21 Jun 2016, Paul Tan wrote:
> On Tue, Jun 21, 2016 at 6:34 PM, Johannes Schindelin
> wrote:
> > - this uncovered a problem with builtin am, where it asked the diff
> > machinery to close the file stream, but actually called the log_tree
> > machinery (which might mean that
Hi Johannes,
On Tue, Jun 21, 2016 at 6:34 PM, Johannes Schindelin
wrote:
> - this uncovered a problem with builtin am, where it asked the diff
> machinery to close the file stream, but actually called the log_tree
> machinery (which might mean that this patch series inadvertently fixes
> a
As this developer has no access to MacOSX developer setups anymore,
Travis becomes the best bet to run performance tests on that OS.
However, on MacOSX /usr/bin/time is that good old BSD executable that
no Linux user cares about, as demonstrated by the perf-lib.sh's use
of GNU-ish extensions. And
SALUT
Je veux vous demander votre avis sur la façon d'investir dans votre
pays ?? nos principaux bailleurs sommes prêts à financer des projets
rentables et offrir des prêts pour des projets privés, nos Partenaire
( chef financer ) est en Europe, en Asie, Emirats Arabes Unis et
l'Afrique Même si v
Hi Lars,
On Tue, 21 Jun 2016, Lars Schneider wrote:
> > On 21 Jun 2016, at 13:55, Johannes Schindelin
> > wrote:
> >
> >> ...
> >> If we don't run any perf tests by default on Travis CI then I wouldn't
> >> take the ".travis.yml" part of the patch just to keep our Travis CI
> >> setup as lean
> On 21 Jun 2016, at 13:55, Johannes Schindelin
> wrote:
>
>> ...
>> I think we definitively should take the "perf-lib.sh" part of the patch
>> as this makes the perf test run on OSX and therefore is a strict
>> improvement.
>
> Yes, it was meant as the starting point to get more things to run
Just like the pretty printing machinery, we should simply ignore empty
lines at the beginning of the commit messages.
This discrepancy was noticed when an early version of the rebase--helper
produced commit objects with more than one empty line between the header
and the commit message.
Signed-of
On Mon, Jun 20, 2016 at 11:37:50PM -0700, Norbert Kiesel wrote:
> There are more strange things happening with dates. One example is
> that `git commit --date=@4102444799` produces a commit with the
> correct author date "Thu Dec 31 15:59:59 2099 -0800" (for my local
> timezone which is Americas/
On Tue, Jun 21, 2016 at 11:23:03AM +, Eric Wong wrote:
> I noticed "fatal: The remote end hung up unexpectedly" in server
> logs from shallow clones. Totally reproducible in the test
> cases, too. The following change shows it:
> [...]
> [Tue Jun 21 11:07:41.391269 2016] [cgi:error] [pid 215
Hi Junio,
On Mon, 20 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The recently introduced developer flags identified a couple of
> > old-style function declarations in the Windows-specific code where
> > the parameter list was left empty instead of specifying "void"
> > e
Hi Junio,
On Mon, 20 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Just like the pretty printing machinery, we should simply ignore empty
> > lines at the beginning of the commit messages.
> >
> > This discrepancy was noticed when an early version of the rebase--helper
> >
Hi Junio,
On Mon, 20 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Windows, we have to juggle two different schemes of representing
> > paths: the native, Windows paths (the only ones known to the main Git
> > executable) on the one hand, and POSIX-ish ones used by the
Hi Lars,
On Tue, 21 Jun 2016, Lars Schneider wrote:
> > On 20 Jun 2016, at 21:48, Junio C Hamano wrote:
> >
> > Johannes Schindelin writes:
> >
> >> On Sun, 19 Jun 2016, Lars Schneider wrote:
> >>
> On 18 Jun 2016, at 15:03, Johannes Schindelin
> wrote:
>
> As this deve
Mark strings often displayed to user for translation.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 53 +++--
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..2521832
Mark simple strings (without interpolation) for translation.
Brackets around first parameter of ternary operator is necessary because
otherwise xgettext fails to extract strings marked for translation from
the rest of the file.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 68 +++
Mark message of edit_hunk_manually displayed in the editing file when
user chooses 'e' option. The message had to be unfolded to allow
translation of the $participle verb.
Some messages end up being exactly the same for some uses cases, but
left it for easer change in the future, e.g., wanting to
Signed-off-by: Vasco Almeida
---
git-difftool.perl | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index ebd13ba..fe7f003 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -22,6 +22,7 @@ use File::Path qw(mkpath
Mark warnings, errors and other messages that are interpolated for
translation.
We must call sprintf() before calling die() and in few other
circumstances in order to interpolation take place.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 71
Mark warnings, errors and other messages for translation.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2521832..e7f712e 100755
--- a/
Mark messages in here document without interpolation for translation.
Marking for translation by removing here documents this way, rather than
take advantage of "print __ << EOF" way, makes other instances of help
messages in clean.c match the first two in this file. Otherwise,
reusing here docum
Mark message assembled in place for translation, unfolding each use case
for each entry in the %patch_modes hash table.
Previously, this script relied on whether $patch_mode was set to run the
command patch_update_cmd() or show status and loop the main loop. Now,
it uses $cmd to indicate we must r
Mark plural strings for translation. Unfold each action case in one
entire sentence.
Pass new keyword for xgettext to extract.
Update test to include new subrotine Q__() for plural strings handling.
Signed-off-by: Vasco Almeida
---
Makefile | 3 ++-
git-add--interactive.perl
Use of sprintf following die or error_msg is necessary for placeholder
substitution take place.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interac
Mark help message of help_patch_cmd for translation. The message must
be unfolded to be free of variables so we can have hight quality
translations.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 65 +++
1 file changed, 54 insertions(+),
I noticed "fatal: The remote end hung up unexpectedly" in server
logs from shallow clones. Totally reproducible in the test
cases, too. The following change shows it:
diff --git a/t/t5561-http-backend.sh b/t/t5561-http-backend.sh
index 90e0d6f..cfa55ce 100755
--- a/t/t5561-http-backend.sh
+++ b/
The diff machinery can optionally output to a file stream other than
stdout, by overriding diffopt.file. In such a case, the rest of the
log tree machinery should also write to that stream.
Currently, there is no user of the line level log that wants to
redirect output to a file. Therefore, one mi
We rely on the auto-detection ("is stdout a terminal?") to determine
whether to use color in the output of format-patch or not. That happens
to work because we freopen() stdout when redirecting the output to files.
However, we are about to fix that work-around, in which case the
auto-detection has
The idea is to allow callers to redirect log-tree's output to a file
without having to freopen() stdout (which would modify global state,
a big no-no-no for library functions).
I reviewed log-tree.c, graph.c, line-log.c, builtin/shortlog.c and
builtin/log.c line by line to ensure that all calls th
We are about to teach the log_tree machinery to reuse the diffopt.file
setting to output to a file stream different from stdout.
This means that builtin am can no longer ask the diff machinery to
close the file when actually calling the log_tree machinery (which
wants to flush the very same file s
We just taught the relevant functions to respect the diffopt.file field,
to allow writing somewhere else than stdout. Let's make use of it.
Technically, we do not need to avoid that call in a builtin: we assume
that builtins (as opposed to library functions) are stand-alone programs
that may do wi
It is never a good idea to ignore errors, so let's handle them.
While at it, handle fopen() errors more gently (i.e. give the caller a
chance to do something about it rather than die()ing).
Note: there are more places in the builtin am code that ignore
errors returned from library functions. Fixi
Earlier, we freopen()ed stdout in order to write patches to files.
That forced us to duplicate stdout (naming it "realstdout") because we
*still* wanted to be able to report the file names.
As we do not abuse stdout that way anymore, we no longer need to
duplicate stdout, either.
Signed-off-by: J
When the caller overrides diffopt.file (which defaults to stdout),
the diff machinery already redirects its output, and the graph display
should also write to that file.
Signed-off-by: Johannes Schindelin
---
graph.c | 30 +-
1 file changed, 17 insertions(+), 13 delet
The diff options already know how to print the output anywhere else
than stdout. The same is needed for log output in general, e.g.
when writing patches to files in `git format-patch`. Let's allow
users to use log_tree_commit() *without* changing global state via
freopen().
Signed-off-by: Johannes
Hi,
On Tue, 21 Jun 2016, Johannes Schindelin wrote:
> On Tue, 21 Jun 2016, Johannes Schindelin wrote:
>
> > Expect v3 in a moment.
>
> I am sorry. The regression test suite just sounded red alert. So: do not
> expect v3 in a moment, but later today.
So making maybe_flush_or_die() uncovered a p
This will be needed to avoid freopen() in `git format-patch`.
Signed-off-by: Johannes Schindelin
---
builtin/shortlog.c | 13 -
shortlog.h | 1 +
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index bfc082e..39d74fe 100
> On 21 Jun 2016, at 09:50, LUCAS Thomas (EXT)
> wrote:
>
> Setup:
> - 2.9.0.windows.1 x64 on a windows 7 16g ram, ssd
> - No particular installation settings, default.
>
> Details:
> - Running git from either a cmd or GitExtensions, I encountered an issue
> while staging or checkout of lfs
Nikolaus Rath venit, vidit, dixit 21.06.2016 01:21:
> On Jun 20 2016, Junio C Hamano wrote:
>> Nikolaus Rath writes:
>>
>>> What's the best way to find all commits in a branch A that have not been
>>> cherry-picked from (or to) another branch B?
>>>
>>> I think I could format-patch all commits in
Previously this example would fail if the oldest commit(s) in any filtered
branch is/are empty (no files) because the index would not change, and the mv
would fail with:
mv: cannot stat /index.new': No such file or directory
This commonly occurs with histories created from git-svn-clone
> On 20 Jun 2016, at 21:48, Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
>> On Sun, 19 Jun 2016, Lars Schneider wrote:
>>
On 18 Jun 2016, at 15:03, Johannes Schindelin
wrote:
As this developer has no access to MacOSX developer setups anymore,
Travis becom
Setup:
- 2.9.0.windows.1 x64 on a windows 7 16g ram, ssd
- No particular installation settings, default.
Details:
- Running git from either a cmd or GitExtensions, I encountered an issue while
staging or checkout of lfs files. I am processing 3000 files for a total of
500MB.
Files are proccesse
Hi,
On Tue, 21 Jun 2016, Johannes Schindelin wrote:
> Expect v3 in a moment.
I am sorry. The regression test suite just sounded red alert. So: do not
expect v3 in a moment, but later today.
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
> On 21 Jun 2016, at 08:20, Matthieu Moy wrote:
>
> Antoine Queru writes:
>
>> However, in the last version, if we want to deny an website,
>> including all schemes, we can blacklist the url without the
>> scheme. For example, "pushBlacklist = github.com". By doing so, this
>> remote is not an
1 - 100 of 102 matches
Mail list logo
