Hi Travis,
On 2015-06-27, Travis Scrimshaw wrote:
> In that situation (which I consider as a special case), one should instead
> create a new branch based off the point right before the move happened.
Actually, after posting, I realised that in the special situation I need
the commits (or at l
> In that situation (which I consider as a special case), one should instead
> create a new branch based off the point right before the move happened.
Works for me, since the final branch is the same.
> Don't change history!
You would call it "rewriting history" if, after the merge, you push
the
In that situation (which I consider as a special case), one should instead
create a new branch based off the point right before the move happened.
Don't change history!
Travis
On Friday, June 26, 2015 at 12:11:59 PM UTC-7, Nathann Cohen wrote:
>
>Ah, sorry. From all the different git workf
>
>Ah, sorry. From all the different git workflows I've seen and read, it
> is better to push your comments and revert them in later commits because it
> shows a history of things you tried (and possibly pull code from).
>
Once in a branch somebody moved a lot of code from one place to anot
> If I recall correctly, I found severeal git introductions recommending
>> to commit often and early. And how should one possibly show the code to
>> a ticket's referee if not by a commit?
>
>
> What I meant was: You should commit often, but you shouldn't import said
> commits into other bra
Hey Simon,
Ah, sorry. From all the different git workflows I've seen and read, it
is better to push your comments and revert them in later commits because it
shows a history of things you tried (and possibly pull code from).
Best,
Travis
On Thursday, June 25, 2015 at 4:52:08 PM UTC-7, Simo
Hi Volker,
On 2015-06-26, Volker Braun wrote:
> What I meant was: You should commit often, but you shouldn't import said
> commits into other branches if you can avoid it.
OK, that makes sense. Thank you.
Cheers,
Simon
--
You received this message because you are subscribed to the Google Gro
On Friday, June 26, 2015 at 12:45:30 PM UTC+2, Simon King wrote:
>
> > If in doubt always use the minimal number of commits; There is nothing
> to
> > be gained by extra stuff in the history that you revert later.
>
> If I recall correctly, I found severeal git introductions recommending
> to c
Hi Volker,
On 2015-06-26, Volker Braun wrote:
> The best solution is probably to implement your proof of concept in an
> altogether separate ticket.
No, it is a proof of concept of one possible interpreation of the
ticket's topic, and thus I wouldn't open a new ticket for it. The topic
is about
The best solution is probably to implement your proof of concept in an
altogether separate ticket.
If in doubt always use the minimal number of commits; There is nothing to
be gained by extra stuff in the history that you revert later.
On Thursday, June 25, 2015 at 11:07:53 PM UTC+2, Simon Kin
On 2015-06-26 01:51, Simon King wrote:
Which of the two approaches ("Keep the critical commits in and perhaps
revert them in a later commit" or "Leave the critical commits out and
perhaps insert them later") has the least probability of confusing a
referee or upsetting the release manager?
Do y
Hi Travis,
On 2015-06-25, Travis Scrimshaw wrote:
>You could just make 2 branches, one for each of the commits and
> cherry-pick commits between the two branches (or just keep a reference to
> the commits you don't want).
I know that I can do this. I want to know: What should I push to tra
Hey Simon,
You could just make 2 branches, one for each of the commits and
cherry-pick commits between the two branches (or just keep a reference to
the commits you don't want).
Best,
Travis
On Thursday, June 25, 2015 at 2:07:53 PM UTC-7, Simon King wrote:
>
> Hi!
>
> Trac ticket #18758 d
13 matches
Mail list logo
