git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH] merge: loosen overcautious "working file will be lost" check.

From
LTLuben Tuikov <ltuikov@yahoo.com>
Date
Oct 10, 2006, 00:59 UTC
Message-ID
<20061010005915.30066.qmail@web31813.mail.mud.yahoo.com>
In-Reply-To
<7vd5919g55.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
Show 37 quoted lines
> Ah, I misunderstood.  But then I do not understand why you see
> all 0 anywhere.  Merge base has the path, branch B has it, and
> trunk has it too; wouldn't it result in regular 3-way merge?
> 
> I understand you do _not_ even want a regular 3-way merge in
> this case, but that is a separate issue.  You could write a new
> merge strategy to traverse ancestry chain between the merge base
> and each heads you are merging and notice disappearance and
> reappearance of the path, but that would slow things down
> tremendously for normal case and I do not think it is worth it.
> 
> You would also have exactly the same issue if you do not remove
> and then add the file, but if your work on the branch involves a
> significant rewrite.  Depending on how good the rewrite is,
> bugfixes that happened on the trunk based on an ancient code may
> not even be needed (in other words, it would not apply cleanly
> anyway, but it does not matter -- the branch work is much better
> or has different set of problems that the trunk fix is
> irrelevant).
> 
> At that point, M1 would involve significant merge conflicts (and
> not all-0 which I am still puzzled about), but I suspect that
> the situation is obvious enough to the human (inspect git log
> branch...trunk output and the log somewhere had better indicate
> that the are unrelated), and the solution very much is different
> case-by-case (most likely the person who pulls branch into trunk
> would say "keep ours" for the path which would mean running "git
> cat-file :2:$path >$path", or say "we are not really ready to merge
> yet" and abort the entire merge; somebody on the trunk pulling
> from that branch might say "I want other smaller fixes but this
> total rewrite is not ready yet -- keep ours", or "now we know
> this is total rewrite and the small updates on the trunk does
> not matter -- take theirs and from now on we will improve on the
> work done on the branch").
> 
> So in short, I do not think there is a clear-cut improvement we
> can do to the tools to solve this.
Yes, I agree.
   Luben
Previous: Junio C HamanoNext: Linus Torvalds
Message 9 of 12 in “"fatal: Untracked working tree file 'so-and-so' would be overwritten by merge"”
  1. Linus TorvaldsOct 9, 2006
  2. Junio C HamanoOct 9, 2006
  3. Junio C HamanoOct 9, 2006
  4. merge: loosen overcautious "working file will be lost" check.Junio C Hamano, Oct 9, 2006
  5. Luben TuikovOct 9, 2006
  6. Junio C HamanoOct 9, 2006
  7. Luben TuikovOct 10, 2006
  8. Junio C HamanoOct 10, 2006
  9. Luben TuikovOct 10, 2006
  10. Linus TorvaldsOct 9, 2006
  11. Junio C HamanoOct 9, 2006
  12. Junio C HamanoOct 10, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.