* Re: [RFH] NetBSD 6?
From: Greg Troxel @ 2013-01-03 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd2xnypt6.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> I realize a README.foo file for N different systems could be clutter,
>> but having these checked in would provide the concise help that people
>> on any of those platforms need.
>
> Our Makefile documents knobs people on various platforms can tweak
> (PYTHON_PATH and OLD_ICONV are two examples of them), sets default
> values for them based on $(uname -S), then includes config.mak file
> the user can optionally create to override these platform defaults.
> This infrastructure is used across platforms, not just for NetBSD.
If you have to choose a single PYTHON_PATH, the one you picked is right
(for now, and likely will be right for a long time).
But as a general rule, I think configure tests are preferable to
OS-specific variables.
> The part shown in the patch was to update the platform default for
> NetBSD. The setting we have been shipping in our Makefile seemed to
> be different from what I needed on my NetBSD 6 install, and I was
> wondering if we have no real users of Git on the platorm (which
> would explain why we didn't get any complaints or patches to update
> this part). Or there are some optional packages all real NetBSD
> users install, but being a NetBSD newbie I didn't, that makes the
> values I showed in the patch inappropriate for them (e.g. Perhaps
> there is a mechanism other than pkgsrc that installs perl and python
> under /usr/bin? Perhaps an optional libi18n package that gives
> iconv(3) with new function signature?), in which case I definitely
> should not apply that patch to my tree, as it would only be an
> improvement for one person and a regression for existing users at
> the same time.
A large number of people on NetBSD use git, but almost all of them get
it via pkgsrc (which is also where they get perl, emacs, svn, and
everything else you didn't find in /usr/bin). The exception would be
people that want to hack on git itself.
People who want gnu libiconv can install the libiconv package from
pkgsrc. (I'm guessing OLD_ICONV means "POSIX iconv", without GNU
extensions (iconvctl?).) The git package doesn't depend on GNU iconv,
though (perhaps it should but we tend to avoid dependencies that arren't
really needed).
There are no mechanisms to install python/perl in /usr/bin, and doing so
would be viewed as bizarre. /usr/bin belongs to the base system,
/usr/pkg to pkgsrc and /usr/local to the user.
So, it doesn't matter too much for pkgsrc what you change, because it
can be patched anyway (once, for all users). It's probably better to
make a straightforward build from source come out right.
But, if the build respects the PYTHON_PATH environment variable, that's
easier (and more robust against changes) than patching.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* [PATCH v2 0/5] nd/maint-branch-desc-doc reroll
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 14:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
- move the comment in 5/5 into the commented code block
- resolve branch name for "HEAD" in 4/5
Nguyễn Thái Ngọc Duy (5):
config.txt: a few lines about branch.<name>.description
branch: delete branch description if it's empty
t4014: a few more tests on cover letter using branch description
format-patch: pick up correct branch name from symbolic ref
format-patch: pick up branch description when no ref is specified
Documentation/config.txt | 6 ++++++
builtin/branch.c | 2 +-
builtin/log.c | 33 ++++++++++++++++++++-------------
t/t4014-format-patch.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 69 insertions(+), 14 deletions(-)
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply
* [PATCH v2 1/5] config.txt: a few lines about branch.<name>.description
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 14:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1357221791-7496-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..ee64846 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -735,6 +735,12 @@ branch.<name>.rebase::
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
+branch.<name>.description::
+ Branch description, can be edited with
+ `git branch --edit-description`. Branch description is
+ automatically added in the format-patch cover letter or
+ request-pull summary.
+
browser.<tool>.cmd::
Specify the command to invoke the specified browser. The
specified command is evaluated in shell with the URLs passed
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2 2/5] branch: delete branch description if it's empty
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 14:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1357221791-7496-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 1ec9c02..873f624 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -725,7 +725,7 @@ static int edit_branch_description(const char *branch_name)
stripspace(&buf, 1);
strbuf_addf(&name, "branch.%s.description", branch_name);
- status = git_config_set(name.buf, buf.buf);
+ status = git_config_set(name.buf, buf.len ? buf.buf : NULL);
strbuf_release(&name);
strbuf_release(&buf);
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2 3/5] t4014: a few more tests on cover letter using branch description
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 14:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1357221791-7496-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t4014-format-patch.sh | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 16a4ca1..ec9ef9e 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -963,4 +963,25 @@ test_expect_success 'format patch ignores color.ui' '
test_cmp expect actual
'
+test_expect_success 'cover letter using branch description (1)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter master >actual &&
+ grep hello actual >/dev/null
+'
+
+test_expect_success 'cover letter using branch description (2)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter rebuild-1~2..rebuild-1 >actual &&
+ grep hello actual >/dev/null
+'
+
+test_expect_success 'cover letter using branch description (3)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter ^master rebuild-1 >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2 4/5] format-patch: pick up correct branch name from symbolic ref
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 14:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1357221791-7496-1-git-send-email-pclouds@gmail.com>
find_branch_name() assumes to take refs/heads/<branch>. But we also
have symbolic refs, such as HEAD, that can point to a valid branch in
refs/heads and do not follow refs/heads/<branch> syntax. Remove the
assumption and apply normal ref resolution. After all it would be
confusing if rev machinery resolves a ref in one way and
find_branch_name() another.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/log.c | 21 +++++++++------------
t/t4014-format-patch.sh | 14 ++++++++++++++
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..039bf67 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1016,8 +1016,8 @@ static char *find_branch_name(struct rev_info *rev)
{
int i, positive = -1;
unsigned char branch_sha1[20];
- struct strbuf buf = STRBUF_INIT;
- const char *branch;
+ const char *ref;
+ char *full_ref, *branch = NULL;
for (i = 0; i < rev->cmdline.nr; i++) {
if (rev->cmdline.rev[i].flags & UNINTERESTING)
@@ -1029,16 +1029,13 @@ static char *find_branch_name(struct rev_info *rev)
}
if (positive < 0)
return NULL;
- strbuf_addf(&buf, "refs/heads/%s", rev->cmdline.rev[positive].name);
- branch = resolve_ref_unsafe(buf.buf, branch_sha1, 1, NULL);
- if (!branch ||
- prefixcmp(branch, "refs/heads/") ||
- hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
- branch = NULL;
- strbuf_release(&buf);
- if (branch)
- return xstrdup(rev->cmdline.rev[positive].name);
- return NULL;
+ ref = rev->cmdline.rev[positive].name;
+ if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
+ !prefixcmp(full_ref, "refs/heads/") &&
+ !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ branch = xstrdup(full_ref + strlen("refs/heads/"));
+ free(full_ref);
+ return branch;
}
int cmd_format_patch(int argc, const char **argv, const char *prefix)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index ec9ef9e..903a797 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -984,4 +984,18 @@ test_expect_success 'cover letter using branch description (3)' '
grep hello actual >/dev/null
'
+test_expect_success 'cover letter using branch description (4)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter master.. >actual &&
+ grep hello actual >/dev/null
+'
+
+test_expect_success 'cover letter using branch description (5)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter -2 HEAD >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH v2 5/5] format-patch: pick up branch description when no ref is specified
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 14:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1357221791-7496-1-git-send-email-pclouds@gmail.com>
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/log.c | 16 +++++++++++++---
t/t4014-format-patch.sh | 7 +++++++
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 039bf67..81683f6 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1027,12 +1027,22 @@ static char *find_branch_name(struct rev_info *rev)
else
return NULL;
}
- if (positive < 0)
+ if (positive >= 0)
+ ref = rev->cmdline.rev[positive].name;
+ else if (!rev->cmdline.nr && rev->pending.nr == 1 &&
+ !strcmp(rev->pending.objects[0].name, "HEAD"))
+ /*
+ * No actual ref from command line, but "HEAD" from
+ * rev->def was added in setup_revisions()
+ * e.g. format-patch --cover-letter -12
+ */
+ ref = "HEAD";
+ else
return NULL;
- ref = rev->cmdline.rev[positive].name;
if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
!prefixcmp(full_ref, "refs/heads/") &&
- !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ (positive < 0 ||
+ !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1)))
branch = xstrdup(full_ref + strlen("refs/heads/"));
free(full_ref);
return branch;
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 903a797..7e52941 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -998,4 +998,11 @@ test_expect_success 'cover letter using branch description (5)' '
grep hello actual >/dev/null
'
+test_expect_success 'cover letter using branch description (6)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter -2 >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
From: Junio C Hamano @ 2013-01-03 15:22 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Chris Rorvick, Eric Raymond, git
In-Reply-To: <CALWbr2xx0beca_LUHO45pGMZ4Y0jZ9-iMWq8WBO6PmW==Ysw=A@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
>> Doesn't Python come with a standard subprocess module that lets you
>> spawn external programs safely, similar to the way Perl's list form
>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
... and of course a more boring "system('git', $subcmd, @args)", as well.
> You mean something like this:
>
> p1 = subprocess.Popen([backend.command()], stdout=subprocess.PIPE)
> subprocess.Popen(["git", "fast-import", "--quiet"] + gitopts,
> cwd=outdir, stdin=p1.stdout)
>
> Assuming gitopts is a list rather than a string. (care must be taken
> with backend.command() also)
Yes.
I vaguely recall that the subprocess module once used to be one
portability issue but that was between Python 2.3 and 2.4 or some
ancient history, and it should no longer be relevant.
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Junio C Hamano @ 2013-01-03 15:34 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git
In-Reply-To: <20130103083712.GC32377@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > So I think we need to update twoway_merge to recognize unmerged entries,
>> > which gives us two options:
>> >
>> > 1. Reject the merge.
>> >
>> > 2. Throw away the current unmerged entry in favor of the "new" entry
>> > (when old and new are the same, of course; otherwise we would
>> > reject).
>> >
>> > I think (2) is the right thing.
>>
>> As "--reset" in "read-tree --reset -u A B" is a way to say "we know
>> we are based on A and we want to go to B no matter what", I agree we
>> should not reject the merge.
>>
>> With -m instead of --reset, I am not sure what the right semantics
>> should be, though.
>
> Good point; I was just thinking about the --reset case.
>
> With "-m", though, we could in theory carry over the unmerged entries
> (again, assuming that "old" and "new" are the same; otherwise it is an
> obvious reject). But those entries would be confused with any new
> unmerged entries we create. It seems we already protect against this,
> though: "read-tree -m" will not run at all if you have unmerged entries.
>
> Likewise, "checkout" seems to have similar protections.
>
> So I think it may be a non-issue.
Yeah. Also earlier in the thread you mentioned three-way case, but
I do not think we ever would want --reset with three trees, so I
think that too is a non-issue for the same reason.
I would still feel safer if we expressed the expectation of
the callee in the code, perhaps like this in the two-way case:
if (current->ce_flags & CE_CONFLICTED) {
if (!o->reset) {
... either die or fail ...
} else {
... your fix ...
}
}
^ permalink raw reply
* Re: cvsps, parsecvs, svn2git and the CVS exporter mess
From: Michael Haggerty @ 2013-01-03 15:37 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Yann Dirson, Heiko Voigt, Antoine Pelisse, Bart Massey,
Keith Packard, David Mansfield, git
In-Reply-To: <20121222173649.04C5B44119@snark.thyrsus.com>
On 12/22/2012 06:36 PM, Eric S. Raymond wrote:
> * One is Michael Haggerty's cvs2git. I had bad experiences with the
> cvs2svn code it's derived from in the past, but Michael believes those
> problems have been fixed and I will accept that - at least until I can
> test for myself. Its documented interface is not quite good enough
> yet; as the documentation says, "The data that should be fed to git
> fast-import are written to two files, which have to be loaded into git
> fast-import manually."
There are two good reasons that the output is written to two separate files:
1. The files are generated during different passes of cvs2git, and since
the cvs2git conversion is restartable pass-by-pass, the first file might
only need to be generated once even while the user is iterating on
adjustments to other conversion options.
2. The first ("blobfile") contains blob definitions for file revisions,
which are read out of the RCS files in the order they are held in the
RCS file. This is vastly faster than reading the file revisions in the
order that they are needed for git commits because (1) all revisions for
a file can be computed from one serial read of the RCS file; (2) there
is no need to jump around from rcsfile to rcsfile. The second
("dumpfile") stitches the blobs together into git commits by referring
to the blobs that are needed. This file is smaller because it doesn't
contain the actual file contents. Another advantage of this approach is
that a blob need only appear once in the blobfile even if it is used
multiple times in the git history.
Anyway, surely cat'ing two output files together is not such a difficult
problem?
A potentially bigger problem is that if you want to handle such
blob/dump output, you have to deal with git-fast-import format's "blob"
command as opposed to only handling inline blobs. However, if that is a
problem, it is possible to configure cvs2git to write the blobs inline
with the rest of the dumpfile (this mode is supported because "hg
fast-import" doesn't support detached blobs). You would have to create
an options file that uses GitRevisionInlineWriter, similar to what is
done in cvs2hg-example.options.
> [...]
> Having three different tools for this job seems to me duplicative and
> pointless; two of them should probably be let die an honorable death.
> I don't actually care which of the three survives - and, in
> particular, if I determine that cvs2git is doing the best job of the
> three I am quite willing to declare end-of-life for cvsps and
> parsecvs. It's not like I don't have plenty of other projects to work
> on.
cvs2git does not currently support incremental conversions; therefore, a
cvsps-based option (if it would actually work, that is) would have at
least one advantage over cvs2git.
> I presently know of three test suites other than mine. One was built
> by Heiko to test cvsps, another lives in the git t/ directory, and the
> third is cvs2git's. I haven't looked at cv2git's yet, but the others
> are not in their present form suited to where I am taking cvsps and
> parsecvs. Heiko's relies on the default human-readable cvsps format,
> which I consider obsolete and uninteresting. The git tests are
> dependent on details of porcelain behavior. I think it would be
> better to test import-stream output.
cvs2svn has an extensive test suite which includes tests derived from
bug reports that we have received over the years. I adapted a few of
its test repositories to create the git test suite additions that I made
in Feb 2009, but there are many more in our project.
A lot of our test suite deals with additional conversion features, like:
* Re-encoding filenames, usernames, and log messages from whatever
happens to have been used in the CVS repository into UTF-8
* Fixing CVS branches, tags, and mixed branch/tag messes according to
user wishes; renaming branches and tags
* Allowing the user to influence the choice of which branch should serve
as the source for another branch/tag (CVS records this information very
ambiguously)
* Fixing binary vs. text files, expanding/contracting CVS keywords, etc.
* Removing lots of synthetic revisions and other cruft generated by CVS
to fit within the RCS file format
* Dealing with vendor branches in a sensible way, especially considering
that very many users misuse vendor branches for initial imports
* Dealing with various common types of CVS repository corruption
See our list of features [1] for more details. Presumably many of these
features would not be covered by your test framework, and are not
supported by the other conversion tools.
Unfortunately, our tests are mostly based on cvs2svn (i.e., not 2git);
that is, the conversion is done with cvs2svn and checked by verifying
the contents of the resulting Subversion repository.
The script contrib/verify-cvs2svn.py is another kind of test; it checks
every branch and tag out of CVS and the destination repository and
verifies that their contents are identical. This script is intended to
be used by users to check their own conversion. Please note that it
doesn't check the history, only the branch/tag tips. But this script
works with both Subversion and git (at least it should; it probably
doesn't get tested much).
> Here is what I propose. Let's build a common test suite that cvs2git,
> git-cvsimport, cvsps, and parsecvs can all use, apply it rigorously,
> and let the best tool win. (This would mean, among other things, that
> git can stop carrying things that are essentially cvsps tests in its
> tree.)
I think it would be great to have a way to test across tools, though
please realize that the inference of the most plausible "true" CVS
history is partly objective but also often a matter of heuristics and
taste. Moreover, the choice of how to represent the inferred history in
git, which has rather a different model than CVS/Subversion, is also
non-obvious and somewhat controversial. I expect that there will be a
number of simple CVS repositories for which we can all agree about the
correct git output, but not far away will be a vast number for which the
"correct" answer is unclear. Many of the interesting tests would fall
into the latter category.
> The two people I most need to sign off on this are, I guess, Michael
> Haggerty and either Junio Hamano or whoever specifically owns
> git-cvsimport and its tests. [...]
It's not clear what you want me to sign off on. I guess you want to
replace (or augment?) the cvs2svn test suite with one based on your
framework? Right off the top of my head I can think of a few
considerations from the point of view of the cvs2svn project:
* We definitely want to continue testing the Subversion output of
cvs2svn. A test suite that only tests the git output could at best be
an addition to the current test suite, not a replacement for it. (That
being said, the addition of good tests of the 2git output would be great.)
* A test suite that tests only the easy cases wouldn't really be
interesting, because the difficult cases are where the potential
problems lie.
* It would be unfortunate if the cvs2svn test suite would grow another
run-time dependency or if we would have to invest a lot of time
synchronizing with another project, though if the gain were big enough
we could consider it.
* The licenses obviously have to be compatible to the extent required by
the level of coupling.
* I don't have a lot of time to work on the integration. cvs2svn has
long been at a level of maturity where it doesn't need much care and
feeding, and I would like to keep it that way :-) Nowadays I am far
more interested in working on the git project with my little available
open-sourcin' time.
Rereading this email, I realize that it is not clear to me why your new
testing project needs the "signoff" or cooperation from any of the
conversions tool projects (git-cvsimport or cvs2svn or parsecvs or ...)
in the first place. The essence of your project will be a collection of
CVS test repositories, and code that can read the conversion output
(whether via git or as fast-input data) and verify that it matches
expectations (right?). Presumably it will have a place where any of the
conversion tools could be plugged into it, and perhaps a bit of code
that knows how to configure and run the best-known tools (and perhaps
even to download and build them).
It would seem natural to me that your project stops there, and stays at
arms-length from the conversion projects. If your test suite proves
itself to be obviously better than the cvs2svn test suite, then we might
try to integrate it *then* (or not; even then it wouldn't really be
obligatory).
Michael
[1] http://cvs2svn.tigris.org/features.html
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 5/5] format-patch: pick up branch description when no ref is specified
From: Junio C Hamano @ 2013-01-03 15:49 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1357221791-7496-6-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> We only try to get branch name in "format-patch origin" case or
> similar and not "format-patch -22" where HEAD is automatically
> added. Without correct branch name, branch description cannot be
> added. Make sure we always get branch name.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> builtin/log.c | 16 +++++++++++++---
> t/t4014-format-patch.sh | 7 +++++++
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 039bf67..81683f6 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -1027,12 +1027,22 @@ static char *find_branch_name(struct rev_info *rev)
> else
> return NULL;
> }
> - if (positive < 0)
> + if (positive >= 0)
> + ref = rev->cmdline.rev[positive].name;
> + else if (!rev->cmdline.nr && rev->pending.nr == 1 &&
> + !strcmp(rev->pending.objects[0].name, "HEAD"))
> + /*
> + * No actual ref from command line, but "HEAD" from
> + * rev->def was added in setup_revisions()
> + * e.g. format-patch --cover-letter -12
> + */
> + ref = "HEAD";
> + else
> return NULL;
> - ref = rev->cmdline.rev[positive].name;
> if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
> !prefixcmp(full_ref, "refs/heads/") &&
> - !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
> + (positive < 0 ||
> + !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1)))
This hashcmp() is to make sure that the tip we _guessed_ with
dwim_ref() that the user meant matches what we are going to use, so
I do not think disabling the check is a good idea.
You could (and I think you should) do something like this:
if (0 <= positive) {
ref = rev->cmdline.rev[positive].name;
tip_sha1 = rev->cmdline.rev[positive].item->sha1;
} else if (... defaulted to implied HEAD? ...) {
ref = "HEAD";
tip_sha1 = rev->pending.objects[0].item->sha1;
} else {
return NULL;
}
if (dwim_ref(...) && !prefixcmp(full_ref, "refs/heads/") &&
!hashcmp(tip_sha1, branch_sha1))
to preserve that safety instead.
^ permalink raw reply
* Re: cvsps, parsecvs, svn2git and the CVS exporter mess
From: Martin Langhoff @ 2013-01-03 15:51 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Yann Dirson, Michael Haggerty, Heiko Voigt, Antoine Pelisse,
Bart Massey, Keith Packard, David Mansfield, Git Mailing List
In-Reply-To: <20121222173649.04C5B44119@snark.thyrsus.com>
On Sat, Dec 22, 2012 at 12:36 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> It is pure accident that I now maintain two of these.
Maintainership is always temporary.
> Having three different tools for this job seems to me duplicative and
> pointless; two of them should probably be let die an honorable death.
Perhaps just maintain the code that serves your goals. That way, you
don't need long trolly emails nor approval from anyone.
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH v3 5/5] format-patch: pick up branch description when no ref is specified
From: Nguyễn Thái Ngọc Duy @ 2013-01-03 16:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <7v7gnuxo4q.fsf@alter.siamese.dyndns.org>
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Thu, Jan 3, 2013 at 10:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> You could (and I think you should) do something like this:
>
> if (0 <= positive) {
> ref = rev->cmdline.rev[positive].name;
> tip_sha1 = rev->cmdline.rev[positive].item->sha1;
> } else if (... defaulted to implied HEAD? ...) {
> ref = "HEAD";
> tip_sha1 = rev->pending.objects[0].item->sha1;
> } else {
> return NULL;
> }
>
> if (dwim_ref(...) && !prefixcmp(full_ref, "refs/heads/") &&
> !hashcmp(tip_sha1, branch_sha1))
>
> to preserve that safety instead.
Good idea. Done.
builtin/log.c | 18 +++++++++++++++---
t/t4014-format-patch.sh | 7 +++++++
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 039bf67..72a368a 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1016,6 +1016,7 @@ static char *find_branch_name(struct rev_info *rev)
{
int i, positive = -1;
unsigned char branch_sha1[20];
+ const unsigned char *tip_sha1;
const char *ref;
char *full_ref, *branch = NULL;
@@ -1027,12 +1028,23 @@ static char *find_branch_name(struct rev_info *rev)
else
return NULL;
}
- if (positive < 0)
+ if (0 <= positive) {
+ ref = rev->cmdline.rev[positive].name;
+ tip_sha1 = rev->cmdline.rev[positive].item->sha1;
+ } else if (!rev->cmdline.nr && rev->pending.nr == 1 &&
+ !strcmp(rev->pending.objects[0].name, "HEAD")) {
+ /*
+ * No actual ref from command line, but "HEAD" from
+ * rev->def was added in setup_revisions()
+ * e.g. format-patch --cover-letter -12
+ */
+ ref = "HEAD";
+ tip_sha1 = rev->pending.objects[0].item->sha1;
+ } else
return NULL;
- ref = rev->cmdline.rev[positive].name;
if (dwim_ref(ref, strlen(ref), branch_sha1, &full_ref) &&
!prefixcmp(full_ref, "refs/heads/") &&
- !hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ !hashcmp(tip_sha1, branch_sha1))
branch = xstrdup(full_ref + strlen("refs/heads/"));
free(full_ref);
return branch;
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 903a797..7e52941 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -998,4 +998,11 @@ test_expect_success 'cover letter using branch description (5)' '
grep hello actual >/dev/null
'
+test_expect_success 'cover letter using branch description (6)' '
+ git checkout rebuild-1 &&
+ test_config branch.rebuild-1.description hello &&
+ git format-patch --stdout --cover-letter -2 >actual &&
+ grep hello actual >/dev/null
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [RFH] NetBSD 6?
From: Junio C Hamano @ 2013-01-03 16:17 UTC (permalink / raw)
To: Greg Troxel; +Cc: git
In-Reply-To: <rmi8v8av05d.fsf@fnord.ir.bbn.com>
Greg Troxel <gdt@ir.bbn.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Greg Troxel <gdt@ir.bbn.com> writes:
>>
>>> I realize a README.foo file for N different systems could be clutter,
>>> but having these checked in would provide the concise help that people
>>> on any of those platforms need.
>>
>> Our Makefile documents knobs people on various platforms can tweak
>> (PYTHON_PATH and OLD_ICONV are two examples of them), sets default
>> values for them based on $(uname -S), then includes config.mak file
>> the user can optionally create to override these platform defaults.
>> This infrastructure is used across platforms, not just for NetBSD.
>
> If you have to choose a single PYTHON_PATH, the one you picked is right
> (for now, and likely will be right for a long time).
>
> But as a general rule, I think configure tests are preferable to
> OS-specific variables.
I forgot to mention that we also ship configure (and keep track of
configure.ac) so that optionally people can let autoconf machinery
to create config.mak.autogen to be included at the same place as
handcrafted config.mak in their build process. I do not offhand
know if we do "for p in python python2.6 python2.7; do ..." kind of
thing, though.
> A large number of people on NetBSD use git, but almost all of them get
> it via pkgsrc (which is also where they get perl, emacs, svn, and
> everything else you didn't find in /usr/bin). The exception would be
> people that want to hack on git itself.
Yeah, that much I figured ;-)
> People who want gnu libiconv can install the libiconv package from
> pkgsrc. (I'm guessing OLD_ICONV means "POSIX iconv", without GNU
> extensions (iconvctl?).)
It refers to the type of the second parameter to iconv(); OLD_ICONV
makes it take "const char *", as opposed to "char *", the latter of
which matches
http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
> So, it doesn't matter too much for pkgsrc what you change, because it
> can be patched anyway (once, for all users).
Yes. The values in the Makefile are fallback defaults, and matters
only to people who build from the source.
^ permalink raw reply
* Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
From: Michael Haggerty @ 2013-01-03 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, Chris Rorvick, Eric Raymond, git
In-Reply-To: <7vip7expd8.fsf@alter.siamese.dyndns.org>
On 01/03/2013 04:22 PM, Junio C Hamano wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>>> Doesn't Python come with a standard subprocess module that lets you
>>> spawn external programs safely, similar to the way Perl's list form
>>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
>
> ... and of course a more boring "system('git', $subcmd, @args)", as well.
Python's os.system() takes exactly one argument, which must be a string,
and executes it in a subshell. subprocess is indeed the way to go.
>> You mean something like this:
>>
>> p1 = subprocess.Popen([backend.command()], stdout=subprocess.PIPE)
>> subprocess.Popen(["git", "fast-import", "--quiet"] + gitopts,
>> cwd=outdir, stdin=p1.stdout)
>>
>> Assuming gitopts is a list rather than a string. (care must be taken
>> with backend.command() also)
>
> Yes.
>
> I vaguely recall that the subprocess module once used to be one
> portability issue but that was between Python 2.3 and 2.4 or some
> ancient history, and it should no longer be relevant.
subprocess was added in Python 2.4, and the above example should work
fine in any version >= 2.4. But please note that other functions have
been added to the module since then, like check_call() (v2.5),
check_output (v2.7), and some methods were added to the Popen object in
v2.6.
Such things are documented pretty reliably in the Python library
documentation [1]; when in doubt, one can view older versions of the
library documentation, which are all available online [2].
Michael
[1] http://docs.python.org/2/library/
[2] http://www.python.org/doc/versions/
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Pretty pictures of git merge conflicts
From: Michael Haggerty @ 2013-01-03 16:37 UTC (permalink / raw)
To: git discussion list
Hi,
I've been thinking lately about how to attack difficult git merge
conflicts. The first step is to visualize them. I have written some
articles [1,2,3] describing a way to atomize a complicated merge and
efficiently compute diagrams that show which pairwise commits cause the
merge to go awry. I hope you find them interesting; feedback would be
very welcome.
I am working on some more articles (including software) that I plan to
grow into tools to help users perform git merges that would otherwise
seem hopeless.
Michael
[1]
http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html
[2]
http://softwareswirl.blogspot.de/2012/12/mapping-merge-conflict-frontier.html
[3]
http://softwareswirl.blogspot.de/2012/12/real-world-conflict-diagrams.html
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] merge: Honor prepare-commit-msg return code
From: Antoine Pelisse @ 2013-01-03 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7vwqvv1dta.fsf@alter.siamese.dyndns.org>
> Oh, that wasn't meant as a complaint. I am tempted to rewrite the
> log message like so, though:
>
> 65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to
> make "git commit" and "git merge" consistent, because a merge that
> required user assistance has to be concluded with "git commit", but
> only "git commit" triggered prepare-commit-msg hook. When it added
> a call to run the prepare-commit-msg hook, however, it forgot to
> check the exit code from the hook like "git commit" does, and ended
> up replacing one inconsistency with another.
That's fine with me
>>> diff --git a/t/t7505-prepare-commit-msg-hook.sh b/t/t7505-prepare-commit-msg-hook.sh
>>> index bc497bc..3573751 100755
>>> --- a/t/t7505-prepare-commit-msg-hook.sh
>>> +++ b/t/t7505-prepare-commit-msg-hook.sh
>>> @@ -172,11 +172,12 @@ test_expect_success 'with failing hook (merge)' '
>>> git checkout -B other HEAD@{1} &&
>>> echo "more" >> file &&
>>> git add file &&
>>> - chmod -x $HOOK &&
>>> + rm -f "$HOOK" &&
>>> git commit -m other &&
>>> - chmod +x $HOOK &&
>>> + write_script "$HOOK" <<-EOF
>>> + exit 1
>>> + EOF
>>> git checkout - &&
>>> - head=`git rev-parse HEAD` &&
>>> test_must_fail git merge other
>>>
>>> '
>>
>> What about moving the hook file then ? Not very important to me, just
>> a suggestion as it would keep the shebang.
>
> Strictly speaking, the way $HOOK is prepared in the original is
> wrong. The script is always run under "#!/bin/sh" instead of the
> shell the user told us to use with $SHELL_PATH. For a simple one
> liner that only exits with 1, it does not matter, though.
>
> Many test scripts got this wrong and that was the reason we later
> added write_script helper function to the test suite.
So let's keep your suggestion and squash the commit.
Thanks,
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Greg Troxel @ 2013-01-03 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcbew895.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
> I forgot to mention that we also ship configure (and keep track of
> configure.ac) so that optionally people can let autoconf machinery
> to create config.mak.autogen to be included at the same place as
> handcrafted config.mak in their build process. I do not offhand
> know if we do "for p in python python2.6 python2.7; do ..." kind of
> thing, though.
pkgsrc uses the configure method, but it seems not to output a
PYTHON_PATH. It looks like automake's python.m4 is not used by git's
configure.ac. But pkgsrc passes PYTHON_PATH in the environment to make,
so it works out currently.
> It refers to the type of the second parameter to iconv(); OLD_ICONV
> makes it take "const char *", as opposed to "char *", the latter of
> which matches
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
Thanks - I now see our extra const and am looking into it.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Junio C Hamano @ 2013-01-03 19:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
This allows things like:
$ DEFAULT_DOC_TARGET=html make doc
$ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
on a platform that does not have manpage viewer. Which is not very
useful, given that you can already say
$ make install-html
on such a platform, and these install-$format targets will not go
away.
The real motivation behind this was to let me say:
$ git checkout $some_old_fork_point
$ DEFAULT_DOC_TARGET=git-push.1 make doc
while updating the sources to the documentation for the maintainance
track, without having to format everything else that is different
between the old fork point and the primary branch I usually work on.
The first one was discussed some time ago on the list and all the
fixes mentioned on the thread already squashed in. The second one
is merely for completeness.
For previous round, see:
http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201
Junio C Hamano (2):
Allow generating a non-default set of documentation
Allow installing a non-default set of documentation
Documentation/Makefile | 10 ++++++++--
Makefile | 13 ++++++++++++-
2 files changed, 20 insertions(+), 3 deletions(-)
--
1.8.1.293.g4a210a9
^ permalink raw reply
* [PATCH v2 1/2] Allow generating a non-default set of documentation
From: Junio C Hamano @ 2013-01-03 19:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <1357239920-2201-1-git-send-email-gitster@pobox.com>
By default, "make doc" generates the manpages and htmldocs in the
Documentation directory, but you may want to change this depending
on the target environment, e.g. to include 'pdf'. Introduce a new
Makefile variable DEFAULT_DOC_TARGET to allow customizing this.
The primary motivation is to let us check documentation patches with
$ DEFAULT_DOC_TARGET=git-push.1 make doc
but it is not so far-fetched to imagine that Windows users may want to
omit manpages with
$ DEFAULT_DOC_TARGET=html make doc
or somesuch. It won't be useful without additional support to tweak
the format installed by default via DEFAULT_DOC_INSTALL_TARGET, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/Makefile | 7 ++++++-
Makefile | 10 +++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 063fa69..0f8fdf8 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,3 +1,6 @@
+# The default target of this Makefile is...
+all::
+
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
@@ -65,6 +68,8 @@ endif
-include ../config.mak.autogen
-include ../config.mak
+DEFAULT_DOC_TARGET ?= html man
+
#
# For docbook-xsl ...
# -1.68.1, no extra settings are needed?
@@ -151,7 +156,7 @@ ifndef V
endif
endif
-all: html man
+all:: $(DEFAULT_DOC_TARGET)
html: $(DOC_HTML)
diff --git a/Makefile b/Makefile
index 6b0c961..71655a7 100644
--- a/Makefile
+++ b/Makefile
@@ -281,6 +281,12 @@ all::
# DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
# DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
#
+# You can define DEFAULT_DOC_TARGET to change it from the built-in
+# default of generating manpages and htmldocs. e.g.
+#
+# DEFAULT_DOC_TARGET='man html info pdf'
+# DEFAULT_DOC_TARGET='html'
+#
# Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on
# header files to be automatically computed, to avoid rebuilding objects when
# an unrelated header file changes. Define it to "no" to use the hard-coded
@@ -1421,6 +1427,8 @@ ifneq (,$(SOCKLEN_T))
BASIC_CFLAGS += -Dsocklen_t=$(SOCKLEN_T)
endif
+DEFAULT_DOC_TARGET ?= html man
+
ifeq ($(uname_S),Darwin)
ifndef NO_FINK
ifeq ($(shell test -d /sw/lib && echo y),y)
@@ -2371,7 +2379,7 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
$(VCSSVN_LIB): $(VCSSVN_OBJS)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS)
-export DEFAULT_EDITOR DEFAULT_PAGER
+export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET
doc:
$(MAKE) -C Documentation all
--
1.8.1.293.g4a210a9
^ permalink raw reply related
* [PATCH v2 2/2] Allow installing a non-default set of documentation
From: Junio C Hamano @ 2013-01-03 19:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <1357239920-2201-1-git-send-email-gitster@pobox.com>
In a fashion similar to the previous DEFAULT_DOC_TARGET patch, teach
the build procedure to allow installing the documentation sets
specified via DEFAULT_DOC_INSTALL_TARGET.
These two symbols must be separate, as we should allow formatting
more than what will be installed. The default has been to format
both html and manpages, and to install only the latter.
$ make DEFAULT_DOC_INSTALL_TARGET='html man' install-doc
will format and install both html and manpages.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/Makefile | 3 ++-
Makefile | 5 ++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 0f8fdf8..bd7800d 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -69,6 +69,7 @@ endif
-include ../config.mak
DEFAULT_DOC_TARGET ?= html man
+DEFAULT_DOC_INSTALL_TARGET ?= $(DEFAULT_DOC_TARGET)
#
# For docbook-xsl ...
@@ -171,7 +172,7 @@ info: git.info gitman.info
pdf: user-manual.pdf
-install: install-man
+install: $(patsubst %,install-%,$(DEFAULT_DOC_INSTALL_TARGET))
install-man: man
$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
diff --git a/Makefile b/Makefile
index 71655a7..422a15f 100644
--- a/Makefile
+++ b/Makefile
@@ -287,6 +287,8 @@ all::
# DEFAULT_DOC_TARGET='man html info pdf'
# DEFAULT_DOC_TARGET='html'
#
+# DEFAULT_DOC_INSTALL_TARGET can be used in a similar way.
+#
# Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on
# header files to be automatically computed, to avoid rebuilding objects when
# an unrelated header file changes. Define it to "no" to use the hard-coded
@@ -1428,6 +1430,7 @@ ifneq (,$(SOCKLEN_T))
endif
DEFAULT_DOC_TARGET ?= html man
+DEFAULT_DOC_INSTALL_TARGET ?= man
ifeq ($(uname_S),Darwin)
ifndef NO_FINK
@@ -2379,7 +2382,7 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
$(VCSSVN_LIB): $(VCSSVN_OBJS)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS)
-export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET
+export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET DEFAULT_DOC_INSTALL_TARGET
doc:
$(MAKE) -C Documentation all
--
1.8.1.293.g4a210a9
^ permalink raw reply related
* What's cooking in git.git (Jan 2013, #02; Thu, 3)
From: Junio C Hamano @ 2013-01-03 19:17 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The post 1.8.1 cycle has started, and about a dozen topics (mostly
fixes) have graduated to the 'master' branch. The second batch will
follow shortly.
As usual, this cycle is expected to last for 8 to 10 weeks. To
ensure the quality of the end result, let's merge topics in flight
earlier than previous cycles to 'next' and fix issues in-tree.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jn/less-reconfigure (2013-01-02) 1 commit
(merged to 'next' on 2013-01-02 at e5cd6cf)
+ build: do not automatically reconfigure unless configure.ac changed
When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* ap/merge-stop-at-prepare-commit-msg-failure (2013-01-03) 1 commit
- merge: Honor prepare-commit-msg return code
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook. t7505 may want a general clean-up but that is
a different topic.
Will merge to 'next'.
* tb/test-shell-lint (2013-01-02) 1 commit
- test: Add check-non-portable-shell.pl
Check for common mistakes in the test scripts, based on simple
pattern-matching.
Will merge to 'next'.
* jk/enable-test-lint-by-default (2013-01-03) 1 commit
- tests: turn on test-lint by default
We had two simple and quick tests to catch common mistakes when
writing test scripts, but they weren't run by default when running
tests.
Will merge to 'next'.
--------------------------------------------------
[Graduated to "master"]
* as/test-tweaks (2012-12-20) 7 commits
(merged to 'next' on 2012-12-22 at 7312c6c)
+ tests: paint unexpectedly fixed known breakages in bold red
+ tests: test the test framework more thoroughly
+ tests: refactor mechanics of testing in a sub test-lib
+ tests: change info messages from yellow/brown to cyan
+ tests: paint skipped tests in blue
+ tests: paint known breakages in yellow
+ tests: test number comes first in 'not ok $count - $message'
Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* da/p4merge-mktemp (2012-12-26) 1 commit
(merged to 'next' on 2012-12-26 at 036938a)
+ mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
Create an empty file in $TMPDIR instead of using an empty file in
the local directory.
* dm/port (2012-12-19) 4 commits
(merged to 'next' on 2012-12-22 at 8adc198)
+ git-compat-util.h: do not #include <sys/param.h> by default
+ Generalize the inclusion of strings.h
+ Detect when the passwd struct is missing pw_gecos
+ Support builds when sys/param.h is missing
(this branch is used by mk/qnx.)
Add a few more knobs for new platform ports can tweak.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* jc/maint-fnmatch-old-style-definition (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at 540df2c)
+ compat/fnmatch: update old-style definition to ANSI
Update old-style function definition "int foo(bar) int bar; {}"
to "int foo(int bar) {}".
* jc/maint-test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at daeed53)
+ t4014: fix arguments to grep
+ t9502: do not assume GNU tar
+ t0200: "locale" may not exist
(this branch is used by jc/test-portability.)
Minor test fixes noticed while running our tests on OpenBSD 5.2,
applicable to 'maint'.
* jc/mkstemp-more-careful-error-reporting (2012-12-18) 1 commit
(merged to 'next' on 2012-12-22 at 18cdaf0)
+ xmkstemp(): avoid showing truncated template more carefully
After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* jc/same-encoding (2012-12-10) 1 commit
(merged to 'next' on 2012-12-17 at 86b41c7)
+ format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
* jc/test-cvs-no-init-in-existing-dir (2012-12-24) 1 commit
(merged to 'next' on 2012-12-26 at 3b93f37)
+ t9200: let "cvs init" create the test repository
t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* jc/test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 123041b)
+ t9020: use configured Python to run the test helper
+ t3600: Avoid "cp -a", which is a GNUism
+ Merge branch 'jc/maint-test-portability' into 'jc/test-portability'
(this branch uses jc/maint-test-portability.)
The remainder of jc/maint-test-portability, applicable to 'master'.
* jk/repack-ref-racefix (2012-12-21) 1 commit
(merged to 'next' on 2012-12-22 at 03e1ca9)
+ refs: do not use cached refs in repack_without_ref
"git pack-refs" that ran in parallel to another process that
created new refs had a nasty race.
* md/gitweb-sort-by-age (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at 9f39410)
+ gitweb: Sort projects with undefined ages last
Gitweb showed repositories without any commit at the top in its
age-sorted view, in which the users are interested in looking at
active projects; sorting them at the bottom makes it more useful.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
(merged to 'next' on 2012-12-26 at 2ff59ab)
+ graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
* mk/qnx (2012-12-19) 2 commits
(merged to 'next' on 2012-12-22 at 0473197)
+ Port to QNX
+ Make lock local to fetch_pack
(this branch uses dm/port.)
Port to QNX.
* ms/subtree-fixlets (2012-12-22) 2 commits
(merged to 'next' on 2012-12-26 at 1cb26eb)
+ git-subtree: fix typo in manpage
+ git-subtree: ignore git-subtree executable
* nd/invalidate-i-t-a-cache-tree (2012-12-15) 4 commits
(merged to 'next' on 2012-12-18 at 33e4488)
+ cache-tree: invalidate i-t-a paths after generating trees
+ cache-tree: fix writing cache-tree when CE_REMOVE is present
+ cache-tree: replace "for" loops in update_one with "while" loops
+ cache-tree: remove dead i-t-a code in verify_cache()
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ launch_editor: propagate signals from editor to git
+ run-command: do not warn about child death from terminal
+ launch_editor: ignore terminal signals while editor has control
+ launch_editor: refactor to use start/finish_command
+ run-command: drop silent_exec_failure arg from wait_or_whine
The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
* rb/http-cert-cred-no-username-prompt (2012-12-21) 1 commit
(merged to 'next' on 2012-12-22 at 9fc28ed)
+ http.c: Avoid username prompt for certifcate credentials
It is wrong to ask for username if the authentication is done by
certificate identity.
* sp/shortlog-missing-lf (2012-12-11) 2 commits
(merged to 'next' on 2012-12-11 at 64b8429)
+ strbuf_add_wrapped*(): Remove unused return value
+ shortlog: fix wrapping lines of wraplen
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
* ss/nedmalloc-compilation (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at c1f0d7f)
+ nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2
* ss/svn-prompt (2012-12-17) 3 commits
(merged to 'next' on 2012-12-26 at 1012ae2)
+ git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
+ perl/Git.pm: Honor SSH_ASKPASS as fallback if GIT_ASKPASS is not set
+ git-svn, perl/Git.pm: add central method for prompting passwords
Tweak the way "git svn" asks for password to be in line with the
rest of the system, so that the same SSH/GIT_ASKPASS can be used.
--------------------------------------------------
[Stalled]
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
But this does not yet do so (does not remove the checkout of the
submodule). The design discussion petered out.
http://thread.gmane.org/gmane.comp.version-control.git/210867/focus=211456
Will kick back to 'pu'.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
Will kick back to 'pu'.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jc/doc-default-format (2013-01-03) 2 commits
- Allow installing a non-default set of documentation
- Allow generating a non-default set of documentation
Instead of the default of generating html/man and installing man,
you can control what "make doc" and "make install-doc" do via two
make variables.
Will merge to 'next'.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
In the longer term, tightening rules is a good thing to do, and
because nobody who has worked in the remote helper area seems to be
interested in reviewing this, I would assume they do not think
such a retroactive tightening will affect their remote helpers. So
let's advance this topic to see what happens.
* fc/remote-bzr (2013-01-02) 9 commits
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree upon pushing
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr, with minimum fix squashed in.
Will merge to 'next'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
As nobody seems to be stepping up to review this, I am tempted to
merge this to 'next and see who screams.
* jc/submittingpatches (2013-01-02) 4 commits
- SubmittingPatches: give list and maintainer addresses
- SubmittingPatches: remove overlong checklist
- SubmittingPatches: mention subsystems with dedicated repositories
- SubmittingPatches: who am I and who cares?
Will merge to 'next'.
* kb/maint-bundle-doc (2013-01-01) 2 commits
- Documentation: full-ness of a bundle is significant for cloning
- Documentation: correct example restore from bundle
Will merge to 'next'.
* nd/maint-branch-desc-doc (2013-01-03) 5 commits
- format-patch: pick up branch description when no ref is specified
- format-patch: pick up correct branch name from symbolic ref
- t4014: a few more tests on cover letter using branch description
- branch: delete branch description if it's empty
- config.txt: a few lines about branch.<name>.description
Will merge to 'next'.
* tb/test-t9020-no-which (2013-01-01) 1 commit
- t9020: which is not portable
Will merge to 'next'.
* tb/test-t9810-no-sed-i (2013-01-01) 1 commit
- t9810: Do not use sed -i
Will merge to 'next'.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
(merged to 'next' on 2013-01-02 at b9db3a2)
+ rebase: Handle cases where format-patch fails
Save output from format-patch command in a temporary file, just in
case it aborts, to give a better failure-case behaviour.
* ap/status-ignored-in-ignored-directory (2013-01-01) 2 commits
- git-status: Test --ignored behavior
- dir.c: Make git-status --ignored more consistent
Will merge to 'next'.
* ta/remove-stale-translated-tut (2012-12-27) 1 commit
(merged to 'next' on 2013-01-02 at e70df8e)
+ Remove Documentation/pt_BR/gittutorial.txt
Remove a translation of a document that was left stale.
* er/stop-recommending-parsecvs (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at fd816dd)
+ Remove the suggestion to use parsecvs, which is currently broken.
Stop recommending a defunct third-party software.
* as/test-name-alias-uniquely (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at e297810)
+ Use longer alias names in subdirectory tests
A few short-and-bland aliases used in the tests were interfering
with git-custom command in user's $PATH.
* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at 8795e87)
+ merge --no-edit: do not credit people involved in the side branch
Stop spending cycles to compute information to be placed on
commented lines in "merge --no-edit".
* as/check-ignore (2012-12-28) 19 commits
- Add git-check-ignore sub-command
- setup.c: document get_pathspec()
- pathspec.c: extract new validate_path() for reuse
- pathspec.c: move reusable code from builtin/add.c
- add.c: remove unused argument from validate_pathspec()
- add.c: refactor treat_gitlinks()
- dir.c: provide clear_directory() for reclaiming dir_struct memory
- dir.c: keep track of where patterns came from
- dir.c: use a single struct exclude_list per source of excludes
- dir.c: rename free_excludes() to clear_exclude_list()
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
- Improve documentation and comments regarding directory traversal API
- api-directory-listing.txt: update to match code
Rerolled. The early parts looked mostly fine; we may want to split
this into two topics and have the early half graduate sooner.
* jc/format-patch-reroll (2013-01-02) 9 commits
- format-patch: give --reroll-count a short synonym -v
- format-patch: document and test --reroll-count
- format-patch: add --reroll-count=$N option
- get_patch_filename(): split into two functions
- get_patch_filename(): drop "just-numbers" hack
- get_patch_filename(): simplify function signature
- builtin/log.c: stop using global patch_suffix
- builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
- builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
Will merge to 'next'.
* mz/pick-unborn (2012-12-23) 2 commits
(merged to 'next' on 2013-01-02 at 22b9951)
+ learn to pick/revert into unborn branch
+ tests: move test_cmp_rev to test-lib-functions
Allows "git cherry-pick $commit" when you do not have any history
behind HEAD yet.
* nd/retire-fnmatch (2013-01-01) 7 commits
- Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
- wildmatch: advance faster in <asterisk> + <literal> patterns
- wildmatch: make a special case for "*/" with FNM_PATHNAME
- test-wildmatch: add "perf" command to compare wildmatch and fnmatch
- wildmatch: support "no FNM_PATHNAME" mode
- wildmatch: make dowild() take arbitrary flags
- wildmatch: rename constants and update prototype
(this branch uses nd/wildmatch.)
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.
Will merge to 'next'.
* os/gitweb-highlight-uncaptured (2013-01-01) 1 commit
- gitweb: fix error in sanitize when highlight is enabled
Will merge to 'next'.
* jc/merge-blobs (2012-12-26) 5 commits
- merge-tree: fix d/f conflicts
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* jk/pathspec-literal (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at c794bd6)
+ add global --literal-pathspecs option
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
Will merge to 'master'.
* er/python-version-requirements (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at 1023a3f)
+ Add checks to Python scripts for version dependencies.
Some python scripts we ship cannot be run with old versions of the
interpreter.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* mz/oneway-merge-wo-u-no-lstat (2012-12-20) 1 commit
(merged to 'next' on 2012-12-22 at 87bd30e)
+ oneway_merge(): only lstat() when told to update worktree
Optimize "read-tree -m <tree-ish>" without "-u".
* wk/submodule-update-remote (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 7ddf897)
+ submodule add: If --branch is given, record it in .gitmodules
+ submodule update: add --remote for submodule's upstream changes
+ submodule: add get_submodule_config helper funtion
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
Will merge to 'master'.
* cc/no-gitk-build-dependency (2012-12-18) 3 commits
(merged to 'next' on 2012-12-22 at da7b2cf)
+ Makefile: replace "echo 1>..." with "echo >..."
+ Makefile: detect when PYTHON_PATH changes
+ Makefile: remove tracking of TCLTK_PATH
Remove leftover bits from an earlier change to move gitk in its own
subdirectory. Reimplementing the dependency tracking rules needs
to be done in gitk history separately.
Will merge to 'master'.
* jc/format-color-auto (2012-12-17) 2 commits
(merged to 'next' on 2012-12-18 at 5aaac94)
+ log --format: teach %C(auto,black) to respect color config
+ t6006: clean up whitespace
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
Will merge to 'master'.
* zk/clean-report-failure (2013-01-02) 2 commits
- (SQUASH???) fix-up only the trivial bits
- git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Rerolled, and comments sent.
* mp/complete-paths (2012-12-21) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts' review.
* ja/directory-attrs (2012-12-17) 1 commit
(merged to 'next' on 2012-12-17 at ced8e73)
+ Add directory pattern matching to attributes
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
Will merge to 'master'.
* jk/mailmap-from-blob (2012-12-13) 5 commits
(merged to 'next' on 2012-12-17 at 14b7cdc)
+ mailmap: default mailmap.blob in bare repositories
+ mailmap: fix some documentation loose-ends for mailmap.blob
+ mailmap: clean up read_mailmap error handling
+ mailmap: support reading mailmap from blobs
+ mailmap: refactor mailmap parsing for non-file sources
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
Will merge to 'master'.
* jk/complete-commit-c (2012-12-15) 1 commit
(merged to 'next' on 2012-12-18 at 75b5f21)
+ completion: complete refs for "git commit -c"
Complete "git commmit -c foo<TAB>" into a refname that begins with
"foo".
Will merge to 'master'.
* jk/error-const-return (2012-12-15) 2 commits
(merged to 'next' on 2012-12-22 at bf2b1cd)
+ silence some -Wuninitialized false positives
+ make error()'s constant return value more visible
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings. Looks somewhat ugly but not too much.
Will merge to 'master'.
* ap/log-mailmap (2012-12-27) 10 commits
- log --use-mailmap: optimize for cases without --author/--committer search
- log: add log.mailmap configuration option
- log: grep author/committer using mailmap
- test: Add test for --use-mailmap option
- log: Add --use-mailmap option
- pretty: Use mailmap to display username and email
- mailmap: Add mailmap structure to rev_info and pp
- mailmap: Simplify map_user() interface
- mailmap: Remove buffer length limit in map_user
- Use split_ident_line to parse author and committer
(this branch is used by jc/mailmap.)
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
Expecting a reroll.
$gmane/212426
* jc/fetch-ignore-symref (2012-12-11) 1 commit
(merged to 'next' on 2012-12-17 at 370e2c8)
+ fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
Will merge to 'master'.
* bc/append-signed-off-by (2013-01-01) 12 commits
- t4014: do not use echo -n
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a reroll.
$gmane/212507
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
Will merge to 'master'.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will merge to 'master'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
Deal with a situation where .config/git is a file and we notice
.config/git/config is not readable due to ENOTDIR, not ENOENT.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will merge to 'master'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will merge to 'master'.
* nd/wildmatch (2013-01-01) 18 commits
(merged to 'next' on 2013-01-01 at 8c633a5)
+ wildmatch: replace variable 'special' with better named ones
+ compat/fnmatch: respect NO_FNMATCH* even on glibc
+ wildmatch: fix "**" special case
(merged to 'next' on 2012-12-15 at c734714)
+ t3070: Disable some failing fnmatch tests
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch is used by nd/retire-fnmatch.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
Will merge to 'master'.
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Stefano Lattarini @ 2013-01-03 19:28 UTC (permalink / raw)
To: Greg Troxel; +Cc: Junio C Hamano, git
In-Reply-To: <rmiobh6rujt.fsf@fnord.ir.bbn.com>
On 01/03/2013 07:27 PM, Greg Troxel wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I forgot to mention that we also ship configure (and keep track of
>> configure.ac) so that optionally people can let autoconf machinery
>> to create config.mak.autogen to be included at the same place as
>> handcrafted config.mak in their build process. I do not offhand
>> know if we do "for p in python python2.6 python2.7; do ..." kind of
>> thing, though.
>
> pkgsrc uses the configure method, but it seems not to output a
> PYTHON_PATH. It looks like automake's python.m4 is not used by git's
> configure.ac.
>
That is not surprising, since Git build system doesn't use Automake :-)
In addition, it's worth nothing that Automake's python support (both
in its m4 and make components) is intended as an help to install python
*modules* from Autotools-based packages; using it for mere stand-alone
scripts would be overkill.
In the case of Git, an adapted version of something like this might
be enough:
AC_CHECK_PROGS([PYTHON], [python python2.7 python2.6 python2.5])
if test -z "$PYTHON"; then
AC_MSG_WARNING([python not found])
fi
$PYTHON -c 'check-not-py3k' || AC_MSG_WARNING([Python 3 is not supported])
$PYTHON -c 'check-its-version' || AC_MSG_WARNING([python is too old])
(Automake itself uses, in its own build system, a similar idiom to
look for a Perl interpreter at configure runtime).
Not my itch so far, but I will happily review a patch if anyone is
willing to write it.
> But pkgsrc passes PYTHON_PATH in the environment to make,
> so it works out currently.
>
>> It refers to the type of the second parameter to iconv(); OLD_ICONV
>> makes it take "const char *", as opposed to "char *", the latter of
>> which matches
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
>
> Thanks - I now see our extra const and am looking into it.
Regards,
Stefano
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Jeff King @ 2013-01-03 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vehi2xote.fsf@alter.siamese.dyndns.org>
On Thu, Jan 03, 2013 at 07:34:53AM -0800, Junio C Hamano wrote:
> > Good point; I was just thinking about the --reset case.
> >
> > With "-m", though, we could in theory carry over the unmerged entries
> > (again, assuming that "old" and "new" are the same; otherwise it is an
> > obvious reject). But those entries would be confused with any new
> > unmerged entries we create. It seems we already protect against this,
> > though: "read-tree -m" will not run at all if you have unmerged entries.
> >
> > Likewise, "checkout" seems to have similar protections.
> >
> > So I think it may be a non-issue.
>
> Yeah. Also earlier in the thread you mentioned three-way case, but
> I do not think we ever would want --reset with three trees, so I
> think that too is a non-issue for the same reason.
Yeah, agreed; we should always reject in the three-way case. I would
worry more that it has a bug where something is _not_ rejected, and we
end up putting a bogus null sha1 entry into the index (which is the
actual problem with twoway_merge). IOW, if we have the bogus sha1 in the
index (because we marked it with CE_CONFLICTED), and the two sides and
the common ancestor are all the same, would we blindly carry through the
bogus conflicted entry (which we would prefer, because it has the
up-to-date stat information)?
Or are you suggesting that the three-way case should always be protected
by checking that there are no unmerged entries before we start it? That
seems sane to me, but I haven't confirmed that that is the case.
> I would still feel safer if we expressed the expectation of
> the callee in the code, perhaps like this in the two-way case:
>
> if (current->ce_flags & CE_CONFLICTED) {
> if (!o->reset) {
> ... either die or fail ...
> } else {
> ... your fix ...
> }
> }
Agreed. I looked at that, but it seemed like it was going to involve
repeating a lot of the "are the two trees the same" logic. Let me see if
I can refactor it to avoid that.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Jeff King @ 2013-01-03 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1357239920-2201-1-git-send-email-gitster@pobox.com>
On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote:
> This allows things like:
>
> $ DEFAULT_DOC_TARGET=html make doc
> $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
>
> on a platform that does not have manpage viewer. Which is not very
> useful, given that you can already say
>
> $ make install-html
>
> on such a platform, and these install-$format targets will not go
> away.
I think the usefulness is that it can be set by default for a particular
uname, so people on Windows can just type "make install-doc" without
having to care about setting anything (though to be honest, I do not
even know what they build by default; maybe they do build manpages).
Except that in the original thread:
> http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201
it became clear that to do that we would also want to hoist the uname
automagic defaults into their own file that could be read from
Documentation/Makefile.
> The real motivation behind this was to let me say:
>
> $ git checkout $some_old_fork_point
> $ DEFAULT_DOC_TARGET=git-push.1 make doc
>
> while updating the sources to the documentation for the maintainance
> track, without having to format everything else that is different
> between the old fork point and the primary branch I usually work on.
I still don't see how this is any advantage over:
make -C Documentation git-push.1
> The first one was discussed some time ago on the list and all the
> fixes mentioned on the thread already squashed in. The second one
> is merely for completeness.
I wonder...do we really need DEFAULT_DOC_INSTALL_TARGET? Why isn't it
the same as DEFAULT_DOC_TARGET? I realize that right now we build html
and manpages by default, but only install man. But then why do we bother
building html then?
-Peff
^ 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