Hi Nils,
On 2017-07-12, Nils Bruin wrote:
> On Wednesday, July 12, 2017 at 8:46:00 AM UTC+2, Simon King wrote:
>>
>> Actually I still miss the old sage development workflow with mercurial.
>
> Are you sure? It led to some precious losses of code:
>
> https://trac.sagemath.org/ticket/13447#comm
On Wednesday, July 12, 2017 at 8:46:00 AM UTC+2, Simon King wrote:
>
> Actually I still miss the old sage development workflow with mercurial.
>
> Are you sure? It led to some precious losses of code:
https://trac.sagemath.org/ticket/13447#comment:84
--
You received this message because you a
a very useful option is to cherry-pick but not commit:
git cherry-pick -n
after this you can undo changes made by cherry-pick (by git reset --
or otherwise)
then doing "git add -p ..." --- which is more robust than editing patches,
and then
commit the result.
Well, yes, our old patch-quilt
On Tue, Jul 11, 2017 at 6:13 PM, Simon King wrote:
> Hi Erik,
>
> On 2017-07-11, Erik Bray wrote:
>> cherry-pick basically does exactly that. If a patch doesn't apply
>> with cherry-pick it will give you the opportunity to resolve the merge
>> conflict manually, which you'll probably have to do
Hi Ralf,
On 2017-07-12, Ralf Stephan wrote:
> Just to emphasize that there are different ways to work with patches, I am
> using patchfiles exclusively, always piping the diff into a text file and
> editing that. It's quite easy, just don't change hunk headers.
Actually I still miss the old sa
Just to emphasize that there are different ways to work with patches, I am
using patchfiles exclusively, always piping the diff into a text file and
editing that. It's quite easy, just don't change hunk headers.
--
You received this message because you are subscribed to the Google Groups
"sage
Hi,
perhaps not intellectually satisfying, but if the change to cherry-pick is
only one line, perhaps just rewriting the line by hand is the simplest
way.
Ciao,
Thierry
On Tue, Jul 11, 2017 at 04:13:03PM +, Simon King wrote:
> Hi Erik,
>
> On 2017-07-11, Erik Bray wrote:
> > cherry-pick b
Hi Erik,
On 2017-07-11, Erik Bray wrote:
> cherry-pick basically does exactly that. If a patch doesn't apply
> with cherry-pick it will give you the opportunity to resolve the merge
> conflict manually, which you'll probably have to do no matter what in
> most cases.
Sure. The point is that wit
On Tue, Jul 11, 2017 at 4:05 PM, Ralf Hemmecke wrote:
> If it is only a small difference to just one file on another (diverged)
> branch, then why not simply create a patch and apply it to the right branch.
>
> Something like this.
>
> git checkout mybranch
> git format-patch -k1 # if it is j
Hi Ralf,
On 2017-07-11, Ralf Hemmecke wrote:
> If it is only a small difference to just one file on another (diverged)
> branch, then why not simply create a patch and apply it to the right branch.
That's what I eventually did. However, I think it would be good to know
whether one can do without
If it is only a small difference to just one file on another (diverged)
branch, then why not simply create a patch and apply it to the right branch.
Something like this.
git checkout mybranch
git format-patch -k1 # if it is just on commit
# This gives a file 0001-...
git checkout master
git
On 2017-07-11, Daniel Krenn wrote:
> On 2017-07-11 14:39, Simon King wrote:
>> Being on a different git branch, I tried
>>git cherry-pick xyz
>
> Why cherry-pick and not simply
> git merge xyz
> ? This could git help finding a proper merge base.
Because I didn't want to merge the whole bran
On 2017-07-11, Simon King wrote:
> Being on a different git branch, I tried
>git cherry-pick xyz
Could a different strategy help? When I did
git cherry-pick --strategy=recursive -X theirs xyz
I actually got no conflict at all.
But there *should* be a conflict here! After all, the changes
13 matches
Mail list logo
