Re: more merge strategies : feature request

["Caleb Cushing" <xenoterracide@gmail.com>]

>  If you could come up with use-cases where each would be useful, I
>  think you'd have a much easier time to gain acceptance for your
>  suggestions. Right now, you're saying "I want a red button" but
>  you're not explaining what it's for.

conflict: when auto-merging isn't merging the way you want it too, but
you still want to see the diffs and handle them by hand. no commit
won't do this, it just doesn't commit. I've had 2 situations now where
git's fast-forward has overwritten changes in a branch I didn't want
it to, it would have been better if I could handle them by hand
without having to have 1 terminal open to the diff and the other open
to the editor to fix it. and yes git was right by it's perspective,
but the code it created was wrong by what I wanted and needed. I'm not
really sure what more of a use case is needed for this.

no-overwrite: it's basically my way of saying that even though git
thinks it's changes are newer and better than the ones in my branch I
know they aren't. I only want the new stuff from the other branch. In
the second situation mentioned above I have 2 branches that I like to
merge back and forth, each needing a specific set of changes to
certain files however most changes are shared. when I merge them I
often have to change those specific changes back, if it didn't
ovewrite them I wouldn't have a problem.

for example I'm tracking my dot files with git, in my main user
account I set umask 077 however in my web development account I need
umask 027 so apache can read the files I create. when I create a
change in webdev and need to merge it back into master it overwrites
the 077 umask which I then change back. when I create a change in
master that I want in webdev it then changes webdev's umask. very
annoying.

the other problem I had was where I'd overwritten a file in another
branch just for the point of merging it into the master branch so I
could see the differences, and handle them properly (as I see it)
unfortunately git felt that this file was newer and simply overwrote
the changes in master. this was incorrect they were simply different
versions of the same type of file, like comparing an httpd.conf from a
gentoo and another from a fedora system. I was merely trying to figure
the best of both files to get the results I wanted.

technically the conflict strategy I propose would be adequate for both
but the no-overwrite seems like a good idea as well.






-- 
Caleb Cushing