Pranit Bauva writes:
> I completely missed your point and you want me to go the Eric Sunshine's way?
I am neutral.
When I read your response to Eric's "top down" suggestion, I didn't
quite get much more than "I started going this way, and I do not
want to change to the
Torsten Bögershausen writes:
> That's true, but the test passes anyway.
You can also remove the body of the test and replace it with "true"
and say "the test passes anyway". Changing the test to use a file
with only one line is irresponsible, if you do not know the nature
of
Christian Couder wrote:
> Signed-off-by: Christian Couder
Thanks Christian,
Signed-off-by: Eric Wong
...And pushed to my svn/bad-ref branch for Junio.
(I don't think I'll have other git-svn-related changes
immediately
On Sat, May 7, 2016 at 7:32 AM, Jeff King wrote:
> On Fri, May 06, 2016 at 08:33:15AM -0700, Junio C Hamano wrote:
>
>> > Then I replied:
>> >
>> >However, that doesn't mean that we have to spread this badly chosen
>> >name from options to config variables, does it? I
I've noticed a slightly annoying behaviour of git-push's
--force-with-lease option around branch creation.
I'd like to be able to do:
git push --force-with-lease origin refs/heads/jk/*
to push out a load of topic branches safely in case I've switched client
machines and forgotten to
git-blame has a few options are useful when working with commits that
only modify whitespace (-w), move code within the file (-M), or move
code between files (-C). It would be nice if there was a way to
configure git so these options could be enabled by default when
running `git blame`.
I suppose
On 2016-05-07 14.19, Andreas Schwab wrote:
> Torsten Bögershausen writes:
>
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++
These tests fail here under Mac OS,
they pass under Linux:
commit ff3d9b660a4b6e9d3eeb664ce1febe717adff737
I haven't had a chance to dig further.
expecting success:
git for-each-ref --format="%(if)%(authorname)%(then)%(authorname):
%(refname)%(end)" >actual &&
cat >expect <<-\EOF
Good job.Cleaner now.
I found these typos by aspell, and duplicate words by grep -rnIE
'\b(\w+)\s+\1\b' :)
Thanks!
--
发件人:Junio C Hamano
发送时间:2016年5月7日(星期六) 02:30
收件人:李三0159
抄 送:Jeff King
Quoting Junio C Hamano :
SZEDER Gábor writes:
Arguably this helper function could be just a simple variable. I
opted for a function because:
- I preferred a single '#ifdef NO_POSIX_GOODIES', and putting a
static variable so near to EOF felt just
On 07/05/16 14:15, Ramsay Jones wrote:
>
>
> On 07/05/16 13:19, Andreas Schwab wrote:
>> Torsten Bögershausen writes:
>>
>>> The "seq" is not understood by all shells,
>>> using printf fixes this,
>>>
>>> index 20a3ffe..48d964e 100755
>>> ---
On Fri, May 6, 2016 at 6:10 PM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>
>> t1500-rev-parse contains envrionment leaks (changing dir without
>> changing back, setting config variables, etc). Add a test to clean this
>> up up so that future tests
On 07/05/16 13:19, Andreas Schwab wrote:
> Torsten Bögershausen writes:
>
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++
On Sat, May 7, 2016 at 3:45 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> A very interesting fact to note:
>> I made a mistake by dropping of the first argument 'term' in the function
>> one_of() and compiled and the test suite passed fully
Torsten Bögershausen writes:
> The "seq" is not understood by all shells,
> using printf fixes this,
>
> index 20a3ffe..48d964e 100755
> --- a/t/t6044-merge-unrelated-index-changes.sh
> +++ b/t/t6044-merge-unrelated-index-changes.sh
> @@ -20,7 +20,7 @@ test_description="merges
Hi Chris,
On Sat, 7 May 2016, Christian Couder wrote:
> On Fri, May 6, 2016 at 5:34 PM, Johannes Schindelin
> wrote:
> >
> > On Fri, 6 May 2016, Christian Couder wrote:
> >
> >> On Thu, May 5, 2016 at 10:07 PM, Johannes Sixt wrote:
> >> > Am
The "seq" is not understood by all shells,
using printf fixes this,
index 20a3ffe..48d964e 100755
--- a/t/t6044-merge-unrelated-index-changes.sh
+++ b/t/t6044-merge-unrelated-index-changes.sh
@@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
# Commit E: renames
Hi Dscho,
On Fri, May 6, 2016 at 5:34 PM, Johannes Schindelin
wrote:
> Hi Chris,
>
> On Fri, 6 May 2016, Christian Couder wrote:
>
>> On Thu, May 5, 2016 at 10:07 PM, Johannes Sixt wrote:
>> > Am 05.05.2016 um 11:50 schrieb Christian Couder:
>> >>
>>
On Sat, May 7, 2016 at 2:18 AM, Stefan Beller wrote:
> On Fri, May 6, 2016 at 12:02 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> On Fri, May 6, 2016 at 3:30 AM, Duy Nguyen wrote:
On Fri, May 6, 2016
When passing a bad --trunk option to `git svn clone`, like for example the
same URL that we are cloning:
C:\Windows\system32>git svn clone
https://mycompany.svn.beanstalkapp.com/myproject --no-metadata -A
c:\temp\svn_to_git_users.txt
For some reason, the definition of the MINGW version of
`mark_as_git_dir()` slipped into this developer's patch series to
support building Git for Windows.
As the `mark_as_git_dir()` function is not needed at all anymore (it was
used originally to support the core.hideDotFiles = gitDirOnly
On Unix (and Linux) it is common that files and directories whose names
start with a dot are not shown by default. This convention is used by Git:
the .git/ directory should be left alone by regular users, and only
accessed through Git itself.
On Windows, no such convention exists. Instead, there
Windows does not share Unix' convention that files and directories whose
names start with a dot are hidden. Hence `.git/`, for example, is in
plain view, and caused quite a bit of trouble: some users wanted to peek
inside and did not understand what it contains, others modified files.
There was a
Hi Junio,
On Fri, 6 May 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I agree with the goal of the change, but I am having a hard time
> >> justifying this addition. Primarily because I do not understand the
> >> need for this.
> >>
> >> In
From: Torsten Bögershausen
Before this change,
$ echo "* text=auto" >.gitattributes
$ echo "* eol=crlf" >>.gitattributes
would have the same effect as
$ echo "* text" >.gitattributes
$ git config core.eol crlf
Since the 'eol' attribute had higher priority than 'text=auto', this
From: Torsten Bögershausen
When statistics are done for the autocrlf handling, the search in
the content can be stopped, if e.g
- a search for binary is done, and a NUL character is found
- a search for CRLF is done, and the first CRLF is found.
Similar when statistics for binary
From: Torsten Bögershausen
A follow-up after a discussion how to fix the flaky execution
of t0025, gmane/$284352.
This patch extends the work done in commit c480539:
"Make it work also for un-normalized repositories". Make sure that CRLF
can be converted round trip, or don't
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
From: Torsten Bögershausen
Changes since v8:
As discussed earlier, 1..4 should be broken out into
tb/autocrlf-fix or so.
1..4 are not part of this series any more.
The old 10/10 is now 6/6.
It is replaced by "ce_compare_data() checks for a sha1 of a path"
It now
29 matches
Mail list logo