On Mon, Jul 7, 2014 at 3:12 PM, Charles R Harris
<charlesr.har...@gmail.com> wrote:
> On Mon, Jul 7, 2014 at 6:46 AM, Julian Taylor
> <jtaylor.deb...@googlemail.com> wrote:
>>
>> On Mon, Jul 7, 2014 at 2:34 PM, Charles R Harris
>> <charlesr.har...@gmail.com> wrote:
>> > On Mon, Jul 7, 2014 at 2:02 AM, Julian Taylor
>> > <jtaylor.deb...@googlemail.com> wrote:
>> >>
>> >> On 07.07.2014 07:53, Charles R Harris wrote:
>> >> > Just so. The fixes for 1.9.0b1 are now in that branch ready for the
>> >> > next
>> >> > beta.
>> >> >
>> >>
>> >> how did you do that without a merge commit?
>> >
>> >
>> > git branch tmp maintenance/1.9.x
>> > git co tmp
>> > git branch -f maintenance/1.9.x d244ec7
>> > git rebase -p --onto tmp 10098da maintenance/1.9.x
>> >
>> >>
>> >> however you did it you have git has lost ancestry which is not so nice
>> >> for backporting.
>> >
>> >
>> > Same changesets, I believe. If '-p' is omitted the merges are omitted.
>> >
>> >>
>> >> If there are no objections I'd like to rewind the maintenance branch
>> >> back to beta1 and merge master in properly.
>> >
>> >
>> > I thought this somewhat cleaner than a merge :0
>> >
>>
>> By rebasing or cherry-picking git loses the information that the
>> changeset originates from another branch.
>> So when you try to merge or cherrypick more changes from the branch
>> the changes are coming from the automerging bails or is at least less
>> useful.
>> So if you are moving changes from one branch to another one should
>> merge whenever possible.
>>
>> Now that both branches have diverged, 1.9 by the release commit, and
>> 1.10 by the opening commit, there is no easy way for git to track the
>> origins of a changeset and we have to do the usual cherry picking, as
>> to my knowledge git does not have partial merges.
>
>
> Yes, what I did was like one big cherry-pick. But I think we end up in the
> same place with two divergent branches. I think git history is just a string
> of changesets and each changeset has a hash. Same hash, same changeset, and
> I think that was preserved, so in that sense history was preserved. The
> 1.9.x branch pushed without trouble. Anyway, six of one, half dozen of the
> other. I was going to do the merge route originally, even did the merge.
>
the rebase does not preserve hashes, it rewrites the commits (minimal
change is changing the commiter).
Your approach brings us to this state:
R the maintenance release commit, D the master 1.10 opening commit
A - > B -> C -> D < master
\ R -> B' -> C' < maintenance
whereas a merge is this:
A -> B -> C -> D < master
\ merge
\ R -------- \ M < maintenance
the difference is when you now want to merge D into the maintenance branch.
In the first case git tries to merge the D changeset into the branch,
it tracks down the anchestry of D and C' figures
This leads to the merge base A, and git needs to merge B, C, D, R, B', C'
now merging B and B' and C and C' will conflict as they change the
same lines (in an ideal world git would realize that the diffs are
actually equal, but it does not do that in my experience) and asks the
user for help.
now in the merge case its different.
You want to move D into the branch it tracks down the ancestry of D and R
This leads to the merge base A, and both branches have the same commit B and C.
So now it only needs to merge D and R (leading to M) which will be
automatic if they do not conflict.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
