Junio C Hamano wrote:
> Who said anything about a customer?
>
> A newcomer to a community (i.e. Matthieu's student) needs not just
> to show technical excellence with patches, but needs to make a good
> argument on a larger design decision; old timers already tried to
> achieve a concensus on it, a
Junio C Hamano wrote:
> It is a tough topic for a newcomer developer to tackle.
Agreed. We should give these students tasks that are relatively
straightforward, and not controversial.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
Ramkumar Ramachandra writes:
> Matthieu Moy wrote:
>> I tend to agree with you, but the idea has explicitly been rejected in
>> the past. The problem with an option like this is that it would also
>> disable the advices that may be added in the future. By letting people
>> disable the advices one
Junio C Hamano wrote:
> I'd hate to see any Git developers running with advice turned off
> for this exact reason.
Improving advice is your itch, but it is certainly not my itch. I
don't want to see messages like "Commit your changes or stash them",
or "try --continue | --skip | --abort" clutteri
Matthieu Moy wrote:
> I tend to agree with you, but the idea has explicitly been rejected in
> the past. The problem with an option like this is that it would also
> disable the advices that may be added in the future. By letting people
> disable the advices one by one, people see new advices as th
On Mon, Apr 15, 2013 at 07:53:48AM -0700, Junio C Hamano wrote:
> > Yes. The concept isn't that hard, but the question was one of whether it
> > would break some obscure workflows. But I don't remember all of the
> > details; I think I gave some examples in past threads.
>
> I think the one Thoma
Jeff King writes:
> FWIW, I do not think it was so much rejected as that I had initially
> planned to implement it, then decided against it. Mostly because I
> wanted to actually get annoyed with each piece of advice before
> disabling it. Because sometimes the right answer is actually "make the
On Mon, Apr 15, 2013 at 11:18 AM, Ramkumar Ramachandra
wrote:
> A few small personal itches off the top of my head:
>
> - Make git status -s show "state status" as well: this essentially
> requires writing an equivalent of wt_status_print_state() for use in
> wt_shortstatus_print().
I actually su
On Mon, Apr 15, 2013 at 06:32:49PM +0200, Matthieu Moy wrote:
> > - Create an advice.ui (like color.ui) to turn off all advice. I don't
> > need advice.
>
> I tend to agree with you, but the idea has explicitly been rejected in
> the past. The problem with an option like this is that it would al
Ramkumar Ramachandra writes:
> A few small personal itches off the top of my head:
>
> - Make git status -s show "state status" as well: this essentially
> requires writing an equivalent of wt_status_print_state() for use in
> wt_shortstatus_print().
Do you mean, showing it in a natural language
Ramkumar Ramachandra writes:
> - Make the -3 and -c switches in git am configuration variables. I
> have an alias.
- Make failed "git am --3way" due to "unusable index" a bit more
helpful. Right now, the information on which hunk failed to apply
is lost, and there is no "git am --no-3way
A few small personal itches off the top of my head:
- Make git status -s show "state status" as well: this essentially
requires writing an equivalent of wt_status_print_state() for use in
wt_shortstatus_print().
- Make the -s and -b switches in git status configuration variables.
I currently have
Jeff King writes:
> On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
>
>> > * git pull --set-upstream
>> >
>> > This is vaguely related to another itch that nobody has bothered to
>> > fix: 'git fetch origin foo' should really update origin/foo. This has
>> > been discussed on
On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
> > * git pull --set-upstream
> >
> > This is vaguely related to another itch that nobody has bothered to
> > fix: 'git fetch origin foo' should really update origin/foo. This has
> > been discussed on the list a few times alread
On Mon, Apr 15, 2013 at 7:06 PM, Thomas Rast wrote:
> Matthieu Moy writes:
>
>> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
>
> My $0.02:
>
> * Allow "git add -p" to use "git diff --color-words" to show hunks
>
> Check if you can use the existing --word-diff=porcelain output some
On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
> Thomas Rast writes:
> > * Allow git send-email --cc 'f...@example.com, b...@example.com' instead
> > of git send-email --cc f...@example.com --cc b...@example.com
> >
> > That would be really nice. Bonus points if it handles cont
Thomas Rast writes:
> My $0.02:
(BTW, feel free to edit the wiki. I've added a few bits from your
message there already).
> * Allow "git add -p" to use "git diff --color-words" to show hunks
[...]
> If neither one is possible my feeling is that it's one of the
> hardest tasks on the list.
Matthieu Moy writes:
> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
My $0.02:
* Allow "git add -p" to use "git diff --color-words" to show hunks
Check if you can use the existing --word-diff=porcelain output somehow
to get it done in pure perl. Alternatively, try to hack a
Ping Yin writes:
>> 15 git rebase --stash, git pull --rebase --stash
>
> It seems that Ramkumar Ramachandra is working on this in his "[PATCH
> v2 0/3] Introduce pull.autostash" series
> Ping Yin
Ah, cool! Added a note to the wiki, thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To
> 15 git rebase --stash, git pull --rebase --stash
It seems that Ramkumar Ramachandra is working on this in his "[PATCH
v2 0/3] Introduce pull.autostash" series
Ping Yin
On Mon, Apr 15, 2013 at 4:04 AM, Matthieu Moy
wrote:
> Hi,
>
> Like the years before, I'm going to offer my students a 1 mont
20 matches
Mail list logo
