>>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck >>>>> <[email protected]>: >>>>>> >>>>>> 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 <[email protected]> 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-Pharo-td4862708.html#a4862785
