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
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
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at