From: Felipe Contreras Date: Thu, 11 Apr 2013 05:18:08 GMT Subject: Re: [PATCH 2/2] transport-helper: update remote helper namespace Message-ID: In-Reply-To: <20130411050509.GC27795@sigill.intra.peff.net> On Thu, Apr 11, 2013 at 12:05 AM, Jeff King wrote: > On Wed, Apr 10, 2013 at 11:53:38PM -0500, Felipe Contreras wrote: > >> > But if we push some commits to the helper, moving Y up to Z, then it >> > would build the new commit (which contains the foreign-vcs's equivalent of >> > Y..Z) on top of Z, not Y. >> >> Why would it do that? If X points to say revision 100, presumably it >> was stored somewhere while doing a fetch. Similarly, if foreign >> version of Z is 150, it can update that number while doing a push. The >> next fetch it would start from 151. > > I think the only reason not to bump the marker forward during the push > would be if the helper wants for some reason to "re-import" from the > foreign source rather than accepting the git versions of the commits. > Something like git-svn's markup of the commit messages with revision ids > comes to mind. Yeah, but that's already a second level hypothesis. First, remote-helpers would need to be able to work without marks, and they can't. > But if it matters, then by definition that would mean > that the import/export is not bidirectionally clean. I don't see how would that matter. > So I can buy the argument that bumping it forward ourselves will not > matter for any well-implemented helper. Or any helper. > That is the sort of thing that might be helpful to include in the commit > message; if somebody does run across such a helper and bisects to your > commit, then they can understand the rationale for the decision. If it did matter, it would be mentioned. I will updated it later if there's no further comments. -- Felipe Contreras