4:35 a.m.
Hi,
Until yesterday I was wondering what the current talk about back-porting
issues was all about.
Thanks to HHH-5729 I got my own share of problems ;-)
I know Steve is preparing some guidelines regarding this, but there are my
thoughts as a result
from yesterdays experience.
My workflow was:
$ git checkout -b HHH-5729
$ (work)
$ git commit
$ (work)
$ git commit
...
$ git format-patch -M master
Now I had a patch file for each commit. These patch files I copied to my
second checkout of core
where I am working on the branch 3.6. I know, I know, changing branches in
git is fast, but I prefer
(and recommend) everyone to have a separate checkout for the 3.6 branch.
The main reason is the
switch in build tools (maven -> gradle) and additional directory renames
which make IDE setup
refreshes a nightmare.
Anyways, back to back-porting. Once I had the patch files in the right
place, I tried:
$ git am *.patch
Here of course the trouble started. The patches could not be applied due
to the renaming and in some
cases merging of directories. Here are the problems I had to deal with in
my case
* core was renamed to hibernate-core
* testing was moved into hibernate core (and sources moved from
src/main/java -> src/test/java)
* testsuite was moved into hibernate-core
Nothing a little bit of sed work couldn't fix. In fact after fixing the
paths names in the patch files,
the patches applied just fine.
This got me thinking whether we should write a little shell script taking
care of these things and checking
it into the 3.6 branch. The workflow would be something like this then:
$ git format-patch -M master
$ (copy patches to 3.6 branch)
$ adjustPatches.sh *.patch
$ git am *.patch
Thoughts? Am I till missing part of the problem?
--Hardy
6:27 a.m.
The problem like you said in patching is that the dir renames are missed. The
problem in merge/rebase approches is that (due to git's common ancestor
approach) they want to pull in all the other changes back to 3.6 and there is
no way to adjust the base it uses to determine the diffs.
A script is actually a great idea.
The other thought I had was to revert the module dir renames. Or to do it in
3.6 as well. Make them the same. Just not sure the kind of effect that would
have now. Also it would not alleviate the merge/rebase "too much" problem.
There is a 3rd approach someone one #git recommended leveraging cherry
picking, but it was not simple either.
On Friday, November 12, 2010, at 04:35 am, Hardy Ferentschik wrote:
Hi,
Until yesterday I was wondering what the current talk about back-porting
issues was all about.
Thanks to HHH-5729 I got my own share of problems ;-)
I know Steve is preparing some guidelines regarding this, but there are my
thoughts as a result
from yesterdays experience.
My workflow was:
$ git checkout -b HHH-5729
$ (work)
$ git commit
$ (work)
$ git commit
...
$ git format-patch -M master
Now I had a patch file for each commit. These patch files I copied to my
second checkout of core
where I am working on the branch 3.6. I know, I know, changing branches in
git is fast, but I prefer
(and recommend) everyone to have a separate checkout for the 3.6 branch.
The main reason is the
switch in build tools (maven -> gradle) and additional directory renames
which make IDE setup
refreshes a nightmare.
Anyways, back to back-porting. Once I had the patch files in the right
place, I tried:
$ git am *.patch
Here of course the trouble started. The patches could not be applied due
to the renaming and in some
cases merging of directories. Here are the problems I had to deal with in
my case
* core was renamed to hibernate-core
* testing was moved into hibernate core (and sources moved from
src/main/java -> src/test/java)
* testsuite was moved into hibernate-core
Nothing a little bit of sed work couldn't fix. In fact after fixing the
paths names in the patch files,
the patches applied just fine.
This got me thinking whether we should write a little shell script taking
care of these things and checking
it into the 3.6 branch. The workflow would be something like this then:
$ git format-patch -M master
$ (copy patches to 3.6 branch)
$ adjustPatches.sh *.patch
$ git am *.patch
Thoughts? Am I till missing part of the problem?
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
7:09 a.m.
On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole <steve(a)hibernate.org>
wrote:
A script is actually a great idea.
Right now it seems to be the way of least resistance.
The other thought I had was to revert the module dir renames. Or to
do
it in 3.6 as well. Make them the same. Just not sure the kind of
effect that would have now.
I don't have any string feelings about going back from hibernate-core to
core, etc, but
there is also the testsuite and testing module changes. Having these
within core
now makes sense. If adjusting directory names I opt for doing it on the
branch.
There is a 3rd approach someone one #git recommended leveraging
cherry
picking, but it was not simple either.
How does cherry picking solve the problem of the directory name changes?
--Hardy
8:02 a.m.
On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
<steve(a)hibernate.org>
How does cherry picking solve the problem of the directory name changes?
Well like I said before the code in git that does merging understands the fact
that files are renamed. Your approach does not natively because it produces a
diff file which simply has *a* path.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
8:30 a.m.
On Fri, 12 Nov 2010 15:02:55 +0100, Steve Ebersole <steve(a)hibernate.org>
wrote:
On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
> On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole <steve(a)hibernate.org>
> How does cherry picking solve the problem of the directory name changes?
Well like I said before the code in git that does merging understands
the fact
that files are renamed. Your approach does not natively because it
produces a
diff file which simply has *a* path.
Ok, I see. I will try the cherry picking next time. If it is too
complicate I
will go back to the script idea.
--Hardy
8:49 a.m.
Given your setup (separate clones) I am not sure merge, rebase or cherry-pick
are going to work. Another idea I have been toying with is to link the 2
clones (remote can be a file path). Really kind of orthogonal to the original
discussion, but has bearing.
On Friday, November 12, 2010, at 08:30 am, Hardy Ferentschik wrote:
On Fri, 12 Nov 2010 15:02:55 +0100, Steve Ebersole
<steve(a)hibernate.org>
wrote:
> On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
>> On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole <steve(a)hibernate.org>
>> How does cherry picking solve the problem of the directory name changes?
>
> Well like I said before the code in git that does merging understands
> the fact
> that files are renamed. Your approach does not natively because it
> produces a
> diff file which simply has *a* path.
Ok, I see. I will try the cherry picking next time. If it is too
complicate I
will go back to the script idea.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
9:40 a.m.
Hmm, I haven't even thought about this. Might be worth trying.
On Fri, 12 Nov 2010 15:49:21 +0100, Steve Ebersole <steve(a)hibernate.org>
wrote:
Given your setup (separate clones) I am not sure merge, rebase or
cherry-pick
are going to work. Another idea I have been toying with is to link the 2
clones (remote can be a file path). Really kind of orthogonal to the
original
discussion, but has bearing.
5158
days inactive
5158
days old
6 comments
2 participants
participants (2)
-
Hardy Ferentschik -
Steve Ebersole