* [PATCH v3 5/8] userdiff: require explicitly allowing textconv
From: Jeff King @ 2008-10-26 4:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081026043802.GA14530@coredump.intra.peff.net>
Diffs that have been produced with textconv almost certainly
cannot be applied, so we want to be careful not to generate
them in things like format-patch.
This introduces a new diff options, ALLOW_TEXTCONV, which
controls this behavior. It is off by default, but is
explicitly turned on for the "log" family of commands, as
well as the "diff" porcelain (but not diff-* plumbing).
Because both text conversion and external diffing are
controlled by these diff options, we can get rid of the
"plumbing versus porcelain" distinction when reading the
config. This was an attempt to control the same thing, but
suffered from being too coarse-grained.
Signed-off-by: Jeff King <peff@peff.net>
---
The new changes in 4/8 make this even cleaner than before.
builtin-diff.c | 1 +
builtin-log.c | 1 +
diff.c | 26 +++++++++++---------------
diff.h | 1 +
t/t4030-diff-textconv.sh | 2 +-
userdiff.c | 10 +---------
userdiff.h | 3 +--
7 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 9c8c295..2de5834 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -300,6 +300,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
}
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
/*
* If the user asked for our exit code then don't start a
diff --git a/builtin-log.c b/builtin-log.c
index a0944f7..75d698f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -59,6 +59,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
} else
die("unrecognized argument: %s", arg);
}
+ DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
}
/*
diff --git a/diff.c b/diff.c
index 6f01595..608223a 100644
--- a/diff.c
+++ b/diff.c
@@ -93,12 +93,6 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
if (!strcmp(var, "diff.external"))
return git_config_string(&external_diff_cmd_cfg, var, value);
- switch (userdiff_config_porcelain(var, value)) {
- case 0: break;
- case -1: return -1;
- default: return 0;
- }
-
return git_diff_basic_config(var, value, cb);
}
@@ -109,6 +103,12 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
return 0;
}
+ switch (userdiff_config(var, value)) {
+ case 0: break;
+ case -1: return -1;
+ default: return 0;
+ }
+
if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
int slot = parse_diff_color_slot(var, 11);
if (!value)
@@ -123,12 +123,6 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
return 0;
}
- switch (userdiff_config_basic(var, value)) {
- case 0: break;
- case -1: return -1;
- default: return 0;
- }
-
return git_color_default_config(var, value, cb);
}
@@ -1335,7 +1329,7 @@ static void builtin_diff(const char *name_a,
const char *set = diff_get_color_opt(o, DIFF_METAINFO);
const char *reset = diff_get_color_opt(o, DIFF_RESET);
const char *a_prefix, *b_prefix;
- const char *textconv_one, *textconv_two;
+ const char *textconv_one = NULL, *textconv_two = NULL;
diff_set_mnemonic_prefix(o, "a/", "b/");
if (DIFF_OPT_TST(o, REVERSE_DIFF)) {
@@ -1389,8 +1383,10 @@ static void builtin_diff(const char *name_a,
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
- textconv_one = get_textconv(one);
- textconv_two = get_textconv(two);
+ if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
+ textconv_one = get_textconv(one);
+ textconv_two = get_textconv(two);
+ }
if (!DIFF_OPT_TST(o, TEXT) &&
( (diff_filespec_is_binary(one) && !textconv_one) ||
diff --git a/diff.h b/diff.h
index a49d865..42582ed 100644
--- a/diff.h
+++ b/diff.h
@@ -65,6 +65,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_IGNORE_SUBMODULES (1 << 18)
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
+#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 090a21d..1df48ae 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -70,7 +70,7 @@ test_expect_success 'log produces text' '
test_cmp expect.text actual
'
-test_expect_failure 'format-patch produces binary' '
+test_expect_success 'format-patch produces binary' '
git format-patch --no-binary --stdout HEAD^ >patch &&
find_diff <patch >actual &&
test_cmp expect.binary actual
diff --git a/userdiff.c b/userdiff.c
index d95257a..3681062 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -120,7 +120,7 @@ static int parse_tristate(int *b, const char *k, const char *v)
return 1;
}
-int userdiff_config_basic(const char *k, const char *v)
+int userdiff_config(const char *k, const char *v)
{
struct userdiff_driver *drv;
@@ -130,14 +130,6 @@ int userdiff_config_basic(const char *k, const char *v)
return parse_funcname(&drv->funcname, k, v, REG_EXTENDED);
if ((drv = parse_driver(k, v, "binary")))
return parse_tristate(&drv->binary, k, v);
-
- return 0;
-}
-
-int userdiff_config_porcelain(const char *k, const char *v)
-{
- struct userdiff_driver *drv;
-
if ((drv = parse_driver(k, v, "command")))
return parse_string(&drv->external, k, v);
if ((drv = parse_driver(k, v, "textconv")))
diff --git a/userdiff.h b/userdiff.h
index f29c18f..ba29457 100644
--- a/userdiff.h
+++ b/userdiff.h
@@ -14,8 +14,7 @@ struct userdiff_driver {
const char *textconv;
};
-int userdiff_config_basic(const char *k, const char *v);
-int userdiff_config_porcelain(const char *k, const char *v);
+int userdiff_config(const char *k, const char *v);
struct userdiff_driver *userdiff_find_by_name(const char *name);
struct userdiff_driver *userdiff_find_by_path(const char *path);
--
1.6.0.3.524.ge8b2e.dirty
^ permalink raw reply related
* [PATCH v3 6/8] only textconv regular files
From: Jeff King @ 2008-10-26 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081026043802.GA14530@coredump.intra.peff.net>
We treat symlinks as text containing the results of the
symlink, so it doesn't make much sense to text-convert them.
Similarly gitlink components just end up as the text
"Subproject commit $sha1", which we should leave intact.
Note that a typechange may be broken into two parts: the
removal of the old part and the addition of the new. In that
case, we _do_ show the textconv for any part which is the
addition or removal of a file we would ordinarily textconv,
since it is purely acting on the file contents.
Signed-off-by: Jeff King <peff@peff.net>
---
Same as before.
diff.c | 2 ++
t/t4030-diff-textconv.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 608223a..23d454e 100644
--- a/diff.c
+++ b/diff.c
@@ -1311,6 +1311,8 @@ static const char *get_textconv(struct diff_filespec *one)
{
if (!DIFF_FILE_VALID(one))
return NULL;
+ if (!S_ISREG(one->mode))
+ return NULL;
diff_filespec_load_driver(one);
return one->driver->textconv;
}
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 1df48ae..3945731 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -104,7 +104,7 @@ index ad8b3d2..67be421
\ No newline at end of file
EOF
# make a symlink the hard way that works on symlink-challenged file systems
-test_expect_failure 'textconv does not act on symlinks' '
+test_expect_success 'textconv does not act on symlinks' '
echo -n frotz > file &&
git add file &&
git ls-files -s | sed -e s/100644/120000/ |
--
1.6.0.3.524.ge8b2e.dirty
^ permalink raw reply related
* [PATCH v3 7/8] wt-status: load diff ui config
From: Jeff King @ 2008-10-26 4:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081026043802.GA14530@coredump.intra.peff.net>
When "git status -v" shows a diff, we did not respect the
user's usual diff preferences at all. Loading just
git_diff_basic_config would give us things like rename
limits and diff drivers. But it makes even more sense to
load git_diff_ui_config, which gives us colorization if the
user has requested it.
Note that we need to take special care to cancel
colorization when writing to the commit template file, as
described in the code comments.
Signed-off-by: Jeff King <peff@peff.net>
---
This is necessary to do textconvs in the "status -v" diff (which will
come in the next patch).
But it makes me a little nervous. On one hand, I think it is definitely
the right thing for "status -v" to respect user options. But we do
several _other_ diffs in addition, and those are more "plumbing" diffs.
I think they should probably at least have diff_basic_config (e.g., for
rename limits). But we are applying the diff_ui_config options to all
diffs. Looking over the available options, I _think_ there are no nasty
surprises. But you never know.
t/t7502-commit.sh | 8 ++++++++
wt-status.c | 10 +++++++++-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 3eb9fae..ad42c78 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,6 +89,14 @@ test_expect_success 'verbose' '
'
+test_expect_success 'verbose respects diff config' '
+
+ git config color.diff always &&
+ git status -v >actual &&
+ grep "\[1mdiff --git" actual &&
+ git config --unset color.diff
+'
+
test_expect_success 'cleanup commit messages (verbatim,-t)' '
echo >>negative &&
diff --git a/wt-status.c b/wt-status.c
index c3a9cab..54d2f58 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -303,6 +303,14 @@ static void wt_status_print_verbose(struct wt_status *s)
rev.diffopt.detect_rename = 1;
rev.diffopt.file = s->fp;
rev.diffopt.close_file = 0;
+ /*
+ * If we're not going to stdout, then we definitely don't
+ * want color, since we are going to the commit message
+ * file (and even the "auto" setting won't work, since it
+ * will have checked isatty on stdout).
+ */
+ if (s->fp != stdout)
+ DIFF_OPT_CLR(&rev.diffopt, COLOR_DIFF);
run_diff_index(&rev, 1);
}
@@ -422,5 +430,5 @@ int git_status_config(const char *k, const char *v, void *cb)
return error("Invalid untracked files mode '%s'", v);
return 0;
}
- return git_color_default_config(k, v, cb);
+ return git_diff_ui_config(k, v, cb);
}
--
1.6.0.3.524.ge8b2e.dirty
^ permalink raw reply related
* [PATCH v3 8/8] enable textconv for diff in verbose status/commit
From: Jeff King @ 2008-10-26 4:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081026043802.GA14530@coredump.intra.peff.net>
This diff is meant for human consumption, so it makes sense
to apply text conversion here, as we would for the regular
diff porcelain.
Signed-off-by: Jeff King <peff@peff.net>
---
Pretty straightforward, but depends on whether we find 7/8 acceptable.
t/t4030-diff-textconv.sh | 8 ++++++++
wt-status.c | 1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 3945731..09967f5 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -76,6 +76,14 @@ test_expect_success 'format-patch produces binary' '
test_cmp expect.binary actual
'
+test_expect_success 'status -v produces text' '
+ git reset --soft HEAD^ &&
+ git status -v >diff &&
+ find_diff <diff >actual &&
+ test_cmp expect.text actual &&
+ git reset --soft HEAD@{1}
+'
+
cat >expect.stat <<'EOF'
file | Bin 2 -> 4 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 54d2f58..6a7645e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -301,6 +301,7 @@ static void wt_status_print_verbose(struct wt_status *s)
setup_revisions(0, NULL, &rev, s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
rev.diffopt.detect_rename = 1;
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
rev.diffopt.file = s->fp;
rev.diffopt.close_file = 0;
/*
--
1.6.0.3.524.ge8b2e.dirty
^ permalink raw reply related
* Re: [PATCH 4/7] textconv: don't convert for every operation
From: Jeff King @ 2008-10-26 4:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <7vvdvg6xto.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 25, 2008 at 04:48:19PM -0700, Junio C Hamano wrote:
> Another place that would benefit from ALLOW_TEXTCONV is the function
> wt_status_print_verbose() in wt-status.c, where we generate preview diff
> for "git commit -v". The output from that function is purely for human
> consumption and does not have to be applicable.
I agree, but it turned out not to be as straightforward as I had hoped,
since status doesn't even parse diff.* config. See patches 7 and 8 in
the series I just posted.
-Peff
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Jeff King @ 2008-10-26 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <7vej246sb4.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 25, 2008 at 06:47:27PM -0700, Junio C Hamano wrote:
> This was done primarily for fun and killing-time, so I won't be committing
> it to my tree, but it seems to pass all the existing tests.
I just skimmed the code, but it looks reasonably done. I don't have time
to work on this at the moment, but I think you have done most of the
work that requires a lot of git knowledge. Maybe somebody new can pick
this up as a nice starter project to get more involved in git.
-Peff
^ permalink raw reply
* Re: Problem with git filter-branch
From: Jeff King @ 2008-10-26 5:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pascal Obry, git list
In-Reply-To: <alpine.DEB.1.00.0810252235040.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Sat, Oct 25, 2008 at 10:36:26PM +0200, Johannes Schindelin wrote:
> It is a (maybe ill-conceived) feature. When branches are rewritten, their
> original versions are stored in the refs/original/ namespace. You can
> force overwriting with "-f".
>
> I wonder if people would like to have this feature removed; reflogs should
> be enough.
>
> Thoughts?
I have always been annoyed by the refs/original namespace, and it
certainly makes explaining the common task of "how do I get this blob
out of my repo" a bit more confusing.
So I would be happy to see it go, and the reflog mentioned in its place:
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index fed6de6..1e8e7b4 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -43,4 +43,4 @@ rewriting published history.)
Always verify that the rewritten version is correct: The original refs,
-if different from the rewritten ones, will be stored in the namespace
-'refs/original/'.
+if different from the rewritten ones, will be available through the
+reflog as <branch>@{1}.
^ permalink raw reply related
* Re: [PATCH] add -p: warn if only binary changes present
From: Jeff King @ 2008-10-26 5:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1224884916-20369-1-git-send-email-trast@student.ethz.ch>
On Fri, Oct 24, 2008 at 11:48:36PM +0200, Thomas Rast wrote:
> Current 'git add -p' will say "No changes." if there are no changes to
> text files, which can be confusing if there _are_ changes to binary
> files. Add some code to distinguish the two cases, and give a
> different message in the latter one.
Having just looked at this code (for potentially handling "git add -p"
of new files), I think this change is sane.
> + print STDERR "No changes except to binary files.\n";
This wording seems a little awkward to me, though. Maybe
No changed text files.
?
-Peff
^ permalink raw reply
* Re: [PATCH 3/7] gitk: Allow starting gui blame for a specific line.
From: Paul Mackerras @ 2008-10-26 3:58 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200810252045.54010.angavrilov@gmail.com>
Alexander Gavrilov writes:
> Ugh. I guess I'll have to install docs from Tcl 8.4...
Yes, although I strongly encourage people to move to 8.5, I haven't
made it a requirement (yet :).
Paul.
^ permalink raw reply
* Re: git export to svn
From: Björn Steinbrink @ 2008-10-26 9:15 UTC (permalink / raw)
To: Warren Harris; +Cc: J.H., git
In-Reply-To: <2F1954CC-E013-4861-87F8-F89CF37CE53C@gmail.com>
On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
> I tried a fetch, but still no luck:
>
> $ git svn fetch
> W: Ignoring error from SVN, path probably does not exist: (175002): RA
> layer request failed: REPORT of '/svn/!svn/bc/100': Could not read chunk
> size: Secure connection truncated (https://svn)
> W: Do not be alarmed at the above message git-svn is just searching
> aggressively for old history.
> This may take a while on large repositories
> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
> A ...
> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>
> $ git svn rebase
> Unable to determine upstream SVN information from working tree history
Means that your current branch is not based on what git-svn has fetched,
which is expected when you use "svn init" + "svn fetch" after you
already started working.
What's the actual relationship between your local history and the
history you fetched from svn?
If your local stuff started from revision X, which you manually imported
from svn, you can just rebase it:
git rebase --onto <svn-revision-X> <your-revision-X>
If you have a bunch of merges in your local history, you might want to
merge your stuff into the svn-based branch instead. When you dcommit,
the svn repo will only see one big "do it all" commit though.
For that, you would create a graft, so that your first "real" local
commit gets the svn revision X commit as its parent. That is, from:
S---S---SX---S---S---S (svn)
LX--------L---L---L---L (local)
You want to go to:
S---S---SX---S---S---S (svn)
\
LX L---L---L---L (local)
Where 'S' means that the commit came from SVN, and L means that it is a
"local" commit. SX and LX are the commits that have the same tree
attached (same directories/files), but have a different hash due to how
they were created. The graft overrides the parent-child relation for the
first "L" commit, so that it actually appears as being branched off of SX.
And then, you'd merge local into svn, so you get:
S---S---SX---S---S---S--M (svn)
\ /
LX L---L---L---L (local)
If possible, go with the rebase though. That at least gives a somewhat
reasonable history in the svn repo as well. Also note that when you go
with the merge way, make sure that the svn branch is totally uptodate
before you merge and that the merge commit is the only one to be
dcommitted. Otherwise, funny stuff might happen, and rebase might kick
in anyway, I don't exactly remember what git-svn does, but it wasn't
pleasant :-)
Björn
^ permalink raw reply
* Re: [PATCH] add -p: warn if only binary changes present
From: Thomas Rast @ 2008-10-26 10:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081026051013.GD21178@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
Jeff King wrote:
> > + print STDERR "No changes except to binary files.\n";
>
> This wording seems a little awkward to me, though. Maybe
>
> No changed text files.
>
> ?
I tried to make a more precise statement. "No changed text files"
also holds if no files at all were changed. A user can only infer
that there _are_ binary changes if he knows that the message in the
latter case would have been "No changes".
That being said, it is somewhat awkward, I just couldn't come up with
a better message with this meaning. I considered some other options,
such as giving a hint to use git-add or running git-status for the
user, but these would have been far more verbose.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] add -p: warn if only binary changes present
From: SZEDER Gábor @ 2008-10-26 10:40 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <200810261128.14735.trast@student.ethz.ch>
On Sun, Oct 26, 2008 at 12:28:09PM +0200, Thomas Rast wrote:
> Jeff King wrote:
> > > + print STDERR "No changes except to binary files.\n";
> > No changed text files.
> I tried to make a more precise statement. "No changed text files"
> also holds if no files at all were changed. A user can only infer
> that there _are_ binary changes if he knows that the message in the
> latter case would have been "No changes".
>
> That being said, it is somewhat awkward, I just couldn't come up with
> a better message with this meaning.
What about
Only binary files changed.
or something of the sort?
Gábor
^ permalink raw reply
* [PATCH] autoconf: Add link tests to each AC_CHECK_FUNC() test
From: David M. Syzdek @ 2008-10-26 11:52 UTC (permalink / raw)
To: git; +Cc: jnareb, David M. Syzdek
Update configure.ac to test libraries for getaddrinfo, strcasestr, memmem,
strlcpy, strtoumax, setenv, unsetenv, and mkdtemp. The default compilers
on FreeBSD 4.9-SECURITY and FreeBSD 6.2-RELEASE-p4 do not generate warnings
for missing prototypes unless `-Wall' is used. This behavior renders the
results of AC_CHECK_FUNC() void on these platforms. The test AC_SEARCH_LIBS()
verifies a function is valid by linking to symbol within the system libraries.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
configure.ac | 57 ++++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 40 insertions(+), 17 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7c2856e..d3b8bc3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -293,9 +293,11 @@ AC_SUBST(NO_SOCKADDR_STORAGE)
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
AC_CHECK_TYPE([struct addrinfo],[
- AC_CHECK_FUNC([getaddrinfo],
- [NO_IPV6=],
- [NO_IPV6=YesPlease])
+ AC_CHECK_FUNC([getaddrinfo],[
+ AC_SEARCH_LIBS([getaddrinfo],,
+ [NO_IPV6=],
+ [NO_IPV6=YesPlease])
+ ],[NO_IPV6=YesPlease])
],[NO_IPV6=YesPlease],[
#include <sys/types.h>
#include <sys/socket.h>
@@ -387,44 +389,65 @@ AC_SUBST(SNPRINTF_RETURNS_BOGUS)
AC_MSG_NOTICE([CHECKS for library functions])
#
# Define NO_STRCASESTR if you don't have strcasestr.
-AC_CHECK_FUNC(strcasestr,
-[NO_STRCASESTR=],
+AC_CHECK_FUNC(strcasestr,[
+ AC_SEARCH_LIBS(strcasestr,,
+ [NO_STRCASESTR=],
+ [NO_STRCASESTR=YesPlease])
+],
[NO_STRCASESTR=YesPlease])
AC_SUBST(NO_STRCASESTR)
#
# Define NO_MEMMEM if you don't have memmem.
-AC_CHECK_FUNC(memmem,
-[NO_MEMMEM=],
+AC_CHECK_FUNC(memmem,[
+ AC_SEARCH_LIBS(memmem,,
+ [NO_MEMMEM=],
+ [NO_MEMMEM=YesPlease])
+],
[NO_MEMMEM=YesPlease])
AC_SUBST(NO_MEMMEM)
#
# Define NO_STRLCPY if you don't have strlcpy.
-AC_CHECK_FUNC(strlcpy,
-[NO_STRLCPY=],
+AC_CHECK_FUNC(strlcpy,[
+ AC_SEARCH_LIBS(strlcpy,,
+ [NO_STRLCPY=],
+ [NO_STRLCPY=YesPlease])
+],
[NO_STRLCPY=YesPlease])
AC_SUBST(NO_STRLCPY)
#
# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
-AC_CHECK_FUNC(strtoumax,
-[NO_STRTOUMAX=],
+AC_CHECK_FUNC(strtoumax,[
+ AC_SEARCH_LIBS(strtoumax,,
+ [NO_STRTOUMAX=],
+ [NO_STRTOUMAX=YesPlease])
+],
[NO_STRTOUMAX=YesPlease])
AC_SUBST(NO_STRTOUMAX)
#
# Define NO_SETENV if you don't have setenv in the C library.
-AC_CHECK_FUNC(setenv,
-[NO_SETENV=],
+AC_CHECK_FUNC(setenv,[
+ AC_SEARCH_LIBS(setenv,,
+ [NO_SETENV=],
+ [NO_SETENV=YesPlease])
+],
[NO_SETENV=YesPlease])
AC_SUBST(NO_SETENV)
#
# Define NO_UNSETENV if you don't have unsetenv in the C library.
-AC_CHECK_FUNC(unsetenv,
-[NO_UNSETENV=],
+AC_CHECK_FUNC(unsetenv,[
+ AC_SEARCH_LIBS(unsetenv,,
+ [NO_UNSETENV=],
+ [NO_UNSETENV=YesPlease])
+],
[NO_UNSETENV=YesPlease])
AC_SUBST(NO_UNSETENV)
#
# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
-AC_CHECK_FUNC(mkdtemp,
-[NO_MKDTEMP=],
+AC_CHECK_FUNC(mkdtemp,[
+ AC_SEARCH_LIBS(mkdtemp,,
+ [NO_MKDTEMP=],
+ [NO_MKDTEMP=YesPlease])
+],
[NO_MKDTEMP=YesPlease])
AC_SUBST(NO_MKDTEMP)
#
--
1.6.0.2.GIT
^ permalink raw reply related
* [PATCH] Add Makefile check for FreeBSD 4.9-SECURITY
From: David M. Syzdek @ 2008-10-26 11:52 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek
If the system is FreeBSD 4.9, then NO_UINTMAX_T and NO_STRTOUMAX is defined.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index bf6a6dc..c568314 100644
--- a/Makefile
+++ b/Makefile
@@ -679,6 +679,10 @@ ifeq ($(uname_S),FreeBSD)
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
+ ifeq ($(uname_R),4.9-SECURITY)
+ NO_UINTMAX_T = YesPlease
+ NO_STRTOUMAX = YesPlease
+ endif
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
--
1.6.0.2.GIT
^ permalink raw reply related
* [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: David M. Syzdek @ 2008-10-26 11:52 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek
This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then
uintmax_t is defined as uint32_t. This adds a test to configure.ac for
uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
Makefile | 3 +++
config.mak.in | 1 +
configure.ac | 8 ++++++++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 0d40f0e..bf6a6dc 100644
--- a/Makefile
+++ b/Makefile
@@ -931,6 +931,9 @@ endif
ifdef NO_IPV6
BASIC_CFLAGS += -DNO_IPV6
endif
+ifdef NO_UINTMAX_T
+ BASIC_CFLAGS += -Duintmax_t=uint32_t
+endif
ifdef NO_SOCKADDR_STORAGE
ifdef NO_IPV6
BASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in
diff --git a/config.mak.in b/config.mak.in
index b776149..c6558eb 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -39,6 +39,7 @@ NO_C99_FORMAT=@NO_C99_FORMAT@
NO_STRCASESTR=@NO_STRCASESTR@
NO_MEMMEM=@NO_MEMMEM@
NO_STRLCPY=@NO_STRLCPY@
+NO_UINTMAX_T=@NO_UINTMAX_T@
NO_STRTOUMAX=@NO_STRTOUMAX@
NO_SETENV=@NO_SETENV@
NO_UNSETENV=@NO_UNSETENV@
diff --git a/configure.ac b/configure.ac
index d3b8bc3..d9de93f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -415,6 +415,14 @@ AC_CHECK_FUNC(strlcpy,[
[NO_STRLCPY=YesPlease])
AC_SUBST(NO_STRLCPY)
#
+# Define NO_UINTMAX_T if your platform does not have uintmax_t
+AC_CHECK_TYPE(uintmax_t,
+[NO_UINTMAX_T=],
+[NO_UINTMAX_T=YesPlease],[
+#include <inttypes.h>
+])
+AC_SUBST(NO_UINTMAX_T)
+#
# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
AC_CHECK_FUNC(strtoumax,[
AC_SEARCH_LIBS(strtoumax,,
--
1.6.0.2.GIT
^ permalink raw reply related
* Feature request: git-log should optionally include tags
From: Roger Leigh @ 2008-10-26 12:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]
A feature I would very much like to have in git is to have tag
information included in the log generated by git-log. This would
make it easy to see where the tags are in the history. The use
case for us would be to have release tags displayed so that it's
possible to identify which revisions constitute release points,
which is useful for e.g. users to identify points for bisection.
I can do it now using sed to substitute in the contents of
.git/refs/tags/*, but having the functionality in git-log directly
would be most useful.
Regards,
Roger Leigh
Example of existing log:
----------------------------------------------------------------------
commit 62dca2fc0e5e356ecb24ea0d8bd9f04980ab4cbe
Author: Roger Leigh <rleigh@debian.org>
Date: Mon Oct 13 00:31:03 2008 +0100
[Sbuild::Build] Add and use log_info, _warning and _error functions
----------------------------------------------------------------------
Example of log including tags:
----------------------------------------------------------------------
commit 62dca2fc0e5e356ecb24ea0d8bd9f04980ab4cbe
Author: Roger Leigh <rleigh@debian.org>
Date: Mon Oct 13 00:31:03 2008 +0100
Tags: sbuild-0.60.1
[Sbuild::Build] Add and use log_info, _warning and _error functions
----------------------------------------------------------------------
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Feature request: git-log should optionally include tags
From: Mikael Magnusson @ 2008-10-26 12:47 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081026121326.GA3399@codelibre.net>
2008/10/26 Roger Leigh <rleigh@whinlatter.ukfsn.org>:
> A feature I would very much like to have in git is to have tag
> information included in the log generated by git-log. This would
> make it easy to see where the tags are in the history. The use
> case for us would be to have release tags displayed so that it's
> possible to identify which revisions constitute release points,
> which is useful for e.g. users to identify points for bisection.
>
> I can do it now using sed to substitute in the contents of
> .git/refs/tags/*, but having the functionality in git-log directly
> would be most useful.
git log --decorate
--
Mikael Magnusson
^ permalink raw reply
* Re: Feature request: git-log should optionally include tags
From: Roger Leigh @ 2008-10-26 12:52 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Roger Leigh, git
In-Reply-To: <237967ef0810260547o4e2143e0jc9403da7b1f4d85a@mail.gmail.com>
On Sun, Oct 26, 2008 at 01:47:44PM +0100, Mikael Magnusson wrote:
> 2008/10/26 Roger Leigh <rleigh@whinlatter.ukfsn.org>:
> > A feature I would very much like to have in git is to have tag
> > information included in the log generated by git-log. This would
> > make it easy to see where the tags are in the history. The use
> > case for us would be to have release tags displayed so that it's
> > possible to identify which revisions constitute release points,
> > which is useful for e.g. users to identify points for bisection.
> >
> > I can do it now using sed to substitute in the contents of
> > .git/refs/tags/*, but having the functionality in git-log directly
> > would be most useful.
>
> git log --decorate
Many thanks!
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 14:15 UTC (permalink / raw)
To: git; +Cc: mercurial
In-Reply-To: <ge0rla$mce$1@ger.gmane.org>
[Cc: gmane.comp.version-control.git,
gmane.comp.version-control.mercurial.general]
walt <w41ter@gmail.com> writes:
> No, no, I'm not the one calling for a vote. You old-timers here
> will know the name Matt Dillon, who is leading the dragonflybsd
> project (www.dragonflybsd.org).
>
> Matt is the one who is calling for the vote in his thread "Vote
> for your source control system" in the dragonfly.kernel group,
> accessible via nntp://nntp.dragonflybsd.org.
>
> I've already cast my vote for git, which I confess is not very
> honest because I've never even tried mercurial. I would truly
> be grateful to anyone here who knows both git and mercurial who
> could contribute verifiable facts to that debate.
I also used only Git, but I have read a bit about Mercurial; however
the information I have on Mercurial might be out of date.
Below I have tried to compare Git with Mercurial, pointing the most
important (to me) facts:
1. Documentation and ease of use.
Mercurial is supposedly better documented and easier to use; I
think this descends from the early days of Git, where it was not
very user friendly. IMHO Git has much improved since. Mercurial
had 'hgbook' from the beginning; Git User's Manual is more recent.
I also think that ease of use is just different learning curve.
I am also biased and I think that Mercurial starts easy, but it has
more difficult things (like e.g. merging, multiple branches in
single repository etc.) harder than it Git.
I'll admit that Mercurial UI is better designed; Git UI was not as
much designed as it evolved from 'stupid content tracker' to
full-featured SCM, therefore there are a few oddities (for example
git-revert might do not what you expect, if you are accustomed to
Subversion UI).
2. Implementation, portability, bindings and extending
Mercurial is implemented in Python, with core written in C for
better performance. It has a plugin system, and additional extra
features implemented through extensions. I don't know what is the
status of bindings (or implementations) in other programming
languages; but it has some API for use in extensions at least.
Git is implemented as mixture of C, shell scripts, Perl and Tcl/Tk
(for GUI). The main way of extending it is by scripting around
powerfull set of low level tools, called 'plumbing', meant to be
used in scripts. JGit is for example _reimplementation_ of Git in
Java.
3. Repository design and performance.
Git is designed around idea of content adressed object database;
objects are adressed by their content (by SHA-1 of their type and
content). Commits for example have information about author and
comitter, pointer to zero or more parent commits, and pointer to
tree object (representing top directory in project). Branches
and tags are just pointers to DAG (Direct Acyclic Graph) of
commits; current branch is denoted by HEAD pointer to branch.
There is explicit staging area called 'index', used for conflict
resolution dureing merges, and which can be used to make commit in
stages, allow uncomitted changes in tree (in working directory).
Git design supports very well multiple branches in single
repository, and tracking changes in multiple remote repositories
each with multiple branches.
Mercurial, from what I have read of its documentation, and from the
few discussion on #revctrl IRC channel, and from what I understand
is based on changes stored per file, with information about files
and their versions stored in manifest (flat) file, and with changes
described in changelog-like file (changerev). One of limitations
of "record" database (as opposed to Git's object database) is that
commits can have zero (root commit), one or two (merge commits)
parents only. There is apparent in design that Mercurial was
developed with single branch per repository paradigm in mind.
Local branches from what I understand are marked in CVS-like
fashion using tags. Tags are implemented as either local to
repository and untransferable, or as .hgtags versioned file with
special case treatment. (But I'm obviously biased here).
Git and Mercurial have similar performance, although it is thought
that due to design Mercurla has faster patch applying and is
optimized for cold cache case, while Git has faster merging and is
optimized for warm cache case.
Mercurial may have (or had) problems with larger binary files, from
what I have heard.
3. Advanced features, interfaces and tools
I don't know much about Mercurial beside basic usage, what I
remember from 'hgbook', but I think that most if not all advanced
Git features are available either in Mercurial core, or as
Mercurial extensions (plugins).
For example both Git and Mercurial have bisect command for finding
bug by searching (possibly nonlinear) history for commit which
introduced bug, ForestExtension is rough equivalent of git
submodules (or third party git-externals), there is Transplain
extension for git-rebase, etc.
Mercurial has hgserve which can function as both web repository
browser and as anonymous server; in Git they are split between
git-daemon for anonymous repository access, and gitweb (or other
web interfaces: cgit, git-php, ViewGit, Gitorious,..) for web
interface.
NOTE: In Git repacking and garbage collecting is explicit
(although can be automated with "git gc --auto", and some of it
happens automatically); Git use _rename detection_ rather than
_rename tracking_, which has its advantages and disadvantages.
They are many articles comparing Mercurial and Git; if they are blog
posts please read the comments too. Among them are:
* "Git vs. Mercurial: Please Relax" (Git is MacGyver, Mercurial
is James Bond)
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
* "The Differences Between Mercurial and Git"
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
* "Git vs. Mercurial"
http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html
* "Git versus Mercurial..."
http://codeheadsystems.wordpress.com/2008/05/10/git-versus-mercurial/
* "Git vs Mercurial"
http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html
Note however that the comparison at "Better SCM Initiative" has some
wrong information about Git: see
* "Git at Better SCM Initiative comparison of VCS (long)"
http://thread.gmane.org/gmane.comp.version-control.git/95809/focus=97253
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Maxim Vuets @ 2008-10-26 14:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: mercurial, git
In-Reply-To: <m3r663h276.fsf@localhost.localdomain>
On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> 1. Documentation and ease of use.
>
> Mercurial is supposedly better documented and easier to use; I
> think this descends from the early days of Git, where it was not
> very user friendly. IMHO Git has much improved since. Mercurial
> had 'hgbook' from the beginning; Git User's Manual is more recent.
Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
Thanks for the comprarision!
--
. Hoc est simplicissimum!
..: maxim.vuets.name
^ permalink raw reply
* Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 14:46 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
% mkdir 1; cd 1
% echo > a; git add a; git commit -m a
% cd ..
% git clone -s 1 2
% git push . master:master
fatal: Could not switch to
'/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
fatal: The remote end hung up unexpectedly
% PATH=/bin:/usr/bin git push . master:master
Everything up-to-date
The same thing happens if i try to push from 1 to 2:
% cd ../1
% git push ../2
fatal: Could not switch to
'/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
fatal: The remote end hung up unexpectedly
% echo $#PATH
196
% echo $PATH
/home/mikaelh/bin:/opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/i686-pc-linux-gnu/gcc-bin/4.2.4:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/usr/local/ipod-chain/bin
d79796bcf05b89774671a75b3285000c43129823 is first bad commit
commit d79796bcf05b89774671a75b3285000c43129823
Author: Junio C Hamano <gitster@pobox.com>
Date: Tue Sep 9 01:27:10 2008 -0700
push: receiver end advertises refs from alternate repositories
Earlier, when pushing into a repository that borrows from alternate object
stores, we followed the longstanding design decision not to trust refs in
the alternate repository that houses the object store we are borrowing
from. If your public repository is borrowing from Linus's public
repository, you pushed into it long time ago, and now when you try to push
your updated history that is in sync with more recent history from Linus,
you will end up sending not just your own development, but also the
changes you acquired through Linus's tree, even though the objects needed
for the latter already exists at the receiving end. This is because the
receiving end does not advertise that the objects only reachable from the
borrowed repository (i.e. Linus's) are already available there.
This solves the issue by making the receiving end advertise refs from
borrowed repositories. They are not sent with their true names but with a
phoney name ".have" to make sure that the old senders will safely ignore
them (otherwise, the old senders will misbehave, trying to push matching
refs, and mirror push that deletes refs that only exist at the receiving
end).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 6d6027ead17b86519d69c3dfc9b98c01e916d277
45e3cd90fd476cdb0a32e5de27739b18e060e031 Mbuiltin-receive-pack.c
:100644 100644 98a742122dbacbb39fa104cdfe909a9a884ed7b6
99af83a0479ef472078afcd288b1f6ba6283a2f0 Mcache.h
:100644 100644 ae550e89c0942bb9e34b252b653c40e869a074a4
12be17b5dace07a2ca71613e4e9093cdb77492ac Msha1_file.c
--
Mikael Magnusson
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Leo Razoumov @ 2008-10-26 15:05 UTC (permalink / raw)
To: Maxim Vuets; +Cc: Jakub Narebski, mercurial, git
In-Reply-To: <e15351d00810260730t1552e04cqb057993581514f3b@mail.gmail.com>
On 10/26/08, Maxim Vuets <maxim.vuets@gmail.com> wrote:
> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> > 1. Documentation and ease of use.
> >
> > Mercurial is supposedly better documented and easier to use; I
> > think this descends from the early days of Git, where it was not
> > very user friendly. IMHO Git has much improved since. Mercurial
> > had 'hgbook' from the beginning; Git User's Manual is more recent.
>
>
> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
>
> Thanks for the comprarision!
I have been using Mercurial for about two years and am very
comfortable with it. Here are some cons and pros
Mercurial PROS:
* Easier and more consistent UI. Newbie friendly.
* Better documentation. IMHO, hgbook is by far better than
http://book.git-scm.com/
* Windows support (personally, I do not care)
Mercurial CONS:
* Less potential than git. Once Ted Tso even said that "git has more
legs than mercurial", see
http://thunk.org/tytso/blog/2007/03/24/git-and-hg/
* Hg is strictly an SCM system while GIT is a content addressable file
system that can be used in other ways, hence the name Global
Information Tracker (GIT)
* Recently, Hg development seems to have somewhat slowed down. To
simply put it, there is not enough room in the world for several
similar SCM systems. With git's pace and momentum the other SCMs
including Hg are fighting an uphill battle.
Just my two cents.
--Leo--
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-26 15:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810240401q57e40b9dj46c35f90681cfa3d@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>>> .file.git/ to track file's history. .file.git/info/excludes is
>>> initialized to the very strong '*' pattern to ensure that things such
>>> as git status etc only consider the actually tracked file.
>> [...]
>>
>> Could you add it to Git Wiki page:
>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>>
>> I think that the project is interesting enough to be added there
>> even if it is still in beta, or even alpha, stage.
>
> Ah, good idea. Done, in Version Control Interface layers section
Thanks.
I have added link to repositoy, as you didn't configure your gitweb to
display those URL links (see gitweb/README and gitweb/INSTALL).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Felipe Contreras @ 2008-10-26 15:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, mercurial
In-Reply-To: <m3r663h276.fsf@localhost.localdomain>
On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> [Cc: gmane.comp.version-control.git,
> gmane.comp.version-control.mercurial.general]
>
> walt <w41ter@gmail.com> writes:
>
>> No, no, I'm not the one calling for a vote. You old-timers here
>> will know the name Matt Dillon, who is leading the dragonflybsd
>> project (www.dragonflybsd.org).
>>
>> Matt is the one who is calling for the vote in his thread "Vote
>> for your source control system" in the dragonfly.kernel group,
>> accessible via nntp://nntp.dragonflybsd.org.
>>
>> I've already cast my vote for git, which I confess is not very
>> honest because I've never even tried mercurial. I would truly
>> be grateful to anyone here who knows both git and mercurial who
>> could contribute verifiable facts to that debate.
<snip/>
> 3. Repository design and performance.
>
> Git is designed around idea of content adressed object database;
> objects are adressed by their content (by SHA-1 of their type and
> content). Commits for example have information about author and
> comitter, pointer to zero or more parent commits, and pointer to
> tree object (representing top directory in project). Branches
> and tags are just pointers to DAG (Direct Acyclic Graph) of
> commits; current branch is denoted by HEAD pointer to branch.
> There is explicit staging area called 'index', used for conflict
> resolution dureing merges, and which can be used to make commit in
> stages, allow uncomitted changes in tree (in working directory).
> Git design supports very well multiple branches in single
> repository, and tracking changes in multiple remote repositories
> each with multiple branches.
>
> Mercurial, from what I have read of its documentation, and from the
> few discussion on #revctrl IRC channel, and from what I understand
> is based on changes stored per file, with information about files
> and their versions stored in manifest (flat) file, and with changes
> described in changelog-like file (changerev). One of limitations
> of "record" database (as opposed to Git's object database) is that
> commits can have zero (root commit), one or two (merge commits)
> parents only. There is apparent in design that Mercurial was
> developed with single branch per repository paradigm in mind.
> Local branches from what I understand are marked in CVS-like
> fashion using tags. Tags are implemented as either local to
> repository and untransferable, or as .hgtags versioned file with
> special case treatment. (But I'm obviously biased here).
>
> Git and Mercurial have similar performance, although it is thought
> that due to design Mercurla has faster patch applying and is
> optimized for cold cache case, while Git has faster merging and is
> optimized for warm cache case.
>
> Mercurial may have (or had) problems with larger binary files, from
> what I have heard.
The fact that hg is changeset based means that certain operations are
slower, like checkout a specific commit. In hg my bet is you would
need to gather a bunch of changesets while in git the operation is
done in a single step.
It also means that bare clones are not possible in hg, or at least
very complicated.
Note: I'm not sure if what I'm claiming is correct.
--
Felipe Contreras
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: René Scharfe @ 2008-10-26 16:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Santi Béjar, git
In-Reply-To: <20081022075639.GA1284@elte.hu>
Ingo Molnar schrieb:
> The most useful angle would be if git log --format had a way to print
> the reverse name. Then i could do a git-log-line script like:
>
> git log --pretty=format:"%h: %20N %s" $@
>
> where %N prints the reverse name.
>
> While at it: it would be nice if git log had a way to crop string
> output. For example i'd love to use:
>
> git log --pretty=format:"%h: %60s" $@
>
> which would print out at most 60 characters from the first commit line.
>
> That way i can see it properly on an 80 width terminal and can paste it
> into email without linewraps, etc. But --pretty=format does not seem to
> know width restrictions.
You don't need support for format string cropping in git for the latter
example, you can use cut instead:
git log --pretty=format:%h:\ %s $@ | cut -b-70
But I only realized that after I had written the following patch. :)
Would this feature still be useful?
Thanks,
René
---
Documentation/pretty-formats.txt | 5 +++++
pretty.c | 30 ++++++++++++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index f18d33e..cc76c45 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -128,6 +128,11 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
++
+You can also specify a maximum width for each field after the '%', e.g.
+'%60s' will show the first sixty characters of the subject (or less if
+it's shorter).
+
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
diff --git a/pretty.c b/pretty.c
index 1e79943..74e8932 100644
--- a/pretty.c
+++ b/pretty.c
@@ -498,8 +498,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
-static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
- void *context)
+static size_t do_format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
{
struct format_commit_context *c = context;
const struct commit *commit = c->commit;
@@ -621,6 +621,32 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
return 0; /* unknown placeholder */
}
+static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
+{
+ size_t digits = 0;
+ size_t maxlen = 0;
+ size_t consumed;
+
+ if (isdigit(placeholder[0])) {
+ do {
+ digits++;
+ maxlen *= 10;
+ maxlen += placeholder[0] - '0';
+ placeholder++;
+ } while (isdigit(placeholder[0]));
+ maxlen += sb->len;
+ }
+
+ consumed = do_format_commit_item(sb, placeholder, context);
+ if (!consumed)
+ return 0;
+
+ if (digits && sb->len > maxlen)
+ strbuf_setlen(sb, maxlen);
+ return digits + consumed;
+}
+
void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
enum date_mode dmode)
--
1.6.0.3.514.g2f91b
^ permalink raw reply related
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