Re: Rebase and incrementing version numbers
- From
- Jehan Bing <jehan@orb.com>
- Date
- Jan 19, 2012, 21:07 UTC
- Message-ID
- <4F188611.20205@orb.com>
- In-Reply-To
- <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
On 2012-01-19 09:20, Michael Nahas wrote:
Show 21 quoted lines
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.Maybe you can do something with "git rerere" (http://progit.org/2010/03/08/rerere.html). It supposed to automatically resolve known conflicts.
I've never used myself, I just know it exists, so I don't know it's usable in your case. But possibly you would pre-fill the rerere cache (assuming that the format is simple enough) then just run rebase.
Jehan