Starting on a microproject for GSoC

Hi git developers, the next Google Summer of Code is not too far away. I expect git to apply for it and hopefully have some student spots which in turn I plan to apply. It was recommended elsewhere and on this list as well, that it is beneficial to engage with the community early, that's why I am

Re: Starting on a microproject for GSoC

On 01/28/2016 02:18 AM, Stefan Beller wrote: > On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb wrote: >> Before I may introduce myself: I'm a Computer Science student in >> Germany, coming towards the end of my Masters. I am an enthusiastic git >> user that's why

Replacing strbuf_getline_lf() by strbuf_getline() in wt-status.c

Currently I am working on replacing strbuf_getline_lf() by strbuf_getline() in places where the input is trimmed immediately after reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf() callers", 2nd point. One instance I found was in wt-status.c. In read_rebase_todolist() the lin

[PATCH 0/5] Replacing strbuf_getline_lf() by strbuf_getline() on trimmed input

an improve this (and future) patches, as this is my first one. Especially I am not sure about how many arguments from the discussion on the mailing list should be put into the commits. -Moritz [1] http://thread.gmane.org/gmane.comp.version-control.git/284104 Moritz Neeb (5): bisect: re

[PATCH 3/5] notes: read copied notes with strbuf_getline()

The notes that are copied from stdin are trimmed with strbuf_rtrim() after splitting by ' '. There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- builtin/notes.c | 2 +- 1 file changed, 1 inser

[PATCH 5/5] wt-status: read rebase todolist with strbuf_getline()

In read_rebase_todolist() every line is, after reading, checked for a comment_line_char. After that it is trimmed via strbuf_trim(). Assuming we do never expect a CR as comment_line_char, strbuf_getline_lf() can be safely replaced by its CRLF counterpart. Signed-off-by: Moritz

[PATCH 4/5] remote: read $GIT_DIR/branches/* with strbuf_getline()

The line read from the branch file is directly trimmed after reading with strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- remote.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH 1/5] bisect: read bisect paths with strbuf_getline()

The lines read from BISECT_NAMES are trimmed with strbuf_trim() immediately. There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- bisect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/5] clean: read user input with strbuf_getline()

The input that is read is trimmed with strbuf_trim() immediately. There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- builtin/clean.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

Re: Replacing strbuf_getline_lf() by strbuf_getline() in wt-status.c

On 01/30/2016 03:30 PM, Moritz Neeb wrote: > Currently I am working on replacing strbuf_getline_lf() by > strbuf_getline() in places where the input is trimmed immediately after > reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf() > callers", 2nd poin

Re: [PATCH 1/5] bisect: read bisect paths with strbuf_getline()

On 02/01/2016 10:30 PM, Junio C Hamano wrote: > Moritz Neeb writes: > >> The lines read from BISECT_NAMES are trimmed with strbuf_trim() >> immediately. There is thus no logic expecting CR, so >> strbuf_getline_lf() can be replaced by its CRLF counterpart. &

Re: interactive rebase results across shared histories

Hi Seb, On 02/20/2016 11:58 PM, Seb wrote: > Hello, > > I've recently learnt how to consolidate and clean up the master branch's > commit history. I've squashed/fixuped many commits thinking these would > propagate to the children branches with whom it shares the earlier parts > of the its histo

Re: [PATCH] GSoC Micoproject: Hunt down signed int flags

Thanks for your patch. Just to let you know, this will be my first review, but I hope it will be helpful anyway. I will mostly review your commit text. First some general remarks: The text you are submitting with you email is directly used as commit message (the email subject as well, as the first

Re: [PATCH 1/5] bisect: read bisect paths with strbuf_getline()

On 02/15/2016 06:05 AM, Junio C Hamano wrote: > Moritz Neeb writes: > >>> You would also want to think about the necessity of strbuf_trim() >>> here. Now strbuf_getline() would trim the trailing CR, would we >>> still need to call strbuf_trim() here? The code

[PATCH v2 6/6] wt-status: read rebase todolist with strbuf_getline()

that this interface handles the preprocessing of whitespaces, especially CRLFs correctly. Thus in this codepath we can remove the call to strbuf_trim(). For documenting the input as expecting "text" input, strbuf_getline_lf() is still replaced by strbuf_getline(). Signed-off-by: Moritz Nee

[PATCH v2 5/6] remote: read $GIT_DIR/branches/* with strbuf_getline()

The line read from the branch file is directly trimmed after reading with strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- To be honest, I did not yet fully understand the purpose of this branches

[PATCH v2 1/6] quote: remove leading space in sq_dequote_step

following commit. Signed-off-by: Moritz Neeb --- quote.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/quote.c b/quote.c index fe884d2..2714f27 100644 --- a/quote.c +++ b/quote.c @@ -63,6 +63,8 @@ static char *sq_dequote_step(char *arg, char **next) char *src = arg; char c

[PATCH v2 4/6] notes: read copied notes with strbuf_getline()

re is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- builtin/notes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index ed6f222..706ec11 100644 --- a/builtin/not

Re: [PATCH 1/5] bisect: read bisect paths with strbuf_getline()

On 02/15/2016 06:05 AM, Junio C Hamano wrote: > As to bisect pathspec, while I do not think it is sensible to change > it in the middle of bisection, I do not think it would cause the > bisect command to produce an incorrect result if you did so. You > would be changing the definition of what is t

[PATCH v2 0/6] replacing strbuf_getline_lf() by strbuf_getline() on trimmed input

of sq_(de)quote to be a one-to-one transformation * removing some unneccesary trimming calls in: * wt-status.c * builting/notes.c * builtin/clean.c * bisect.c -Moritz [1] http://thread.gmane.org/gmane.comp.version-control.git/284104 Moritz Neeb (6): quote: remove leading space in

[PATCH v2 2/6] bisect: read bisect paths with strbuf_getline()

oting and unexpected whitespace. Helped-by: Junio C Hamano Signed-off-by: Moritz Neeb --- bisect.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/bisect.c b/bisect.c index 06ec54e..e2df02f 100644 --- a/bisect.c +++ b/bisect.c @@ -440,10 +440,9 @@ static void read_bisect_pat

[PATCH v2 3/6] clean: read user input with strbuf_getline()

trimmed in an untouched codepath after it is split up into multiple patterns. This is considered as desirable, because of two reasons: First this fitering is not part of similar UIs and it is way more likely to accidentally type a space in this way of interacting. Signed-off-by: Moritz Neeb --- When

Re: [PATCH v2 3/6] clean: read user input with strbuf_getline()

On 02/22/2016 03:27 AM, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 8:20 PM, Moritz Neeb wrote: >> The inputs that are read are all answers that are given by the user >> when interacting with git on the commandline. As these answers are >> not supposed to contain a meanin

Re: interactive rebase results across shared histories

On 02/23/2016 06:39 PM, Seb wrote: > On Sun, 21 Feb 2016 03:12:49 +0100, > Moritz Neeb wrote: > >> Hi Seb, >> On 02/20/2016 11:58 PM, Seb wrote: >>> Hello, > >>> I've recently learnt how to consolidate and clean up the master >>> bran

[PATCH v3 1/7] quote: remove leading space in sq_dequote_step

following commit. Signed-off-by: Moritz Neeb --- quote.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/quote.c b/quote.c index fe884d2..2714f27 100644 --- a/quote.c +++ b/quote.c @@ -63,6 +63,8 @@ static char *sq_dequote_step(char *arg, char **next) char *src = arg; char c

[PATCH v3 2/7] bisect: read bisect paths with strbuf_getline()

oting and unexpected whitespace. Helped-by: Junio C Hamano Signed-off-by: Moritz Neeb --- bisect.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/bisect.c b/bisect.c index 06ec54e..e2df02f 100644 --- a/bisect.c +++ b/bisect.c @@ -440,10 +440,9 @@ static void read_bisect_pat

[PATCH v3 4/7] notes copy --stdin: split lines with string_list_split()

required to remove potential CRs. In the next step this will then be done implicitly by strbuf_readline(). Thus, this is a preparatory refactoring, towards a trim-free codepath. Signed-off-by: Moritz Neeb --- builtin/notes.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions

[PATCH v3 5/7] notes copy --stdin: read lines with strbuf_getline()

through a dos editor. Signed-off-by: Moritz Neeb --- builtin/notes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index 22909c7..660c0b7 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -290,12 +290,11 @@ static int notes_copy_from

[PATCH v3 0/7] replacing strbuf_getline_lf() by strbuf_getline()

d.gmane.org/gmane.comp.version-control.git/284104 Moritz Neeb (7): quote: remove leading space in sq_dequote_step bisect: read bisect paths with strbuf_getline() clean: read user input with strbuf_getline() notes copy --stdin: split lines with string_list_split() notes copy --stdin: read lines

[PATCH v3 6/7] remote: read $GIT_DIR/branches/* with strbuf_getline()

The line read from the branch file is directly trimmed after reading with strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- remote.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 3/7] clean: read user input with strbuf_getline()

s kept in place. Signed-off-by: Moritz Neeb --- builtin/clean.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/clean.c b/builtin/clean.c index 7b08237..956283d 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -570,7 +570,7 @@ static int *list_and_choose(struct

[PATCH v3 7/7] wt-status: read rebase todolist with strbuf_getline()

that this interface handles the preprocessing of whitespaces, especially CRLFs correctly. Thus in this codepath we can remove the call to strbuf_trim(). For documenting the input as expecting "text" input, strbuf_getline_lf() is still replaced by strbuf_getline(). Signed-off-by: Moritz Nee

Re: [PATCH v3 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On 02/28/2016 07:30 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:07 AM, Moritz Neeb wrote: >> This series deals with strbuf_getline_lf() in certain codepaths: >> Those, where the input that is read, is/was trimmed before doing anything >> that >> could pos

Re: [PATCH v3 2/7] bisect: read bisect paths with strbuf_getline()

On 02/28/2016 07:33 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: >> The file BISECT_NAMES is written by "git rev-parse --sq-quote" via >> sq_quote_argv() when starting a bisection. It can contain pathspecs >> to narrow down the s

Re: [PATCH v3 3/7] clean: read user input with strbuf_getline()

On 02/28/2016 07:36 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: >> The inputs that are read are all answers that are given by the user >> when interacting with git on the commandline. As these answers are >> not supposed to contain a meanin

Re: [PATCH v3 4/7] notes copy --stdin: split lines with string_list_split()

On 02/28/2016 07:56 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: >> This patch changes, how the lines are split, when reading them from >> stdin to copy the notes. The advantage of string_list_split() over >> strbuf_split() is that it r

Re: [PATCH v3 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On 02/28/2016 06:07 AM, Moritz Neeb wrote: > Changes since v2: > > * Line splitting in notes_copy_from_stdin() is changed to string_list_split as > suggested by Eric Sunshine. > * The behavior change in interactive cleaning from patch v2 is undone. > * Some of the previous p

Re: [RFC/PATCH] lockfile: improve error message when lockfile exists

On 02/28/2016 09:11 PM, Matthieu Moy wrote: > A common mistake leading a user to see this message is to launch "git > commit", let the editor open (and forget about it), and try again to > commit. > > The previous message was going too quickly to "a git process crashed" > and to the advice "remove

[PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

.string, from_obj)) -Moritz [1], idea: http://thread.gmane.org/gmane.comp.version-control.git/284104 [2], v2: http://thread.gmane.org/gmane.comp.version-control.git/285118/focus=286865 [3], v3: http://thread.gmane.org/gmane.comp.version-control.git/285118/focus=287747 [4] http://thread.gmane.org/gmane.comp.v

[PATCH v4 1/7] quote: remove leading space in sq_dequote_step

following commit. Signed-off-by: Moritz Neeb --- quote.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/quote.c b/quote.c index fe884d2..2714f27 100644 --- a/quote.c +++ b/quote.c @@ -63,6 +63,8 @@ static char *sq_dequote_step(char *arg, char **next) char *src = arg; char c

[PATCH v4 3/7] clean: read user input with strbuf_getline()

accepting user input with spaces, e.g. " y ", as a valid answer in the interactive cleaning process. Although trimming would not be required anymore to remove a potential CR, we don't want to change the existing behavior with this patch. Thus, the trimming is kept in place. Signed-off-

[PATCH v4 7/7] wt-status: read rebase todolist with strbuf_getline()

that this interface handles the preprocessing of whitespaces, especially CRLFs correctly. Thus in this codepath we can remove the call to strbuf_trim(). For documenting the input as expecting "text" input, strbuf_getline_lf() is still replaced by strbuf_getline(). Signed-off-by: Moritz Nee

[PATCH v4 5/7] notes copy --stdin: split lines with string_list_split()

re of strbuf_split() so let's use string_list_split() instead since it removes the separator character and returns an array of simple NUL-terminated strings. Helped-by: Eric Sunshine Signed-off-by: Moritz Neeb --- builtin/notes.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletion

[PATCH v4 4/7] notes copy --stdin: read lines with strbuf_getline()

necessary before to remove potential CRs inserted through a dos editor. Signed-off-by: Moritz Neeb --- builtin/notes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index ed6f222..706ec11 100644 --- a/builtin/notes.c +++ b/builtin/notes.c

[PATCH v4 6/7] remote: read $GIT_DIR/branches/* with strbuf_getline()

The line read from the branch file is directly trimmed after reading with strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- remote.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v4 2/7] bisect: read bisect paths with strbuf_getline()

h cases: bad quoting and unexpected whitespace. Helped-by: Junio C Hamano Signed-off-by: Moritz Neeb --- bisect.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/bisect.c b/bisect.c index 7996c29..f63aa10 100644 --- a/bisect.c +++ b/bisect.c @@ -440,10 +440,9 @@ static vo

Re: [PATCH v4 4/7] notes copy --stdin: read lines with strbuf_getline()

imes viewed in context wrong? Thanks, Moritz >> Signed-off-by: Moritz Neeb >> --- >> builtin/notes.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/builtin/notes.c b/builtin/notes.c >> index ed6f222..706ec11 100

Re: [PATCH v4 1/7] quote: remove leading space in sq_dequote_step

On 02/29/2016 08:01 PM, Junio C Hamano wrote: > Moritz Neeb writes: > >> Because sq_quote_argv adds a leading space (which is expected in trace.c), >> sq_dequote_step should remove this space again, such that the operations >> of quoting and dequoting are inverse of each

Re: [PATCH v4 1/7] quote: remove leading space in sq_dequote_step

On 02/29/2016 10:45 PM, Moritz Neeb wrote: > On 02/29/2016 08:01 PM, Junio C Hamano wrote: >> Moritz Neeb writes: >> >>> Because sq_quote_argv adds a leading space (which is expected in trace.c), >>> sq_dequote_step should remove this space again, such that

Re: [PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

have to be discussed: On 02/29/2016 09:30 AM, Moritz Neeb wrote: > > Moritz Neeb (7): > quote: remove leading space in sq_dequote_step -- as in v2 in patch 1/7: How many spaces should be removed, cf.: http://thread.gmane.org/gmane.comp.version-control.git/285118/focus=28791

Re: [PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On 03/09/2016 01:39 AM, Junio C Hamano wrote: > Moritz Neeb writes: > >> how to deal with patches during the v2.8.0 rc freeze? Will they wait on >> the mailing list until the feature release cycle is finished? > > Because people are expected to stop getting distracted

Re: GSoC 2016: application period ongoing, a few advices

Hi On 03/19/2016 01:26 PM, Matthieu Moy wrote: > As a reminder, the GSoC students application period has started (since > March 14, deadline = March 25th = soon). Thanks for the reminder. Because you might be expecting a proposal from me, I just wanted to let you know, that I was too busy lately

Re: Improving git branch

Jeff King peff.net> writes: > > On Wed, Dec 17, 2014 at 12:53:49PM -0800, Junio C Hamano wrote: > > > Michael J Gruber drmicha.warpmail.net> writes: > > > > > Rather than extending "git branch" any further[*], I suggest a bolder > > > strategy: > > > > > > - unify/merge for-each-ref and prett

Re: Git GSoC 2015

Le 12/02/2015 10:34, Jeff King a écrit : The beginnings of the Google Summer of Code deadlines are upon us again. Organization applications are due February 20th (next Friday). - Do we want to do it? Unfortunately not so much response on this topic. I was planning to apply as a student. Th