git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Justin Frankel <justin@cockos.com>,
	git@vger.kernel.org, eyvind.bernhardsen@gmail.com,
	Junio C Hamano <gitster@pobox.com>,
	Avery Pennarun <apenwarr@gmail.com>
Subject: Re: [PATCH v2] git-merge: ignore space support
Date: Tue, 24 Aug 2010 22:57:18 -0500	[thread overview]
Message-ID: <20100825035718.GG11619@burratino> (raw)
In-Reply-To: <AANLkTint_aF2ZZue5PeSnaAVFa7v+b1diqm3xyvCQsVJ@mail.gmail.com>

Hi,

Bert Wesarg wrote:

> thanks for doing this. But is there any prior art for using NULL as
> 'use the default flags' in the project? For what I know, I can't think
> of an example. But my inside knowledge into git drifts slowly away.

Not that I know of for option flags.  Probably worth mentioning in the
API docs, which I conveniently forgot to update.

-- 8< --
Subject: ll-merge: document options struct

In particular, try to make it clear that most callers will want to
pass `NULL` as the `opts` parameter.

Cc: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
diff --git a/Documentation/technical/api-merge.txt b/Documentation/technical/api-merge.txt
index a7e050b..9dc1bed 100644
--- a/Documentation/technical/api-merge.txt
+++ b/Documentation/technical/api-merge.txt
@@ -17,6 +17,40 @@ responsible for a few things.
    path-specific merge drivers (specified in `.gitattributes`)
    into account.
 
+Data structures
+---------------
+
+* `mmbuffer_t`, `mmfile_t`
+
+These store data usable for use by the xdiff backend, for writing and
+for reading, respectively.  See `xdiff/xdiff.h` for the definitions
+and `diff.c` for examples.
+
+* `struct ll_merge_options`
+
+This describes the set of options the calling program wants to affect
+the operation of a low-level (single file) merge.  Some options:
+
+`virtual_ancestor`::
+	Behave as though this were part of a merge between common
+	ancestors in a recursive merge.
+	If a helper program is specified by the
+	`[merge "<driver>"] recursive` configuration, it will
+	be used (see linkgit:gitattributes[5]).
+
+`variant`::
+	Resolve local conflicts automatically in favor
+	of one side or the other (as in 'git merge-file'
+	`--ours`/`--theirs`/`--union`).  Can be `0`,
+	`XDL_MERGE_FAVOR_OURS`, `XDL_MERGE_FAVOR_THEIRS`, or
+	`XDL_MERGE_FAVOR_UNION`.
+
+`renormalize`::
+	Resmudge and clean the "base", "theirs" and "ours" files
+	before merging.  Use this when the merge is likely to have
+	overlapped with a change in smudge/clean or end-of-line
+	normalization rules.
+
 Low-level (single file) merge
 -----------------------------
 
@@ -28,15 +62,24 @@ Low-level (single file) merge
 	`.git/info/attributes` into account.  Returns 0 for a
 	clean merge.
 
-The caller:
+Calling sequence:
 
-1. allocates an mmbuffer_t variable for the result;
-2. allocates and fills variables with the file's original content
-   and two modified versions (using `read_mmfile`, for example);
-3. calls ll_merge();
-4. reads the output from result_buf.ptr and result_buf.size;
-5. releases buffers when finished (free(ancestor.ptr); free(ours.ptr);
-   free(theirs.ptr); free(result_buf.ptr);).
+* Prepare a `struct ll_merge_options` to record options.
+  If you have no special requests, skip this and pass `NULL`
+  as the `opts` parameter to use the default options.
+
+* Allocate an mmbuffer_t variable for the result.
+
+* Allocate and fill variables with the file's original content
+  and two modified versions (using `read_mmfile`, for example).
+
+* Call `ll_merge()`.
+
+* Read the merged content from `result_buf.ptr` and `result_buf.size`.
+
+* Release buffers when finished.  A simple
+  `free(ancestor.ptr); free(ours.ptr); free(theirs.ptr);
+  free(result_buf.ptr);` will do.
 
 If the modifications do not merge cleanly, `ll_merge` will return a
 nonzero value and `result_buf` will generally include a description of
@@ -47,18 +90,6 @@ The `ancestor_label`, `our_label`, and `their_label` parameters are
 used to label the different sides of a conflict if the merge driver
 supports this.
 
-The `flag` parameter is a bitfield:
-
- - The `LL_OPT_VIRTUAL_ANCESTOR` bit indicates whether this is an
-   internal merge to consolidate ancestors for a recursive merge.
-
- - The `LL_OPT_FAVOR_MASK` bits allow local conflicts to be automatically
-   resolved in favor of one side or the other (as in 'git merge-file'
-   `--ours`/`--theirs`/`--union`).
-   They can be populated by `create_ll_flag`, whose argument can be
-   `XDL_MERGE_FAVOR_OURS`, `XDL_MERGE_FAVOR_THEIRS`, or
-   `XDL_MERGE_FAVOR_UNION`.
-
 Everything else
 ---------------
 
-- 

  reply	other threads:[~2010-08-25  3:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23 20:59 [PATCH v2] git-merge: ignore space support Justin Frankel
2010-08-24  2:28 ` Jonathan Nieder
2010-08-24  3:39   ` [RFC/PATCH jn/merge-renormalize] merge-recursive: expose merge options for builtin merge Jonathan Nieder
2010-08-24 18:52     ` Junio C Hamano
2010-08-25  4:29       ` Jonathan Nieder
2010-08-24  4:30   ` [PATCH v2] git-merge: ignore space support Justin Frankel
2010-08-25  4:40     ` Jonathan Nieder
2010-08-25  7:22       ` Bert Wesarg
2010-08-25 15:51         ` Justin Frankel
2010-08-25 17:55           ` Junio C Hamano
2010-08-25 18:21             ` Justin Frankel
2010-08-24 19:01   ` Junio C Hamano
2010-08-24 20:01   ` Bert Wesarg
2010-08-25  3:57     ` Jonathan Nieder [this message]
2010-08-26  5:41 ` [PATCH v3 0/4] " Jonathan Nieder
2010-08-26  5:47   ` [PATCH 1/4] merge-recursive: expose merge options for builtin merge Jonathan Nieder
2010-08-26  5:49   ` [PATCH 2/4] ll-merge: replace flag argument with options struct Jonathan Nieder
2010-08-26 16:39     ` Junio C Hamano
2011-01-16  1:08       ` [PATCH v1.7.4-rc2] ll-merge: simplify opts == NULL case Jonathan Nieder
2010-08-26  5:50   ` [PATCH 3/4] merge-recursive --patience Jonathan Nieder
2010-08-26  5:51   ` [PATCH 4/4] merge-recursive: options to ignore whitespace changes Jonathan Nieder
2010-08-26 16:39     ` Junio C Hamano
2010-08-27  8:24       ` Jonathan Nieder

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=20100825035718.GG11619@burratino \
    --to=jrnieder@gmail.com \
    --cc=apenwarr@gmail.com \
    --cc=bert.wesarg@googlemail.com \
    --cc=eyvind.bernhardsen@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=justin@cockos.com \
    /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).