Christian Couder writes:
> On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano wrote:
>> On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
>> wrote:
>>>
>>> If we don't want to support positional arguments, then I would suggest
>>> supporting first the following instead:
>>>
>>> git bisect
On 2015-06-26 13:06, Ties wrote:
> Do you have an ETA on the final release?
No, sorry, no ETA yet.
--
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
Hi Junio,
On 2015-06-26 19:37, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Fri, Jun 26, 2015 at 10:06:20AM +0200, Johannes Schindelin wrote:
>>
>>> I understood what you were saying, but it still appears too fragile to
>>> me to mix functions that assume NUL-terminated strings with an ad-h
Hi,
Git v2.5.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 65 updated messages need to be translated since last
update:
l10n: git.pot: v2.5.0 round 1 (65 new, 15 removed)
Generate po/git.pot from v2.5.0-rc0 for git v2.5.0 l10n round 1.
Si
Hello All,
As part of GSoC I'm working on the Unification of 'for-each-ref', 'tag -l'
and 'branch -l'. Sorry for the lack of update since Jun 14, was a
little busy with an exam I had. Now thats over, I will be working more
on the project.
Current Progress:
1. Building ref-filter.{c,h} from for-e
Johannes Schindelin writes:
> On 2015-06-26 19:37, Junio C Hamano wrote:
>> Jeff King writes:
>>
>>> On Fri, Jun 26, 2015 at 10:06:20AM +0200, Johannes Schindelin wrote:
>>>
I understood what you were saying, but it still appears too fragile to
me to mix functions that assume NUL-term
Matthieu Moy writes:
> Christian Couder writes:
>
>> On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano wrote:
>>> On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
>>> wrote:
If we don't want to support positional arguments, then I would suggest
supporting first the following inst
David Turner writes:
> This version addresses Junio's comments on v3.
The end result makes more sense than the previous one, but did you
screw up when rewriting and/or squashing patches around the new 4/6?
I think that one has two separate changes mixed into one and does a
lot more than "this i
On Thu, Jun 25, 2015 at 1:43 PM, Karthik Nayak wrote:
> Add support for %(refname:lalignX) where X is a number.
> This will print a shortened refname aligned to the left
> followed by spaces for a total length of X characters.
> If X is less than the shortened refname size, the entire
> shortened
On Mon, 1 Jun 2015, John Lee wrote:
On Sun, 31 May 2015, David Aguilar wrote:
Were you thinking of something like this, or something else?
Can you describe your use case a bit more?
I think now I should just publish my script and then it will be very clear
what I'm talking about. If somebod
On Thu, Jun 25, 2015 at 6:43 PM, Karthik Nayak wrote:
> Add support for %(refname:lalignX) where X is a number.
> This will print a shortened refname aligned to the left
> followed by spaces for a total length of X characters.
> If X is less than the shortened refname size, the entire
> shortened
On Wed, Jun 24, 2015 at 8:03 PM, Philip Oakley wrote:
> Delete the duplicated GUID from the generation code for the Visual Studio
> .sln project file.
>
> The duplicate GUID tended to be allocated to test-svn-fe, which was then
> ignored by Visual Studio / MSVC, and it's omission from the build ne
On Sat, Jun 27, 2015 at 10:02 PM, Christian Couder
wrote:
> On Thu, Jun 25, 2015 at 1:43 PM, Karthik Nayak wrote:
>
>> + if (starts_with(formatp, "lalign")) {
>> + const char *valp;
>> + int val;
>> +
>> +
On 06/27/2015 06:25 AM, Junio C Hamano wrote:
> On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
> wrote:
>>
>> If we don't want to support positional arguments, then I would suggest
>> supporting first the following instead:
>>
>> git bisect terms --name-good=fast --name-bad=slow
>>
On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty wrote:
>
> I would like to remind everybody of my old claim that it would be
> possible to teach `git bisect` to infer by itself which term means
> "older" and which term means "newer":
>
> http://article.gmane.org/gmane.comp.version-control.g
On 06/28/2015 08:15 AM, Junio C Hamano wrote:
> On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty
> wrote:
>>
>> I would like to remind everybody of my old claim that it would be
>> possible to teach `git bisect` to infer by itself which term means
>> "older" and which term means "newer":
>>
>>
16 matches
Mail list logo
