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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html