cherry picking changesets instead of commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have a project stored in a git repository with other versions stored
in both cvs and perforce (sadly).  I want the ability to propagate
changes back and forth between all three repositories without mangling
the git history.  I specifically want to avoid (1) having two copies
of each commit (e.g., an initial version and a version pulled from
cvsimport) and (2) commits full of git-p4 metadata (the [git-p4] lines
in commit messages).

One way to do this would be to have cvs branch imported using "git
cvsimport", and a perforce branch imported via "git-p4", and
communicate between the cvs/p4 branches and the main git branches
entirely through cherry picking.  Unfortunately, "git cherry" doesn't
recognize when commits with potentially different author names or log
messages polluted with "[git-p4]" produce the same changeset, so if I
export a change from the git master branch through cvsexportcommit and
update the cvs branch with cvsimport, "git cherry" will report that
the change doesn't exist on the git master branch.

Has anyone tackled this problem before?  Would it be straightforward
to add an option to "git cherry" to ignore differences in metadata?
The cherry documentation doesn't give its criteria for when commits
match, and I'm not familiar enough with the code yet to figure out
those criteria directly from cmd_cherry in builtin-log.c.

Thanks,
Geoffrey
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux