Hi all, thanks for all you clever replies.

Here's what I've done:

$ git branch 2.2 tag2.1
$ git checkout 2.2
$ git merge 2.1
$ git checkout 2.1 
$ git revert --no-commit <sha-1 of all commits between tag2.1 and HEAD
$ git commit -m "Reverted what ought to be in branch 2.2"

In that manner, all history is kept and impacts on those who pulled from 
the 'origin' is minimal.

I tried cherry-picking all commits from tag2.1 to HEAD of 2.1 but I 
consistently had error messages and the process was not seemless, hence the 
merge. But I seem to have all the history of the about 50 commits not 
squashed into a single merge commit, which is fine.

For the time being, we're only a couple developer so the impact is rather 
limited.

But I'll try avoid that kind of error in the future, if possible.


Le lundi 18 juin 2012 10:55:12 UTC-4, Konstantin Khomoutov a écrit :
>
> On Sun, 17 Jun 2012 09:12:26 -0400 
> Eric Parent wrote: 
>
> >    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? 
>
> 0) $ git checkout 2.1 
> 1) $ git branch 2.2 
> 2) $ git reset --hard tag2.1 
>
> This will: 
> 1) Create a branch named "2.2" which points to the same commit 
>    the branch "2.1" currently does. 
> 2) Make the "2.1" branch point to the same commit the tag "tag2.1" 
>    points (effectively truncating the branch). 
>
> You will have to forcibly push your 2.1 branch to your authoritative 
> (central) repo if you have it. 
>
> Your confusion about how to achieve what you want probably stems from 
> the fact you think a branch is something special, while in git both 
> tags and branches are simply references to a specific commit. 
> What constitutes a line of history then is commit chanining: each 
> commit references one or more parent commit(s) (except for the root 
> commit in a repository which references nothing). 
>
> Tags and branches are only different when it comes to committing 
> (committing on a branch updates the reference while committing when you 
> "have a tag checked out" does not update anything). 
>

-- 
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/-/EYGwcx9IyAYJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to