Hi Daniel, I tried the following:
Le lundi 18 juin 2012 01:55:06 UTC-4, Daniel Dotsenko a écrit : > > // truncate 2.1 > git co 2.1 > git br 2.2 // 2.2 will retain all commits you reset below > git reset tag2.1 --hard > > // revert selected commits in what will be 2.2 > git co 2.2 > > Omitted the "revert" intentionnally for now. $ pwd pk $ cd .. $ mkdir momo $ cd momo $ git init --bare $ cd pk $ git remote add momo ../momo $ git checkout 2.1 # my branch with the new HEAD $ git push momo 2.1 $ git checkout 2.2 # my new branch with the actual history $ git push momo 2.2 Now, see if this repo is consistent when pulling from it... But seems like there is something wrong $ cd .. $ mkdir tata $ cd tata $ git clone ../momo Cloning into 'momo'... done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Waiting until I do some more tests... /Eric > > // and you have 2.2 that will still contain A, B, but will have reverseA, > reverseB at the tail. > > branch 2.1: A <- B > branch 2.2: A <- B <- C <- D <- ... <- K <- reverseA > <- reverseB > > All commits in 2.2 retain commit IDs, so for other team members revA and > revB will just be a pull/merge. > > The 2.1 branch, though will cause a bit of headache for some who rely on > it as remote. They will have to do > > git fetch --all -p > > // -p purges local cache, should put new "remote" 2.1 in the right place > for people. > > > Alternatively, > > // truncate 2.1 > git co A-1 > git br 2.2 > git reset tag2.1 --hard > > // revert selected commits in what will be 2.2 > git co 2.2 > git cherry-pick C..K > > But in this case, C-K in 2.2 branch will have new commit IDs. > > Daniel. > > > > > On Sunday, June 17, 2012 6:12:26 AM UTC-7, EricP wrote: >> >> Hi, >> >> I've been working on a branch, say '2.1' and made a few commits on >> it. We've made a release and tagged the changeset at which the commit >> was produced, say 'tag2.1'. >> >> Development continued and a few more commits were made on that >> branch, the '2.1'. >> >> As the development goes, we think it would be a better idea to >> create a branch '2.2' that starts at the tag where the release was >> made and keep '2.1' only for the maintenance of that release. >> >> So here's what we have at the moment: >> >> (tag2.1) >> branch 2.1 : A <- B <- C <- D <- ... <- K >> >> Here is what we would like to have: >> >> >> changesets C up to K to be on a branch 2.2 starting at 'tag2.1': >> >> (tag2.1) >> branch 2.1: A <- B >> branch 2.2: <- C' <- D' <- E' <- ... <- K' >> >> Any hints? >> >> I tried a few things like: >> >> $ git checkout 2.1 >> $ git branch 2.2 'tag2.1' >> $ git reset --hard 'tag2.1' >> >> But that left me with an inconsistent repo... >> >> $ git checkout 2.1 >> $ git branch tmp 'tag2.1' >> $ git branch 2.2 'tag2.1' >> $ git rebase --onti 2.2 tmp 2.1 >> >> But did not leave me with the expected result either. >> >> Any hint is welcome. >> >> Cheers! >> >> -- >> - Eric >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/6hg6HyozbIkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
