* [PATCH v3 2/2] Reduce parse-options.o dependencies
From: Dmitry Ivankov @ 2011-08-11 9:15 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, David Barr, Dmitry Ivankov
In-Reply-To: <1313054138-30885-1-git-send-email-divanorama@gmail.com>
Currently parse-options.o pulls quite a big bunch of dependencies.
his complicates it's usage in contrib/ because it pulls external
dependencies and it also increases executables size.
Split off less generic and more internal to git part of
parse-options.c to parse-options-cb.c.
Move prefix_filename function from setup.c to abspath.c. abspath.o
and wrapper.o pull each other, so it's unlikely to increase the
dependencies. It was a dependency of parse-options.o that pulled
many others.
Now parse-options.o pulls just abspath.o, ctype.o, strbuf.o, usage.o,
wrapper.o, libc directly and strlcpy.o indirectly.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
Makefile | 3 +-
abspath.c | 28 ++++++++++++
parse-options-cb.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++
parse-options.c | 121 --------------------------------------------------
setup.c | 28 ------------
5 files changed, 155 insertions(+), 150 deletions(-)
create mode 100644 parse-options-cb.c
diff --git a/Makefile b/Makefile
index 62ad0c2..7d47bdb 100644
--- a/Makefile
+++ b/Makefile
@@ -642,6 +642,7 @@ LIB_OBJS += pack-revindex.o
LIB_OBJS += pack-write.o
LIB_OBJS += pager.o
LIB_OBJS += parse-options.o
+LIB_OBJS += parse-options-cb.o
LIB_OBJS += patch-delta.o
LIB_OBJS += patch-ids.o
LIB_OBJS += path.o
@@ -2204,7 +2205,7 @@ test-delta$X: diff-delta.o patch-delta.o
test-line-buffer$X: vcs-svn/lib.a
-test-parse-options$X: parse-options.o
+test-parse-options$X: parse-options.o parse-options-cb.o
test-string-pool$X: vcs-svn/lib.a
diff --git a/abspath.c b/abspath.c
index 37287f8..f04ac18 100644
--- a/abspath.c
+++ b/abspath.c
@@ -139,3 +139,31 @@ const char *absolute_path(const char *path)
}
return buf;
}
+
+/*
+ * Unlike prefix_path, this should be used if the named file does
+ * not have to interact with index entry; i.e. name of a random file
+ * on the filesystem.
+ */
+const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
+{
+ static char path[PATH_MAX];
+#ifndef WIN32
+ if (!pfx_len || is_absolute_path(arg))
+ return arg;
+ memcpy(path, pfx, pfx_len);
+ strcpy(path + pfx_len, arg);
+#else
+ char *p;
+ /* don't add prefix to absolute paths, but still replace '\' by '/' */
+ if (is_absolute_path(arg))
+ pfx_len = 0;
+ else if (pfx_len)
+ memcpy(path, pfx, pfx_len);
+ strcpy(path + pfx_len, arg);
+ for (p = path + pfx_len; *p; p++)
+ if (*p == '\\')
+ *p = '/';
+#endif
+ return path;
+}
diff --git a/parse-options-cb.c b/parse-options-cb.c
new file mode 100644
index 0000000..c248f66
--- /dev/null
+++ b/parse-options-cb.c
@@ -0,0 +1,125 @@
+#include "git-compat-util.h"
+#include "parse-options.h"
+#include "cache.h"
+#include "commit.h"
+#include "color.h"
+#include "string-list.h"
+
+/*----- some often used options -----*/
+
+int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)
+{
+ int v;
+
+ if (!arg) {
+ v = unset ? 0 : DEFAULT_ABBREV;
+ } else {
+ v = strtol(arg, (char **)&arg, 10);
+ if (*arg)
+ return opterror(opt, "expects a numerical value", 0);
+ if (v && v < MINIMUM_ABBREV)
+ v = MINIMUM_ABBREV;
+ else if (v > 40)
+ v = 40;
+ }
+ *(int *)(opt->value) = v;
+ return 0;
+}
+
+int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ *(unsigned long *)(opt->value) = approxidate(arg);
+ return 0;
+}
+
+int parse_opt_color_flag_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ int value;
+
+ if (!arg)
+ arg = unset ? "never" : (const char *)opt->defval;
+ value = git_config_colorbool(NULL, arg, -1);
+ if (value < 0)
+ return opterror(opt,
+ "expects \"always\", \"auto\", or \"never\"", 0);
+ *(int *)opt->value = value;
+ return 0;
+}
+
+int parse_opt_verbosity_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ int *target = opt->value;
+
+ if (unset)
+ /* --no-quiet, --no-verbose */
+ *target = 0;
+ else if (opt->short_name == 'v') {
+ if (*target >= 0)
+ (*target)++;
+ else
+ *target = 1;
+ } else {
+ if (*target <= 0)
+ (*target)--;
+ else
+ *target = -1;
+ }
+ return 0;
+}
+
+int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+
+ if (!arg)
+ return -1;
+ if (get_sha1(arg, sha1))
+ return error("malformed object name %s", arg);
+ commit = lookup_commit_reference(sha1);
+ if (!commit)
+ return error("no such commit %s", arg);
+ commit_list_insert(commit, opt->value);
+ return 0;
+}
+
+int parse_opt_tertiary(const struct option *opt, const char *arg, int unset)
+{
+ int *target = opt->value;
+ *target = unset ? 2 : 1;
+ return 0;
+}
+
+int parse_options_concat(struct option *dst, size_t dst_size, struct option *src)
+{
+ int i, j;
+
+ for (i = 0; i < dst_size; i++)
+ if (dst[i].type == OPTION_END)
+ break;
+ for (j = 0; i < dst_size; i++, j++) {
+ dst[i] = src[j];
+ if (src[j].type == OPTION_END)
+ return 0;
+ }
+ return -1;
+}
+
+int parse_opt_string_list(const struct option *opt, const char *arg, int unset)
+{
+ struct string_list *v = opt->value;
+
+ if (unset) {
+ string_list_clear(v, 0);
+ return 0;
+ }
+
+ if (!arg)
+ return -1;
+
+ string_list_append(v, xstrdup(arg));
+ return 0;
+}
diff --git a/parse-options.c b/parse-options.c
index 7b061af..503ab5d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -3,7 +3,6 @@
#include "cache.h"
#include "commit.h"
#include "color.h"
-#include "string-list.h"
static int parse_options_usage(struct parse_opt_ctx_t *ctx,
const char * const *usagestr,
@@ -584,123 +583,3 @@ static int parse_options_usage(struct parse_opt_ctx_t *ctx,
return usage_with_options_internal(ctx, usagestr, opts, 0, err);
}
-
-/*----- some often used options -----*/
-#include "cache.h"
-
-int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)
-{
- int v;
-
- if (!arg) {
- v = unset ? 0 : DEFAULT_ABBREV;
- } else {
- v = strtol(arg, (char **)&arg, 10);
- if (*arg)
- return opterror(opt, "expects a numerical value", 0);
- if (v && v < MINIMUM_ABBREV)
- v = MINIMUM_ABBREV;
- else if (v > 40)
- v = 40;
- }
- *(int *)(opt->value) = v;
- return 0;
-}
-
-int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
- int unset)
-{
- *(unsigned long *)(opt->value) = approxidate(arg);
- return 0;
-}
-
-int parse_opt_color_flag_cb(const struct option *opt, const char *arg,
- int unset)
-{
- int value;
-
- if (!arg)
- arg = unset ? "never" : (const char *)opt->defval;
- value = git_config_colorbool(NULL, arg, -1);
- if (value < 0)
- return opterror(opt,
- "expects \"always\", \"auto\", or \"never\"", 0);
- *(int *)opt->value = value;
- return 0;
-}
-
-int parse_opt_verbosity_cb(const struct option *opt, const char *arg,
- int unset)
-{
- int *target = opt->value;
-
- if (unset)
- /* --no-quiet, --no-verbose */
- *target = 0;
- else if (opt->short_name == 'v') {
- if (*target >= 0)
- (*target)++;
- else
- *target = 1;
- } else {
- if (*target <= 0)
- (*target)--;
- else
- *target = -1;
- }
- return 0;
-}
-
-int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
-{
- unsigned char sha1[20];
- struct commit *commit;
-
- if (!arg)
- return -1;
- if (get_sha1(arg, sha1))
- return error("malformed object name %s", arg);
- commit = lookup_commit_reference(sha1);
- if (!commit)
- return error("no such commit %s", arg);
- commit_list_insert(commit, opt->value);
- return 0;
-}
-
-int parse_opt_tertiary(const struct option *opt, const char *arg, int unset)
-{
- int *target = opt->value;
- *target = unset ? 2 : 1;
- return 0;
-}
-
-int parse_options_concat(struct option *dst, size_t dst_size, struct option *src)
-{
- int i, j;
-
- for (i = 0; i < dst_size; i++)
- if (dst[i].type == OPTION_END)
- break;
- for (j = 0; i < dst_size; i++, j++) {
- dst[i] = src[j];
- if (src[j].type == OPTION_END)
- return 0;
- }
- return -1;
-}
-
-int parse_opt_string_list(const struct option *opt, const char *arg, int unset)
-{
- struct string_list *v = opt->value;
-
- if (unset) {
- string_list_clear(v, 0);
- return 0;
- }
-
- if (!arg)
- return -1;
-
- string_list_append(v, xstrdup(arg));
- return 0;
-}
diff --git a/setup.c b/setup.c
index 5ea5502..3463819 100644
--- a/setup.c
+++ b/setup.c
@@ -40,34 +40,6 @@ char *prefix_path(const char *prefix, int len, const char *path)
return sanitized;
}
-/*
- * Unlike prefix_path, this should be used if the named file does
- * not have to interact with index entry; i.e. name of a random file
- * on the filesystem.
- */
-const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
-{
- static char path[PATH_MAX];
-#ifndef WIN32
- if (!pfx_len || is_absolute_path(arg))
- return arg;
- memcpy(path, pfx, pfx_len);
- strcpy(path + pfx_len, arg);
-#else
- char *p;
- /* don't add prefix to absolute paths, but still replace '\' by '/' */
- if (is_absolute_path(arg))
- pfx_len = 0;
- else if (pfx_len)
- memcpy(path, pfx, pfx_len);
- strcpy(path + pfx_len, arg);
- for (p = path + pfx_len; *p; p++)
- if (*p == '\\')
- *p = '/';
-#endif
- return path;
-}
-
int check_filename(const char *prefix, const char *arg)
{
const char *name;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 1/2] parse-options: export opterr, optbug
From: Dmitry Ivankov @ 2011-08-11 9:15 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, David Barr, Dmitry Ivankov
In-Reply-To: <1313054138-30885-1-git-send-email-divanorama@gmail.com>
opterror and optbug functions are used by some of parsing routines
in parse-options.c to report errors and bugs respectively.
Export these functions to allow more custom parsing routines to use
them in a uniform way.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
parse-options.c | 4 ++--
parse-options.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 879ea82..7b061af 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -12,14 +12,14 @@ static int parse_options_usage(struct parse_opt_ctx_t *ctx,
#define OPT_SHORT 1
#define OPT_UNSET 2
-static int optbug(const struct option *opt, const char *reason)
+int optbug(const struct option *opt, const char *reason)
{
if (opt->long_name)
return error("BUG: option '%s' %s", opt->long_name, reason);
return error("BUG: switch '%c' %s", opt->short_name, reason);
}
-static int opterror(const struct option *opt, const char *reason, int flags)
+int opterror(const struct option *opt, const char *reason, int flags)
{
if (flags & OPT_SHORT)
return error("switch `%c' %s", opt->short_name, reason);
diff --git a/parse-options.h b/parse-options.h
index 05eb09b..59e0b52 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -165,6 +165,8 @@ extern NORETURN void usage_msg_opt(const char *msg,
const char * const *usagestr,
const struct option *options);
+extern int optbug(const struct option *opt, const char *reason);
+extern int opterror(const struct option *opt, const char *reason, int flags);
/*----- incremental advanced APIs -----*/
enum {
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 0/2] Reduce parse-options.o dependencies
From: Dmitry Ivankov @ 2011-08-11 9:15 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, David Barr, Dmitry Ivankov
This is a reroll of [1]. The main purpose is to make parse-options.o more
self-contained so that it at least doesn't pull any extlibs. Immediate usage
is for stuff in contrib (svn-fe). Distant application is that some day we could
publish this small library separately.
Mostly no changes since [1], just commit message line wrapping, fixup for a
Makefile typo and rebase on top of master (new parse_opt_string_list moved to
parse-options-cb.c too).
[1] http://thread.gmane.org/gmane.comp.version-control.git/176318/focus=176574
Dmitry Ivankov (2):
parse-options: export opterr, optbug
Reduce parse-options.o dependencies
Makefile | 3 +-
abspath.c | 28 ++++++++++++
parse-options-cb.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++
parse-options.c | 125 +---------------------------------------------------
parse-options.h | 2 +
setup.c | 28 ------------
6 files changed, 159 insertions(+), 152 deletions(-)
create mode 100644 parse-options-cb.c
--
1.7.3.4
^ permalink raw reply
* [BUG] git-svn: error importing git repository in svn when first git commit was empty
From: s b @ 2011-08-11 9:13 UTC (permalink / raw)
To: git
Couldn't find any bugtracker for git so I supposed it would be ok to
post the bug here.
# Situation:
I usually start my projects with git as it's quick and simple to track
modifications. If the code grows and is of any interest for my work I
push it to the corporate svn. I usually use this tutorial
(http://eikke.com/importing-a-git-tree-into-a-subversion-repository/)
which makes it a simple thing to do.
Some time ago I started having a first empty commit in my git
repository using 'git commit --allow-empty' as I read (can't remember
where) it could help for some cases. I don't have need for those edge
cases yet but remember thinking I could need them in the future.
# Problem:
When your first git commit is empty, git-svn fails with the following message :
$ git svn dcommit
Committing to https://svn/repo/trunk ...
No changes
71fb4051d840e27a43b87b071ccc7ea70bd0c5e8~1 ==
71fb4051d840e27a43b87b071ccc7ea70bd0c5e8
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
Unable to extract revision information from commit
867ee195730507fb769e794eb4abe09d0e2e7c8f~1
At the same time, it also completely breaks the logs.
# How to reproduce: (the svn repository just has one commit for usual
trunk/branches/tags folders)
$ mkdir foobar
$ cd foobar/
$ git init
Initialized empty Git repository in /home/hr/tmp/foobar/.git/
$ git commit --allow-empty -m "Project init"
[master (root-commit) 0f1e71a] Project init
$ echo "foo" > test.txt; git add test.txt; git commit -m "Initial version"
[master 119fc0a] Initial version
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test.txt
$ echo "bar" > test.txt; git commit test.txt -m "Second version"
[master 77b2681] Second version
1 files changed, 1 insertions(+), 1 deletions(-)
$ git svn init -s https://code/svn/foobar/
$ git svn fetch
r1 = 8bc83d5d63b4191509d29aa90e35e24edba393c1 (refs/remotes/trunk)
$ git log --pretty=oneline master
77b268140a03cbe98215ea160704ba14ce79e096 Second version
119fc0a55d1eb851fcedfe0bdc6de3c1ab047601 Initial version
0f1e71a283d7b4b27d23debaac091b654d495124 Project init
$ git show-ref trunk
8bc83d5d63b4191509d29aa90e35e24edba393c1 refs/remotes/trunk
$ echo "0f1e71a283d7b4b27d23debaac091b654d495124
8bc83d5d63b4191509d29aa90e35e24edba393c1" >> .git/info/grafts
$ git log --pretty=oneline
77b268140a03cbe98215ea160704ba14ce79e096 Second version
119fc0a55d1eb851fcedfe0bdc6de3c1ab047601 Initial version
0f1e71a283d7b4b27d23debaac091b654d495124 Project init
8bc83d5d63b4191509d29aa90e35e24edba393c1 * Init project, mkdir trunk branches ta
$ git svn dcommit
Committing to https://code/svn/foobar/trunk ...
No changes
0f1e71a283d7b4b27d23debaac091b654d495124~1 ==
0f1e71a283d7b4b27d23debaac091b654d495124
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
Unable to extract revision information from commit
119fc0a55d1eb851fcedfe0bdc6de3c1ab047601~1
$ git log
commit 8bc83d5d63b4191509d29aa90e35e24edba393c1
Author: root <root@e969a563-e91d-45ef-9946-abb13e32418c>
Date: Thu Jul 7 06:40:59 2011 +0000
* Init project, mkdir trunk branches tags.
git-svn-id: https://code/svn/foobar/trunk@1 e969a563-e91d-45ef-9946-abb13e32
# Solution:
Not really a solution but instead of using the first commit for the
grafts, I use the second one (that is non empty).
Hope this can help getting a better git-svn!!
Stefan
--
Stefan Berder Mail: sberder#gmail.com
/(bb|[^b]{2})/
^ permalink raw reply
* Re: git-mergetool: wrap tools with 3 files only to use the BASE file instead of MERGED
From: Jonathan Nieder @ 2011-08-11 8:49 UTC (permalink / raw)
To: David Aguilar; +Cc: Tanguy Ortolo, git, Sebastian Schuberth, Charles Bailey
In-Reply-To: <20110811083835.GA29507@gmail.com>
David Aguilar wrote:
> I think it sounds like a good thing for certain tools.
> Sebastian mentioned it being fine in ecmerge and bc3.
> xxdiff also lets you specify the output file, so it
> probably wouldn't need it either, I think.
At the risk of taking away the itch for a good feature: meld joined
the crowd of tools with -o to specify an output file in v1.5.0.
http://thread.gmane.org/gmane.comp.gnome.meld.general/1270
^ permalink raw reply
* Re: git-mergetool: wrap tools with 3 files only to use the BASE file instead of MERGED
From: David Aguilar @ 2011-08-11 8:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Tanguy Ortolo, git, Sebastian Schuberth, Charles Bailey
In-Reply-To: <20110810161211.GC4076@elie.gateway.2wire.net>
On Wed, Aug 10, 2011 at 11:12:11AM -0500, Jonathan Nieder wrote:
> (+cc: some relevant people)
> Hi,
>
> Tanguy Ortolo wrote[1]:
>
> > git-mergetool ideally uses tools that work with 4 files: BASE, LOCAL,
> > REMOTE, which are the usual original and two new version of the file,
> > and MERGED, which is where the tool is supposed to write the result of
> > the merge.
> >
> > The problem is that most tools, at least graphical ones, specifically
> > meld, can only work with three files, as they save the result to the
> > original file.
> >
> > git-mergetool currently handles this situation by passing MERGED LOCAL
> > REMOTE to the tool. This could be fine, but unfortunately MERGE contains
> > the conflicts, formatted for manual resolution, so it is not really
> > appropriate as an original file.
> >
> > I think it would be better to wrap such merge tools by:
> > 1. passing them BASE LOCAL REMOTE;
> > 2. checking whether or not BASE hase been modified:
> > * if it has, then copying it to MERGED,
> > * if it has not, exiting with return code 1 (merge failed).
> > This check can be by either saving and comparing the mdate, or perhaps
> > the SHA-1 hash of the BASE file.
> >
> > If this sounds good enough, I can dive into git-mergetoo--lib and
> > implement it. In the meantime, here is an example of a custom merge tool
> > that wraps meld for that purpose.
>
> I think you forgot to include the example. Anyway, at first glance it
> sounds like a sensible idea. David et al: thoughts?
I think it sounds like a good thing for certain tools.
Sebastian mentioned it being fine in ecmerge and bc3.
xxdiff also lets you specify the output file, so it
probably wouldn't need it either, I think.
If the patch touches individual tools that need it, e.g. meld,
I say go for it.
> Regards,
> Jonathan
>
> [1] http://bugs.debian.org/637355
cheers,
--
David
^ permalink raw reply
* Suggestions to make git easier to understand
From: Philippe Vaucher @ 2011-08-11 7:48 UTC (permalink / raw)
To: git
Hello,
The other day I fell on this post:
http://raflabs.com/blogs/silence-is-foo/2011/04/07/staging-area-index-cache-git/
I thought it made some good points about git being kinda confusing,
for example sentences like "Changed but not updated" in git status
could use a better sentence like "Changed but not in the index". Maybe
--cached could have an alias like --index-only for things to be more
intuitive as well.
`git rm --index-only somefile` is more understandable than `git rm
--cached somefile` imho.
Also, in ls-files, --stage could maybe use an alias like --contents
for it to be more self-explanatory.
Philippe
p.s: not saying we should absolutly do what I suggest, but rather
start a discussion about how to make git's terminology more intuitive
and self-explanatory.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #02; Mon, 8)
From: Jakub Narebski @ 2011-08-11 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4alrmjd.fsf@alter.siamese.dyndns.org>
On Wed, 10 Aug 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> --------------------------------------------------
>>> [Graduated to "master"]
>>
>>> * jn/gitweb-config-list-case (2011-07-31) 1 commit
>>> (merged to 'next' on 2011-08-01 at 9268738)
>>> + gitweb: Git config keys are case insensitive, make config search too
>>>
>>> * jn/gitweb-system-config (2011-07-24) 1 commit
>>> (merged to 'next' on 2011-08-01 at 4941e45)
>>> + gitweb: Introduce common system-wide settings for convenience
>>
>> What happened with "[PATCH/RFC 0/6] gitweb: Improve project search"
>> series from 29.07.2011?
>
> I dunno--you tell me ;-)
>
> You solicited for comments, presumably you collected them and have been
> preparing a re-roll based on the comments? Or perhaps nobody was
> interested in these changes and you dropped it?
I did not get any responses, unfortunately.
The interest in gitweb patches waxes and wanes, and it looks like it is
time for waning interest. It is a bit frustrating that there is no
response even from people who use gitweb for web interface to hosting
git repositories... but perhaps it is bad time of year.
Anyway, I plan on re-rolling search improvement series, checking if
search is covered by testsuite (IIRC it is).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2] t3900: do not reference numbered arguments from the test script
From: Jonathan Nieder @ 2011-08-11 7:11 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jeff King, git, Michael J Gruber, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4E437F4C.4020305@viscovery.net>
Johannes Sixt wrote:
> Remove it because -m is optional and the test case
> does not check for it. There are tests in t7500 that check combinations of
> --squash and -m.
That's a comfort. Looks obviously good to me, fwiw.
^ permalink raw reply
* [PATCH v2] t3900: do not reference numbered arguments from the test script
From: Johannes Sixt @ 2011-08-11 7:05 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, git, Michael J Gruber, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20110809153638.GA15687@sigill.intra.peff.net>
From: Johannes Sixt <j6t@kdbg.org>
The call to test_expect_success is nested inside a function, whose
arguments the test code wants to access. But it is not specified that any
unexpanded $1, $2, $3, etc in the test code will access the surrounding
function's arguments. Rather, they will access the arguments of the
function that happens to eval the test code.
In this case, the reference is intended to supply '-m message' to a call of
'git commit --squash'. Remove it because -m is optional and the test case
does not check for it. There are tests in t7500 that check combinations of
--squash and -m.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 8/9/2011 17:36, schrieb Jeff King:
> Hmm. Isn't t3900 already broken, even without this patch? It does
> something like this:
>
> foo() {
> test_expect_success 'bar' 'echo $3'
> }
Yes, it's broken and this patch just removes the reference.
t/t3900-i18n-commit.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index c06a5ee..1f62c15 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -147,7 +147,7 @@ test_commit_autosquash_flags () {
git commit -a -m "intermediate commit" &&
test_tick &&
echo $H $flag >>F &&
- git commit -a --$flag HEAD~1 $3 &&
+ git commit -a --$flag HEAD~1 &&
E=$(git cat-file commit '$H-$flag' |
sed -ne "s/^encoding //p") &&
test "z$E" = "z$H" &&
@@ -160,6 +160,6 @@ test_commit_autosquash_flags () {
test_commit_autosquash_flags eucJP fixup
-test_commit_autosquash_flags ISO-2022-JP squash '-m "squash message"'
+test_commit_autosquash_flags ISO-2022-JP squash
test_done
--
1.7.6.1618.gc932c
^ permalink raw reply related
* Documenting the 'rebase -i' workflow
From: Ramkumar Ramachandra @ 2011-08-11 7:00 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder, Johannes Schindelin
Hi,
I used to find it hard to resolve conflicts during complex interactive
rebases, and I asked Jonathan for help off-list. I found the response
very useful. I thought I should reproduce the original email here so
that everyone on the list can benefit from it. Please feel free to
add to it.
Also, we should document this somewhere.
-- 8< --
Ramkumar Ramachandra wrote:
> How did you manage to make the rebase look so effortless? I tried it
> too, but I always end up messing up the conflict resolution, and
> aborting many times before I get it right. Even after that, I run
> tests on all the patches and correct the pending mistakes by hand.
True, this workflow is underdocumented. The most important details
are
[merge] conflictstyle = diff3
[rerere] enabled
in ~/.gitconfig. I used to use "git checkout --conflict=diff3"
explicitly instead, which also works.
If you are lucky, a conflict hunk will look something like this:
<<<<<<< ours
A
B
C
||||||| parent of theirs
B
=======
B
C
D
>>>>>>> theirs
It can be merged blindly by following the rule "whenever a feature
is the same between the ancestor and one of the competing versions,
delete it from them". For example, both the ancestor and "theirs"
have 'B', so:
<<<<<<< ours
A
B
C
||||||| parent of theirs
=======
C
D
>>>>>>> theirs
Our side and their side both added C independently and from the
context we know that a second 'C' would be redundant. So we are ready
to resolve the conflict after thinking a little.
A
B
C
D
Unfortunately sometimes the diff3 conflict style makes conflicts huge
and unmanageable. That's no good. I dream of a conflict style that
would show "our" version and the patch hunk to apply. Since that
doesn't exist yet, often a good strategy is to fake it by looking at
the patch directly. For example, patches to ChangeLog files rarely
merge cleanly and the conflicts don't tend to be very useful.
git checkout HEAD ChangeLog
vim ChangeLog
:split .git/rebase-merge/patch
"git add" is used to mark good changes and "git diff" to see what's
left to do. When ready, I build, run some simple tests, "git diff
--cached", "git rebase -i --continue", flinch at how git 1.7.6 broke
my muscle memory, and "git rebase --continue".
Usually I try to only make a single change in an interactive rebase
and let it ripple through, then rinse and repeat. If something goes
wrong, I can "git rebase --abort" and previous unrelated changes are
not lost.
After a rebase, I use "git diff" to compare to the previous version,
to make sure the changes accumulated are good and nothing was lost.
Summary:
- conflictstyle=diff3 makes 3-way merging require way less thought
and history mining. I don't know how I coped with
conflictstyle=merge.
- For thorny cases, "git checkout --ours file" unapplies the patch.
Then one can
(a) apply the patch by hand, if it is short.
(b) fix up the patch by hand and apply it with "git apply", if
it is long.
The patch is in .git/rebase-merge/patch.
- "git rerere forget" is a lifesaver.
- Check for sanity at each step (by running manual or automatic
tests) before continuing.
- Inspect with "git log -p" and by diffing against a merge of the
pre-rebase state with the new upstream when done.
^ permalink raw reply
* Re: [PATCH 3/5] revert: Allow mixed pick and revert instructions
From: Ramkumar Ramachandra @ 2011-08-11 6:52 UTC (permalink / raw)
To: Jonathan Nieder, Junio C Hamano
Cc: Git List, Christian Couder, Daniel Barkalow, Jeff King
In-Reply-To: <20110810151527.GC31315@elie.gateway.2wire.net>
Hi,
On a note unrelated to Jonathan's review, I noticed some weird
behavior while playing with my new series: when picking a commit
that's already picked, all the code until run_git_commit runs just
fine. Then 'git commit' fails because it's an empty commit.
Unfortunately, run_git_commit returns a positive return status from
do_pick_commit which is against the convention, leading the
cherry-picking machinery to think that a conflict was encountered.
This is highly confusing from the end-user's perspective. The
operation has suddenly stopped without an error, and '--continue'
seems to continue the operation. What is going on, right?
I was hesitant to send out the patch to make run_git_commit return an
error, because it breaks some tests in t3505-cherry-pick-empty.sh.
However, the problem is getting on my nerves now, and I believe that
the patch does the Right Thing (TM), even if it means that we have to
change the tests in t3505-cherry-pick-empty.sh. Thoughts?
-- 8< --
Subject: [PATCH] revert: Classify failure to run 'git commit' as an error
Since a93d2a (revert: Propagate errors upwards from do_pick_commit,
2011-05-20), do_pick_commit differentiates between conflicts and
errors using the signed-ness of its return status. Unfortunately, it
returns the return status from 'git commit' when it fails to run it,
breaking this convention. Change this so that any non-zero return
status from run_git_commit is classified as an error.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
builtin/revert.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 8b452e8..fcd4f3a 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -603,7 +603,9 @@ static int do_pick_commit(struct commit *commit,
struct replay_opts *opts)
rerere(opts->allow_rerere_auto);
} else {
if (!opts->no_commit)
- res = run_git_commit(defmsg, opts);
+ if (run_git_commit(defmsg, opts))
+ return error(_("Failed to run 'git
commit': %s"),
+ sha1_to_hex(commit->object.sha1));
}
free_message(&msg);
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* Re: [PATCH 4/5] sequencer: Expose code that handles files in .git/sequencer
From: Ramkumar Ramachandra @ 2011-08-11 6:27 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110811062236.GA27394@elie.gateway.2wire.net>
Hi Jonathan,
Jonathan Nieder writes:
> I'm a very pragmatic person: as long as the code and history are
> readable and behave reasonably well, I'm happy.
Thanks for clarifying; I'll get to work right away.
-- Ram
^ permalink raw reply
* Re: [PATCH 4/5] sequencer: Expose code that handles files in .git/sequencer
From: Jonathan Nieder @ 2011-08-11 6:22 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <CALkWK0kxtyPABBUOrXtKDxPCBKt3CynoP4Fm8f_+C1ymkLTo-w@mail.gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> Are you certain about pick_revisions? I've copied over the function
> here for your reference. My issue is that it's too specific
> cherry-pick/ revert:
I'm a very pragmatic person: as long as the code and history are
readable and behave reasonably well, I'm happy.
So in this particular case, why not expose pick_revisions, with some
name like revert_or_cherry_pick? It would be readable and behave
reasonably well. :) A theoretical other caller could save a fork
by calling revert_or_cherry_pick instead of forking a subprocess to
do the same.
[...]
> 2. You mentioned multiple entry points earlier, and that's something
> I've been meaning to do: In the long run
Sure, and that still seems like a good idea in the long run.
But as long as we are not closing doors, ideas about the long run
should not get in the way of getting work done today.
Hoping that is clearer.
Jonathan
^ permalink raw reply
* Re: [PATCH 4/5] sequencer: Expose code that handles files in .git/sequencer
From: Ramkumar Ramachandra @ 2011-08-11 6:16 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110810155332.GB4076@elie.gateway.2wire.net>
Hi Jonathan,
Jonathan Nieder writes:
> Well, "beautiful public API" means "just what cmd_cherry_pick and
> cmd_revert needs", right? So I'd suggest:
Yes, but I don't want to put stuff that's too specific to cherry-pick/
revert in the sequencer.
> [...]
> Luckily step (1) is already done. The functions are parse_args()
> and pick_revisions() (though they could presumably use less generic
> names).
Are you certain about pick_revisions? I've copied over the function
here for your reference. My issue is that it's too specific
cherry-pick/ revert:
1. See what walk_revs_populate_todo does: It takes all the operands
and fills up "pick" as the operator. Why would any other caller want
to do this?
2. You mentioned multiple entry points earlier, and that's something
I've been meaning to do: In the long run, I don't want callers to fill
up an opts structure to specify the subcommand! That'd be butt-ugly.
-- 8< --
static int pick_revisions(struct replay_opts *opts)
{
struct replay_insn_list *todo_list = NULL;
unsigned char sha1[20];
read_and_refresh_cache(opts);
/*
* Decide what to do depending on the arguments; a fresh
* cherry-pick should be handled differently from an existing
* one that is being continued
*/
if (opts->subcommand == REPLAY_RESET) {
remove_sequencer_state(1);
return 0;
} else if (opts->subcommand == REPLAY_CONTINUE) {
if (!file_exists(git_path(SEQ_TODO_FILE)))
goto error;
sequencer_read_opts(&opts);
sequencer_read_todo(&todo_list);
/* Verify that the conflict has been resolved */
if (!index_differs_from("HEAD", 0))
todo_list = todo_list->next;
} else {
/*
* Start a new cherry-pick/ revert sequence; but
* first, make sure that an existing one isn't in
* progress
*/
walk_revs_populate_todo(&todo_list, opts);
if (sequencer_create_dir() < 0) {
error(_("A cherry-pick or revert is in progress."));
advise(_("Use --continue to continue the operation"));
advise(_("or --reset to forget about it"));
return -1;
}
if (get_sha1("HEAD", sha1)) {
if (opts->action == REPLAY_REVERT)
return error(_("Can't revert as initial commit"));
return error(_("Can't cherry-pick into empty head"));
}
sequencer_save_head(sha1_to_hex(sha1));
sequencer_save_opts(opts);
}
return pick_commits(todo_list, opts);
error:
return error(_("No %s in progress"), action_name(opts));
}
^ permalink raw reply
* Re: About git-diff
From: Junio C Hamano @ 2011-08-11 4:49 UTC (permalink / raw)
To: Luiz Ramos; +Cc: Andreas Schwab, git
In-Reply-To: <1313024025.97405.YahooMailClassic@web121818.mail.ne1.yahoo.com>
Luiz Ramos <luizzramos@yahoo.com.br> writes:
> Given this, I'd suggest to change the inline documentation of git-diff (git help diff). In the version of my machine (1.7.4.4), it's like that:
>
> (snip)
> ...
> git diff [--options] <commit> [--] [<path>...]
> This form is to view the changes you have in your working tree
> relative to the named <commit>. You can use HEAD to compare it with
> the latest commit, or a branch name to compare with the tip of a
> different branch.
> ...
Strictly speaking, "the changes you have in your working tree" may be what
is confusing. Your working tree does _not_ have "changes"; it only has
"contents". Changes are perceived only if you compare it with something
else, as their _difference_.
This operation compares "the contents of tracked files in your working
tree" with "the contents recorded in the named <commit>"---the result of
this comparison comparison matches what humans perceive as "changes".
So perhaps updating the first sentence with:
Compare the contents of tracked files in your working tree with
what is recorded in the named <commit>.
would be all that is necessary. I didn't bother to look but I suspect we
have a simlar description for "git diff [--options] [--] [<path>...]"
form, and it should be updated in a similar way (the only difference is
that it compares "with what is recorded in the index").
^ permalink raw reply
* Re: About git-diff
From: Luiz Ramos @ 2011-08-11 0:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2hb5pb3pe.fsf@igel.home>
--- Em qua, 10/8/11, Andreas Schwab <schwab@linux-m68k.org> escreveu:
> De: Andreas Schwab <schwab@linux-m68k.org>
> Assunto: Re: About git-diff
> Para: "Luiz Ramos" <luizzramos@yahoo.com.br>
> Cc: git@vger.kernel.org
> Data: Quarta-feira, 10 de Agosto de 2011, 14:01
> Luiz Ramos <luizzramos@yahoo.com.br>
> writes:
>
> > If I run:
> >
> > $ git diff b2 ./
> >
> > that is, the "non-cached" version, it will show the
> same results. This is
> > confusing IMHO, because the git-diff manual suggests
> that invocation
> > should render the difference between the named tree
> contents and the
> > working directory. In the working directory, only to
> recall, file_1 and
> > file_2 are both present and with good versions. In my
> understanding, the
> > command should report that file_1 is in excess in the
> working directory,
> > relative to b2, and report nothing about file_2, as it
> is in the same
> > version as the sample in the tree b2.
>
> Since file_2 is not tracked in the current branch, its
> existence in the
> directory is ignored.
>
> > This doesn't seem to be the same thing git-diff-index
> manual states,
> > however. The manual gets more deep into the details,
> and it's not so easy
> > to understand it unless one knows a lot of the inner
> commands, which does
> > not apply to me. In my basic reading, it seems that
> behind the scenes,
> > git-diff-index is what is run in this case, and the
> fact that file_2 is
> > not in the tree associated to b1 is a relevant thing
> in this case. So, the
> > index seem to matter, and if I try to do it, a
> previous "git update-index"
> > should be done.
>
> It's not the index, but the current tree that matters:
>
> show me the
> differences between HEAD and the currently checked out
> tree - index
> contents _and_ files that aren't up-to-date
>
> Note that it talks about "files that aren't
> up-to-date". Thus untracked
> files are not considered.
>
Ok, understood.
Given this, I'd suggest to change the inline documentation of git-diff (git help diff). In the version of my machine (1.7.4.4), it's like that:
(snip)
...
git diff [--options] <commit> [--] [<path>...]
This form is to view the changes you have in your working tree
relative to the named <commit>. You can use HEAD to compare it with
the latest commit, or a branch name to compare with the tip of a
different branch.
...
(snip)
A unadvised reader could understand that the comparison is between <commit> and the working directory, as if <commit> was the current branch, plainly stated. In fact, there is no mention to the current branch, or to the files being tracked or not, except for the option of mentioning HEAD as the <commit> to be taken into account.
If you'd accept a small contribution of yours truly, here's amy suggestion for this text:
...
git diff [--options] <commit> [--] [<path>...]
This form is to view the changes you have in your working tree
relative to the named <commit>. You can use HEAD to compare it with
the latest commit, or a branch name to compare with the tip of a
different branch. Note, however, that files untracked in the
current branch are handled as if they are missing in the working
directory. Check out git-diff-index documentation for further
information.
...
It's not in the patch format, but if you'd like the suggestion, there is no problem in re-sending it as a formatted patch.
Thanks,
Luiz
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
> 44D5 214B 8276 4ED5
> "And now for something completely different."
>
^ permalink raw reply
* Re: git apply-diff / am cannot deal with patches generated with git diff/format-patch --noprefix?
From: Junio C Hamano @ 2011-08-10 22:32 UTC (permalink / raw)
To: marcel partap; +Cc: git
In-Reply-To: <4E43053C.5080407@gmx.net>
marcel partap <mpartap@gmx.net> writes:
> ...at least it seems so. -p0 does not help:
>> fatal: git apply: bad git-diff - inconsistent old filename on line xx
Hmm, does not reproduce for me.
$ git checkout v1.7.6 ;# or whatever random commit I had at hand
$ git show --no-prefix >P.diff
$ grep "^diff --git" P.diff
diff --git Documentation/RelNotes/1.7.6.txt Documentation/RelNotes/1.7.6.txt
diff --git Documentation/git.txt Documentation/git.txt
diff --git GIT-VERSION-GEN GIT-VERSION-GEN
$ git checkout HEAD^
$ git apply -p0 <P.diff
$ git diff v1.7.6 ; echo nothing
nothing
$ git diff --stat
Documentation/RelNotes/1.7.6.txt | 8 +-------
Documentation/git.txt | 5 +++++
GIT-VERSION-GEN | 2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
^ permalink raw reply
* git apply-diff / am cannot deal with patches generated with git diff/format-patch --noprefix?
From: marcel partap @ 2011-08-10 22:25 UTC (permalink / raw)
To: git
...at least it seems so. -p0 does not help:
> fatal: git apply: bad git-diff - inconsistent old filename on line xx
So it is not possible to have diff.noprefix set as default and generate
patches that can be circulated? Or am i missing something there?
#regards/marcel
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #02; Mon, 8)
From: Junio C Hamano @ 2011-08-10 21:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ty9p1oaa.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> --------------------------------------------------
>> [Graduated to "master"]
>
>> * jn/gitweb-config-list-case (2011-07-31) 1 commit
>> (merged to 'next' on 2011-08-01 at 9268738)
>> + gitweb: Git config keys are case insensitive, make config search too
>>
>> * jn/gitweb-system-config (2011-07-24) 1 commit
>> (merged to 'next' on 2011-08-01 at 4941e45)
>> + gitweb: Introduce common system-wide settings for convenience
>
> What happened with "[PATCH/RFC 0/6] gitweb: Improve project search"
> series from 29.07.2011?
I dunno--you tell me ;-)
You solicited for comments, presumably you collected them and have been
preparing a re-roll based on the comments? Or perhaps nobody was
interested in these changes and you dropped it?
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: René Scharfe @ 2011-08-10 19:55 UTC (permalink / raw)
To: htl10; +Cc: Jeff King, git
In-Reply-To: <1312945714.193.YahooMailClassic@web29510.mail.ird.yahoo.com>
Am 10.08.2011 05:08, schrieb Hin-Tak Leung:
> --- On Sat, 6/8/11, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>
>> That doesn't sound good. Looking at the R source,
>> however, I can see
>> that they use a two different algorithms to compute the
>> checksum than
>> the one specified by POSIX (even though I don't fully
>> understand what it
>> actually is their doing, since I don't know R). So
>> worry too much about
>> the warning; as long e.g. "tar tf <file>" doesn't
>> complain your archive
>> should be intact.
>
> I filed the bug,
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14654
> and they have fixed it bug has a few comments to make:
>
> ---------------
> Fixed in R-devel and patched (your checksum field has more than 6 digits which
> is highly unusual [since it can't be larger than 6 digits] but technically
> allowable).
>
> I should add that the original tar format mandated that checksums are
> terminated by NUL SPACE, so in that sense your tar file is invalid (there can't
> be more than 6 digits since the checksum field consists of 8 bytes). untar2
> will now be more forgiving, but whatever program created that tar file should
> be fixed.
> -----------------
That's good to read, thanks.
> Please feel free to respond directly at the R bug tracking system, or
> I can cut-and-paste bits of e-mails also...
I don't think any further action is needed; there's nothing to fix.
There is not such thing as "the" tar archive format -- there are
multiple dialects. While compatibility is important, ancient versions
of tar haven't been a target for git archive so far.
It creates files in the same format as POSIX pax. I called it "tar"
instead of "pax" because the result can be extracted using GNU tar,
bsdtar, 7-Zip etc., supports long file names as well as symlinks -- and
I had never heard of anyone actually using the pax command, while tar is
quite common. (And pax doesn't restrict the checksum to six digits.)
It would be interesting to know which other tar extractor insists on the
checksum being stored as six zero-padded octal digits followed by NUL
and SPACE instead of seven zero-padded octal digits followed by NUL,
though. (Side note: I guess the reason for using only six digits is
that this enough for even the biggest possible header checksum.)
René
^ permalink raw reply
* Re: git-mergetool: wrap tools with 3 files only to use the BASE file instead of MERGED
From: Sebastian Schuberth @ 2011-08-10 19:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Tanguy Ortolo, git, David Aguilar, Charles Bailey
In-Reply-To: <20110810161211.GC4076@elie.gateway.2wire.net>
On Wed, Aug 10, 2011 at 18:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> I think it would be better to wrap such merge tools by:
>> 1. passing them BASE LOCAL REMOTE;
>> 2. checking whether or not BASE hase been modified:
>> * if it has, then copying it to MERGED,
>> * if it has not, exiting with return code 1 (merge failed).
>> This check can be by either saving and comparing the mdate, or perhaps
>> the SHA-1 hash of the BASE file.
>>
>> If this sounds good enough, I can dive into git-mergetoo--lib and
>> implement it. In the meantime, here is an example of a custom merge tool
>> that wraps meld for that purpose.
>
> I think you forgot to include the example. Anyway, at first glance it
> sounds like a sensible idea. David et al: thoughts?
Sounds sensible to me, too. (Although I'm not affected, as fortunately
the GUI merge tools I've been using so far, namely ECMerge and Beyond
Compare 3, both allow to specify a separate merge output.)
--
Sebastian Schuberth
^ permalink raw reply
* Re: git-mergetool: wrap tools with 3 files only to use the BASE file instead of MERGED
From: Tanguy Ortolo @ 2011-08-10 17:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, David Aguilar, Sebastian Schuberth, Charles Bailey
In-Reply-To: <20110810161211.GC4076@elie.gateway.2wire.net>
[-- Attachment #1.1: Type: text/plain, Size: 133 bytes --]
Jonathan Nieder, 2011-08-10 11:12 UTC-0500:
> I think you forgot to include the example.
Yes, sorry. Here it is.
--
Tanguy Ortolo
[-- Attachment #1.2: meld-mergetool --]
[-- Type: text/plain, Size: 385 bytes --]
#! /bin/sh
BASE="$1"
LOCAL="$2"
REMOTE="$3"
MERGED="$4"
MTIME_BEFORE="$(stat --format='%Y' "$BASE")"
meld "$LOCAL" "$BASE" "$REMOTE"
MTIME_AFTER="$(stat --format="%Y" "$BASE")"
if [ "$MTIME_BEFORE" != "$MTIME_AFTER" ]
then
# The base file was modified, which means the user saved it
cp "$BASE" "$MERGED"
else
# The user did not save the file: merge failed
exit 1
fi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: About git-diff
From: Andreas Schwab @ 2011-08-10 17:01 UTC (permalink / raw)
To: Luiz Ramos; +Cc: git
In-Reply-To: <1312941177.17928.YahooMailClassic@web121810.mail.ne1.yahoo.com>
Luiz Ramos <luizzramos@yahoo.com.br> writes:
> If I run:
>
> $ git diff b2 ./
>
> that is, the "non-cached" version, it will show the same results. This is
> confusing IMHO, because the git-diff manual suggests that invocation
> should render the difference between the named tree contents and the
> working directory. In the working directory, only to recall, file_1 and
> file_2 are both present and with good versions. In my understanding, the
> command should report that file_1 is in excess in the working directory,
> relative to b2, and report nothing about file_2, as it is in the same
> version as the sample in the tree b2.
Since file_2 is not tracked in the current branch, its existence in the
directory is ignored.
> This doesn't seem to be the same thing git-diff-index manual states,
> however. The manual gets more deep into the details, and it's not so easy
> to understand it unless one knows a lot of the inner commands, which does
> not apply to me. In my basic reading, it seems that behind the scenes,
> git-diff-index is what is run in this case, and the fact that file_2 is
> not in the tree associated to b1 is a relevant thing in this case. So, the
> index seem to matter, and if I try to do it, a previous "git update-index"
> should be done.
It's not the index, but the current tree that matters:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
Note that it talks about "files that aren't up-to-date". Thus untracked
files are not considered.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git-mergetool: wrap tools with 3 files only to use the BASE file instead of MERGED
From: Jonathan Nieder @ 2011-08-10 16:12 UTC (permalink / raw)
To: Tanguy Ortolo; +Cc: git, David Aguilar, Sebastian Schuberth, Charles Bailey
In-Reply-To: <20110810160356.GA32126@ortolo.eu>
(+cc: some relevant people)
Hi,
Tanguy Ortolo wrote[1]:
> git-mergetool ideally uses tools that work with 4 files: BASE, LOCAL,
> REMOTE, which are the usual original and two new version of the file,
> and MERGED, which is where the tool is supposed to write the result of
> the merge.
>
> The problem is that most tools, at least graphical ones, specifically
> meld, can only work with three files, as they save the result to the
> original file.
>
> git-mergetool currently handles this situation by passing MERGED LOCAL
> REMOTE to the tool. This could be fine, but unfortunately MERGE contains
> the conflicts, formatted for manual resolution, so it is not really
> appropriate as an original file.
>
> I think it would be better to wrap such merge tools by:
> 1. passing them BASE LOCAL REMOTE;
> 2. checking whether or not BASE hase been modified:
> * if it has, then copying it to MERGED,
> * if it has not, exiting with return code 1 (merge failed).
> This check can be by either saving and comparing the mdate, or perhaps
> the SHA-1 hash of the BASE file.
>
> If this sounds good enough, I can dive into git-mergetoo--lib and
> implement it. In the meantime, here is an example of a custom merge tool
> that wraps meld for that purpose.
I think you forgot to include the example. Anyway, at first glance it
sounds like a sensible idea. David et al: thoughts?
Regards,
Jonathan
[1] http://bugs.debian.org/637355
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox