threads / discuss / 2775

Re: Wine + GIT

Subject: Re: Wine + GIT

## tl;dr

3 messages between Dec 8, 2005 and Dec 8, 2005.

replies: 2people: 3as markdown or json

linux@horizon.com· Dec 8, 2005, 07:30 UTC · lore
Show 5 quoted lines
> The paragraph "Once you have finished editting [sic]..." needs
> to be followed by:
> 
>	git-update-index those paths you hand corrected
>        git-commit

This is what happens when you have people too used to using the pre-porcelain plumbing.

How about just git-commit <the paths you hand corrected>

If you forget any, the commit will fail, but they will have been updated in the index, and you don't need to mention them again in the next attempt.

(Grump... I just noticed that the "recursive" merge stratgy *doesn't* generate a merged file containing conflict markers, at least not in the case I tried. Instead I get "a~HEAD" and "a~branch" files. Time to fix the docs...)

Fredrik Kuivinen· Dec 8, 2005, 09:29 UTC · re: linux@horizon.com · lore
On Thu, Dec 08, 2005 at 02:30:00AM -0500, linux@horizon.com wrote:
> (Grump... I just noticed that the "recursive" merge stratgy *doesn't*
> generate a merged file containing conflict markers, at least not in
> the case I tried.  Instead I get "a~HEAD" and "a~branch" files.
> Time to fix the docs...)

In the most common case, i.e., when you have a file 'a' in the common ancestor and 'a' have been modified in both A and B (where A and B are the branches we are going to merge) then the recursive strategy should generate a merged file with merge(1), which will produce conflict markers if there are conflicts. Any other behaviour is a bug.

However, in some other cases such as rename/rename, file/directory and add/add conflicts "a~A" and "a~B" will be created in the working directory. The recursive strategy will (or, is supposed to) tell you about such things, though.

- Fredrik
Junio C Hamano· Dec 8, 2005, 18:17 UTC · re: Fredrik Kuivinen · lore
Fredrik Kuivinen <freku045@student.liu.se> writes:
> However, in some other cases such as rename/rename, file/directory and
> add/add conflicts "a~A" and "a~B" will be created in the working
> directory. The recursive strategy will (or, is supposed to) tell you
> about such things, though.

I think one reason for this was because read-tree -m was the only way to create higher stage entries in the index, and after detecting renames, the recursive merge strategy did not have a good way to insert these as different stages in the index.

I extended update-index --index-info a little bit to let people insert higher stage entries in the index, so we could if we wanted to.

Here are the differences I know about between resolve and recursive other than ~A ~B:

 - in add/add case, merge-one-file tries to be cuter and leaves
   conflict-marked merge result.
 - content conflict in a renamed path gets its index entry
   collapsed, unlike other content conflicts.

← back to recent threads