2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
I wanted to know how you manage this situation. I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time.
The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:
1) It has an older version number but newer contents
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ??
How do you normally solve this?
On Wed, Jan 13, 2016 at 10:46 PM, David Allouche <david@allouche.net> wrote:
Removing commits from a git branch is only really problematic if there are outstanding, unmerged branches out there, since it tends to cause false merge conflicts.
Locals clones of the public repository WILL complain about a divergence, but they can be fixed by "git pull --force". That is probably acceptable in your context, since you appear to be in a "botched history" situation.
Taking a step back, any distributed version control that uses explicit revision numbers for ordering is broken by design. Yes, Monticello, I am looking at you.
That was one of the design mistakes of GNU Arch, and the reason why all the DVCS that followed it (bzr, hg, git) identify revisions by UUIDs and define ordering exclusively by the ancestry graph. Experience has also shown that using content-based UUIDs like hg and git is preferable, for performance and integrity, to using arbitrary UUIDs like bzr did.
Disclaimer: I am (not yet) familiar with the Monticello model, so I might be all wrong. But I am quite knowledgeable about DVCS design in general.
From the little I know about Monticello I believe you are correct. Its a known problem - just no-one has got to tackle it yet. I'm not familiar with this space, but you may be interested in Ring [1] , Epicea [2], libgit[3], in-image github[4].
cheers -ben [1] http://rmod.lille.inria.fr/archives/talks/2010-Smalltalks-Uquillas-Ring.pdf [2] http://arxiv.org/pdf/1309.4334.pdf [3] https://github.com/theseion/LibGit [4] http://forum.world.st/Basic-versioning-of-GitHub-repositories-from-within-Ph...