Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.

From: Peter Krefting <peter@softwolves.pp.se>
Date: Nov 12, 2009, 09:41 UTC
Message-ID: <alpine.DEB.2.00.0911121034580.8825@ds9.cixit.se>
In-Reply-To: <7vvdhggote.fsf@alter.siamese.dyndns.org>

Junio C Hamano:

> Perhaps there is some different issue at the root of this one.  Why would 
> anybody be tempted to say "-s ours" while running a rebase?  What did the 
> user want to see it do (instead of being a no-op because "ours" by 
> definition ignores the tree the change is replayed from)?

The reason why I wanted it in my initial example was due to me misreading the documentation of "ours".

My scenario is like this:

I have my web site under Git control (used to be CVS). Some parts of the web site is updated in-place (blog comments being saved as HTML directly in the web tree), whereas all other edits are done in clones of the repsository. These changes are then added and committed to the checked out web tree and pushed to the central repo.

In some cases, I wish to edit the comments in one of my clones (to remove spam not stopped by my spam filters, for instance), but editing these risks creating a conflict if there has been other changes in the mean time.

The web tree checkout script uses rebase to avoid introducing merge commits every time the blog comment is updated, as it in 99 % of cases is unrelated to any other changes found in the central repo.

In the few cases where the blog comment update from the web tree conflicts with a change in the central repo, I want the "git pull --rebase" call to overwrite any changes in the central repo with my changes in the web tree (meaning that I would later have to manually re-delete the spam comments, but I can live with that).

Show 7 quoted lines

> It is easy to dismiss it as a user misconception and it also is tempting 
> to think that it would be helped with updated description of "ours" to 
> dispel that misconception, but there may be some user wish that is totally 
> different from "ours merge" strategy but still can be validly labelled 
> using a word "ours" by somebody who does not know the way the word "ours" 
> is used in the git land, and satisfying that unknown user wish might be 
> the real solution to this issue.

Yes, I am apparently looking for something that is not available in the Git codebase yet. :-)

-- 
\\// Peter - http://www.softwolves.pp.se/