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
On 03/09/2016 01:39 AM, Junio C Hamano wrote:
> Moritz Neeb <li...@moritzneeb.de> 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 expec
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=287911
>
On 02/29/2016 10:45 PM, Moritz Neeb wrote:
> On 02/29/2016 08:01 PM, Junio C Hamano wrote:
>> Moritz Neeb <li...@moritzneeb.de> writes:
>>
>>> Because sq_quote_argv adds a leading space (which is expected in trace.c),
>>> sq_dequote_step should remove thi
d in context wrong?
Thanks,
Moritz
>> Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
>> ---
>> builtin/notes.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/builtin/notes.c b/builtin/notes.c
>> index ed6f222..7
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 <li...@moritzneeb.de>
---
remote.c | 2 +-
1 file changed, 1 insertion
h cases:
bad quoting and unexpected whitespace.
Helped-by: Junio C Hamano <gits...@pobox.com>
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
bisect.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 7996c29..f63aa10 100644
--- a/bi
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: Mo
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 <sunsh...@sunshineco.com>
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
builtin/notes.c | 19 +--
necessary before to remove potential CRs inserted
through a dos editor.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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
in the following commit.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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)
cha
to 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-by: M
d.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.version-control.git/285118/focus=287760
Mo
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
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
On 02/28/2016 07:56 AM, Eric Sunshine wrote:
> On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb <li...@moritzneeb.de> wrote:
>> This patch changes, how the lines are split, when reading them from
>> stdin to copy the notes. The advantage of string_list_split()
On 02/28/2016 07:36 AM, Eric Sunshine wrote:
> On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb <li...@moritzneeb.de> 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
>&
On 02/28/2016 07:33 AM, Eric Sunshine wrote:
> On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb <li...@moritzneeb.de> 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
>
On 02/28/2016 07:30 AM, Eric Sunshine wrote:
> On Sun, Feb 28, 2016 at 12:07 AM, Moritz Neeb <li...@moritzneeb.de> 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 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: Mo
ed through
a dos editor.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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,
g/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 with strbu
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 <li...@moritzneeb.de>
---
remote.c | 2 +-
1 file changed, 1 insertion
t in place.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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
in the following commit.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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)
cha
oting and unexpected whitespace.
Helped-by: Junio C Hamano <gits...@pobox.com>
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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
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 <li...@moritzneeb.de>
---
builtin/notes.c | 22 +++---
1 file changed, 11 inse
On 02/23/2016 06:39 PM, Seb wrote:
> On Sun, 21 Feb 2016 03:12:49 +0100,
> Moritz Neeb <li...@moritzneeb.de> wrote:
>
>> Hi Seb,
>> On 02/20/2016 11:58 PM, Seb wrote:
>>> Hello,
>
>>> I've recently learnt how to consolidate and clean up the ma
On 02/22/2016 03:27 AM, Eric Sunshine wrote:
> On Sun, Feb 21, 2016 at 8:20 PM, Moritz Neeb <li...@moritzneeb.de> 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
>&
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 <
in the following commit.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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)
cha
no logic expecting CR, so strbuf_getline_lf()
can be replaced by its CRLF counterpart.
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
builtin/notes.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/notes.c b/builtin/notes.c
index ed6f222..706ec11
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
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: Mo
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 <li...@moritzneeb.de>
---
To be honest, I did not yet fully unde
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 sq_dequote
oting and unexpected whitespace.
Helped-by: Junio C Hamano <gits...@pobox.com>
Signed-off-by: Moritz Neeb <li...@moritzneeb.de>
---
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
On 02/15/2016 06:05 AM, Junio C Hamano wrote:
> Moritz Neeb <li...@moritzneeb.de> 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 s
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
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
On 02/01/2016 10:30 PM, Junio C Hamano wrote:
> Moritz Neeb <li...@moritzneeb.de> 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 re
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: read bi
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 <li...@moritzneeb.de>
---
builtin/notes.c | 2 +-
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
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 <li...@moritzneeb.de>
---
remote.c | 2 +-
1 file chan
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 <li...@moritzneeb.de>
---
bisect.c | 2 +-
1 file changed, 1 insertion
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 <li...@moritzneeb.de>
---
builtin/clean.c | 6 +++---
1 file changed, 3 insertions
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
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
On 01/28/2016 02:18 AM, Stefan Beller wrote:
> On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <li...@moritzneeb.de> 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
>&g
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
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.
Jeff King peff at peff.net writes:
On Wed, Dec 17, 2014 at 12:53:49PM -0800, Junio C Hamano wrote:
Michael J Gruber git at drmicha.warpmail.net writes:
Rather than extending git branch any further[*], I suggest a bolder
strategy:
- unify/merge for-each-ref and pretty formats
53 matches
Mail list logo
