From: Jehan Bing <jehan@orb.com>
Date: Thu, 19 Jan 2012 21:07:29 GMT
Subject: Re: Rebase and incrementing version numbers
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:
> 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