On Tue, Nov 5, 2013 at 12:32 PM, Simon King wrote:
> Hi Gonzalo,
>
> On 2013-11-05, Gonzalo Tornaria wrote:
>> Example:
>>
>> 1. A, B are posted in ticket
>> 2. purple-sage (or sage-next, or whatever) gets interested in ducks,
>> and decides to merge these experimentally
>> 3. C is posted in tick
More reading and some comments:
a. Linus et al on git rebase: http://yarchive.net/comp/linux/git_rebase.html.
b. An article in LWN about the topic: http://lwn.net/Articles/328436/
c. In the first reference there are a couple of comments by Linus on
"revert" -- including a recipe using rebase tha
On 11/05/2013 12:02 PM, Simon King wrote:
> Good. So, would you (and other people) agree that the effort needed to
> rebase X on top of A-C' is always (i.e., also in the case of conflicts)
> the same as the effort needed to rebase X on top of A-B-C-D (where D
> reverts B)?
In terms of code the sit
On 11/05/2013 10:09 AM, Simon King wrote:
>> To achieve this from the above situation, you do
>>
>> git rebase --onto ticket/123 master ticket/456
>
> Good to know! I did not test yet. Is there any manual intervention
> needed, if X is disjoint from the changes introduced in B?
No. A merge confli
> So, what simple and easy-to-use command does git offer to create a
> "negative commit"? That's to say, if I have commits A-B-C and want to
> "remove" B, how can I make git create a commit D for me such that
> A-B-C-D results in the same code as A-C?
https://www.kernel.org/pub/software/scm/git/do
You can put "private" (not: secret) branches on trac, just don't link from
a ticket and you can do with them what you want. Or tell people in a
comment or in the ticket description that the branch is not ready for
public consumption. If you did that, then you can rewrite your history.
However,
On Monday, November 4, 2013 10:33:24 AM UTC-8, David Roe wrote:
>
> I agree with Volker: any plan which involves rewriting the history of your
> branch to make it "nicer" is a very bad idea. Once you push changes to
> trac, you really should not go back and rewrite your commits. Even if you
>
Relevant article by Linus Torvalds:
http://lwn.net/Articles/328438/
Best,
Gonzalo
On Mon, Nov 4, 2013 at 4:33 PM, David Roe wrote:
> I agree with Volker: any plan which involves rewriting the history of your
> branch to make it "nicer" is a very bad idea. Once you push changes to
> trac, you r
I agree with Volker: any plan which involves rewriting the history of your
branch to make it "nicer" is a very bad idea. Once you push changes to
trac, you really should not go back and rewrite your commits. Even if you
decide you don't want some code that you introduced, you should introduce a
n
