Continued work on sr/vcs-helper and sr/gfi-options

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!

On Sun, Dec 06, 2009 at 01:53:03AM +0100, Sverre Rabbelier <srabbelier@gmail.com> wrote:

That part is fairly easy, just don't forget to enable rerere. :)

Sverre Rabbelier <srabbelier@gmail.com> writes:

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).

Heya,

On Sun, Dec 6, 2009 at 02:47, Junio C Hamano <gitster@pobox.com> wrote:

*nod*.

Yup, I'm hoping for a review by Shawn and the vcs list.

That makes sense, this way I don't have to re-resolve those merge conflicts either.

I'm not sure why this is though? (no objections against it, I just don't understand the motivation)

*nod*

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?

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 :).

Sverre Rabbelier <srabbelier@gmail.com> writes:

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.

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.

Heya,

On Mon, Dec 7, 2009 at 00:36, Junio C Hamano <gitster@pobox.com> wrote:

Gotcha, I don't think I use any 1.6.6 features though, so I don't think that will be necessary.

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? :).