Hmm, I haven't even thought about this. Might be worth trying.
On Fri, 12 Nov 2010 15:49:21 +0100, Steve Ebersole
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 (rem
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
On Fri, 12 Nov 2010 15:02:55 +0100, Steve Ebersole
wrote:
>
> On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
>> On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
>> How does cherry picking solve the problem of the directory name changes?
>
> Well like I said before the co
Agreed to disagree :)
On Fri, 12 Nov 2010 14:59:29 +0100, Steve Ebersole
wrote:
> Well we will agree to disagree. Having a file under source control that
> you
> fully expect to change locally on every machine for various
> circumstances is
> lame imo.
___
I will not be able to make the 11/15 IRC dev meeting. Y'all can decide if you
want to get together anyway.
---
Steve Ebersole
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/
On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
> On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
> 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 renam
Well we will agree to disagree. Having a file under source control that you
fully expect to change locally on every machine for various circumstances is
lame imo.
On Friday, November 12, 2010, at 07:12 am, Hardy Ferentschik wrote:
> On Thu, 11 Nov 2010 16:55:27 +0100, Steve Ebersole
>
> wrote
On Thu, 11 Nov 2010 16:55:27 +0100, Steve Ebersole
wrote:
>> Is this really such a big issue? What's the harm if someone accidentally
>> checks in his logging settings?
>
> Long(er) build times. Bloated Hudson workspaces. I guess thats it.
> Are you going to watch for this? And contact th
On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
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
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
Hi,
yesterday I broke the rule to never stop a running system.
I am working on Mac and had po2xml via MacPorts (http://www.macports.org/).
It WAS part of the kdesdk4 bundle. While installing a unrelated port the
system
kindly informed me that my port installation was outdated. It recommended a
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 wa
12 matches
Mail list logo
