git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avery Pennarun <apenwarr@gmail.com>
To: Stephen Kelly <steveire@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: How to keep different version numbers in different branches?
Date: Mon, 5 Apr 2010 14:51:35 -0400	[thread overview]
Message-ID: <y2i32541b131004051151v8f4b8774q360c04ecdb046778@mail.gmail.com> (raw)
In-Reply-To: <hpcscv$umg$3@dough.gmane.org>

On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly <steveire@gmail.com> wrote:
> I want to make a 0.1 release, so that would mean creating a 0.1 branch and
> updating files contained in the branch such as the README file and the CMake
> files and the api documentation to report version 0.1.0, and creating the
> 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously,
> the version number in those files is changes to 0.2.0 in the master branch.
>
> However, now I have changes in my maintenance branch (0.1) which should not
> be merged into master (that is, the commits which change the version
> number).
>
> How are you supposed to handle that with git? Simply merge and resolve the
> conflict on master by keeping its version number? Am I missing some other
> way of doing it here?

I've used that method.  it works fine, and the conflicts are only
whenever the maintenance branch version number changes, which is very
rare (and easy to see).

As someone else suggested, doing it the way git.git does (using
essentially 'git describe HEAD') is another method, though you then
depend on having your source code built from the git repo unless you
do even fancier stuff (like git.git does).

> Additionally, I have some stuff currently in master that should not be in
> the 0.1 release, but should be in the 0.2 release. If I branch and then
> remove those files from the 0.1 branch, a merge will then remove them from
> master too? How do I keep them on master but delete them on 0.1 and still be
> able to merge from 0.1 into master?
>
> The only option I can think of are to do the merge, then revert the commit
> sha on master that does the delete.

That method will work fine.  You could also squash the revert commit
into your merge commit if you want, so that you never have a commit on
master that has the unwanted changes.  (That'll help when bisecting.)
To do that, just revert using "git revert -n", then commit it with
"git commit -a --amend".

Have fun,

Avery

  parent reply	other threads:[~2010-04-05 18:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-05 14:34 How to keep different version numbers in different branches? Stephen Kelly
2010-04-05 17:50 ` Christian MICHON
2010-04-05 18:15 ` Matthieu Moy
2010-04-05 18:51 ` Avery Pennarun [this message]
2010-04-05 19:22   ` Matthieu Moy
2010-04-05 19:36     ` Avery Pennarun
2010-04-06 10:06       ` Stephen Kelly
2010-04-06 11:29         ` Steven Michalske
2010-04-05 19:17 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=y2i32541b131004051151v8f4b8774q360c04ecdb046778@mail.gmail.com \
    --to=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=steveire@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).