From: Junio C Hamano <junkio@cox.net>
To: Ben Lau <benlau@ust.hk>
Cc: git@vger.kernel.org
Subject: Re: Branches merging by only overwrite files
Date: Sun, 11 Dec 2005 01:33:18 -0800 [thread overview]
Message-ID: <7vbqzonfkx.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <439BE3B9.3040308@ust.hk> (Ben Lau's message of "Sun, 11 Dec 2005 16:30:49 +0800")
Ben Lau <benlau@ust.hk> writes:
> I am looking for a solution to merge two branches but do not perform
> file level merge. Instead, I wish the result file is the copy from any
> one of the branches.
It might be better to state why you need this first. It could
be that what you really want to solve is not related to merge at
all.
> For example, assumes it has two branches A and B, some of the files
> are modified in both of them. In this case, `/usr/bin/merge` could not
> be execated, it just have to choose the revision from branch A and
> discards all the changes from B. For the rest of files, it just simply
> choose the newest copy from A or B.
I wonder why you say "could not be executed". I take it to mean
you just do not want to even when it could.
Now, it is not clear if you always want copy from branch A and
not from branch B when both branches have the same path, or you
want to pick one at random between A and B. If branch A kept
the file intact and branch B modified it, what do you want to
happen? The default "merge" semantics in git (unless you are
using "ours" strategy) in such a case is always to take the
version from branch B. Is that consistent with what you want?
What do you exactly mean "newest copy from A or B"? What are
you basing the "newest" determination on? The commit date of A
and B commits, or the author date ot two?
Assuming that you can give reasonable and consistent answer to
the above question to define the semantics of your "new merge
algorithm", what you would do is to write a new script
git-merge-benlau to implement whatever semantics you picked.
You could model it after existing merge strategy, such as
git-merge-resolve.sh or git-merge-stupid.sh. Then you give the
new merge strategy to "git-merge" or "git-pull".
For example, if you want all the usual "trivial merges" to work
just like the default git merge algorithms, but always take
"our" version instead of running file-level merge when both
sides modified a file, then you start from a copy of
git-merge-stupid.sh, and replace "git-merge-one-file" with
"git-merge-one-file-benlau'. Copy "git-merge-one-file.sh" to
create another new script, "git-merge-one-file-benlau", and
replace this line:
merge "$src1" "$orig" "$src"
with
cat "$orig" >"$src1"
and you are done.
I outlined the above without knowing what you really want to
achieve, and I do not think the resulting merge strategy makes
much sense, but that is what I get form hacking without knowing
what you are really trying to do ;-).
next prev parent reply other threads:[~2005-12-11 9:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-11 8:30 Branches merging by only overwrite files Ben Lau
2005-12-11 9:33 ` Junio C Hamano [this message]
2005-12-11 11:15 ` Ben Lau
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vbqzonfkx.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=benlau@ust.hk \
--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.
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 NNTP newsgroup(s).