* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 17:04 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: Soren Brinkmann, Junio C Hamano, git
In-Reply-To: <CAKJhZwROXsTa4wu-C9rhfGysetL+cZRDECyFUn5VTb833pWzMQ@mail.gmail.com>
Hi Zoltan,
On Sun, Dec 09, 2012 at 10:18:19PM +1100, Zoltan Klinger wrote:
> >> Hrm, following your discussion (ellided above), I would have
> >> expected that you would show
> >>
> >> Removing directory foo/bar
> >> Removing untracked_file1
> >
> > Also it would be nice to have warnings about undeleted directories since this git
> > clean behavior (or the work around to pass -f twice) is not documented.
> > Without a warning you would probably miss that something was _not_ deleted.
>
> Thanks for the feedback. I think you're right. Showing 'foo/bar/bar.txt' in
> the list when 'foo/bar/' directory has been successfully deleted is just noise.
>
> 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/
> warning: ignoring untracked git repository untracked_foo/frotz.git/
> warning: ignoring untracked git repository untracked_some.git/
> Use git clean --force --force to delete all untracked git repositories
>
> $ # use forced remove
> $ git clean --force --force -d
> Removing untracked_foo/frotz.git
> Removing untracked_foo/quux/quux.txt
> Removing untracked_some.git/
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove untracked_unreadable_dir/
>
> Can you see any issues with the proposed output, wording above? If
> everyone is happy,
> I'm going to prepare patch V2 for it.
Looks good to me.
Thanks,
Soren
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Johannes Schindelin @ 2012-12-10 17:05 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, git, msysgit
In-Reply-To: <CABPQNSZL-edn4izfMuss1-3KbLBSrGm8J08wn0TbETtsn2nn+A@mail.gmail.com>
Hi kusma,
On Mon, 10 Dec 2012, Erik Faye-Lund wrote:
> On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Erik Faye-Lund <kusmabite@gmail.com> writes:
> >
> >> 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>
> >> ---
> >>
> >> Here's the second version of this patch, sorry for the slight delay.
> >
> > Is this meant for me, or is it to be applied to msysgit and later
> > somehow fed to me in different form?
> >
> > I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
> > want me to do, but otherwise this patch does not apply.
> >
>
> Ugh, you are right. I intended for you to apply it, but I didn't realize
> that my patch was based on the msysGit-master, where Karsten's UTF-8
> patches has been applied.
>
> I'm not entirely sure what the best approach would be. The issue is
> present in both branches, but we only build installers from the
> msysGit-branch. But I think there are other people who builds Git from
> the upstream source code, so it would be slightly less annoying for them
> if the patch was fixed up and applied. But on the other hand, that
> causes some annoyance when (if?) Karsten's UTF-8 patches gets
> upstreamed.
>
> Thoughts?
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.
Ciao,
Dscho
--
*** 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
* Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees
From: Junio C Hamano @ 2012-12-10 17:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <CACsJy8CW1UGgQcgHa11XP71XZGaTxytrGmJmrtdNvy=N7cUyMw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Yeah I use entry_count for two different things here. In the previous
> (unsent) version of the patch I had "entry_count = -1" right after "i
> -= entry_count"
>
>>> + if (sub->cache_tree->entry_count < 0) {
>>> + i -= sub->cache_tree->entry_count;
>>> + sub->cache_tree->entry_count = -1;
>>> + to_invalidate = 1;
>>> + }
>
>
> which makes it clearer that the use of negative entry count is only
> valid within update_one. Then I changed my mind because it says
> 'negative means "invalid"' in cache-tree.h.
But you make it to mean not just 'negative means invalid' but
'negate it and you can learn how many index entries to skip to reach
the entry outside the subtree'. That is what I was wondering about.
I do not think that new invariant does not hold in general; it may
hold true while inside this function, but immediately after somebody
else calls cache_tree_invalidate_path() it won't be true anymore.
Leaking the information to outside callers that can easily be
mistaken as if it may mean something without any comment looks like
we are asking for trouble.
> So, put "entry_count = -1"
> back or just add another field to struct cache_tree for this?
As long as it is made clear with in-code comment that says "negative
entry count, when negated, will give us how many index entries are
covered by this invalid cache tree, only inside this function", and
such a negative entry_count is reset to -1 to avoid leaking out the
value that will soon go stale to the outside world in the "write
this tree out" loop, I think the v2 patch is OK, if not ideal.
If we were to commit to keep the new invariant true throughout the
system, on the other hand, I suspect that a boolean flag "valid" may
help people who keep i-t-a entries around across write-tree calls.
The first if () statement in the update_one() function can check the
validity, and you can say the cache tree is valid even if the
section in the index that is covered by the cache-tree contains
i-t-a entries _after_ you wrote it out as a tree, no? That may make
the semantics a lot cleaner, I suspect.
The new semantics might be:
* update_one() returns negative only when the section of the index
given to it cannot be written out as a tree (i.e. not merged, or
corrupt index);
* update_one() returns the number of entries in the index covered
by the tree, including i-t-a entries (but not REMOVED, as these
entries will not be in the index after the cache-tree has been
written out);
* cache_tree->valid tells if the cache_tree->sha1 is valid; the
section of the index the tree covers may or may not have i-t-a
entries in it;
* cache_tree->entry_count holds the number of index entries the
tree covers, couting i-t-a entries. This field is only meaningful
when cache_tree->valid is true.
or something like that.
I noticed that the recent "ignore i-t-a only while writing trees
instead of erroring out" broke 331fcb5 (git add --intent-to-add: do
not let an empty blob be committed by accident, 2008-11-28) in
another way, by the way. In verify_cache(), there is an unreachable
else clause to warn about "not added yet" entries that should have
been removed but is left behind.
^ permalink raw reply
* 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
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