> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>
> Eric Wong writes:
>
>> Lars Schneider wrote:
>>> Hi,
>>>
>>> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
>>> d9545c7
>>> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>>>
>>> D
On 13.05.16 14:33, Michael Haggerty wrote:
> Torsten, thanks for the report. Peff, thanks for the analysis.
I didn't follow all the details.
The new "pu" passes with no errors on all of my test systems :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
On Sat, May 14, 2016 at 8:26 AM, Johannes Schindelin
wrote:
[...]
>> >> By the way there are no tests yet for this new feature, and I am not
>> >> sure at all that "--silent" and "be_silent" are good names.
>> >
>> > If you want to follow existing code's example, we typically call this
>> > opti
On Sat, May 14, 2016 at 07:40:11AM +0200, Torsten Bögershausen wrote:
> On 13.05.16 18:43, Junio C Hamano wrote:
> > Adam Dinwoodie writes:
> >
> >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
> >> file that would have its line endings rewritten, the "CRLF will be
> >> r
Add failing test case showing CRLF -> LF rewrite warnings being printed
multiple times when running "git commit".
Signed-off-by: Adam Dinwoodie
---
t/t0020-crlf.sh | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index f94120a
Congratulations,
You may not understand why this letter came to you. We have been having a
meeting for quit sometime now and we just came to a logical conclusion few days
ago in affiliation with
the World Bank president. This letter is to few well listed people that have
been scammed
in
On Sat, May 14, 2016 at 3:41 AM, Junio C Hamano wrote:
> * pb/bisect (2016-05-13) 4 commits
> - t6030: explicitly test for bisection cleanup
This one can be considered as independent of the entire series.
> - bisect--helper: `write_terms` shell function in C
> - bisect: rewrite `check_term_f
On do, 2016-05-12 at 16:19 -0400, David Turner wrote:
> This version fixes that. I didn't test on a virtual machine, but I
> did test by adding a sleep().
I can confirm that on my single-cpu test VM, this no longer triggers
errors.
D.
--
To unsubscribe from this list: send the line "unsubscribe
> The configuration sections can have comments and they are preserved
> even when they become empty. Adding something unrelated will still
> make it appear the stale comment applies to it.
Now that you mention it, I think I have read that before. Unfortunately
I forgot about it until you reminde
Hi Everyone,
I'm embarking on a bit of a quest to bring git into a CNC manufacturing
environment for the Mozaik software package. Does anyone in the group have
experience with git for that package (expecting probably not, but I had to
ask)? I'm hoping that there won't be too many problems (interna
Jonas Bernoulli writes:
>> The configuration sections can have comments and they are preserved
>> even when they become empty. Adding something unrelated will still
>> make it appear the stale comment applies to it.
>
> Now that you mention it, I think I have read that before. Unfortunately
> I
On 14.05.16 13:17, Adam Dinwoodie wrote:
> Add failing test case showing CRLF -> LF rewrite warnings being printed
> multiple times when running "git commit".
>
The problem seems to come from this line:
index 5473493..59d4106 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -61,9 +61,18 @@
Hello! I was directed to ask here; I hope I am respecting your format.
I have a repo with a subtree. I squashed every merge with the subtree
remote to keep the history manageable. Now down the road after a bunch
of merges, I need to split my repo’s master branch into two new
branches and move the
Matthieu Moy writes:
> Junio's explanation must not necessarily be read as "it has to be the
> way it is", but more as "getting it right is harder than you think", and
> that in turn explains why no one changed the behavior.
Thanks for clarification. s/must not necessarily/must not/;
--
To unsu
Jeff King writes:
> On Fri, May 13, 2016 at 07:45:42PM -0400, Eric Sunshine wrote:
>
>> > + >expect &&
>>
>> What's this 'expect' file for? Is it leftover gunk from before you
>> settled on 'diff --exit-code'?
>
> Oops, yes, that's exactly it.
>
> -Peff
Thanks for sharp eyes. Let's squas
Lars Schneider writes:
>> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>>
>> Are you saying that "git p4" itself breaks unless fast-import always
>> writes a new (tiny) packfile? That sounds quite broken, and setting
>> unpacklimit to 0 does not sound like a sensible "fix". Of course,
>> i
Christian Couder writes:
> On Thu, May 12, 2016 at 10:43 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Up to this point, the conversion looks quite sensible, even though I
>>> think the organization of fields in apply_state do not look logical.
>>
>> I'd stop here for now, as every
Christian Couder writes:
>>> So it looks to me that --quiet means something like "don't tell the
>>> story of your life, but in case of problem you are allowed to
>>> complain". In other word --quiet generally doesn't suppress error
>>> messages from error() or die().
>>
>> Right.
>>
>> And if yo
Dmitry Gutov writes:
> Hi all,
>
> Subj. ...even though it's explicitly mentioned in the subcommand's man
> page. Git version 2.7.4 here.
>
> To elaborate:
>
> - Call 'git config --global diff.algorithm histogram'.
The variable belongs to UI config, meant for Porcelain "git diff",
together with
Torsten Bögershausen writes:
> Do we need to run diff_populate_filespec() twice when src==dst ?
Of course we do.
src and dst may have the same path, but are coming from different
places (src may be an indexed blob while dst may be a file in the
working tree).
> If yes, we may need to introduce
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio's explanation must not necessarily be read as "it has to be the
>> way it is", but more as "getting it right is harder than you think", and
>> that in turn explains why no one changed the behavior.
>
> Thanks for clarification. s/must no
Stefan Beller writes:
> Labels were originally designed to manage large amount of
> submodules, the discussion steered this in a more general
> direction, such that other files can be labeled as well.
s/other files/any path/.
> Labels are meant to describe arbitrary set of files, which
> is not
On Sat, May 14, 2016 at 8:31 PM, Junio C Hamano wrote:
>
> I however do not see a reason why you need to expose that feature to
> the users of "git apply". So I am not sure if any of us care deeply
> the choice among --silent, --quiet and -q -q.
About that I wrote in initial email above:
"The l
On Sat, May 14, 2016 at 10:37:07AM -0700, Junio C Hamano wrote:
> Thanks for sharp eyes. Let's squash this in, perhaps?
>
> t/t9107-git-svn-migrate.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh
> index 29
If you consider a simple case where I run the following command:
$ git log --oneline --graph --decorate A...B
Where A and B are both branches with a single merge base and a series
of commits on each branch. Very simple example with no loops or crazy
ancestry. Below is an example repo I set up, wh
On Sat, May 14, 2016 at 06:09:21PM -0500, Robert Dailey wrote:
> Using A...B notation, I get this:
>
> $ git log --oneline --decorate --graph A...B
> * eb28ae4 (HEAD -> B) Commit 6
> * 7173fa1 Commit 5
> * b5fe27b Commit 4
> * 37a8ca8 (A) Commit 3
> * 72745a7 Commit 2
>
> The graph no longer mak
Robert Dailey writes:
> This is because the merge base commit isn't shown. I understand this
> is "by-design", but is there a way to include it? It's necessary to
> have it, for this graph to make sense.
--boundary, perhaps?
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
On Sat, May 14, 2016 at 6:30 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> This is because the merge base commit isn't shown. I understand this
>> is "by-design", but is there a way to include it? It's necessary to
>> have it, for this graph to make sense.
>
> --boundary, perhaps?
Big t
Hi,
Not sure this is the right place; I couldn't find a mailing list specifically
for git *users*?
Problem: Given two source trees, neither yet under source control. One
(hereafter:MOD)containing extensive modifications of the other
(hereafter:ORIG), I want to bring these together under sourc
From: Torsten Bögershausen
If .gitattributes are used to enable CRLF->LF rewriting,
then commiting a file that would have its line endings rewritten,
the "CRLF will be replaced by LF" warning is printed 2 times.
A user expects it to be printed only once.
The automatic rename detection by Git runs
From: Torsten Bögershausen
It may be that this patch only covers over a sympton, rather
than fixing the root cause.
Torsten Bögershausen (1):
No duplicate CRLF rewrite warnings on commit
diff.c | 2 ++
diffcore-break.c | 6 --
diffcore.h | 1 +
t/t0020-crlf.sh | 14 ++
On Sun, May 15, 2016 at 2:08 AM, wrote:
> If .gitattributes are used to enable CRLF->LF rewriting,
> then commiting a file that would have its line endings rewritten,
> the "CRLF will be replaced by LF" warning is printed 2 times.
> A user expects it to be printed only once.
> The automatic renam
From: Torsten Bögershausen
Break up the old 10/10 series about CLRF handling into smaller
series.
1/10..4/10 are now found in tb/core-eol-fix
This series includes 3 from the 10/10 series:
09/10 t6038; use crlf on all platforms#now 1/3
05/10 read-cache: factor out get_sha1_fr
From: Torsten Bögershausen
t6038 uses different code, dependig if NATIVE_CRLF is set ot not.
When the native line endings are LF, merge.renormalize is not tested very well.
Change the test to always use CRLF by setting core.eol=crlf.
After doing so, the test fails:
rm '.gitattributes'
rm 'contro
From: Torsten Bögershausen
Factor out the retrieval of the sha1 for a given path in
read_blob_data_from_index() into the function get_sha1_from_index().
This will be used in the next commit, when convert.c can do the
analyze for "text=auto" without slurping the whole blob into memory
at once.
A
From: Torsten Bögershausen
To compare a file in working tree with the index, convert_to_git() is used,
the the result is hashed and the hash value compared with ce->sha1.
Deep down would_convert_crlf_at_commit() is invoked, to check if CRLF
are converted or not: When a CRLF had been in the index
On 14.05.16 20:45, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Do we need to run diff_populate_filespec() twice when src==dst ?
>
> Of course we do.
>
> src and dst may have the same path, but are coming from different
> places (src may be an indexed blob while dst may be a file i
On Sun, May 15, 2016 at 2:38 AM, wrote:
> t6038 uses different code, dependig if NATIVE_CRLF is set ot not.
s/dependig/depending/
s/ot/or/
> When the native line endings are LF, merge.renormalize is not tested very
> well.
> Change the test to always use CRLF by setting core.eol=crlf.
> After
On 14.05.16 20:45, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Do we need to run diff_populate_filespec() twice when src==dst ?
>
> Of course we do.
>
> src and dst may have the same path, but are coming from different
> places (src may be an indexed blob while dst may be a file i
On Sun, May 15, 2016 at 2:38 AM, wrote:
> Factor out the retrieval of the sha1 for a given path in
> read_blob_data_from_index() into the function get_sha1_from_index().
>
> This will be used in the next commit, when convert.c can do the
> analyze for "text=auto" without slurping the whole blob i
On Sun, May 15, 2016 at 2:38 AM, wrote:
> To compare a file in working tree with the index, convert_to_git() is used,
> the the result is hashed and the hash value compared with ce->sha1.
>
> Deep down would_convert_crlf_at_commit() is invoked, to check if CRLF
> are converted or not: When a CRLF
41 matches
Mail list logo
