Christian Couder writes:
>> While I agree with Michael on the other thread that we should limit
>> the syntax and start with ':' only, if you really want to allow
>> random syntax like "Bug #12345" and "Acked-by= Peff", for which you
>> have demonstrations in the tests in the other patch, the abo
I sometimes pull things in from unrelated repositories to rebase or
cherry-pick items from a different line of development. I've done this
to bring isolated features into a project in their own feature
branches with their full development histories, and also to extract
lines of development out to t
if you move two identical {e.g.: empty} files to two new locations in a
single commit, the move detection picks them {seemingly?} arbitrarily.
it should use a statistical algorithm to compare the filenames and pick
a likely match.
my apologies in advance if this isnt the right venue or is impr
Christian Couder writes:
> Now, after having read the recent thread about "git verify-commit", I
> understand
> that you also want me to drop the signature of a tag that was merged, because
> such signatures are added to the commit message.
Huh? I am not sure if I follow. Perhaps we are talki
David Turner writes:
> When git checkout checks out a branch, create or update the
> cache-tree so that subsequent operations are faster.
>
> Signed-off-by: David Turner
> ---
> builtin/checkout.c| 4
> cache-tree.c | 22 --
> cache-tree.h | 1 +
Jeff King writes:
> First off, I agree that "verify-tag" is probably not the right place.
> There _is_ no tag object to verify anymore (the only reason it is a tag
> at all is that the signature came out of what once was a tag).
Yes, if we imagine that the header were called "mergesig", it may b
On Sun, Jun 29, 2014 at 5:13 PM, Jason Pyeron wrote:
>> -Original Message-
>> From: Phil Hord
>> Sent: Sunday, June 29, 2014 16:27
>>
>> On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron
>> wrote:
>> >> -Original Message-
>> >> From: Phil Hord
>> >> Sent: Sunday, June 29, 2014 16:09
>
> -Original Message-
> From: Phil Hord
> Sent: Sunday, June 29, 2014 16:27
>
> On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron
> wrote:
> >> -Original Message-
> >> From: Phil Hord
> >> Sent: Sunday, June 29, 2014 16:09
> >>
> >> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
> >> wr
Use argv_array_pushf for building the number string for the option
--summary-limit directly instead of using an intermediate buffer.
Signed-off-by: Rene Scharfe
---
wt-status.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 2c0bff8..882cfe9
Instead of using a PATH_MAX buffer, use argv_array for constructing the
environment for git submodule summary. This simplifies the code a bit
and removes the arbitrary length limit.
Signed-off-by: Rene Scharfe
---
wt-status.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff
On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron wrote:
>> -Original Message-
>> From: Phil Hord
>> Sent: Sunday, June 29, 2014 16:09
>>
>> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
>> wrote:
>> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron
>> wrote:
>> >> Sorry for the http://pastebin.
> -Original Message-
> From: Phil Hord
> Sent: Sunday, June 29, 2014 16:09
>
> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
> wrote:
> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron
> wrote:
> >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> >> 1ca13ed2271d60ba93d
On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord wrote:
> On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron wrote:
>> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
>> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
>> but it was too long to be readable in t
On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron wrote:
> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
> but it was too long to be readable in the email.
>
> git blame HEAD -- src/Main/Forms/CipherShed
On Fri, Jun 27, 2014 at 6:39 PM, Jason Pyeron wrote:
>> On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron
>> wrote:
>> > There are two identical files from the same original
>> parent, but both were
>> > renamed in their own branches. One branch moved the file to
>> a new folder, the
>> > other renam
Junio,
thanks for your reply and your patch.
Am 27.06.2014 20:31, schrieb Junio C Hamano:
[...]
would be a better workaround that would not break repositories with
large number of references, but it obviously will lose --date-order
option (why would it be even necessary, though? I suspect that
Am 27.06.2014 00:02, schrieb Junio C Hamano:
> Four mingw series are still in limbo--are they in good enough shape
> for Windows folks who wanted to upstream them?
I've now tested the Unicode patches a bit, and I didn't notice a
regression in my use-cases. The patches are good to go, IMHO.
-- Han
Karsten Blees writes:
> Am 28.06.2014 08:01, schrieb Matthieu Moy:
>> Karsten Blees writes:
>>
>>> I still don't like that the invalidation is done in git_config_set, though,
>>> as
>>> this is also used to write completely unrelated files.
>>
>> I don't get it. It is used to write the config
On Thu, Jun 26, 2014 at 4:09 AM, Tanay Abhra wrote:
>
> On 6/25/2014 10:15 AM, Eric Sunshine wrote:
>> On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra wrote:
>>> diff --git a/branch.c b/branch.c
>>> index 660097b..c9a2a0d 100644
>>> --- a/branch.c
>>> +++ b/branch.c
>>> @@ -140,33 +140,25 @@ static
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra wrote:
> On 6/25/2014 1:24 PM, Eric Sunshine wrote:
>> On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra wrote:
>>> Use git_config_get_string instead of git_config to take advantage of
>>> the config hash-table api which provides a cleaner control flow.
>>>
From: Junio C Hamano
> Christian Couder writes:
>
>> +The trailers are recognized in the input message using the following
>> +rules:
>> +
>> +* only lines that contains a ':' (colon) are considered trailers,
>> +
>> +* the trailer lines must all be next to each other,
>> +
>> +* after them it'
On Wed, Jun 25, 2014 at 7:40 PM, Jeff King wrote:
> We already have a nice-to-use bitmap implementation in
> ewah/bitmap.c. It pretends to be infinitely long when asking
> for a bit (and just returns 0 for bits that haven't been
> allocated or set), and dynamically resizes as appropriate
> when yo
22 matches
Mail list logo
