Contributing to git: cleaner git -rm & add configuration options

2013-05-20 Thread Mathieu Liénard--Mayor
Hello everyone, I'm Mathieu LIENARD--MAYOR, a french student at Ensimag - Grenoble INP, and together with my fellow student Jorge GARCIA we will try to contribute to git as our school project. As of now, we are considering the implementation of the following two features: -Cleaner error mess

Re: [PATCH 1/2] rm: better error message on failure for multiple files

2013-06-10 Thread Mathieu Liénard--Mayor
aged, "\n "); Ouch. Wouldn't a string-list be more appropriate for this kind of thing? Matthieu Moy told me string-list would be better aswell, so we're gonna change it. -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 -- T

Re: [PATCH 2/2] rm: introduce advice.rmHints to shorten messages

2013-06-10 Thread Mathieu Liénard--Mayor
we'll work on it. Introduce advice.rmHints to control the whether to display advice when using 'git rm'. Defaults to true, preserving current behavior. -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 -- To unsubscribe from this list: send the line "u

Re: [PATCH 2/2] rm: introduce advice.rmHints to shorten messages

2013-06-10 Thread Mathieu Liénard--Mayor
hints' ' + cat >expect << EOF && +error: the following files have local modifications: + bar.txt +EOF + echo content4 >bar.txt && + test_must_fail git -c advice.rmhints=false rm bar.txt 2>actual && + test_cmp expect

Re: [PATCH 1/2] rm: better error message on failure for multiple files

2013-06-10 Thread Mathieu Liénard--Mayor
+ for (j = 0; j < files_local.nr; j++) { + strbuf_addf(&msg_local, + "\n%s", + files_local.items[j].string); + } + strbuf_addstr(&msg_local, + "\n(use --cached to keep the file, " + "or -f to force removal)"); + errs = error(_("%s"), msg_local.buf); + } + return errs; } -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 -- 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

Re: [PATCH v2 1/2] rm: better error message on failure for multiple files

2013-06-10 Thread Mathieu Liénard--Mayor
_("the following submodules (or one " + "of its nested submodule) use a " + ".git directory:"), +_("\n(use 'rm -rf' if you really " +

Re: [PATCH 2/2] rm: introduce advice.rmHints to shorten messages

2013-06-10 Thread Mathieu Liénard--Mayor
Le 2013-06-10 18:57, Junio C Hamano a écrit : Mathieu Liénard--Mayor writes: Please ignore this, manipulation error while in the git send-email command line. Here is what my mailbox looks like (the penultimate one with 252 lines is what I am responding to). R. [ 146: Mathieu Lienard

New feature discussion: git rebase --status

2013-06-11 Thread Mathieu Liénard--Mayor
es left to apply. As an example, it could say: You are currently rebasing (patch 3/5). What do you think? Does the name rebase --status seem appropriate? Should the output be providing more/less information? Thanks =] -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33

Re: New feature discussion: git rebase --status

2013-06-12 Thread Mathieu Liénard--Mayor
tisfied with your changes) # .. # .. What do you guys think ? -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 -- 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

Re: New feature discussion: git rebase --status

2013-06-12 Thread Mathieu Liénard--Mayor
Le 2013-06-12 13:12, Célestin Matte a écrit : Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit : Now, I'm not sure if we should always display the list of commits already applied and those left to apply. What I mean is that maybe it would be better to make status require a flag to di

Re: New feature discussion: git rebase --status

2013-06-12 Thread Mathieu Liénard--Mayor
se pieces of advice would be a good idea, especially since you can deactivate it with advice.statusHints. On Jun 12, 2013 8:29 AM, "Antoine Pelisse" wrote: On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor wrote: > Le 2013-06-12 13:12, Célestin Matte a écrit : > >>

Re: New feature discussion: git rebase --status

2013-06-13 Thread Mathieu Liénard--Mayor
ly: # e a832578 rm: better error message on failure for multiple files # e fd0330b rm: introduce advice.rmHints to shorten messages # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) I'm s

Re: [PATCH] status: display the SHA1 of the commit being currently processed

2013-06-17 Thread Mathieu Liénard--Mayor
imilar. Actually, at first I dealt with it this way: status_printf_ln(s, color, _("Splitting %s while rebasing branch '%s' on '%s'."), stopped_sha ? stopped_sha : _("a commit"), ); Would this be more suitable for translat

Re: [PATCH] status: display the SHA1 of the commit being currently processed

2013-06-17 Thread Mathieu Liénard--Mayor
Le 2013-06-17 15:54, Peter Krefting a écrit : Mathieu Liénard--Mayor: Actually, at first I dealt with it this way: status_printf_ln(s, color, _("Splitting %s while rebasing branch '%s' on '%s'."), stopped_s

Re: [PATCH] status: display the SHA1 of the commit being currently processed

2013-06-18 Thread Mathieu Liénard--Mayor
atively take you to detached HEAD state to give control back to you in the middle. "git status" knows what operation is in progress, and I think we should start our output _without_ that "HEAD detached at" line. Thanks. -- Mathieu Liénard--Mayor, 2nd year at Greno

Re: [PATCH] send-email: allow use of basic email list in --cc --to and --bcc

2013-06-18 Thread Mathieu Liénard--Mayor
t - -foreach my $entry (@initial_to) { - die "Comma in --to entry: $entry'\n" unless $entry !~ m/,/; -} -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a messa

Re: [PATCH] send-email: allow use of basic email list in --cc --to and --bcc

2013-06-18 Thread Mathieu Liénard--Mayor
which is the new feature we're introducing. Then we compare the output of the two, and expect it to be exactly the same. Shouldn't $ git send-email --cc 'f...@example.com' --cc 'b...@example.com' and $ git send-email --cc 'f...@example.com, b...@example.com