John, Mike,
Thanks for your comments. I’ve been using rebase for a while now and it
certainly makes resolving conflicts in patches much easier, as opposed to
manually inspecting reject files. My workflow is as per your suggestion,
bash common/bin/hgforest.sh push -a
bash common/bin/hgforest.sh
Jonathan Gibbons ([email protected]) wrote:
> Could we do the same with the trees extension?
You can do it now with:
hg tpull --rebase
(As mentioned in my other message, I always precede the above with
'hg qpush -a' to avoid reject files.)
-John
> On 04/11/2014 10:55 AM, Mike
Mike Duigou ([email protected]) wrote:
>
> On Apr 11 2014, at 12:06 , Chris Hegarty wrote:
>
> > On 11 Apr 2014, at 18:55, Mike Duigou wrote:
> >
> >> Have you looked at using rebase?
> >
> > I have not, in any detail.
> >
> >> I've been using
> >>
> >> sh common/bin/hgforest.sh pull
>
Chris Hegarty ([email protected]) wrote:
> On 11/04/14 15:59, Jonathan Gibbons wrote:
> > Popping all patches beforehand is reasonable, but afterwards, it would
> > be better to reset to the patches that were previously applied than to
> > try and push all of them.
>
> Michael as requested
On Apr 11 2014, at 12:06 , Chris Hegarty wrote:
> On 11 Apr 2014, at 18:55, Mike Duigou wrote:
>
>> Have you looked at using rebase?
>
> I have not, in any detail.
>
>> I've been using
>>
>> sh common/bin/hgforest.sh pull
>> sh common/bin/hgforest.sh rebase
>> sh common/bin/hgforest.sh upda
On 11 Apr 2014, at 18:55, Mike Duigou wrote:
> Have you looked at using rebase?
I have not, in any detail.
> I've been using
>
> sh common/bin/hgforest.sh pull
> sh common/bin/hgforest.sh rebase
> sh common/bin/hgforest.sh update
>
> rather than get_source.sh as it allows me to skip the qpop/
Could we do the same with the trees extension?
-- Jon
On 04/11/2014 10:55 AM, Mike Duigou wrote:
Have you looked at using rebase? I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip
Have you looked at using rebase? I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Mike
On Apr 11 2014, at 07:58 , Chris Hegarty wrote:
> Anyone using MQ for
On 11 apr 2014, at 17:19, Jonathan Gibbons wrote:
> Is it common to use mq in all repos of a forest?
For me it is very common to be working on a fix that spans multiple repos (up
to 5 different repos at times). So, yes.
I like this fix, but I would be very annoyed if all my patches were appli
On 11/04/14 16:19, Chris Hegarty wrote:
On 11/04/14 15:59, Michael McMahon wrote:
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the
Is it common to use mq in all repos of a forest?
I've never used mq that way; it would only have occurred to me to use mq
in the repo I'm interested in -- in my case, langtools. But then, I
admit I tend not to clone forests more than necessary. configure.sh
--with-override-repo-name is your
On 11/04/14 15:59, Michael McMahon wrote:
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
That would require a
On 11/04/14 15:59, Jonathan Gibbons wrote:
Popping all patches beforehand is reasonable, but afterwards, it would
be better to reset to the patches that were previously applied than to
try and push all of them.
Michael as requested same.
What is the behavior if you cannot qpush patches after
Popping all patches beforehand is reasonable, but afterwards, it would
be better to reset to the patches that were previously applied than to
try and push all of them.
What is the behavior if you cannot qpush patches after the pull, because
of merge issues?
-- Jon
On 04/11/2014 07:58 AM, C
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
Michael
On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/g
16 matches
Mail list logo
