On Tuesday, November 5, 2013 6:32:49 AM UTC-8, Simon King wrote:
>
> To say it clearly: In the scenario above, you *have* to rebase, with or
> without a change of history, and the rebase (if I understand correctly)
> is the same effort with or without a change of history.
>
> Hence, saying that
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
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 ticket
> 4. review of ticket requests D, E
> 5. author rewrites his
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
Hi Ralf,
On 2013-11-05, Ralf Hemmecke wrote:
>> If you agree, then let me repeat my question: Why do some people believe
>> that changing A-B-C into A-B-C-D is better than changing it into A-C'?
>> Because in this case I really don't get the argument.
>
> Some people believe that changing history
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 2013-11-03, Nils Bruin wrote:
> It seems that the current "branch" field in trac serves two purposes:
> (a) It's a pointer to code-in-development that people who are
> collaborating can refer to
> (b) It serves as the official "to-be-merged" code once the ticket has a
> positive review
>
>
Hi Ralf,
On 2013-11-05, Ralf Hemmecke wrote:
>> 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 conflict can only happen, if X builds (depends) on changes
> that are introduced in B, since these chang
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
Hi Ralf,
On 2013-11-05, Ralf Hemmecke wrote:
>> 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
> 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
Hi David,
On 2013-11-04, David Roe wrote:
> Even if you
> decide you don't want some code that you introduced, you should introduce a
> new commit that deletes the code rather than removing old commits and
> force-pushing your branch.
Good example.
So, what simple and easy-to-use command does g
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
Hi!
On 2013-11-04, kcrisman wrote:
> --=_Part_109_13671842.1383581913134
> Content-Type: text/plain; charset=ISO-8859-1
>
> I like this discussion, hopefully we'll find a good result. What if
> multiple people are contributing to a ticket - how might that play in for
> the various options?
git blame already does cumulative blame over a range of commits. By mashing
commits together you don't gain anything. But you invalidate all branches
that were based on the un-mashed commits.
If you absolutely can't live with others noticing that you are human after
all, then you can still squ
I like this discussion, hopefully we'll find a good result. What if
multiple people are contributing to a ticket - how might that play in for
the various options?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group an
On Monday, November 4, 2013 7:15:19 AM UTC+1, Nils Bruin wrote:
>
> On Sunday, November 3, 2013 6:51:48 PM UTC-8, P Purkayastha wrote:
>
>> If you check out the branch locally, you can run a
>>
>> git diff
>>
>> to see the cumulative changes.
>>
>
> That's good to know. However, when trying
On Sunday, November 3, 2013 6:51:48 PM UTC-8, P Purkayastha wrote:
> If you check out the branch locally, you can run a
>
> git diff
>
> to see the cumulative changes.
>
That's good to know. However, when trying to figure out the history of
code, it's usually not so much the question what h
On 11/04/2013 06:25 AM, Volker Braun wrote:
On Sunday, November 3, 2013 9:29:09 PM UTC, Nils Bruin wrote:
For purpose (b), however, it would be nicer if
The git log is easily accessible from code. Its easy to write all kinds
of analysis scripts if you care to.
If you check out the b
On Sunday, November 3, 2013 9:29:09 PM UTC, Nils Bruin wrote:
>
> For purpose (b), however, it would be nicer if
>
The git log is easily accessible from code. Its easy to write all kinds of
analysis scripts if you care to.
--
You received this message because you are subscribed to the Goo
23 matches
Mail list logo
