Re: Current state / standard advice for rebasing merges without information loss/re-entry?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Philip Oakley <philipoakley@iee.email> writes:

> The rerere man page is still magic for me. The UX here could be
> improved. (also, could the rerere-train be focussed on each merge?)

I am curious to see a clarification on the question in parentheses.

>> These kinds of discussions frequently seem to feature git experts
>> saying "I have a script for my version of this problem" (Elijah,
>> Junio, Johannes Schindelin, ...), or even "I have a VCS for this
>> problem" :), but I seem to be too stupid or impatient to dig
>> through/understand whether or when these things will work for a
>> regular joe and how to use them.

You shouldn't take that to mean "there already is a script to
satisfy _my_ needs and no improvement is needed"; read it as "we
have real need that cannot wait for improvements in this area, so
(unfortunately) we have built our workflow around some scripts".
We can use these scripts to learn the workflows that are not yet
directly supported with existing tools like rebase, but other than
that, their presence is not a sign that discourage you to improve
the standard tools---it is quite an opposite.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux