Hi, Junio
The following changes since commit 1d25dd416f08f39042d23340db380f28abb81962:
Update draft release notes to 1.8.5 (2013-10-16 12:27:45 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
Jean-Noel Avila (1):
l10n: fr.po: 2135/2135 messages t
Am 17.10.2013 23:07, schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> Karsten Blees writes:
>>
>>> Am 16.10.2013 23:43, schrieb Junio C Hamano:
* kb/fast-hashmap (2013-09-25) 6 commits
- fixup! diffcore-rename.c: simplify finding exact renames
- diffcore-rename.c: use new h
On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano wrote:
> Brandon Casey writes:
>
>> From: Brandon Casey
>>
>> The setting of denyDeleteCurrent applies to both bare and non-bare
>> repositories. Correct the description on this point, and expand it to
>> provide some background justification for
Philip Oakley wrote:
> A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh
> directly uses `git rev-parse --show-toplevel`, which simply returns
> work_tree (static char *work_tree; in environment.c, with comment /*
> This is set by setup_git_dir_gently() and/or git_default_confi
Yoshioka Tsuneo writes:
> In the "[PATCH v7]", I changed to keep filename part of suffix to handle
> above case, but not always keep directory part because I feel totally
> keeping all part of long suffix including directory name may cause output
> like:
> …{… => …}…ongPath1/LongPath2/nameOf
From: "Philip Oakley"
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
"Philip Oakley" writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level,
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio, can you make an exception and reply to this thread? The change
> > to move away from the term "the index" has been suggested many times
> > since many years ago, it is an extremely important change to users,
> > and all the Git develop
Brandon Casey writes:
> From: Brandon Casey
>
> The setting of denyDeleteCurrent applies to both bare and non-bare
> repositories. Correct the description on this point, and expand it to
> provide some background justification for the current behavior and
> describe the full suite of settings.
Hello Junio
Thank you very much for the reviewing.
I try to fix the issues, and posted the updated patch as "[PATCH v7]".
> I am not sure if distributing the burden of truncation equally to
> three parts so that the resulting pieces are of similar lengths is
> really a good idea. Between these t
"git diff -M --stat" can detect rename and show renamed file name like
"foofoofoo => barbarbar".
Before this commit, this output is shortened always by omitting left most
part like "...foo => barbarbar". So, if the destination filename is too long,
source filename putting left or arrow can be tot
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> Such a review comment and the discussion that follows it after a
> >> patch is posted is an essential part of the collaborative
> >> development process in this community and it has helped the quality
> >> of our en
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> Jeff King writes:
> >>
> >> > It seems[1] that some
> >> > people define "ci" as "commit -a", and some people define "st" as
> >> > "status -s" or even "status -sb".
> >>
> >> These option variants aside.
> >>
>
Jonathan Nieder wrote:
> Philip Oakley wrote:
>
> > Would this be a good time to suggest a specific wording should be
> > proposed (or a reminder of what was proposed repeated) for the
> > documentation of this option. It will be the documentation that
> > users will refer to when they need to kno
Phillip Susi writes:
> I have a commit I am trying to cherry pick that removes a number of
> files. It seems to generate conflicts for those files that have been
> modified on this branch since the common ancestor.
Correct.
Without inspecting them, you would not know what you would be losing
b
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
"Philip Oakley" writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that le
Junio C Hamano writes:
> Karsten Blees writes:
>
>> Am 16.10.2013 23:43, schrieb Junio C Hamano:
>>> * kb/fast-hashmap (2013-09-25) 6 commits
>>> - fixup! diffcore-rename.c: simplify finding exact renames
>>> - diffcore-rename.c: use new hash map implementation
>>> - diffcore-rename.c: simpli
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> "Philip Oakley" writes:
>>
>>> ... and the detection process for 'toplevel' may not work
>>> properly when in a separated work-tree environment.
>>
>> Without GIT_WORK_TREE exported to point at the top-level, there is
>> nothing that lets us "
Matthieu Moy writes:
> v3
> ( http://thread.gmane.org/gmane.comp.version-control.git/235409/focus=235408 )
> is the last version I sent, and I got no feedback on it, so I guess it's
> ready for you to pick.
Thanks; done with s/pick/nitpick/ ;-).
--
To unsubscribe from this list: send the line "u
Karsten Blees writes:
> Am 16.10.2013 23:43, schrieb Junio C Hamano:
>> * kb/fast-hashmap (2013-09-25) 6 commits
>> - fixup! diffcore-rename.c: simplify finding exact renames
>> - diffcore-rename.c: use new hash map implementation
>> - diffcore-rename.c: simplify finding exact renames
>> - di
From: "Junio C Hamano"
"Philip Oakley" writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that lets us "detect" it, as the working tree does not have
wor...@alum.mit.edu (Dale R. Worley) writes:
> I must admit I've never seen the design (and I personally doubt that
> the design has ever been written down). But at least the following
> commands work correctly on a detached worktree if the current
> directory contains the .git directory, because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a commit I am trying to cherry pick that removes a number of
files. It seems to generate conflicts for those files that have been
modified on this branch since the common ancestor. Since they are
being removed, I don't care about what changes
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Such a review comment and the discussion that follows it after a
>> patch is posted is an essential part of the collaborative
>> development process in this community and it has helped the quality
>> of our end product. We unfortunately saw time
Yoshioka Tsuneo writes:
> Before this commit, this output is shortened always by omitting left most
> part like "...foo => barbarbar". So, if the destination filename is too long,
> source filename putting left or arrow can be totally omitted like
> "...barbarbar", without including any of "foofo
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Jeff King writes:
>>
>> > It seems[1] that some
>> > people define "ci" as "commit -a", and some people define "st" as
>> > "status -s" or even "status -sb".
>>
>> These option variants aside.
>>
>> Just like thinking that committing must be
Felipe Contreras writes:
> Junio, can you make an exception and reply to this thread? The change
> to move away from the term "the index" has been suggested many times
> since many years ago, it is an extremely important change to users,
> and all the Git developers agree it must be done.
"It mu
From: "Jonathan Nieder"
Philip Oakley wrote:
Would this be a good time to suggest a specific wording should be
proposed (or a reminder of what was proposed repeated) for the
documentation of this option. It will be the documentation that
users will refer to when they need to know, rather than
Jakub Narębski writes:
> W dniu 2013-10-16 23:38, Junio C Hamano pisze:
>> I recall that I wanted to see this change happen myself long time
>> ago,...
>> In short, I personally do prefer to see dashless form at the top of
>> the manpage, if it does not break other things, and there may need
>> c
Yoshioka Tsuneo writes:
> "git diff -M --stat" can detect rename and show renamed file name like
> "foofoofoo => barbarbar".
> Before this commit, this output is shortened always by omitting left most
> part like "...foo => barbarbar". So, if the destination filename is too long,
> source filenam
> From: Junio C Hamano
>
> wor...@alum.mit.edu (Dale R. Worley) writes:
>
> > In general, Git commands on a repository with a detached worktree can
> > be executed by cd'ing into the directory containing the .git
> > directory, ...
>
> Eh? News to me; it might happened to have appeared to work
Jens Lehmann wrote:
> In commit 0656781fa "git mv" learned to update the submodule path in the
> .gitmodules file when moving a submodule in the work tree. But since that
> commit update_path_in_gitmodules() gets called no matter if we moved a
> submodule or a regular file, which is wrong and lead
Matthieu Moy writes:
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 0f57397..9edd9c3 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -863,6 +863,13 @@ static const char *unique_tracking_name(const char
> *name, unsigned char *sha1)
> return NULL;
> }
>
Good day friend,
Its a year now since we won the EuroMillions Lottery of £148,656,000 pounds
sterling. To verify, you can watch our YouTube video here
http://www.youtube.com/watch?v=4lgIpsIe3a4
Recently,my wife Gillian suggested that we commence an end of year charity
event by giving out part
Ваши языковые навыки поразят Вас самих
http://kuhny.com.ua/components/com_contact/ndavv.htm
NЇВцьrИyњшиbВXЌЖЧЇvи^)оК{.nЧ+З иЇЖЁмЈ}ЉВЦ
zк&j:+vЈОЋъчzZ+Ъ+zfЃЂЗhЇ~лiџћрzЙ ЎwЅЂИ?Јшк&Ђ)пЂf
Nguyễn Thái Ngọc Duy writes:
> This is the only plumbing command that is controlled by
> core.preferredPackVersion so far.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/technical/protocol-capabilities.txt | 4
> builtin/receive-pack.c| 3 ++-
>
Hi,
On 09:13 Thu 17 Oct, John Keeping wrote:
> It took me a minute to spot the problem when I tested this, but you're
> right that there is a bug and I agree that the patch below is the right
> fix.
>
> Perhaps a better commit message will help others looking at this, maybe
> something like this?
Am 16.10.2013 00:22, schrieb pro-logic:
> I also get fairly slow performance out of the checkout / reset
> operations on windows.
>
> This discussion got me trying to work out what's taking so long on
> windows. To help I used killcache [1] to flush the HDD cache and
> Very Sleepy [2] to profile
Jeff King writes:
> On Wed, Oct 16, 2013 at 09:41:16AM -0600, Martin Fick wrote:
>
>> I have nightmares about this sort of thing every now and
>> then, and we even experience some corruption here and there
>> that needs to be fixed (mainly missing objects when we toy
>> with different git repa
On rename detection like command "git diff -M ...", rename is detected
based on file similarities. This file similarities are calculated based
on the contents of file. And, if the similarities of contents are the
same, filename is taken into account.
But, the similarity of filename is calculated j
освободится от невыносимого зрения очевидно http://www.tayga.pro/tmp/pbfdx.htm
On Thu, Oct 17, 2013 at 1:13 PM, Jakub Narębski wrote:
>> Felipe Contreras writes:
>>> diff --git a/Documentation/git-checkout.txt
>>> b/Documentation/git-checkout.txt
>>> index ca118ac..8d98383 100644
>>> --- a/Documentation/git-checkout.txt
>>> +++ b/Documentation/git-checkout.txt
>>> @@ -1,9 +
W dniu 2013-10-16 23:38, Junio C Hamano pisze:
Felipe Contreras writes:
[...]
I recall that I wanted to see this change happen myself long time
ago, and suspect that there may have been some reason that prevented
us from doing so. I might have found that AsciiDoc back then did
not like the in
Junio C Hamano writes:
> Did anything further happen to this discussion? Is v3 the version
> with agreement among the list members I just should pick up?
v3
( http://thread.gmane.org/gmane.comp.version-control.git/235409/focus=235408 )
is the last version I sent, and I got no feedback on it, so
Am 16.10.2013 23:43, schrieb Junio C Hamano:
> * kb/fast-hashmap (2013-09-25) 6 commits
> - fixup! diffcore-rename.c: simplify finding exact renames
> - diffcore-rename.c: use new hash map implementation
> - diffcore-rename.c: simplify finding exact renames
> - diffcore-rename.c: move code arou
On rename detection like command "git diff -M ...", rename is detected
based on file similarities. This file similarities are calculated based
on the contents of file. And, if the similarities of contents are the
same, filename is taken into account.
But, the similarity of filename is calculated j
On Thu, Oct 17, 2013 at 09:52:09AM +0300, Hemmo Nieminen wrote:
> The log's graph's colors were off sometimes when merging several
> branches. For example in the graph depicted below, the '-.' part
> following the asterisk was colored with incorrect colors. This was
> caused by the fact that th
46 matches
Mail list logo
