git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] xdl_merge(): fix and simplify conflict handling
Date: Tue, 05 Dec 2006 14:54:39 -0800	[thread overview]
Message-ID: <7v3b7ueyxc.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0612052320320.28348@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Tue, 5 Dec 2006 23:24:41 +0100 (CET)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Speaking about a builtin merge: I like the fact that git-apply also works 
> outside of git repositories. It makes life easier to have a sane patcher 
> around.

Well, git-apply is designed as a better "patch", so it is
natural that it works in a non-git directory [*1*].

I am not sure what you mean by a builtin merge that works
outside the context of git.  Do you mean a pure RCS merge
replacement that takes three files and spits out the result in
one of them?  If so that would probably deserve to be a separate
command, because I do not think of a use for such a thing inside
git.  We've done merge-recursive.c already so it would not need
an external 'merge'.  If somebody is so inclined to to do the
"merge-resolve" strategy, I think the right way is to make a
single program that does what git-merge-index and merge-one-file
does without fork nor exec, so it would not need an external
'merge' either.

> Now, I'd like the same with git-diff, and an RCS merge replacement...

Yes, back when I was actively hacking git-diff, I dreamt about a
variant that takes two or more (non-git managed) directories and
does an equivalent of diff-tree with -M/-C/.../-c/--cc.  It
would be cool and useful.

I understand your aversion to new commands, but I do not think
you can avoid it if what you mean is an RCS merge replacement.

The diff that works on "two or more directories without anything
git" could be just a new option to "git diff", though.

But I am not going to do it myself; it's usually a lot faster
for me to just do "git init-db; git add . " on an extracted
tarball.

[Footnote]

*1* ... and that is one of the reasons why it does not even try
to read the index unless it is told to do so.

And we should not make it "detect we are in git repository" and
default to --index either.  Often running without --index is
useful inside a git repository.  I would say roughly 50% of the
time I use the command with --index and the rest without, so
"more often" argument unfortunately does not apply to "apply".

I wish it were "2% without --index, 98% with --index".  Then we
could easily say "add '--no-index if you do not want to".



  reply	other threads:[~2006-12-05 22:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-01  7:06 Resolving conflicts Wink Saville
2006-12-01  7:30 ` Alan Chandler
2006-12-01  7:41   ` Wink Saville
2006-12-01  8:10     ` Alan Chandler
2006-12-01  7:39 ` Linus Torvalds
2006-12-01  7:52   ` Wink Saville
2006-12-01  7:57     ` Linus Torvalds
2006-12-01  8:00       ` Linus Torvalds
2006-12-01  8:13         ` Alan Chandler
2006-12-01  8:22         ` Wink Saville
2006-12-01 23:47           ` Alan Chandler
2006-12-02  3:04             ` Wink Saville
2006-12-02  4:30     ` Linus Torvalds
2006-12-02  7:55       ` Junio C Hamano
2006-12-02 10:49         ` using xdl_merge(), was " Johannes Schindelin
2006-12-05 17:58           ` Ramsay Jones
2006-12-05 18:28             ` Linus Torvalds
2006-12-05 18:43               ` Junio C Hamano
2006-12-05 18:53               ` Johannes Schindelin
2006-12-05 19:50                 ` Junio C Hamano
2006-12-05 21:15                   ` [PATCH] xdl_merge(): fix and simplify conflict handling Johannes Schindelin
2006-12-05 22:10                     ` Junio C Hamano
2006-12-05 22:24                       ` Johannes Schindelin
2006-12-05 22:54                         ` Junio C Hamano [this message]
2006-12-05 22:27                       ` Jakub Narebski
2006-12-05 22:27                         ` Johannes Schindelin
2006-12-06  9:48                   ` using xdl_merge(), was Re: Resolving conflicts Junio C Hamano
2006-12-06 10:02                     ` Johannes Schindelin
2006-12-06 10:13                       ` Junio C Hamano
2006-12-06 10:47                         ` Johannes Schindelin
2006-12-05 18:36             ` Johannes Schindelin
2006-12-01  7:53   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v3b7ueyxc.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).