* Re: [PATCH 1/8] Use %B for Split Subject/Body
From: Junio C Hamano @ 2013-01-02 0:30 UTC (permalink / raw)
To: greened; +Cc: git, Techlive Zheng
In-Reply-To: <87wqvwfsfm.fsf@waller.obbligato.org>
greened@obbligato.org writes:
> Ack, of course. I don't know how I missed that.
>
>>> # 15
>>> test_expect_success 'add main6' '
>>> create main6 &&
>>
>> Why?
>
> It was in the original testsuite from Avery. I didn't add or remove any
> tests when I first integrated git-subtree.
The question was about the lossage of the blank line, which does not
seem to be related to what this patch wants to do.
>>> -# 25
>>> +#25
>>
>> Why the lossage of a SP?
>
> I think this got fixed later in the series.
That is not a good excuse to introduce breakages in the first place, no?
>> It may make sense to lose these "# num" that will have to be touched
>> every time somebody inserts new test pieces in the middle, as a
>> preparatory step before any of these patches, by the way. That will
>> reduce noise in the patches for real changes.
>
> Yeah, I know, but it makes it really easy to find a test when something
> goes wrong.
That is what "tXXXX-*.sh -i" is for, isn't it?
^ permalink raw reply
* Re: [PATCH 2/8] Add --unannotate
From: Junio C Hamano @ 2013-01-02 0:32 UTC (permalink / raw)
To: greened; +Cc: git, James Nylen
In-Reply-To: <87sj6kfsbz.fsf@waller.obbligato.org>
greened@obbligato.org writes:
> In the meantime, will you apply the patch or do you prefer a new design?
The --unannotate option will become a baggage you will have to keep
working until the end of time, if we applied it. I think it is not
too uch a baggage, so it probably is OK.
^ permalink raw reply
* Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
From: Eric S. Raymond @ 2013-01-02 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfw2k8t7k.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> So..., is this a flag-day patch?
>
> After this is merged, users who have been interoperating with CVS
> repositories with the older cvsps have to install the updated cvsps
> before using a new version of Git that ships with it?
Yes, they must install an updated cvsps. But this is hardly a loss, as
the old version was perilously broken.
There was an error or typo in the branch-analysis code, dating from
2006 and possibly earlier, that meant that branch root points would
almost always be attributed to parent patchsets one patchset earlier
than they should have been. Shocked me when I found it - how was this
missed for six years?
Because of the way the analysis is done, this fundamental bug would
also cause secondary damage like file changes near the root point
getting attributed to the wrong branch. In fact, this is how I
first spotted the problem; my test suite exhibited this symptom.
And mind you this is on top of ancestry-branch tracking not working -
two separate bugs that could interact in ways I'd really rather not
think about. The bottom line is that every import of a branchy CVS
repo with a pre-3.x version of cvsps is probably wrong.
The old git-cvsimport code was doing its part to screw things up, too.
At least three of the bugs on its manual page are problems I couldn't
reproduce using a bare cvsps instance, even the old broken version.
> As long as
> they update both cvsps and cvsimport, they can continue using the
> existing repository to get updates from the same upstream CVS
> repository without losing hisory continuity?
Yes, but in that case I would strongly advise re-importing the entire
CVS history, as the portion analyzed with 2.2b1 and earlier versions
of cvsps will almost certainly have been somewhat garbled if it
contains any branches.
> I would have preferred an addition of "git cvsimport-new" (or rename
> of the existing one to "git cvsimport-old"), with additional tests
> that compare the results of these two implemenations on simple CVS
> history that cvsimport-old did *not* screw up, to ensure that (1)
> people with existing set-up can choose to keep using the old one,
> perhaps by tweaking their process to use cvsimport-old, and (2) the
> updated one will give these people the identical conversion results,
> as long as the history they have been interacting with do not have
> the corner cases that trigger bugs in older cvsps.
>
> Or am I being too conservative?
I think you are being too conservative. This patch is *not* a mere
feature upgrade. The branch-analysis bug I found three days ago is not
a minor problem, it is a big ugly showstopper for any case beside the
simplest linear histories. Only linear histories will not break.
'People with existing set-ups' should absolutely *not* 'keep using the
old one'; we should yank that choice away from them and get the old
cvsimport/cvsps pair out of use *as fast as possible*, because it
silently mangles branchy imports.
Accordingly, giving people the idea that it's OK to use old and new
versions in parallel would be an extremely bad idea. I would go so
far as to call it irresponsible.
Here is what I have done to ease the transition:
If you try to use old git-cvsimport with new cvsps, new cvsps will detect
this and ship a message to stderr telling you to upgrade
If you try to use new git-cvsimport with old cvsps, old cvsps will complain
of an invalid argument and git-cvsimport will quit.
As for testing...cvsps now has several dozen self-tests on five
different CVS repositories, including improved versions of the
t960[123] tests. I will keep developing these as I work on bringing
parsecvs up to snuff.
I don't think there is a lot of point in git-cvsimport having its own
tests any more. If you read it I think you'll see why; it's a much
thinner wrapper around the conversion engine(s) than it used to be. In
particular, it no longer does its own protocol transactions to the
CVS server.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
From: Junio C Hamano @ 2013-01-02 1:06 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20130102003344.GA9651@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Junio C Hamano <gitster@pobox.com>:
>> So..., is this a flag-day patch?
>>
>> After this is merged, users who have been interoperating with CVS
>> repositories with the older cvsps have to install the updated cvsps
>> before using a new version of Git that ships with it?
>
> Yes, they must install an updated cvsps. But this is hardly a loss, as
> the old version was perilously broken.
>
> There was an error or typo in the branch-analysis code, dating from
> 2006 and possibly earlier, that meant that branch root points would
> almost always be attributed to parent patchsets one patchset earlier
> than they should have been. Shocked me when I found it - how was this
> missed for six years?
Would it be that not many people use branchy history in CVS, as
merging there was soooo painful?
>> Or am I being too conservative?
>
> I think you are being too conservative. This patch is *not* a mere
> feature upgrade. The branch-analysis bug I found three days ago is not
> a minor problem, it is a big ugly showstopper for any case beside the
> simplest linear histories. Only linear histories will not break.
That is exactly my point. It never worked in a branchy history, and
that is an indication that people who didn't complain and used the
old cvsimport with branch-incapable cvsps happily would have been
working with a linear history. Either nobody uses cvsimport in the
daily work, in which case a flag-day is perfectly fine, or we will
have many people who are forced to update to unproven version for no
immediate upside because the upstream repositories they work with, or
options they use cvsimport, do not trigger the multi-branch bug.
I however do understand that updating is the only sensible thing to
do for them *in the longer term*, as older cvsimport and cvsps are
no longer maintained, and sooner they update the better the chance
the new cvsimport becomes perfect earlier.
> 'People with existing set-ups' should absolutely *not* 'keep using the
> old one'; we should yank that choice away from them and get the old
> cvsimport/cvsps pair out of use *as fast as possible*, because it
> silently mangles branchy imports.
I still am not convinced, especially without a "we make sure we do
not regress in linear histories" side-by-side test in place. That
sounds irresponsible.
But others may disagree, and I'd have to sleep on it.
I'd prefer to hear from somebody who is *not* defending on his newer
implementation, but from somebody who is actively using cvsimport as
an end user. On the end-users' side, there always is this anxiety
that a radical rewrite will always introduce new bugs, even when
they know the rewrite is done very competently.
> Here is what I have done to ease the transition:
>
> If you try to use old git-cvsimport with new cvsps, new cvsps will detect
> this and ship a message to stderr telling you to upgrade
Sounds sensible.
> If you try to use new git-cvsimport with old cvsps, old cvsps will complain
> of an invalid argument and git-cvsimport will quit.
With an error message that tells the user to update cvsps, this also
sounds sensible.
^ permalink raw reply
* Makefile dependency from 'configure' to 'GIT-VERSION-FILE'
From: Martin von Zweigbergk @ 2013-01-02 1:11 UTC (permalink / raw)
To: Stefano Lattarini, Jeff King, Jonathan Nieder; +Cc: git
Hi,
I use autoconf with git.git. I have noticed lately, especially when
doing things like "git rebase -i --exec make", that ./configure is run
every time. If I understand correctly, this is because of 8242ff4
(build: reconfigure automatically if configure.ac changes,
2012-07-19). Just a few days before that commit, on 2012-07-15, the
branch jn/makefile-cleanup including 520a6cd (Makefile: move
GIT-VERSION-FILE dependencies closer to use, 2012-06-20) was merged
(to next?). I wonder if these two subjects were aware of each other.
The reason 'configure' depends on GIT-VERSION-FILE is because it
inserts the version into the call to AC_INIT. I have close to no
experience with autoconf or even make and it's not at all clear to me
why we need to pass the verison to AC_INIT. It seems like it's just
for messages printed by ./configure. If that's the case, we shouldn't
need to generate a new 'configure' file ever time. At the very least,
we shouldn't need to run it.
Do you think we should simply remove the dependency from 'configure'
to 'GIT-VERSION-FILE' and leave a comment there instead? Or should we
instead somehow make 'reconfigure' depend only on 'configure.ac'? Both
of these feel a little wrong to me, because they would remove real
dependencies. Maybe the (probably mangled) patch at the end of this
message is better?
Martin
diff --git a/Makefile b/Makefile
index 736ecd4..ec5d7ca 100644
--- a/Makefile
+++ b/Makefile
@@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
mv $@+ $@
endif # NO_PYTHON
-configure: configure.ac GIT-VERSION-FILE
- $(QUIET_GEN)$(RM) $@ $<+ && \
- sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $< > $<+ && \
- autoconf -o $@ $<+ && \
- $(RM) $<+
+configure: configure.ac
+ $(QUIET_GEN)$(RM) $@ && \
+ autoconf -o $@ $<
ifdef AUTOCONFIGURED
config.status: configure
diff --git a/configure.ac b/configure.ac
index ad215cc..00c3e38 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,7 +142,10 @@ fi
## Configure body starts here.
AC_PREREQ(2.59)
-AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
+AC_INIT([git],
+ m4_esyscmd([ ./GIT-VERSION-GEN &&
+ { sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE
| xargs echo -n; } ]),
+ [git@vger.kernel.org])
AC_CONFIG_SRCDIR([git.c])
^ permalink raw reply related
* Re: [PATCH 3/4] t4014: do not uese echo -n
From: Junio C Hamano @ 2013-01-02 1:16 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Torsten Bögershausen
In-Reply-To: <201301012241.17050.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> echo -n is not portable on all systems.
> Use printf instead
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
Brandon, this comes from 932581b (Unify appending signoff in
format-patch, commit and sequencer, 2012-11-25). Please make sure
to squash it in when you reroll the series.
Thanks (and a happy new year ;-).
> t/t4014-format-patch.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index 6cfad13..f460930 100755
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -993,7 +993,7 @@ EOF
> '
>
> test_expect_success 'signoff: commit with only subject that does not end with NL' '
> - echo -n subject | append_signoff >actual &&
> + printf subject | append_signoff >actual &&
> cat >expected <<\EOF &&
> 4:Subject: [PATCH] subject
> 8:
^ permalink raw reply
* Re: [PATCH 2/3] format-patch: pick up branch description when no ref is specified
From: Duy Nguyen @ 2013-01-02 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v38ykbpv3.fsf@alter.siamese.dyndns.org>
On Wed, Jan 2, 2013 at 3:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> find_branch_name() fails to detect "format-patch --cover-letter -3"
>> where no command line arguments are given and HEAD is automatically
>> added.
>
> Nicely spotted.
>
> That is not the only case that takes this codepath, though.
>
> $ git format-patch --cover-letter master..
>
> will also give you the same (if you say it without "..", which is
> the more normal invocation of the command, then the caller already
> know you meant the current branch and this function is not called).
>
> And in that case you will have two tokens on cmdline.nr, one for
> "master.." to show where he bottom is, and the other for the
> implied "HEAD";
Interesting. find_brach_name() handles this case wrong because
rev->cmdline[positive].name is "HEAD" and it goes ahead prepending
"refs/heads/" anyway. I'll fix it in the reroll. I was avoiding tests
with an excuse that you did not write tests when you added this
function either. But with this change, I think tests are required.
> I do not think this patch is a sufficient solution
> for the more general cases, but on the other hand I do not know how
> much it matters.
I think the best place to handle this is setup_revisions() for general
cases. But we do not need branch detection anywhere else yet, I guess
it's ok to fix it case by case here. We can move the code back to
revisions.c when there are more use cases for it.
>> - if (positive < 0)
>> + if (positive < 0) {
>> + /*
>> + * No actual ref from command line, but "HEAD" from
>> + * rev->def was added in setup_revisions()
>> + * e.g. format-patch --cover-letter -12
>> + */
>
> That comment does not describe "positive < 0" case, but belongs to
> the conditional added in this patch, no?
It's meant as the comment for the following block, yes. I'll move it
into the block for clarity.
>> + if (!rev->cmdline.nr &&
>> + rev->pending.nr == 1 &&
>> + !strcmp(rev->pending.objects[0].name, "HEAD")) {
>> + const char *ref;
>> + ref = resolve_ref_unsafe("HEAD", branch_sha1, 1, NULL);
>> + if (ref && !prefixcmp(ref, "refs/heads/"))
>> + return xstrdup(ref + strlen("refs/heads/"));
>> + }
>> 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 ||
--
Duy
^ permalink raw reply
* Re: Bug in latest gitk - can't click lines connecting commits
From: Paul Mackerras @ 2013-01-01 23:22 UTC (permalink / raw)
To: Stefan Haller; +Cc: Jason Holden, git
In-Reply-To: <1kw18d3.5sftkl125qdz4M%stefan@haller-berlin.de>
On Tue, Jan 01, 2013 at 06:54:23PM +0100, Stefan Haller wrote:
> Jason Holden <jason.k.holden.swdev@gmail.com> wrote:
>
> > I was testing some patches against the latest gitk, and noticed that when I
> > click the mouse on the lines that connect the commits in the history graph,
> > I get an error popup with:
> > Error: can't read "cflist_top": no such variable
> >
> > Looks like this was introduced in gitk commit b967135d89e8d8461d059
> > gitk: Synchronize highlighting in file view when scrolling diff
>
> A patch that fixes this was proposed over two months ago, and Paul said
> he had applied it:
>
> <http://permalink.gmane.org/gmane.comp.version-control.git/208162>
>
> However, looking at git://ozlabs.org/~paulus/gitk.git it's not there.
> Paul?
I just forgot to push it out. It's there now.
Paul.
^ permalink raw reply
* [PATCH v3] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2013-01-02 1:45 UTC (permalink / raw)
To: git; +Cc: Zoltan Klinger
(1) Only print out the names of the files and directories that got
actually deleted.
(2) Show warning message for ignored untracked git repositories
Consider the following repo layout:
test.git/
|-- tracked_dir/
| |-- some_tracked_file
| |-- some_untracked_file
|-- tracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| |-- frotz.tx
|-- untracked_some.git/
|-- some.txt
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Removing untracked_foo/
Removing untracked_some.git/
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Create a recursive delete function 'remove_dirs' in builtin/clean.c
to run in both dry_run and delete modes with the delete logic as
follows:
(a) Check if the current directory to be deleted is an untracked
git repository. If it is and --force --force option is not set
do not touch this directory, print ignore message, set dir_gone
flag to false for the caller and return.
(b) Otherwise for each item in current directory:
(i) If current directory cannot be accessed, print warning,
set dir_gone flag to false and return.
(ii) If the item is a subdirectory recurse into it,
check for the returned value of the dir_gone flag.
If the subdirectory is gone, add the name of the deleted
directory to a list of successfully removed items 'dels'.
Else set the dir_gone flag as the current directory
cannot be removed because we have at least one subdirectory
hanging around.
(iii) If it is a file try to remove it. If success add the
file name to the 'dels' list, else print error and set
dir_gone flag to false.
(c) After we finished deleting all items in the current directory and
the dir_gone flag is still true, remove the directory itself.
If failed set the dir_gone flag to false.
(d) If the current directory cannot be deleted because the dir_gone flag
has been set to false, print out all the successfully deleted items
for this directory from the 'dels' list.
(e) We're done with the current directory, return.
(2) Modify the cmd_clean() function to:
(a) call the recursive delete function 'remove_dirs()' for each
topmost directory it wants to remove
(b) check for the returned value of dir_gone flag. If it's true
print the name of the directory as being removed.
Consider the output of the improved version:
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
warning: ignoring untracked git repository untracked_foo/frotz.git
Removing untracked_foo/bar
Removing untracked_foo/emptydir
warning: ignoring untracked git repository untracked_some.git/
Now it displays only the file and directory names that got actually
deleted and shows warnings about ignored untracked git repositories.
Reported-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
---
builtin/clean.c | 149 ++++++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 120 insertions(+), 29 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..37e403a 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -10,6 +10,7 @@
#include "cache.h"
#include "dir.h"
#include "parse-options.h"
+#include "refs.h"
#include "string-list.h"
#include "quote.h"
@@ -20,6 +21,13 @@ static const char *const builtin_clean_usage[] = {
NULL
};
+static const char* MSG_REMOVE = "Removing %s\n";
+static const char* MSG_WOULD_REMOVE = "Would remove %s\n";
+static const char* MSG_WOULD_NOT_REMOVE = "Would not remove %s\n";
+static const char* MSG_WOULD_IGNORE_GIT_DIR = "Would ignore untracked git repository %s\n";
+static const char* MSG_WARN_GIT_DIR_IGNORE = "ignoring untracked git repository %s";
+static const char* MSG_WARN_REMOVE_FAILED = "failed to remove %s";
+
static int git_clean_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "clean.requireforce"))
@@ -34,11 +42,109 @@ static int exclude_cb(const struct option *opt, const char *arg, int unset)
return 0;
}
+static int remove_dirs(struct strbuf *path, const char *prefix, int force_flag,
+ int dry_run, int quiet, int *dir_gone)
+{
+ DIR *dir;
+ struct strbuf quoted = STRBUF_INIT;
+ struct dirent *e;
+ int res = 0, ret = 0, gone = 1, original_len = path->len, len, i;
+ unsigned char submodule_head[20];
+ struct string_list dels = STRING_LIST_INIT_DUP;
+
+ *dir_gone = 1;
+
+ quote_path_relative(path->buf, strlen(path->buf), "ed, prefix);
+ if ((force_flag & REMOVE_DIR_KEEP_NESTED_GIT) &&
+ !resolve_gitlink_ref(path->buf, "HEAD", submodule_head)) {
+ if (dry_run && !quiet)
+ printf(_(MSG_WOULD_IGNORE_GIT_DIR), quoted.buf);
+ else if (!dry_run)
+ warning(_(MSG_WARN_GIT_DIR_IGNORE), quoted.buf);
+
+ *dir_gone = 0;
+ return 0;
+ }
+
+ dir = opendir(path->buf);
+ if (!dir) {
+ /* an empty dir could be removed even if it is unreadble */
+ res = dry_run ? 0 : rmdir(path->buf);
+ if (res) {
+ warning(_(MSG_WARN_REMOVE_FAILED), quoted.buf);
+ *dir_gone = 0;
+ }
+ return res;
+ }
+
+ if (path->buf[original_len - 1] != '/')
+ strbuf_addch(path, '/');
+
+ len = path->len;
+ while ((e = readdir(dir)) != NULL) {
+ struct stat st;
+ if (is_dot_or_dotdot(e->d_name))
+ continue;
+
+ strbuf_setlen(path, len);
+ strbuf_addstr(path, e->d_name);
+ quote_path_relative(path->buf, strlen(path->buf), "ed, prefix);
+ if (lstat(path->buf, &st))
+ ; /* fall thru */
+ else if (S_ISDIR(st.st_mode)) {
+ if (remove_dirs(path, prefix, force_flag, dry_run, quiet, &gone))
+ ret = 1;
+ if (gone)
+ string_list_append(&dels, quoted.buf);
+ else
+ *dir_gone = 0;
+ continue;
+ } else {
+ res = dry_run ? 0 : unlink(path->buf);
+ if (!res)
+ string_list_append(&dels, quoted.buf);
+ else {
+ warning(_(MSG_WARN_REMOVE_FAILED), quoted.buf);
+ *dir_gone = 0;
+ ret = 1;
+ }
+ continue;
+ }
+
+ /* path too long, stat fails, or non-directory still exists */
+ *dir_gone = 0;
+ ret = 1;
+ break;
+ }
+ closedir(dir);
+
+ strbuf_setlen(path, original_len);
+ quote_path_relative(path->buf, strlen(path->buf), "ed, prefix);
+
+ if (*dir_gone) {
+ res = dry_run ? 0 : rmdir(path->buf);
+ if (!res)
+ *dir_gone = 1;
+ else {
+ warning(_(MSG_WARN_REMOVE_FAILED), quoted.buf);
+ *dir_gone = 0;
+ ret = 1;
+ }
+ }
+
+ if (!*dir_gone && !quiet) {
+ for (i = 0; i < dels.nr; i++)
+ printf(dry_run ? _(MSG_WOULD_REMOVE) : _(MSG_REMOVE), dels.items[i].string);
+ }
+ string_list_clear(&dels, 0);
+ return ret;
+}
+
int cmd_clean(int argc, const char **argv, const char *prefix)
{
- int i;
- int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
- int ignored_only = 0, config_set = 0, errors = 0;
+ int i, res;
+ int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int ignored_only = 0, config_set = 0, errors = 0, gone = 1;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf directory = STRBUF_INIT;
struct dir_struct dir;
@@ -49,7 +155,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
char *seen = NULL;
struct option options[] = {
OPT__QUIET(&quiet, N_("do not print names of files removed")),
- OPT__DRY_RUN(&show_only, N_("dry run")),
+ OPT__DRY_RUN(&dry_run, N_("dry run")),
OPT__FORCE(&force, N_("force")),
OPT_BOOLEAN('d', NULL, &remove_directories,
N_("remove whole directories")),
@@ -77,7 +183,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (ignored && ignored_only)
die(_("-x and -X cannot be used together"));
- if (!show_only && !force) {
+ if (!dry_run && !force) {
if (config_set)
die(_("clean.requireForce set to true and neither -n nor -f given; "
"refusing to clean"));
@@ -150,38 +256,23 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (S_ISDIR(st.st_mode)) {
strbuf_addstr(&directory, ent->name);
qname = quote_path_relative(directory.buf, directory.len, &buf, prefix);
- if (show_only && (remove_directories ||
- (matches == MATCHED_EXACTLY))) {
- printf(_("Would remove %s\n"), qname);
- } else if (remove_directories ||
- (matches == MATCHED_EXACTLY)) {
- if (!quiet)
- printf(_("Removing %s\n"), qname);
- if (remove_dir_recursively(&directory,
- rm_flags) != 0) {
- warning(_("failed to remove %s"), qname);
+ if (remove_directories || (matches == MATCHED_EXACTLY)) {
+ if (remove_dirs(&directory, prefix, rm_flags, dry_run, quiet, &gone))
errors++;
- }
- } else if (show_only) {
- printf(_("Would not remove %s\n"), qname);
- } else {
- printf(_("Not removing %s\n"), qname);
+ if (gone && !quiet)
+ printf(dry_run ? _(MSG_WOULD_REMOVE) : _(MSG_REMOVE), qname);
}
strbuf_reset(&directory);
} else {
if (pathspec && !matches)
continue;
qname = quote_path_relative(ent->name, -1, &buf, prefix);
- if (show_only) {
- printf(_("Would remove %s\n"), qname);
- continue;
- } else if (!quiet) {
- printf(_("Removing %s\n"), qname);
- }
- if (unlink(ent->name) != 0) {
- warning(_("failed to remove %s"), qname);
+ res = dry_run ? 0 : unlink(ent->name);
+ if (res) {
+ warning(_(MSG_WARN_REMOVE_FAILED), qname);
errors++;
- }
+ } else if (!quiet)
+ printf(dry_run ? _(MSG_WOULD_REMOVE) :_(MSG_REMOVE), qname);
}
}
free(seen);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
From: Jason Holden @ 2013-01-02 1:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1357082695-29713-3-git-send-email-gitster@pobox.com>
On Tue, Jan 01, 2013 at 03:24:54PM -0800, Junio C Hamano wrote:
>
> ------------------------------------------------
> +Subsystems with dedicated maintainers
> +
> +Some parts of the system have dedicated maintainers with their own
> +repositories.
> +
> + - git-gui/ comes from git-gui project, maintained by Pat Thoyts:
> +
> + git://repo.or.cz/git-gui.git
> +
> + - gitk-git/ comes from Paul Mackerras's gitk project:
> +
> + git://ozlabs.org/~paulus/gitk
> +
> + - po/ comes from the localization coordinator, Jiang Xin:
> +
> + https://github.com/git-l10n/git-po/
> +
> +Patches to these parts should be based on their trees.
> +
> +------------------------------------------------
> An ideal patch flow
>
Any reason to leave out the maintainers email addresses? If we add that, all
the content of the MAINTAINERS file we had been discussing would then be in
this file.
My only other suggestion for this series might be to augment the file with
a patch submittal example(s). I found the best example to be in
git-send-email's man page, but maybe enumerate the example out for the
most common workflows. Maybe something like:
-----------------------------------------------------------
Example of sending patches for a new feature:
Create the patches:
$ git format-patch --cover-letter -M origin/master -o outgoing/
$ edit outgoing/0000-*
To send your completed patches for initial consideration:
$ git send-email outgoing/* -to git@vger.kernel.org -cc gitster@pobox.com
To send your reviewed patches for inclusion:
$ git send-email outgoing/* -to gitster@pobox.com -cc git@vger.kernel.org
-Jason
^ permalink raw reply
* Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
From: Junio C Hamano @ 2013-01-02 2:14 UTC (permalink / raw)
To: Jason Holden; +Cc: git
In-Reply-To: <20130102015233.GA25288@gmail.com>
Jason Holden <jason.k.holden.swdev@gmail.com> writes:
> Any reason to leave out the maintainers email addresses?
Nothing particular, other than that I did not find anywhere in the
file that does not break the flow.
> My only other suggestion for this series might be to augment the file with
> a patch submittal example(s). I found the best example to be in
> git-send-email's man page,...
I'd feel better to avoid copying and pasting. If send-email has
good examples, shouldn't it be sufficient to refer to them?
> -----------------------------------------------------------
> Example of sending patches for a new feature:
>
> Create the patches:
> $ git format-patch --cover-letter -M origin/master -o outgoing/
> $ edit outgoing/0000-*
>
> To send your completed patches for initial consideration:
> $ git send-email outgoing/* -to git@vger.kernel.org -cc gitster@pobox.com
This is ambiguous; it makes it look as if you are CC'ing the
maintainer, but for the initial round, it is likely that you are
sending it to me only because I have been involved in the area the
patch touches.
> To send your reviewed patches for inclusion:
> $ git send-email outgoing/* -to gitster@pobox.com -cc git@vger.kernel.org
This is fine, but we would probably want to see it CC'ed to people
who reviewed the initial submission, too.
^ permalink raw reply
* Re: [PATCH 3/8] Better Error Handling for add
From: Junio C Hamano @ 2013-01-02 2:21 UTC (permalink / raw)
To: greened; +Cc: git
In-Reply-To: <87obh8fs8e.fsf@waller.obbligato.org>
greened@obbligato.org writes:
>> If you want to make sure you give a comit to add_commit, you can
>> probably say something like this:
>>
>> git rev-parse -q --verify "$1^{commit}" >/dev/null ||
>> die "'$1' does not refer to a commit"
>
> What does $1^{commit} mean?
"$thing^{type}" tells Git to interpret the $thing as that type (and
error out if it can't).
So v1.0.0^{commit} is a less cryptic way to say v1.0.0^0 (there is
no need to say "zeroth parent of a commit is the commit itself?
Yeah, it makes sort of sense" when you learn it).
"git cat-file -t junio-gpg-pub^{blob}" will say "blob", but you will
get a failure from "git rev-parse v1.0.0^{blob}" as you can only
dereference a tag that refers to a commit down to the comit and then
to its top-level tree, but not to a single blob.
And you can ask for the tree object with v1.0.0^{tree}, for example.
^ permalink raw reply
* Re: [PATCH 1/4] test: Add target test-lint-shell-syntax
From: Junio C Hamano @ 2013-01-02 2:22 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <50E37BD3.6060709@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> The suggestion is to run it every time the test suite is run, at the begining.
> And it seems to be fast enough:
>
> $ time ./check-non-portable-shell.pl ../../git.master/t/t[0-9]*.sh
> real 0m0.263s
> user 0m0.239s
> sys 0m0.021s
Hmph. OK.
^ permalink raw reply
* Re: [RFC] pack-objects: compression level for non-blobs
From: Duy Nguyen @ 2013-01-02 2:23 UTC (permalink / raw)
To: Shawn Pearce
Cc: Jeff King, David Michael Barr, Git Mailing List, Junio C Hamano
In-Reply-To: <CAJo=hJsZedd0kfYJnXPhcud8bz3mgU0NMf6O6-_PY1yqv-EfDg@mail.gmail.com>
On Wed, Jan 2, 2013 at 12:17 AM, Shawn Pearce <spearce@spearce.org> wrote:
>> And I was wrong. At least since 1b4bb16 (pack-objects: optimize
>> "recency order" - 2011-06-30) commits are spread out and can be mixed
>> with trees too. Grouping them back defeats what Junio did in that
>> commit, I think.
>
> I think you misunderstand what 1b4bb16 does. Junio uses a layout
> similar to what JGit has done for years. Commits are packed, then
> trees, then blobs. Only annotated tags are interspersed with commits.
> The decision on where to place tags is different, but has a similar
> purpose.
This is embarrassing. I looked at verify-pack output and somehow saw
trees mixed with commits. I must have read it wrong. "git verify-pack
-v <pack>|awk '{print $2;}'|uniq on recently created pack shows that
only tags and commits are mixed. Sorry for the noise.
--
Duy
^ permalink raw reply
* Test failures with python versions when building git 1.8.1
From: Dan McGee @ 2013-01-02 4:12 UTC (permalink / raw)
To: GIT Mailing-list, Florian Achleitner, David Michael Barr
A test case snuck in this release that assumes /usr/bin/python is
python2 and causes test failures. Unlike all other tests and code
depending on python, this one does not respect PYTHON_PATH, which we
explicitly set when building git on Arch Linux due to python2 vs
python3 differences.
-Dan
make[1]: Entering directory `/build/src/git-1.8.1/t'
rm -f -r test-results
*** prove ***
Test Summary Report
-------------------
t9020-remote-svn.sh (Wstat: 256 Tests: 6 Failed: 4)
Failed tests: 1-2, 5-6
Non-zero exit status: 1
Files=608, Tests=8772, 76 wallclock secs ( 4.07 usr 0.65 sys + 91.83
cusr 37.14 csys = 133.69 CPU)
Result: FAIL
make[1]: *** [prove] Error 1
make[1]: Leaving directory `/build/src/git-1.8.1/t'
make: *** [test] Error 2
$ contrib/svn-fe/svnrdump_sim.py
File "contrib/svn-fe/svnrdump_sim.py", line 43
print "usage: %s dump URL -rLOWER:UPPER"
^
SyntaxError: invalid syntax
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 1cfac4a..7e6148d 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -40,7 +40,7 @@ def writedump(url, lower, upper):
if __name__ == "__main__":
if not (len(sys.argv) in (3, 4, 5)):
- print "usage: %s dump URL -rLOWER:UPPER"
+ print("usage: %s dump URL -rLOWER:UPPER")
sys.exit(1)
if not sys.argv[1] == 'dump': raise NotImplementedError('only
"dump" is suppported.')
url = sys.argv[2]
^ permalink raw reply related
* Re: Test failures with python versions when building git 1.8.1
From: Junio C Hamano @ 2013-01-02 5:19 UTC (permalink / raw)
To: Dan McGee
Cc: GIT Mailing-list, Florian Achleitner, David Michael Barr,
Eric S. Raymond
In-Reply-To: <CAEik5nOqge8ix4WGf-h+0Dmz1CanH_XtQdB-CxvPsggSu1-LzQ@mail.gmail.com>
Dan McGee <dan@archlinux.org> writes:
> A test case snuck in this release that assumes /usr/bin/python is
> python2 and causes test failures. Unlike all other tests and code
> depending on python, this one does not respect PYTHON_PATH, which we
> explicitly set when building git on Arch Linux due to python2 vs
> python3 differences.
I had an impression that you are not supposed to run our scripts
with python3 yet (no python scripts have been checked for python3
compatibility), even though some people have expressed interests in
doing so.
Eric?
^ permalink raw reply
* Re: Test failures with python versions when building git 1.8.1
From: Eric S. Raymond @ 2013-01-02 5:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan McGee, GIT Mailing-list, Florian Achleitner,
David Michael Barr
In-Reply-To: <7va9ss5fhq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> Dan McGee <dan@archlinux.org> writes:
>
> > A test case snuck in this release that assumes /usr/bin/python is
> > python2 and causes test failures. Unlike all other tests and code
> > depending on python, this one does not respect PYTHON_PATH, which we
> > explicitly set when building git on Arch Linux due to python2 vs
> > python3 differences.
>
> I had an impression that you are not supposed to run our scripts
> with python3 yet (no python scripts have been checked for python3
> compatibility), even though some people have expressed interests in
> doing so.
>
> Eric?
Yeah, git's stuff is nowhere even *near* python3 ready.
I have it on my to-do list to run 2to3 on the in-tree scripts as a
diagnostic, but I haven't had time to do that yet...mainly because
cvsps/cvsimport blew up in my face when I poked at them.
Now I need to go beat parsecvs into shape and run both it and cvs2git
against the CVS torture tests I'm developing, so the 2to3 check won't
happen for a week or two at least. Sorry.
As in a general thing, I wouldn't advise worrying too much about python3
compatibility. That version is not gaining adoption very fast, mainly
due to the rat's nest around plain strings vs. UTF-8 which can make
code conversion a serious pain in the ass.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Test failures with python versions when building git 1.8.1
From: Jeff King @ 2013-01-02 6:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan McGee, GIT Mailing-list, Florian Achleitner,
David Michael Barr, Eric S. Raymond
In-Reply-To: <7va9ss5fhq.fsf@alter.siamese.dyndns.org>
On Tue, Jan 01, 2013 at 09:19:13PM -0800, Junio C Hamano wrote:
> Dan McGee <dan@archlinux.org> writes:
>
> > A test case snuck in this release that assumes /usr/bin/python is
> > python2 and causes test failures. Unlike all other tests and code
> > depending on python, this one does not respect PYTHON_PATH, which we
> > explicitly set when building git on Arch Linux due to python2 vs
> > python3 differences.
>
> I had an impression that you are not supposed to run our scripts
> with python3 yet (no python scripts have been checked for python3
> compatibility), even though some people have expressed interests in
> doing so.
>
> Eric?
Yeah, but the worrying thing to me is that we are not respecting
PYTHON_PATH. So even if Arch does everything right, it is getting
punished just for having python3 on the system at all.
I think we need to either:
1. Build contrib/svn-fe/svnrdump_sim.py into svnrdump using our normal
build procedure, which handles $PYTHON_PATH (right now we seem to
just symlink[1] it into place as svnrdump during the test script
run).
2. Create svnrdump as a shell script in the test suite to do something
like[2]:
$PYTHON_PATH "$TEST_DIRECTORY"/../contrib/svn-fe/svnrdump_sim.py
-Peff
[1] This symlink is doubly wrong, because any use of symbolic links
in the test scripts needs to depend on the SYMLINKS prereq, and this
does not.
[2] In both the current code and what I showed above, the test scripts
depend on things in contrib/. This is probably a bad idea in
general, as the quality of what goes into contrib is not as closely
watched (especially with respect to things like portability).
Certainly I would not have known to look more carefully at a patch
to contrib/svn-fe for breakage to the test suite.
FWIW, we also have this situation with t9902 (bash completion),
though the dependency is a little more obvious there. It might be
worth promoting bash completion out of contrib (or alternatively,
demoting t9902 into contrib/completion/, possibly with a feature to
make it easier to run tests out of contrib).
^ permalink raw reply
* Re: [PATCH] gitk tag delete/rename support
From: Paul Mackerras @ 2013-01-02 7:11 UTC (permalink / raw)
To: Leon KUKOVEC; +Cc: git
In-Reply-To: <1353870345-3054-1-git-send-email-leon.kukovec@gmail.com>
On Sun, Nov 25, 2012 at 08:05:45PM +0100, Leon KUKOVEC wrote:
> Right clicking on a tag pops up a menu, which allows
> tag to be renamed or deleted.
Nice idea, but I am concerned that renaming a tag that refers to a tag
object will turn it into a lightweight tag, which would be surprising
for users. I think that needs to be fixed before I apply the patch.
Also, when renaming a tag it would be good to check for the cases
where the new name is the same as the old (in which case nothing needs
to be done) and where the new name already exists.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Paul Mackerras @ 2013-01-02 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Łukasz Stelmach
In-Reply-To: <7vlidhmc5i.fsf@alter.siamese.dyndns.org>
On Sat, Dec 01, 2012 at 06:16:25PM -0800, Junio C Hamano wrote:
> Łukasz Stelmach <stlman@poczta.fm> writes:
>
> > Enable hiding of tags displayed in the tree as yellow labels.
> > If a repository is used together with a system like Gerrit
> > there may be quite a lot of tags used to control building
> > and there may be hardly any place left for commit subjects.
> >
> > Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
> > ---
>
> Paul, this patch is not done against your tree (does not have gitk
> at the top-level), but other than that, the change mimics the way
> existing hideremoes is implemented and looks reasonable to me.
>
> We _may_ want to unify these two "hidestuff" into a list of patterns
> that hides any ref that match one of the patterns in the list, e.g.
>
> set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
>
> may hide all tags, all remote-tracking branches and local branches
> that have a slash in their names.
If the concern is the amount of screen real-estate that the tags take
up when there are many of them (which is a reasonable concern), I'd
rather just put a single tag icon with "tags..." inside it and arrange
to list all the tags in the diff display pane when the user clicks on
it. I think that would be better than not showing the tags at all.
Paul.
^ permalink raw reply
* Re: Test failures with python versions when building git 1.8.1
From: Junio C Hamano @ 2013-01-02 7:18 UTC (permalink / raw)
To: Jeff King
Cc: Dan McGee, GIT Mailing-list, Florian Achleitner,
David Michael Barr, Eric S. Raymond
In-Reply-To: <20130102065345.GA8685@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [1] This symlink is doubly wrong, because any use of symbolic links
> in the test scripts needs to depend on the SYMLINKS prereq, and this
> does not.
Yeah, I think we have discussed this once already in
http://thread.gmane.org/gmane.comp.version-control.git/210688/focus=210714
> [2] In both the current code and what I showed above, the test scripts
> depend on things in contrib/. This is probably a bad idea in
> general, as the quality of what goes into contrib is not as closely
> watched (especially with respect to things like portability).
> Certainly I would not have known to look more carefully at a patch
> to contrib/svn-fe for breakage to the test suite.
As long as such tests are made skippable with appropriate
prerequisites, I do not think it is bad to have their tests in t/; I
would say it is rather better than having them in contrib/ and leave
it not run by anybody, which happened to some of the stuff in
contrib/ already.
> ... possibly with a feature to
> make it easier to run tests out of contrib).
Yes, that certainly is a workable alternative.
^ permalink raw reply
* Re: Makefile dependency from 'configure' to 'GIT-VERSION-FILE'
From: Jonathan Nieder @ 2013-01-02 7:21 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Stefano Lattarini, Jeff King, git
In-Reply-To: <CANiSa6jt7_ixi7L6U9sfpV2mvT_7zgYV+m+sLiXjkDsFehAuwA@mail.gmail.com>
Hi Martin,
Martin von Zweigbergk wrote:
> I use autoconf with git.git. I have noticed lately, especially when
> doing things like "git rebase -i --exec make", that ./configure is run
> every time. If I understand correctly, this is because of 8242ff4
> (build: reconfigure automatically if configure.ac changes,
> 2012-07-19).
How about this patch (untested)?
-- >8 --
Subject: build: do not automatically reconfigure unless configure.ac changed
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), "config.status --recheck" is
automatically run every time the "configure" script changes. In
particular, that means the configuration procedure repeats whenever
the version number changes (since the configure script changes to
support "./configure --version" and "./configure --help"), making
bisecting painfully slow.
The intent was to make the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
Reported-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
[...]
> --- a/Makefile
> +++ b/Makefile
> @@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
> mv $@+ $@
> endif # NO_PYTHON
>
> -configure: configure.ac GIT-VERSION-FILE
> +configure: configure.ac
[...]
> --- a/configure.ac
> +++ b/configure.ac
> @@ -142,7 +142,10 @@ fi
> ## Configure body starts here.
>
> AC_PREREQ(2.59)
> -AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
> +AC_INIT([git],
> + m4_esyscmd([ ./GIT-VERSION-GEN &&
> + { sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE | xargs echo -n; } ]),
> + [git@vger.kernel.org])
I don't think that would warrant dropping the GIT-VERSION-FILE
dependency, since the resulting configure script still hard-codes the
version number.
Sane?
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 736ecd45..2a22041f 100644
--- a/Makefile
+++ b/Makefile
@@ -2275,7 +2275,7 @@ configure: configure.ac GIT-VERSION-FILE
$(RM) $<+
ifdef AUTOCONFIGURED
-config.status: configure
+config.status: configure.ac
$(QUIET_GEN)if test -f config.status; then \
./config.status --recheck; \
else \
--
1.8.1
^ permalink raw reply related
* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Junio C Hamano @ 2013-01-02 7:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Łukasz Stelmach
In-Reply-To: <20130102071701.GG20724@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Sat, Dec 01, 2012 at 06:16:25PM -0800, Junio C Hamano wrote:
>> Łukasz Stelmach <stlman@poczta.fm> writes:
>>
>> > Enable hiding of tags displayed in the tree as yellow labels.
>> > If a repository is used together with a system like Gerrit
>> > there may be quite a lot of tags used to control building
>> > and there may be hardly any place left for commit subjects.
>> >
>> > Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
>> > ---
>> ...
> If the concern is the amount of screen real-estate that the tags take
> up when there are many of them (which is a reasonable concern), I'd
> rather just put a single tag icon with "tags..." inside it and arrange
> to list all the tags in the diff display pane when the user clicks on
> it. I think that would be better than not showing the tags at all.
Yeah, sounds very sensible. Thanks.
Łukasz, what do you think?
^ permalink raw reply
* Re: Makefile dependency from 'configure' to 'GIT-VERSION-FILE'
From: Martin von Zweigbergk @ 2013-01-02 7:47 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Stefano Lattarini, Jeff King, git
In-Reply-To: <20130102072141.GB18974@elie.Belkin>
On Tue, Jan 1, 2013 at 11:21 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> How about this patch (untested)?
Looks good. Thanks!
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
>> mv $@+ $@
>> endif # NO_PYTHON
>>
>> -configure: configure.ac GIT-VERSION-FILE
>> +configure: configure.ac
> [...]
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -142,7 +142,10 @@ fi
>> ## Configure body starts here.
>>
>> AC_PREREQ(2.59)
>> -AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
>> +AC_INIT([git],
>> + m4_esyscmd([ ./GIT-VERSION-GEN &&
>> + { sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE | xargs echo -n; } ]),
>> + [git@vger.kernel.org])
>
> I don't think that would warrant dropping the GIT-VERSION-FILE
> dependency, since the resulting configure script still hard-codes the
> version number.
Yeah, you're right. I was merely sweeping the dependency under the rug :-(
>
> diff --git a/Makefile b/Makefile
> index 736ecd45..2a22041f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2275,7 +2275,7 @@ configure: configure.ac GIT-VERSION-FILE
> $(RM) $<+
>
> ifdef AUTOCONFIGURED
> -config.status: configure
> +config.status: configure.ac
> $(QUIET_GEN)if test -f config.status; then \
> ./config.status --recheck; \
> else \
The next line just outside the context here does depend on
'configure', which is why I thought this would not be right. But it
seems impossible to get away from that, and AUTOCONFIGURED should only
be set when ./configure has been run (IIUC), so it's not even
realistic to have "git reconfigure" fail to find "./configure". So,
again, looks good.
^ permalink raw reply
* What's cooking in git.git (Jan 2013, #01; Tue, 1)
From: Junio C Hamano @ 2013-01-02 7:54 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 tip of the 'master' branch is at 1.8.1; the tip of 'next' will
be rewound soonish to reorder topics that are already well cooked
during the pre-release freeze earlier than the others so that they
can orderly be merged to 'master' after the dust settles, probably
towards the end of this week.
Note that many topics that have been marked as "Will cook in next"
have been recategorized to be merged to 'master' soonish, and a few
topics have been marked to be kicked back to 'pu'. Please holler if
a topic that still has unresolved issues is marked to be merged to
'master' by mistake.
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]
* jc/submittingpatches (2013-01-01) 3 commits
- SubmittingPatches: remove overlong checklist
- SubmittingPatches: mention subsystems with dedicated repositories
- SubmittingPatches: who am I and who cares?
Will reroll.
* 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-01) 3 commits
- branch: delete branch description if it's empty
- format-patch: pick up branch description when no ref is specified
- config.txt: a few lines about branch.<name>.description
Waiting for a reroll.
* 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'.
--------------------------------------------------
[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.
* fc/remote-bzr (2012-12-13) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- 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 (v3). With minor fixes, this may be ready
for '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
Needs review by folks interested in cvsserver.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- 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.
Will merge to 'next'.
* 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.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* 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 in a follow-up patch.
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/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* 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.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* 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
- Remove Documentation/pt_BR/gittutorial.txt
Remove a translation of a document that was left stale.
Will merge to 'next'.
* er/stop-recommending-parsecvs (2012-12-28) 1 commit
- Remove the suggestion to use parsecvs, which is currently broken.
Stop recommending a defunct third-party software.
Will merge to 'next'.
* as/test-name-alias-uniquely (2012-12-28) 1 commit
- 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.
Will merge to 'next'.
* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
- 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".
Will merge to 'next'.
* 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 progress earlier.
* jc/format-patch-reroll (2012-12-22) 7 commits
- 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.
Needs tests and documentation updates.
* 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
Will merge to 'master' in the first batch.
* mz/pick-unborn (2012-12-23) 2 commits
- learn to pick/revert into unborn branch
- tests: move test_cmp_rev to test-lib-functions
Will merge to 'next'.
* 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'.
* 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
Will merge to 'master' in the first batch.
* 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.
* 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 ;-)
Will merge to 'master' in the first batch.
* 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
An earlier patch to save original arguments to mkstemp() away and
use it to report what filename we failed to create incorrectly used
the buffer munged by failing mkstemp().
Will merge to 'master' in the first batch.
* 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'.
Will merge to 'master' in the first batch.
* 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'.
Will merge to 'master' in the first batch.
* 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) {}".
Will merge to 'master' in the first batch.
* 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' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* er/python-version-requirements (2012-12-28) 1 commit
- Add checks to Python scripts for version dependencies.
Will merge to 'next'.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
* 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".
Will cook in 'next'.
* 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
Race-fix for pack-refs running in parallel to ref creation.
Will merge to 'master' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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' in the first batch.
* 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' in the first batch.
* 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' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* zk/clean-report-failure (2012-12-17) 1 commit
- 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.
Expecting a reroll.
* 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' in the first batch.
* 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' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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' in the first batch.
* 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' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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'
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Will merge to 'master' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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.
Waiting for further tweaks.
* 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' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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
Will merge to 'master' in the first batch.
* 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
Will merge to 'master' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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.
Will merge to 'master' in the first batch.
* 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
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Will merge to 'master' in the first batch.
* 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.
* 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' in the first batch.
* 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' in the first batch.
* 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
Will merge to 'master' in the first batch.
* 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.
Will cook in 'next'.
* 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.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will merge to 'master' in the first batch.
* 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' in the first batch.
* 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.
Will cook in 'next'.
* 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' in the first batch.
* 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.
Will cook in 'next'.
* 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' in the first batch.
^ 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