On Thu, Apr 11, 2013 at 12:05 AM, Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html