* Continued work on sr/vcs-helper and sr/gfi-options
@ 2009-12-06 0:53 Sverre Rabbelier
2009-12-06 1:05 ` Miklos Vajna
2009-12-06 1:47 ` Junio C Hamano
0 siblings, 2 replies; 6+ messages in thread
From: Sverre Rabbelier @ 2009-12-06 0:53 UTC (permalink / raw)
To: Junio C Hamano, Git List
Heya,
I'm planning to start finishing up git-remote-hg this week, and for
that I need both sr/vcs-helper (in next) and sr/gfi-options (in pu).
How can I best go about working on these? I _think_ what I want is to
merge sr/vcs-helper and sr/gfi-options, into either master or next
(with a three-way merge), but I'm not sure? Also, when I try to rebase
sr/vcs-helper onto master I get conflicts yet again, since these were
already resolved in next, what is the best way for me to proceed in
such a way that it is convenient for you (Junio) and the list, if
possible, without having to untangle those merge conflicts.
Thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Continued work on sr/vcs-helper and sr/gfi-options
2009-12-06 0:53 Continued work on sr/vcs-helper and sr/gfi-options Sverre Rabbelier
@ 2009-12-06 1:05 ` Miklos Vajna
2009-12-06 1:47 ` Junio C Hamano
1 sibling, 0 replies; 6+ messages in thread
From: Miklos Vajna @ 2009-12-06 1:05 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Sun, Dec 06, 2009 at 01:53:03AM +0100, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> (with a three-way merge), but I'm not sure? Also, when I try to rebase
> sr/vcs-helper onto master I get conflicts yet again, since these were
That part is fairly easy, just don't forget to enable rerere. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Continued work on sr/vcs-helper and sr/gfi-options
2009-12-06 0:53 Continued work on sr/vcs-helper and sr/gfi-options Sverre Rabbelier
2009-12-06 1:05 ` Miklos Vajna
@ 2009-12-06 1:47 ` Junio C Hamano
2009-12-06 10:23 ` Sverre Rabbelier
1 sibling, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2009-12-06 1:47 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I'm planning to start finishing up git-remote-hg this week, and for
> that I need both sr/vcs-helper (in next) and sr/gfi-options (in pu).
> How can I best go about working on these? I _think_ what I want is to
> merge sr/vcs-helper and sr/gfi-options, into either master or next
> (with a three-way merge), but I'm not sure? Also, when I try to rebase
> sr/vcs-helper onto master I get conflicts yet again, since these were
> already resolved in next, what is the best way for me to proceed in
> such a way that it is convenient for you (Junio) and the list, if
> possible, without having to untangle those merge conflicts.
Some observations.
- sr/vcs-helper seems to be near completion; I'd expect it to be among
the first batch of topics to go to 'master' after 1.6.6 final (some
fixes may happen between now and 1.6.6 final to make the series a bit
longer, though).
- sr/gfi-options started moving again and there could be a couple more
iterations before it would hit 'next'.
Until sr/gfi-options becomes more solid, one way we can manage
sr/remote-hg is (thinking aloud):
- Fork sr/remote-hg from today's sr/vcs-helper;
- Merge today's 'master' to sr/remote-hg (optional);
- Whenever any updates to vcs-helper topic appears, apply them to
sr/vcs-helper, and merge the result to sr/remote-hg;
- Create an unstable sr/pu-remote-hg branch that:
- is reset to the tip of sr/remote-hg at the beginning of the day;
- merges the day's sr/gfi-options on top;
- re-applies patches to implement Hg interoperation on top of the
result.
When sr/gfi-options becomes solid, we can merge it to sr/remote-hg itself,
get rid of sr/pu-remote-hg "patch queue", and move the Hg interoperation
patches we helpd in sr/pu-remote-hg to sr/remote-hg branch. We will merge
early parts of sr/remote-hg (at least up to the merge with sr/gfi-options,
and perhaps early parts of individual Hg interoperation patches as well)
to 'next', and remaining parts on the branch to 'pu' (and they can be
replaced).
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Continued work on sr/vcs-helper and sr/gfi-options
2009-12-06 1:47 ` Junio C Hamano
@ 2009-12-06 10:23 ` Sverre Rabbelier
2009-12-06 23:36 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Sverre Rabbelier @ 2009-12-06 10:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
Heya,
On Sun, Dec 6, 2009 at 02:47, Junio C Hamano <gitster@pobox.com> wrote:
> - sr/vcs-helper seems to be near completion; I'd expect it to be among
> the first batch of topics to go to 'master' after 1.6.6 final (some
> fixes may happen between now and 1.6.6 final to make the series a bit
> longer, though).
*nod*.
> - sr/gfi-options started moving again and there could be a couple more
> iterations before it would hit 'next'.
Yup, I'm hoping for a review by Shawn and the vcs list.
> Until sr/gfi-options becomes more solid, one way we can manage
> sr/remote-hg is (thinking aloud):
>
> - Fork sr/remote-hg from today's sr/vcs-helper;
That makes sense, this way I don't have to re-resolve those merge
conflicts either.
> - Merge today's 'master' to sr/remote-hg (optional);
I'm not sure why this is though? (no objections against it, I just
don't understand the motivation)
> - Whenever any updates to vcs-helper topic appears, apply them to
> sr/vcs-helper, and merge the result to sr/remote-hg;
*nod*
> - Create an unstable sr/pu-remote-hg branch that:
>
> - is reset to the tip of sr/remote-hg at the beginning of the day;
> - merges the day's sr/gfi-options on top;
> - re-applies patches to implement Hg interoperation on top of the
> result.
Ok, that does make sense, how would I send out patches for review from
this unstable branch though? (since others would not have the required
merges etc) I reckon it would be necessary to publish sr/pu-remote-hg
somewhere?
> When sr/gfi-options becomes solid, we can merge it to sr/remote-hg itself,
> get rid of sr/pu-remote-hg "patch queue", and move the Hg interoperation
> patches we helpd in sr/pu-remote-hg to sr/remote-hg branch. We will merge
> early parts of sr/remote-hg (at least up to the merge with sr/gfi-options,
> and perhaps early parts of individual Hg interoperation patches as well)
> to 'next', and remaining parts on the branch to 'pu' (and they can be
> replaced).
Luckily the remote-hg patch is just that, a single patch. I've already
put all the other work that's needed into sr/vcs-helper and
sr/gfi-options.
Thank you for the detailed explanation :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Continued work on sr/vcs-helper and sr/gfi-options
2009-12-06 10:23 ` Sverre Rabbelier
@ 2009-12-06 23:36 ` Junio C Hamano
2009-12-07 0:52 ` Sverre Rabbelier
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2009-12-06 23:36 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> - Merge today's 'master' to sr/remote-hg (optional);
>
> I'm not sure why this is though? (no objections against it, I just
> don't understand the motivation)
It would make sense if you use 1.6.6 features in your new series (as the
forkpoint of sr/vcs-helper is beginning to look a tad stale), but
otherwise unnecessary; that is the reason why I said it is "(optional)"
and it is up to what is in the remote-hg patch.
>> - Create an unstable sr/pu-remote-hg branch that:
>>
>> - is reset to the tip of sr/remote-hg at the beginning of the day;
>> - merges the day's sr/gfi-options on top;
>> - re-applies patches to implement Hg interoperation on top of the
>> result.
>
> Ok, that does make sense, how would I send out patches for review from
> this unstable branch though? (since others would not have the required
> merges etc) I reckon it would be necessary to publish sr/pu-remote-hg
> somewhere?
I was thinking about carrying it myself (perhaps with help from you in
conflict resolution as necessary) when I wrote it, but if you want me to
pull from your repository somewhere e.g. repo.or.cz, that would also be
fine.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Continued work on sr/vcs-helper and sr/gfi-options
2009-12-06 23:36 ` Junio C Hamano
@ 2009-12-07 0:52 ` Sverre Rabbelier
0 siblings, 0 replies; 6+ messages in thread
From: Sverre Rabbelier @ 2009-12-07 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
Heya,
On Mon, Dec 7, 2009 at 00:36, Junio C Hamano <gitster@pobox.com> wrote:
> It would make sense if you use 1.6.6 features in your new series (as the
> forkpoint of sr/vcs-helper is beginning to look a tad stale), but
> otherwise unnecessary; that is the reason why I said it is "(optional)"
> and it is up to what is in the remote-hg patch.
Gotcha, I don't think I use any 1.6.6 features though, so I don't
think that will be necessary.
> I was thinking about carrying it myself (perhaps with help from you in
> conflict resolution as necessary) when I wrote it
That would be great! If you are you offering to create the
sr/pu-remote-hg branch and merge it to pu so that I can send patches
based on that, please do. If not, what do I do instead? :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-12-07 0:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-06 0:53 Continued work on sr/vcs-helper and sr/gfi-options Sverre Rabbelier
2009-12-06 1:05 ` Miklos Vajna
2009-12-06 1:47 ` Junio C Hamano
2009-12-06 10:23 ` Sverre Rabbelier
2009-12-06 23:36 ` Junio C Hamano
2009-12-07 0:52 ` Sverre Rabbelier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).