* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Junio C Hamano @ 2012-12-10 17:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <alpine.DEB.1.00.1212101804290.32206@s15462909.onlinehome-server.info>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> My preference would be to fix it in both branches. I will fix the merge
> conflicts when rebasing onto Junio's master branch next time.
OK, then I'll queue the following to my tree.
Thanks for a quick turnaround.
-- >8 --
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Mon, 10 Dec 2012 15:42:27 +0100
Subject: [PATCH] mingw_rmdir: do not prompt for retry when non-empty
in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.
However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.
Fix this by setting errno, and guarding the prompting-loop with an
errno-check.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
compat/mingw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 4e63838..28527ab 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -256,6 +256,8 @@ int mingw_rmdir(const char *pathname)
while ((ret = rmdir(pathname)) == -1 && tries < ARRAY_SIZE(delay)) {
if (!is_file_in_use_error(GetLastError()))
+ errno = err_win_to_posix(GetLastError());
+ if (errno != EACCES)
break;
if (!is_dir_empty(pathname)) {
errno = ENOTEMPTY;
@@ -271,7 +273,7 @@ int mingw_rmdir(const char *pathname)
Sleep(delay[tries]);
tries++;
}
- while (ret == -1 && is_file_in_use_error(GetLastError()) &&
+ while (ret == -1 && errno == EACCES && is_file_in_use_error(GetLastError()) &&
ask_yes_no_if_possible("Deletion of directory '%s' failed. "
"Should I try again?", pathname))
ret = rmdir(pathname);
--
1.8.1.rc1.123.gf61cb86
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zoltan Klinger, Soren Brinkmann, git
In-Reply-To: <7v38zecrqc.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, Dec 09, 2012 at 11:04:59PM -0800, Junio C Hamano wrote:
> Zoltan Klinger <zoltan.klinger@gmail.com> writes:
>
> > Would like to get some more feedback on the proposed output in case of
> > (1) an untracked subdirectory with multiple files where at least one of them
> > cannot be removed.
> > (2) reporting ignored untracked git subdirectories
> >
> > Suppose we have a repo like the one below:
> > test.git/
> > |-- tracked_file
> > |-- untracked_file
> > |-- untracked_foo/
> > | |-- bar/
> > | | |-- bar.txt
> > | |-- emptydir/
> > | |-- frotz.git/
> > | | |-- frotx.txt
> > | |-- quux/
> > | |-- failedquux.txt
> > | |-- quux.txt
> > |-- untracked_unreadable_dir/
> > | |-- afile
> > |-- untracked_some.git/
> > |-- some.txt
> >
> > $ git clean -fd
> > Removing untracked_file
> > Removing untracked_foo/bar
> > Removing untracked_foo/emptydir
> > Removing untracked_foo/quux/quux.txt
> > warning: failed to remove untracked_foo/quux/failedquux.txt
> > warning: failed to remove remove untracked_unreadable_dir/
>
> "remove remove" is a typo, I presume.
>
> > warning: ignoring untracked git repository untracked_foo/frotz.git/
> > warning: ignoring untracked git repository untracked_some.git/
>
> If you mean "we report the topmost directory and nothing about
> (recursive) contents in it if everything is removed successfully"
> (in other words, if we had subdirectories and files inside
> untracked_foo/bar/ and we successfully removed all of them, the
> above output does not change), it seems quite reasonable.
>
> > Use git clean --force --force to delete all untracked git repositories
>
> But I am not sure if this is ever sane. Especially the one that
> removes an embedded repository is suspicious. "git clean" should
> not ever touch it with or without --superforce or any other command.
As I mentioned in my email where I reported this incorrect git clean output, I
have a use case where I want git clean to remove embedded repositories.
Whether it is a sane one is probably a different discussion.
Soren
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-10 18:03 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: Zoltan Klinger, git
In-Reply-To: <5b69a9f1-0860-41da-914c-d55a17e54092@TX2EHSMHS026.ehs.local>
Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
>> > Use git clean --force --force to delete all untracked git repositories
>>
>> But I am not sure if this is ever sane. Especially the one that
>> removes an embedded repository is suspicious. "git clean" should
>> not ever touch it with or without --superforce or any other command.
> As I mentioned in my email where I reported this incorrect git clean output, I
> have a use case where I want git clean to remove embedded repositories.
> Whether it is a sane one is probably a different discussion.
Why is it a different discussion? If something is not sane, the
tool shouldn't encourage users to do such an insane thing.
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 18:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Soren Brinkmann, Zoltan Klinger, git
In-Reply-To: <7va9tlbx8v.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 10:03:28AM -0800, Junio C Hamano wrote:
> Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
>
> >> > Use git clean --force --force to delete all untracked git repositories
> >>
> >> But I am not sure if this is ever sane. Especially the one that
> >> removes an embedded repository is suspicious. "git clean" should
> >> not ever touch it with or without --superforce or any other command.
> > As I mentioned in my email where I reported this incorrect git clean output, I
> > have a use case where I want git clean to remove embedded repositories.
> > Whether it is a sane one is probably a different discussion.
>
> Why is it a different discussion? If something is not sane, the
> tool shouldn't encourage users to do such an insane thing.
>
Well, ok. So I have a repository which essentially consists of a bunch of
scripts which then pull sources via git to build root filesystems, busybox,
kernel etc.
So I have the master repository I'm actually interested in. And then all the
other projects which are pulled in to build stuff from.
looking somehow like this:
top.git
|-src
| |-proj1.git
| |-proj2.git
| |-projn.git
|-build
|-proj1
|-proj2
...
Since the scripts are not perfect I usually used 'git clean -xdf' to wipe
everything and build from scratch. And I had to experience that the git clean
behavior somehow changed recently and the 'projn.git' directories were no longer
removed anymore, despite git indicating otherwise in its output.
So, I think having 'git clean -ff' removing embedded git repos is okay. But either
way, the output of git clean should match what it is doing. And at least tell me
if it didn't remove certain dirs or files.
Soren
^ permalink raw reply
* Use of a mailmap file with git-log
From: Rich Midwinter @ 2012-12-10 18:22 UTC (permalink / raw)
To: git
Hi
I'm working on a project for a large organisation that wants to make
widespread use of git and the mailmap feature.
This seems to be supported by default in git-shortlog but not git-log
(and other variants) without specifying custom formats, which isn't
really something I want to try and 'fix' across the organisation. Is
there a reason for this feature omission or has it just evolved that
way and could it be fixed?
Thanks
Rich
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 18:48 UTC (permalink / raw)
To: Rich Midwinter; +Cc: git
In-Reply-To: <CALKB1SXdNVsQop5VYmShOMx93+j5SPdkGF9yNU5k7nXg87TwMw@mail.gmail.com>
Rich Midwinter <rich.midwinter@gmail.com> writes:
> I'm working on a project for a large organisation that wants to make
> widespread use of git and the mailmap feature.
>
> This seems to be supported by default in git-shortlog but not git-log
> (and other variants) without specifying custom formats, which isn't
> really something I want to try and 'fix' across the organisation. Is
> there a reason for this feature omission or has it just evolved that
> way and could it be fixed?
I think it was pretty much the latter, but people may already be
depending on the command to give them the "true as recorded back
then" names in the output. A fix may have to involve inventing a
new option "log --use-mailmap" that is explicitly given from the
command line.
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-10 18:53 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: Zoltan Klinger, git
In-Reply-To: <aecaf65e-2b7f-4309-a7b5-622c7779de17@DB3EHSMHS018.ehs.local>
Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
> But either
> way, the output of git clean should match what it is doing. And at least tell me
> if it didn't remove certain dirs or files.
Oh, no question about that part. I was reacting to --force --force
in general, and an unrelated git repository inside a working tree is
just a subset of the issue.
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 19:43 UTC (permalink / raw)
To: git; +Cc: Rich Midwinter
In-Reply-To: <7v38zdbv6d.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Rich Midwinter <rich.midwinter@gmail.com> writes:
>
>> I'm working on a project for a large organisation that wants to make
>> widespread use of git and the mailmap feature.
>>
>> This seems to be supported by default in git-shortlog but not git-log
>> (and other variants) without specifying custom formats, which isn't
>> really something I want to try and 'fix' across the organisation. Is
>> there a reason for this feature omission or has it just evolved that
>> way and could it be fixed?
>
> I think it was pretty much the latter, but people may already be
> depending on the command to give them the "true as recorded back
> then" names in the output. A fix may have to involve inventing a
> new option "log --use-mailmap" that is explicitly given from the
> command line.
If somebody wants to do this, I think the overall design should go
like this:
* We may want to rewrite blame.c::get_ac_line() and the code in
pretty.c::pp_user_info() that parse author/committer lines by
using ident.c::split_ident_line() for better code reuse as a
preparation step before all of the below.
* We may want to lift the buffer length limit from the implementation
of mailmap.c::map_user() by using the strbuf API as a preparation
step before all of the below.
* We may also want to rethink its signature (we may want to get a
single strbuf and have the function parse out "Name <mail>"; I
didn't check the existing callers to see if that would make it
easier to use, and if it does not, this obviously shouldn't be done)
as a preparation step before all of the below.
* Introduce a new "struct string_list *mailmap" member to "struct
pretty_print_context" and "struct rev_info" (default to NULL);
* In log-tree.c::show_log(), copy opt->mailmap to ctx.mailmap;
* Update pretty.c::pp_user_info() to convert the email address on
"line" (between the beginning and "namelen") by calling
map_user() immediately after it parses time/tz out, and adjust
the remainder of the function to use it, when pp->mailmap is
present;
* Teach log.c::cmd_log_init_finosh() about "--use-mailmap" option.
Allocate one "struct string_list" instance and use read_mailmap()
on it when the option is used, and store it in rev->mailmap.
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Antoine Pelisse @ 2012-12-10 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rich Midwinter, git
In-Reply-To: <7v38zdbv6d.fsf@alter.siamese.dyndns.org>
Hi,
I was thinking about that last week.
It could indeed be very interesting to have mailmap applied to git-log and
especially to git-log --author/--committer.
My first look at the code let me think that we would need to change the
parse_commit_buffer to replace, at reading time, the name of author and
committer if an option (--use-mailmap seems like a wise choice) and
probably a config option.
The choice of parse_commit_buffer to do the modification is due to
the grepping being done directly on buffer when grepping author/committerer.
Yet I'm afraid it could be:
1. expensive to rewrite all commit log (reallocating the buffer)
2. Inappropriate to change the value in function that is supposed to
read
My 2 cents.
Cheers,
On Mon, Dec 10, 2012 at 7:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Rich Midwinter <rich.midwinter@gmail.com> writes:
>
>> I'm working on a project for a large organisation that wants to make
>> widespread use of git and the mailmap feature.
>>
>> This seems to be supported by default in git-shortlog but not git-log
>> (and other variants) without specifying custom formats, which isn't
>> really something I want to try and 'fix' across the organisation. Is
>> there a reason for this feature omission or has it just evolved that
>> way and could it be fixed?
>
> I think it was pretty much the latter, but people may already be
> depending on the command to give them the "true as recorded back
> then" names in the output. A fix may have to involve inventing a
> new option "log --use-mailmap" that is explicitly given from the
> command line.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 20:05 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Rich Midwinter, git
In-Reply-To: <CALWbr2ydMkR_O-Gev7k-HjGadRJMv0UH3XdqtM0Jt=vC82GwJw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> Yet I'm afraid it could be:
> 1. expensive to rewrite all commit log (reallocating the buffer)
> 2. Inappropriate to change the value in function that is supposed to
> read
In my suggestion I avoided rewriting the log buffer, primarily
because of #2 (in addition to "read" cleanliness, such a change may
break the gpg signature checking for merges).
We do reencode the contents before we write it out when "encoding"
is present, so logically such a rewrite of authors and committers
belongs to where that happens, in pretty_print_commit(). Note that
this existing rewrite is not done to the commit log buffer but is to
a separate buffer meant to be used only for output.
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 20:16 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Rich Midwinter, git
In-Reply-To: <CALWbr2ydMkR_O-Gev7k-HjGadRJMv0UH3XdqtM0Jt=vC82GwJw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> It could indeed be very interesting to have mailmap applied to git-log and
> especially to git-log --author/--committer.
> ...
> The choice of parse_commit_buffer to do the modification is due to
> the grepping being done directly on buffer when grepping author/committerer.
For pattern matching, I think revision.c::commit_match() is probably
the right place to do this kind of thing. I just noticed that we
grep for the string inside a raw buffer, even when "encoding" is
specified, which I think is a bug.
^ permalink raw reply
* [PATCH] format_commit_message(): simplify calls to logmsg_reencode()
From: Junio C Hamano @ 2012-12-10 20:57 UTC (permalink / raw)
To: git
All the other callers of logmsg_reencode() pass return value of
get_commit_output_encoding() or get_log_output_encoding(). Teach
the function to optionally take NULL as a synonym to "" aka "no
conversion requested" so that we can simplify the only remaining
calling site.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pretty.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/pretty.c b/pretty.c
index e87fe9f..732e2a2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -500,7 +500,7 @@ char *logmsg_reencode(const struct commit *commit,
char *encoding;
char *out;
- if (!*output_encoding)
+ if (!output_encoding || !*output_encoding)
return NULL;
encoding = get_header(commit, "encoding");
use_encoding = encoding ? encoding : utf8;
@@ -1184,23 +1184,15 @@ void format_commit_message(const struct commit *commit,
const struct pretty_print_context *pretty_ctx)
{
struct format_commit_context context;
- static const char utf8[] = "UTF-8";
const char *output_enc = pretty_ctx->output_encoding;
memset(&context, 0, sizeof(context));
context.commit = commit;
context.pretty_ctx = pretty_ctx;
context.wrap_start = sb->len;
- context.message = commit->buffer;
- if (output_enc) {
- char *enc = get_header(commit, "encoding");
- if (strcmp(enc ? enc : utf8, output_enc)) {
- context.message = logmsg_reencode(commit, output_enc);
- if (!context.message)
- context.message = commit->buffer;
- }
- free(enc);
- }
+ context.message = logmsg_reencode(commit, output_enc);
+ if (!context.message)
+ context.message = commit->buffer;
strbuf_expand(sb, format, format_commit_item, &context);
rewrap_message_tail(sb, &context, 0, 0, 0);
--
1.8.1.rc1.123.gf61cb86
^ permalink raw reply related
* Re: Millisecond precision in timestamps?
From: James Cloos @ 2012-12-10 20:56 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Junio C Hamano, Jeff King, Shawn Pearce, Felipe Contreras, git
In-Reply-To: <20121128075807.GA9912@thyrsus.com>
>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:
ESR> I've never seen a software project under version control with bits
ESR> that old,
They do exist, but the vcs timestamps are (at least for those in git :)
not (always) correlated to when the files were first added to the project.
Maxima, as an example, has code which was written in the '60s. (A
couple of years ago a bug was fixed in a contrib module which had
been added to MACSYMA back in '62 or so.)
I beleive axiom also has some similarly ancient code.
Those two are now managed in git. (Except for the openaxiom fork.)
And there is a high-energy physics package still under development
with code going back to the '50s. I'm pretty sure they moved to a
vcs sometime in the last decade or two. :)
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply
* [ANNOUNCE] Git v1.8.0.2
From: Junio C Hamano @ 2012-12-10 22:17 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.0.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
1e1640794596da40f35194c29a8cc4e41c6b4f6d git-1.8.0.2.tar.gz
6b9e14c5b19b2e27605014252febd61a700012a3 git-htmldocs-1.8.0.2.tar.gz
ce0673256ce90451269a82a2464eab060adbfec6 git-manpages-1.8.0.2.tar.gz
Also the following public repositories all have a copy of the v1.8.0.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.0.2 Release Notes
==========================
Fixes since v1.8.0.1
--------------------
* Various codepaths have workaround for a common misconfiguration to
spell "UTF-8" as "utf8", but it was not used uniformly. Most
notably, mailinfo (which is used by "git am") lacked this support.
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* "git update-ref -d --deref SYM" to delete a ref through a symbolic
ref that points to it did not remove it correctly.
* Syntax highlighting in "gitweb" was not quite working.
Also contains other minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.8.0.1 are as follows:
Antoine Pelisse (1):
Fix typo in remote set-head usage
Eric S. Raymond (1):
doc/fast-import: clarify how content states are built
Johan Herland (2):
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Fix failure to delete a packed ref through a symref
Junio C Hamano (13):
reencode_string(): introduce and use same_encoding()
test: add failing tests for "diff --stat" to t4049
diff --stat: status of unmodified pair in diff-q is not zero
diff --stat: use "file" temporary variable to refer to data->files[i]
diff --stat: move the "total count" logic to the last loop
diff --stat: do not count "unmerged" entries
diff --shortstat: do not count "unmerged" entries
Documentation/git-push.txt: clarify the "push from satellite" workflow
Start preparing for 1.8.0.2
t4049: refocus tests
Update draft release notes to 1.8.0.2
git(1): remove a defunct link to "list of authors"
Git 1.8.0.2
Linus Torvalds (1):
Fix "git diff --stat" for interesting - but empty - file changes
Mark Szepieniec (1):
Documentation: improve phrasing in git-push.txt
Matthieu Moy (2):
git-remote-mediawiki: escape ", \, and LF in file names
git-fast-import.txt: improve documentation for quoted paths
Nguyễn Thái Ngọc Duy (1):
compat/fnmatch: fix off-by-one character class's length check
Paul Gortmaker (1):
Makefile: hide stderr of curl-config test
Pete Wyckoff (1):
git p4: RCS expansion should not span newlines
Ralf Thielow (1):
completion: add options --single-branch and --branch to "git clone"
Richard Hubbell (1):
gitweb.perl: fix %highlight_ext mappings
Sébastien Loriot (1):
Documentation/git-stash.txt: add a missing verb
W. Trevor King (1):
git-submodule: wrap branch option with "<>" in usage strings.
^ permalink raw reply
* What's cooking in git.git (Dec 2012, #02; Mon, 10)
From: Junio C Hamano @ 2012-12-10 23:16 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'.
A new maintenance release 1.8.0.2 was tagged with accumulated fixes
we have already been using on the 'master' front for a while. The
tip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are
getting into good shape in 'next', hopefully ready to be merged soon
after the 1.8.1 final.
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]
* ef/mingw-rmdir (2012-12-10) 1 commit
- mingw_rmdir: do not prompt for retry when non-empty
MinGW has a workaround when rmdir unnecessarily fails to retry with
a prompt, but the logic was kicking in when the rmdir failed with
ENOTEMPTY, i.e. was expected to fail and there is no point retrying.
Will fast-track to 'master'.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
- sh-setup: work around "unset IFS" bug in some shells
Will merge to 'next'.
* jc/merge-blobs (2012-12-09) 4 commits
- 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.
* jc/same-encoding (2012-12-10) 1 commit
- 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.
* nd/invalidate-i-t-a-cache-tree (2012-12-09) 1 commit
- cache-tree: invalidate i-t-a paths after generating trees
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
--------------------------------------------------
[Graduated to "master"]
* rr/t4041-cleanup (2012-12-02) 4 commits
(merged to 'next' on 2012-12-04 at ecee35d)
+ t4041 (diff-submodule-option): modernize style
+ t4041 (diff-submodule-option): rewrite add_file() routine
+ t4041 (diff-submodule-option): parse digests sensibly
+ t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
Test clean-up.
--------------------------------------------------
[Stalled]
* fc/remote-bzr (2012-11-28) 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
- 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.
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- 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
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* 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.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* 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.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- 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 ;-)
Anybody who worked on "--graph" wants to comment?
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 re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* ef/mingw-tty-getpass (2012-12-04) 6 commits
(merged to 'next' on 2012-12-07 at 1737ff1)
+ mingw: get rid of getpass implementation
+ mingw: reuse tty-version of git_terminal_prompt
+ compat/terminal: separate input and output handles
+ compat/terminal: factor out echo-disabling
+ mingw: make fgetc raise SIGINT if apropriate
+ mingw: correct exit-code for SIGALRM's SIG_DFL
Update getpass() emulation for MinGW.
Will fast-track to 'master'.
* 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.
Will cook in 'next'.
* sl/git-svn-docs (2012-12-05) 4 commits
(merged to 'next' on 2012-12-07 at 5bfbb73)
+ git-svn: Note about tags.
+ git-svn: Expand documentation for --follow-parent
+ git-svn: Recommend use of structure options.
+ git-svn: Document branches with at-sign(@).
Will cook in 'next'.
* 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 cook in 'next'.
* bc/append-signed-off-by (2012-11-26) 11 commits
- 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 re-roll after a review.
* 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 cook in 'next'.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* 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 cook in 'next'.
* mh/doc-remote-helpers (2012-12-07) 6 commits
(merged to 'next' on 2012-12-07 at 7ac8c25)
+ git-remote-helpers.txt: clarify options & ref list attributes
+ git-remote-helpers.txt: clarify command <-> capability correspondences
+ git-remote-helpers.txt: rearrange description of capabilities
+ git-remote-helpers.txt: minor grammar fix
+ git-remote-helpers.txt: document missing capabilities
+ git-remote-helpers.txt: document invocation before input format
Will cook in 'next'.
* 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 cook in 'next'.
* 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
An RFC to 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 cook in 'next'.
* 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 cook in 'next'.
* 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 cook in 'next'.
* nd/wildmatch (2012-11-20) 14 commits
(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
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
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 cook in 'next'.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2012-12-10 23:16 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.8.0 done on
Oct 21, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.0.2. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- 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/
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
design and implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre for helping with packfile design and
implementation issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
cvsserver and cvsimport.
- Paul Mackerras for gitk.
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
Bilotta for maintaining and enhancing gitweb.
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
Xin for volunteering to be the l10n coordinator.
- Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
Porcelains.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard for Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Patrick Donnelly @ 2012-12-11 5:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Michael Haggerty, Felipe Contreras, Eric S. Raymond, git
In-Reply-To: <CACsJy8BgOpWdxgCfwBwZ=abAEDr+sbj3hnmKY2EYCFeBPRUT7w@mail.gmail.com>
Sorry I'm late to this party...
I'm an Nmap developer that is casually interested in git development.
I've been lurking for a while and thought I'd post my thoughts on this
thread.
On Sun, Nov 25, 2012 at 6:25 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> The most important issues to consider when imagining a future with a
>> hybrid of code in C and some scripting language "X" are:
>>
>> * Portability: is "X" available on all platforms targeted by git, in
>> usable and mutually-compatible versions?
>>
>> * Startup time: Is the time to start the "X" interpreter prohibitive?
>> (On my computer, "python -c pass", which starts the Python
>> interpreter and does nothing, takes about 24ms.) This overhead would
>> be incurred by every command that is not pure C.
>>
>> * Should the scripting language access the C functionality only by
>> calling pure-C executables or by dynamically or statically linking to
>> a binary module interface? If the former, then the granularity of
>> interactions between "X" and C is necessarily coarse, and "X" cannot
>> be used to implement anything but the outermost layer of
>> functionality. If the latter, then the way would be clear to
>> implement much more of git in "X" (and lua would also be worth
>> considering).
>>
>> * Learning curve for developers: how difficult is it for a typical git
>> developer to become conversant with "X", considering both (1) how
>> likely is it that the typical git developer already knows "X" and
>> (2) how straightforward and predictable is the language "X"?
>> In this category I think that Python has a huge advantage over
>> Perl, though certainly opinions will differ and Ruby would also be
>> a contender.
>
> * We might also need an embedded language variant, like Jeff's lua
> experiment. I'd be nice if "X" can also take this role.
Lua has been an incredible success for Nmap [2](and other projects).
As an embedded scripting language, it's unrivaled in terms of ease of
embedding, ease of use for users, and performance. I would strongly
recommend the git developers to seriously consider it.
Addressing the points listed above:
>> * Portability: is "X" available on all platforms targeted by git, in
>> usable and mutually-compatible versions?
Lua is written in ANSI C and so compiles basically anywhere (certainly
anywhere git does).
>> * Startup time: Is the time to start the "X" interpreter prohibitive?
>> (On my computer, "python -c pass", which starts the Python
>> interpreter and does nothing, takes about 24ms.) This overhead would
>> be incurred by every command that is not pure C.
As mentioned elsewhere in this thread by Joshua:
"Because Lua was mentioned in another message of this thread, I'll
provide the following:
* A cold run of 'lua5.1 -e ""' takes 0.4 seconds. The second run
takes 0.03 seconds.
* A cold run of LuaJIT takes the same."
The runtime figures would probably be much lower if git modules (e.g.
pull) were capable of calling other modules without forking, all
within the same Lua environment.
>> * Should the scripting language access the C functionality only by
>> calling pure-C executables or by dynamically or statically linking to
>> a binary module interface? If the former, then the granularity of
>> interactions between "X" and C is necessarily coarse, and "X" cannot
>> be used to implement anything but the outermost layer of
>> functionality. If the latter, then the way would be clear to
>> implement much more of git in "X" (and lua would also be worth
>> considering).
Using Lua as a glue between a proper git C API and modules would be
optimal in my opinion and experience.
>> * Learning curve for developers: how difficult is it for a typical git
>> developer to become conversant with "X", considering both (1) how
>> likely is it that the typical git developer already knows "X" and
>> (2) how straightforward and predictable is the language "X"?
>> In this category I think that Python has a huge advantage over
>> Perl, though certainly opinions will differ and Ruby would also be
>> a contender.
Lua is remarkably easy to learn and is engineered so it's approachable
by novice (or non-) programmers. Still, it offers all the features you
expect from a modern scripting language including GC, real lexical
scoping and closure, tables/arrays, and *coroutines*. While Nmap
occasionally gets questions about why we didn't use Python, no one
complains about Lua itself.
As for version considerations, Lua changes at a glacial pace compared
to other popular languages like Python or Ruby. Lua 5.2 was released
last year and 5.1 was released 5 years before that [1]. Still, while
users (people who bind Lua to applications) are certainly encouraged
to upgrade Lua, there is no real need to. Binding Lua to an
application statically is not a significant cost as it compiles to
less than 200 KB including base libraries; so, it's simple and cheap
to remain independent of the system git runs on. It isn't unreasonable
-- indeed, it is common -- to select one version of Lua and keep it
for a significant lifetime of the project.
[I'd be happy to answer any questions concerning Lua and/or scripting
Git. I'd also be happy to assist in embedding Lua in Git.]
[1] http://www.lua.org/versions.html
[2] http://nmap.org/book/nse.html
--
- Patrick Donnelly
^ permalink raw reply
* [PATCH 0/2] Re: [PATCH] shortlog: Fix wrapping lines of wraplen
From: Steffen Prohaska @ 2012-12-11 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan H. Schoenherr, Steffen Prohaska
In-Reply-To: <7v8v97efdv.fsf@alter.siamese.dyndns.org>
On Dec 9, 2012, at 10:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> > A recent commit [1] fixed a off-by-one wrapping error. As
> > a side-effect, add_wrapped_shortlog_msg() needs to be changed to always
> > append a newline.
>
> Could you clarify "As a side effect" a bit more? Do you mean
> something like this?
See updated patches below.
Steffen
Steffen Prohaska (2):
shortlog: Fix wrapping lines of wraplen (was broken since recent
off-by-one fix)
strbuf_add_wrapped*(): Remove unused return value
builtin/shortlog.c | 5 ++---
t/t4201-shortlog.sh | 24 ++++++++++++++++++++++++
utf8.c | 13 ++++++-------
utf8.h | 4 ++--
4 files changed, 34 insertions(+), 12 deletions(-)
--
1.8.1.rc1.2.gfb98a3a
^ permalink raw reply
* [PATCH 2/2] strbuf_add_wrapped*(): Remove unused return value
From: Steffen Prohaska @ 2012-12-11 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan H. Schoenherr, Steffen Prohaska
In-Reply-To: <1355205562-23459-1-git-send-email-prohaska@zib.de>
Since shortlog isn't using the return value anymore (see previous
commit), the functions can be changed to void.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
utf8.c | 13 ++++++-------
utf8.h | 4 ++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/utf8.c b/utf8.c
index 5c61bbe..a4ee665 100644
--- a/utf8.c
+++ b/utf8.c
@@ -323,7 +323,7 @@ static size_t display_mode_esc_sequence_len(const char *s)
* If indent is negative, assume that already -indent columns have been
* consumed (and no extra indent is necessary for the first line).
*/
-int strbuf_add_wrapped_text(struct strbuf *buf,
+void strbuf_add_wrapped_text(struct strbuf *buf,
const char *text, int indent1, int indent2, int width)
{
int indent, w, assume_utf8 = 1;
@@ -332,7 +332,7 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
if (width <= 0) {
strbuf_add_indented_text(buf, text, indent1, indent2);
- return 1;
+ return;
}
retry:
@@ -356,14 +356,14 @@ retry:
if (w <= width || !space) {
const char *start = bol;
if (!c && text == start)
- return w;
+ return;
if (space)
start = space;
else
strbuf_addchars(buf, ' ', indent);
strbuf_add(buf, start, text - start);
if (!c)
- return w;
+ return;
space = text;
if (c == '\t')
w |= 0x07;
@@ -405,13 +405,12 @@ new_line:
}
}
-int strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
+void strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
int indent, int indent2, int width)
{
char *tmp = xstrndup(data, len);
- int r = strbuf_add_wrapped_text(buf, tmp, indent, indent2, width);
+ strbuf_add_wrapped_text(buf, tmp, indent, indent2, width);
free(tmp);
- return r;
}
int is_encoding_utf8(const char *name)
diff --git a/utf8.h b/utf8.h
index 93ef600..a214238 100644
--- a/utf8.h
+++ b/utf8.h
@@ -9,9 +9,9 @@ int is_utf8(const char *text);
int is_encoding_utf8(const char *name);
int same_encoding(const char *, const char *);
-int strbuf_add_wrapped_text(struct strbuf *buf,
+void strbuf_add_wrapped_text(struct strbuf *buf,
const char *text, int indent, int indent2, int width);
-int strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
+void strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,
int indent, int indent2, int width);
#ifndef NO_ICONV
--
1.8.1.rc1.2.gfb98a3a
^ permalink raw reply related
* [PATCH 1/2] shortlog: Fix wrapping lines of wraplen (was broken since recent off-by-one fix)
From: Steffen Prohaska @ 2012-12-11 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan H. Schoenherr, Steffen Prohaska
In-Reply-To: <1355205562-23459-1-git-send-email-prohaska@zib.de>
A recent commit [1] fixed a off-by-one wrapping error. As
a side-effect, the conditional in add_wrapped_shortlog_msg() whether to
append a newline needs to be removed. add_wrapped_shortlog_msg() should
always append a newline, which was the case before the off-by-one fix,
because strbuf_add_wrapped_text() never returned a value of wraplen.
[1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one
wrapping of text
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
builtin/shortlog.c | 5 ++---
t/t4201-shortlog.sh | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index b316cf3..8360514 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -306,9 +306,8 @@ parse_done:
static void add_wrapped_shortlog_msg(struct strbuf *sb, const char *s,
const struct shortlog *log)
{
- int col = strbuf_add_wrapped_text(sb, s, log->in1, log->in2, log->wrap);
- if (col != log->wrap)
- strbuf_addch(sb, '\n');
+ strbuf_add_wrapped_text(sb, s, log->in1, log->in2, log->wrap);
+ strbuf_addch(sb, '\n');
}
void shortlog_output(struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 6872ba1..02ac978 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -120,6 +120,30 @@ test_expect_success 'shortlog from non-git directory' '
test_cmp expect out
'
+test_expect_success 'shortlog should add newline when input line matches wraplen' '
+ cat >expect <<\EOF &&
+A U Thor (2):
+ bbbbbbbbbbbbbbbbbb: bbbbbbbb bbb bbbb bbbbbbb bb bbbb bbb bbbbb bbbbbb
+ aaaaaaaaaaaaaaaaaaaaaa: aaaaaa aaaaaaaaaa aaaa aaaaaaaa aa aaaa aa aaa
+
+EOF
+ git shortlog -w >out <<\EOF &&
+commit 0000000000000000000000000000000000000001
+Author: A U Thor <author@example.com>
+Date: Thu Apr 7 15:14:13 2005 -0700
+
+ aaaaaaaaaaaaaaaaaaaaaa: aaaaaa aaaaaaaaaa aaaa aaaaaaaa aa aaaa aa aaa
+
+commit 0000000000000000000000000000000000000002
+Author: A U Thor <author@example.com>
+Date: Thu Apr 7 15:14:13 2005 -0700
+
+ bbbbbbbbbbbbbbbbbb: bbbbbbbb bbb bbbb bbbbbbb bb bbbb bbb bbbbb bbbbbb
+
+EOF
+ test_cmp expect out
+'
+
iconvfromutf8toiso88591() {
printf "%s" "$*" | iconv -f UTF-8 -t ISO8859-1
}
--
1.8.1.rc1.2.gfb98a3a
^ permalink raw reply related
* Re: [PATCH 1/2] shortlog: Fix wrapping lines of wraplen (was broken since recent off-by-one fix)
From: "Jan H. Schönherr" @ 2012-12-11 10:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <1355205562-23459-2-git-send-email-prohaska@zib.de>
Am 11.12.2012 06:59, schrieb Steffen Prohaska:
> A recent commit [1] fixed a off-by-one wrapping error. As
> a side-effect, the conditional in add_wrapped_shortlog_msg() whether to
> append a newline needs to be removed. add_wrapped_shortlog_msg() should
> always append a newline, which was the case before the off-by-one fix,
> because strbuf_add_wrapped_text() never returned a value of wraplen.
I agree with this explanation, although there exists a case where wraplen
(or wraplen+1 after the off-by-one fix) is returned: This happens
when there is not a single space within the string and it has just the
correct length. But also in this case, the newline must be added to get
a correctly formatted output. So your patch is good as it is. :)
But I still wonder about the original motivation for the removed
conditional. It looks like, it wasn't even needed in the very first
version (3714e7c8)?! (And it wasn't present in the version on the mailing
list: http://article.gmane.org/gmane.comp.version-control.git/35221)
Regards
Jan
^ permalink raw reply
* Re: [PATCH] gitweb: Sort projects with undefined ages last
From: Matthew Daley @ 2012-12-11 10:56 UTC (permalink / raw)
To: gitster; +Cc: git, Matthew Daley
In-Reply-To: <7vip8actz3.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 7:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Yeah, it could be argued that in a very minor corner case showing
> new and empty ones at the top might attract more attention to them,
> but new and empty ones can stay inactive, so this change would be an
> overall improvement for these two sites. An alternative could be to
> give the mtime of the git directory to the age field if there is no
> commits in the repository, to sink the empty and inactive ones to
> the bottom quickly while showing newly created ones at the top, but
> it shouldn't make any practical difference.
Agreed.
> Two observations:
>
> * This iterates over the same @$projlist twice with grep, with one
> "defined" and the other "!defined", which may risk these two
> complementary grep conditions to go out of sync (it also may
> affect performance but that is a lessor issue).
>
> An alternative may be to change the expression used inside sort()
> to treat an undef as if it were a very large value, something
> like:
>
> sort {
> defined $a->{$oi->{'key'}}
> ? (defined $b->{$oi->{'key'}}
> ? ($a->{$oi->{'key'}} <=> $b->{$oi->{'key'}})
> : -1)
> : (defined $b->{$oi->{'key'}} ? 1 : 0);
> }
>
> * This "sort undefs at the end is better than at the beginning" is
> good only for the "age" field, and we wouldn't know if we would
> add other keys for which it may be better to sort undef at the
> beginning. The order_info{} currently has only one field of the
> 'num' type, so this is not an immediate issue, but in order to
> future proof, it may make sense to rewrite the sort_projects_list
> function to map the order field name to a function given to sort,
> e.g.
>
> my %order_sort = (
> project => sub { $a->{'path'} cmp $b->{'path'} },
> descr => sub { $a->{'descr_long'} cmp $b->{'descr_long'} },
> owner => sub { $a->{'owner'} cmp $b->{'owner'} },
> age => sub { ... the num cmp with undef above ... },
> );
> if (!exists $order_sort{$order}) {
> return @$projlist;
> }
> return sort $order_sort{$order} @$projlist;
>
> I am not sure the second one is worth it, though.
I thought about both of those variants as well. What about this:
-- >8 --
Subject: [PATCH] gitweb: Sort projects with undefined ages last
Sorting gitweb's project list by age ('Last Change') currently shows
projects with undefined ages at the head of the list. This gives a less
useful result when there are a number of projects that are missing or
otherwise faulty and one is trying to see what projects have been
updated recently.
Fix by sorting these projects with undefined ages at the bottom of the
list when sorting by age.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
gitweb/gitweb.perl | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0f207f2..656b324 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5528,23 +5528,30 @@ sub fill_project_list_info {
sub sort_projects_list {
my ($projlist, $order) = @_;
- my @projects;
- my %order_info = (
- project => { key => 'path', type => 'str' },
- descr => { key => 'descr_long', type => 'str' },
- owner => { key => 'owner', type => 'str' },
- age => { key => 'age', type => 'num' }
- );
- my $oi = $order_info{$order};
- return @$projlist unless defined $oi;
- if ($oi->{'type'} eq 'str') {
- @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @$projlist;
- } else {
- @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @$projlist;
+ sub order_str {
+ my $key = shift;
+ return sub { $a->{$key} cmp $b->{$key} };
}
- return @projects;
+ sub order_num_then_undef {
+ my $key = shift;
+ return sub {
+ defined $a->{$key} ?
+ (defined $b->{$key} ? $a->{$key} <=> $b->{$key} : -1) :
+ (defined $b->{$key} ? 1 : 0)
+ };
+ }
+
+ my %orderings = (
+ project => order_str('path'),
+ descr => order_str('descr_long'),
+ owner => order_str('owner'),
+ age => order_num_then_undef('age'),
+ );
+
+ my $ordering = $orderings{$order};
+ return defined $ordering ? sort $ordering @$projlist : @$projlist;
}
# returns a hash of categories, containing the list of project
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2012-12-11 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Soren Brinkmann, git
In-Reply-To: <7v38zecrqc.fsf@alter.siamese.dyndns.org>
>> Use git clean --force --force to delete all untracked git repositories
>
> But I am not sure if this is ever sane. Especially the one that
> removes an embedded repository is suspicious. "git clean" should
> not ever touch it with or without --superforce or any other command.
My original intention with this patch was to provide more accurate
delete messages for the git-clean command when it's used with the
current set of command line options. I didn't know that --force
--force was so controversial.
The --force --force option has been around since v1.6.4.2. Commit
a0f4afbe introduced it. If the consensus is that it is not a sane
option to have let's remove it by all means. But I think it should be
done in a separate patch '[PATCH] git-clean: Never delete any embedded
git repository' or such.
> I do not think trying to remove something that cannot be removed due
> to filesystem permissions is sensible, either. We simply should treat
> such a case a grave error and have the user sort things out, instead
> of blindly attempt to "chmod" them ourselves (which may still fail).
But this is not how git-clean works with or without the --force
--force flag. The recursive delete does the right thing: it tries to
delete a file or directory, if that fails for whatever reason it will
report the error and move on. That's it. No "chmod" or any other
hackery at all. The --force --force flag only means "if during
recursion you encounter an embedded git directory that is not tracked
you are allowed to recurse into it and keep on deleting files and
sub-directories as per usual".
Cheers,
Zoltan
^ permalink raw reply
* How to avoid the ^M induced by Meld and Git
From: Karl Brand @ 2012-12-11 12:33 UTC (permalink / raw)
To: git
Esteemed Git users,
What i do:
1. Create a script.r using Emacs/ESS.
2. Make some modifications to script.r with the nice diff gui, Meld
3. Commit these modifications using git commit -am "my message"
4. Reopen script.r in Emacs/ESS to continue working.
The lines added (&/edited ?) using Meld all end with ^M which i
certainly don't want. Lines not added/edited with Meld do NOT end with ^M.
There are plenty of posts around about these being line endings used for
windows which can appear when working on a script under a *nix OS which
has previously been edited in a Windows OS. This is not the case here -
everything is taking place on Ubuntu 12.04.
FWIW: the directory is being synced by dropbox; and in Meld, Preferences
> Encoding tab, "utf8" is entered in the text box.
Current work around is running in a terminal: dos2unix /path/to/script.r
which strips the ^M's
But this just shouldn't be necessary and I'd really appreciate the
reflections & advice on how to stop inducing these ^M's !
With thanks,
Karl
(re)posted here as suggested off topic at SO:
http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m
--
Karl Brand
Dept of Cardiology and Dept of Bioinformatics
Erasmus MC
Dr Molewaterplein 50
3015 GE Rotterdam
T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161
^ permalink raw reply
* [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-11 14:39 UTC (permalink / raw)
To: git list
There seems to be some bad interactions between git-push and grafts.
The problem seems to occur when a commit that exists in the remote
repo is subject to a graft in the local repo, and we try to push one
of the fake parents.
The problem was first seen on 1.7.12.3 in a private repo, and I could
reproduce it using 1.8.1.rc0, as shown below. 1.7.10.4 seems even
more affected, with something looking like a memory corruption issue.
Here is the test:
$ git clone git.git git-test
Cloning into 'git-test'...
done.
Checking out files: 100% (2518/2518), done.
$ cd git-test/
git-test$ git co maint
Branch maint set up to track remote branch maint from origin.
Switched to a new branch 'maint'
git-test$ echo >> README
git-test$ git commit -a -m "test"
[maint 0708279] test
1 file changed, 1 insertion(+)
git-test$ echo $(git rev-parse origin/master; git rev-parse origin/master^; git rev-parse HEAD) > .git/info/grafts
git-test$ git version
git version 1.8.1.rc0
git-test$ git push origin maint
Total 0 (delta 0), reused 0 (delta 0)
fatal: bad object 0708279e168b52003234dd23601796b3b12e278b
fatal: bad object 0708279e168b52003234dd23601796b3b12e278b
To /home/localadm/softs/git.git
! [remote rejected] maint -> maint (missing necessary objects)
error: failed to push some refs to '/home/localadm/softs/git.git'
$ git version
git version 1.7.10.4
git-test$ git push origin maint
Total 0 (delta 0), reused 0 (delta 0)
fatal: bad object 0708279e168b52003234dd23601796b3b12e278b
fatal: bad object 0708279e168b52003234dd23601796b3b12e278b
Auto packing the repository for optimum performance.
fatal: protocol error: bad line length character: Remo
error: error in sideband demultiplexer
error: >S��ŋJ�jB�;�x'��R died of signal 13
To /home/localadm/softs/git.git
! [remote rejected] maint -> maint (missing necessary objects)
error: failed to push some refs to '/home/localadm/softs/git.git'
--
Yann Dirson - Bertin Technologies
^ 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