On Tue, Mar 18, 2014 at 8:29 PM, Junio C Hamano wrote:
>
> I've never said any such thing.
>
> I only said I am not enthused against a proposal to add a build
> target that runs checkpatch or equivalent over *all* existing code,
> which will invite needless churn (read again the part of the messag
C. I still haven't
submitted my application about git bisect (life got in the way!), but
Michael Heggarty remarked in $gmane/242703 that my original idea had
too little meat in it to constitute a good GSoC proposal.
Cheers,
Jacopo Notarstefano
--
To unsubscribe from this list: send the line "
On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:
> I think you fundamentally cannot use two labels that are merely
> "distinct" and bisect correctly. You need to know which ones
> (i.e. good) are to be excluded and the other (i.e. bad) are to be
> included when computing the "remaining to be
On Wed, Mar 5, 2014 at 8:55 PM, Vincenzo di Cicco wrote:
> Hi there, I'm NaN.
> Recently I enrolled to this mailing list thanks to the GSoC.
> I've looked the Ideas Page but -unfortunately- some projects are very
> difficult for me.
Hi Vincenzo!
I also got interested in contributing to Git becau
On Sun, Mar 2, 2014 at 3:02 AM, Kyle J. McKay wrote:
> I can't reproduce, mostly, on Mac OS X 10.5.8 or 10.6.8.
>
> What I mean by mostly is that the very first time I ran the test script I
> got approximately 36 of these errors:
>
> fatal: unable to access
> 'https://android.googlesource.com/plat
ich uses a strbuf
(documented in Documentation/technical/api-strbuf.txt) to store this value.
Remove this unneeded check and thus allow for branch names longer than 1009
characters.
Signed-off-by: Jacopo Notarstefano
---
branch.c | 4
1 file changed, 4 deletions(-)
diff --git a/branch.c
Redirection operators should have a space before them, but not after them.
Signed-off-by: Jacopo Notarstefano
---
git-bisect.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 73b4c14..af4d04c 100755
--- a/git-bisect.sh
+++ b/git
The part about this being a GSoC microproject should go below the
three dashes, since it's not information that needs to
be recorded in the codebase.
On Sun, Mar 2, 2014 at 12:52 PM, Guanglin Xu wrote:
> GSoC2014 Microproject: according to the idea#2 for microprojects, change
> install_branch_c
> I am not sure I understand what you are trying to say. Are you
> saying that we should stick to good/bad and allow the users use
> nothing else, because allowing "fixed" will be confusing?
>
No! Pretty much the opposite of that. My idea (the "mark" subcommand)
is to let people define their own
> Nice. new_ref is passed in install_branch_config() in latest code. I
> guess you already made sure this function did not make any assumption
> about new_ref's length?
>
The function install_branch_config uses the strbuf, as I wrote in the
commit message. The contents of this buffer are then fed
> This patch removes this unneeded check and thus allows for branch names
> longer than 1019 characters.
>
Ach! I amended the commit in my local history to read "Remove this
unneded check and thus allow for branch names longer than 1019
characters", but for some reason git format-patch -1 --signof
t a9f2c136, which uses a strbuf
(documented in Documentation/technical/api-strbuf.txt) to store this value.
This patch removes this unneeded check and thus allows for branch names
longer than 1019 characters.
Signed-off-by: Jacopo Notarstefano
---
Submitted as GSoC microproject #3.
branch.c |
the
list as well.)
On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty wrote:
> Please forgive my typos and brevity; this was typed on a phone.
>
> Michael
> On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano
> wrote:
>>On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty
;
> Michael
> On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano
> wrote:
>>On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty
>> wrote:
>>> What happens if the user mixes, say, "good" and "fixed" in a single
>>> bisect session
mmits; if the user is asking
for such a thing then she has a fundamental misconception of the state
of her repository.
> By the way, although "git bisect fixed/unfixed" would be a very useful
> improvement, and has gone unimplemented for a lamentably long time, my
> personal feel
in which the chosen
labels are listed and reused across all tools that require them.
(Sorry for sending this email twice, I thought I had sent it to the
list as well!)
On Wed, Feb 26, 2014 at 8:58 PM, Junio C Hamano wrote:
> Jacopo Notarstefano writes:
>
>> Does this make sense? Did
sals on this topic, among which those
listed at
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed.
I'm interested in contacting the prospective mentor, Christian Couder,
to go over these. What's the proper way to ask for an introduction? I
tried asking on IRC, b
17 matches
Mail list logo
