* [PATCHv3 4/4] gitweb: link heads and remotes view
From: Giuseppe Bilotta @ 2008-11-16 13:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226842089-1159-4-git-send-email-giuseppe.bilotta@gmail.com>
Add a link in heads view to remotes view (if the feature is
enabled), and conversely from remotes to heads.
---
gitweb/gitweb.perl | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6b09918..95162db 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4736,7 +4736,10 @@ sub git_tags {
sub git_heads {
my $head = git_get_head_hash($project);
git_header_html();
- git_print_page_nav('','', $head,undef,$head);
+ my $heads_nav = gitweb_check_feature('remote_heads') ?
+ $cgi->a({-href => href(action=>"remotes", -replay=>1)},
+ "remotes") : undef;
+ git_print_page_nav('','', $head,undef,$head, $heads_nav);
git_print_header_div('summary', $project);
my @headslist = git_get_heads_list(undef, 'heads');
@@ -4752,7 +4755,10 @@ sub git_remotes {
my $head = git_get_head_hash($project);
git_header_html();
- git_print_page_nav('','', $head,undef,$head);
+ my $heads_nav =
+ $cgi->a({-href => href(action=>"heads", -replay=>1)},
+ "heads");
+ git_print_page_nav('','', $head,undef,$head, $heads_nav);
git_print_header_div('summary', $project);
my @remotelist = git_get_heads_list(undef, 'remotes');
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3 3/4] gitweb: separate heads and remotes lists
From: Giuseppe Bilotta @ 2008-11-16 13:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226842089-1159-3-git-send-email-giuseppe.bilotta@gmail.com>
We specialize the 'heads' action to only display local branches, and
introduce a 'remotes' action to display the remote branches (only
available when the remotes_head feature is enabled).
Mirroring this, we also split the heads list in summary view into
local and remote lists, each linking to the appropriate action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0512020..6b09918 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -527,6 +527,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "remotes" => \&git_remotes,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -4467,6 +4468,7 @@ sub git_summary {
my %co = parse_commit("HEAD");
my %cd = %co ? parse_date($co{'committer_epoch'}, $co{'committer_tz'}) : ();
my $head = $co{'id'};
+ my $remote_heads = gitweb_check_feature('remote_heads');
my $owner = git_get_project_owner($project);
@@ -4474,7 +4476,8 @@ sub git_summary {
# These get_*_list functions return one more to allow us to see if
# there are more ...
my @taglist = git_get_tags_list(16);
- my @headlist = git_get_heads_list(16);
+ my @headlist = git_get_heads_list(16, 'heads');
+ my @remotelist = $remote_heads ? git_get_heads_list(16, 'remotes') : ();
my @forklist;
my $check_forks = gitweb_check_feature('forks');
@@ -4553,6 +4556,13 @@ sub git_summary {
$cgi->a({-href => href(action=>"heads")}, "..."));
}
+ if (@remotelist) {
+ git_print_header_div('remotes');
+ git_heads_body(\@remotelist, $head, 0, 15,
+ $#remotelist <= 15 ? undef :
+ $cgi->a({-href => href(action=>"remotes")}, "..."));
+ }
+
if (@forklist) {
git_print_header_div('forks');
git_project_list_body(\@forklist, 'age', 0, 15,
@@ -4729,13 +4739,29 @@ sub git_heads {
git_print_page_nav('','', $head,undef,$head);
git_print_header_div('summary', $project);
- my @headslist = git_get_heads_list();
+ my @headslist = git_get_heads_list(undef, 'heads');
if (@headslist) {
git_heads_body(\@headslist, $head);
}
git_footer_html();
}
+sub git_remotes {
+ gitweb_check_feature('remote_heads')
+ or die_error(403, "Remote heads view is disabled");
+
+ my $head = git_get_head_hash($project);
+ git_header_html();
+ git_print_page_nav('','', $head,undef,$head);
+ git_print_header_div('summary', $project);
+
+ my @remotelist = git_get_heads_list(undef, 'remotes');
+ if (@remotelist) {
+ git_heads_body(\@remotelist, $head);
+ }
+ git_footer_html();
+}
+
sub git_blob_plain {
my $type = shift;
my $expires;
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3 2/4] gitweb: git_get_heads_list accepts an optional list of refs.
From: Giuseppe Bilotta @ 2008-11-16 13:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226842089-1159-2-git-send-email-giuseppe.bilotta@gmail.com>
git_get_heads_list(limit, class1, class2, ...) can now be used to retrieve
refs/class1, refs/class2 etc. Defaults to ('heads') or ('heads', 'remotes')
depending on the remote_heads option.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e1f81f6..0512020 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2681,15 +2681,18 @@ sub parse_from_to_diffinfo {
## parse to array of hashes functions
sub git_get_heads_list {
- my $limit = shift;
+ my ($limit, @class) = @_;
+ unless (defined @class) {
+ my $remote_heads = gitweb_check_feature('remote_heads');
+ @class = ('heads', $remote_heads ? 'remotes' : undef);
+ }
+ my @refs = map { "refs/$_" } @class;
my @headslist;
- my $remote_heads = gitweb_check_feature('remote_heads');
-
open my $fd, '-|', git_cmd(), 'for-each-ref',
($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
'--format=%(objectname) %(refname) %(subject)%00%(committer)',
- 'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
+ @refs
or return;
while (my $line = <$fd>) {
my %ref_item;
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Giuseppe Bilotta @ 2008-11-16 13:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226842089-1159-1-git-send-email-giuseppe.bilotta@gmail.com>
With this feature enabled, remotes are retrieved (and displayed)
when getting (and displaying) the heads list. Typical usage would be for
local repository browsing, e.g. by using git-instaweb (or even a more
permanent gitweb setup), to check the repository status and the relation
between tracking branches and the originating remotes.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 31 +++++++++++++++++++++++++++++--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b0d00ea..e1f81f6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -329,6 +329,18 @@ our %feature = (
'ctags' => {
'override' => 0,
'default' => [0]},
+
+ # Make gitweb show remotes too in the heads list
+
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'remote_heads'}{'default'} = [1];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'remote_heads'}{'override'} = 1;
+ # and in project config gitweb.remote_heads = 0|1;
+ 'remote_heads' => {
+ 'sub' => \&feature_remote_heads,
+ 'override' => 0,
+ 'default' => [0]},
);
# retrieve the value of a given feature, as an array
@@ -410,6 +422,18 @@ sub feature_pickaxe {
return ($_[0]);
}
+sub feature_remote_heads {
+ my ($val) = git_get_project_config('remote_heads', '--bool');
+
+ if ($val eq 'true') {
+ return (1);
+ } elsif ($val eq 'false') {
+ return (0);
+ }
+
+ return ($_[0]);
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -2660,10 +2684,12 @@ sub git_get_heads_list {
my $limit = shift;
my @headslist;
+ my $remote_heads = gitweb_check_feature('remote_heads');
+
open my $fd, '-|', git_cmd(), 'for-each-ref',
($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
'--format=%(objectname) %(refname) %(subject)%00%(committer)',
- 'refs/heads'
+ 'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
or return;
while (my $line = <$fd>) {
my %ref_item;
@@ -2674,8 +2700,9 @@ sub git_get_heads_list {
my ($committer, $epoch, $tz) =
($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
$ref_item{'fullname'} = $name;
- $name =~ s!^refs/heads/!!;
+ $name =~ s!^refs/(head|remote)s/!!;
+ $ref_item{'class'} = $1;
$ref_item{'name'} = $name;
$ref_item{'id'} = $hash;
$ref_item{'title'} = $title || '(no commit message)';
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3 0/4] gitweb: remote heads feature
From: Giuseppe Bilotta @ 2008-11-16 13:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
A new version of the remote heads feature patchset. This is considerably
stripped down in comparison to the previous version, as it's limited to
implementing the remote_heads feature and the minimal amount of UI changes to
accomodate it cleanly. Other features such as grouping of heads and supporting
detached HEAD will be implemented separately.
*NOTE*: this patchset is based on my previous
"gitweb: fixes to gitweb feature check code"
patch http://article.gmane.org/gmane.comp.version-control.git/101070
Giuseppe Bilotta (4):
gitweb: introduce remote_heads feature
gitweb: git_get_heads_list accepts an optional list of refs.
gitweb: separate heads and remotes lists
gitweb: link heads and remotes view
gitweb/gitweb.perl | 74 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 68 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Giuseppe Bilotta @ 2008-11-16 12:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200811161312.50090.jnareb@gmail.com>
On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> The problem is that we have gsoc2008/gitweb-caching/branch1
>> gsoc2008/gitweb-caching/branch2 gsoc2008/gitstats/branch3
>> gsoc2008/gitstats/branch3, and my current code would show
>> gitweb-caching/branch1, gitweb-caching/branch2 etc under gsoc2008.
>
> I'm not sure if it wouldn't be simpler solution to just code _sorting_
> heads-like view ('heads', 'remotes', 'tags') by ref name, or by age.
> It would be best to have both, even...
>
> Even without dividing 'remotes' view into subcategories (and
> subsubcategories) you would have natural grouping:
>
> gsoc2008/gitweb-caching/branch1
> gsoc2008/gitweb-caching/branch2
> gsoc2008/gitstats/branch3
> gsoc2008/gitstats/branch4
>
> if sorted by branch (ref) name, and not (possibly)
>
> gsoc2008/gitweb-caching/branch1
> gsoc2008/gitstats/branch4
> origin/todo
> gsoc2008/gitweb-caching/branch2
> gsoc2008/gitstats/branch3
>
> when sorted by age (hmmm... committerdate or authordate?)
Sorting is another interesting feature to look into, yes, but as you
mention it's a separate feature that would complement grouping.
>> Having branch1 and branch2 under gsoc2008/gitweb-caching, and branch3
>> and branch4 under gsoc2008/gitstats would be more logical,
>> remote-wise, but it would of course lose the coupling between all the
>> gsoc2008 remotes.
>>
>> If deep nesting is not a problem, I can code something to have
>> gitweb-caching and gistats under gsoc2008, and the respective branches
>> within.
>
> The problems with nesting is those pesky remotes with only single
> tracked branch to them; they are I think quote common... well, unless
> you do one-shot pull, directly into local branch.
My idea with this would be to only create a group if it has at least N
> 1 (probably N=2) entries.
> All that said, splitting 'remotes' section is difficult; using first
> dirname as section is probably easiest, and good enough in most cases.
> That is why I think this part should be put into separate series, to
> not hinder rest of patches.
Yes, I will resend the 'remote_heads' feature as a new (reduced)
patchset, then add (separate patchset) grouping for ref lists, and
then add (yet another patchset) detached head.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Jakub Narebski @ 2008-11-16 12:12 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <cb7bb73a0811150425j2475db8dsdee57c1cc5e208ab@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sat, Nov 15, 2008 at 1:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Second, this patch wouldn't do what you want from it if there are
>>> remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
>>> for Lea Wiemann repository with her GSoC 2008 work on adding caching
>>> to gitweb.
>>
>> I think your point is if you also use gsoc2008/gitstats from another
>> remote repository, these two sets of remote tracking branches will be
>> shown grouped together. But is it a bad thing? After all, you chose to
>> use hierarchical names for them, _and_ you chose to use the same toplevel
>> hierarchy name for them. Doesn't that mean you _wanted_ to have them both
>> appear in the same GSoC 2008 group?
Actually I _don't_ have 'gsoc2008/gitstats' remote, nor gsoc2008/gitstats/*
remote-tracking branches. 'gsoc2008/gitweb-caching' is the only remote
with hierarchical name. But I digress...
> The problem is that we have gsoc2008/gitweb-caching/branch1
> gsoc2008/gitweb-caching/branch2 gsoc2008/gitstats/branch3
> gsoc2008/gitstats/branch3, and my current code would show
> gitweb-caching/branch1, gitweb-caching/branch2 etc under gsoc2008.
I'm not sure if it wouldn't be simpler solution to just code _sorting_
heads-like view ('heads', 'remotes', 'tags') by ref name, or by age.
It would be best to have both, even...
Even without dividing 'remotes' view into subcategories (and
subsubcategories) you would have natural grouping:
gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2
gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch4
if sorted by branch (ref) name, and not (possibly)
gsoc2008/gitweb-caching/branch1
gsoc2008/gitstats/branch4
origin/todo
gsoc2008/gitweb-caching/branch2
gsoc2008/gitstats/branch3
when sorted by age (hmmm... committerdate or authordate?)
> Having branch1 and branch2 under gsoc2008/gitweb-caching, and branch3
> and branch4 under gsoc2008/gitstats would be more logical,
> remote-wise, but it would of course lose the coupling between all the
> gsoc2008 remotes.
>
> If deep nesting is not a problem, I can code something to have
> gitweb-caching and gistats under gsoc2008, and the respective branches
> within.
The problems with nesting is those pesky remotes with only single
tracked branch to them; they are I think quote common... well, unless
you do one-shot pull, directly into local branch.
All that said, splitting 'remotes' section is difficult; using first
dirname as section is probably easiest, and good enough in most cases.
That is why I think this part should be put into separate series, to
not hinder rest of patches.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-16 11:50 UTC (permalink / raw)
To: Christian Couder; +Cc: Git Mailing List
In-Reply-To: <200811151615.42345.chriscool@tuxfamily.org>
Christian Couder wrote:
> Hi Andreas,
>
> Le vendredi 14 novembre 2008, Andreas Ericsson a écrit :
>> I've been working quite a lot on git -> libgit2 code moving,
>
> It would be nice if there was somewhere on the web where your work could be
> seen. If there is already, could you send (or resend) the URL? This way
> people might have look and perhaps even help you. (Though I don't promise
> anything as I have already a lot of things on my TODO list.) Thanks in
> advance.
>
When I was about to, I realized these licensing issues actually made it
illegal to do so without getting the permissions from the involved authors.
Now that Linus and a lot of other core contributors have given their consent,
I'll be able to start re-ordering the commits so I can publish those parts
originating from consenting authors while holding off on those that I can't
tell for sure are ok with it. Legal issues are no fun what so ever.
>> but the licensing stuff is a bit depressing, as I can't know
>> if the work I'm doing is for nothing or not.
>>
>> The license decided for libgit2 is "GPL with gcc exception".
>> Those who are OK with relicensing their contributions under
>> that license for the purpose of libgit2, can you please say
>> so?
>
> It's ok to relicense my git related work under the "GPL with gcc exception"
> license.
>
Thank you. With the current list of ok's 73.09% of the code in git.git
seems to be relicenseable for the purpose of libgit2. That will provide
quite a kickstart.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #05; Sat, 15)
From: Nguyen Thai Ngoc Duy @ 2008-11-16 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlk04hkk.fsf@gitster.siamese.dyndns.org>
On 11/16/08, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/rename-cache (Sat Nov 8 18:27:33 2008 +0700) 2 commits
> - diffcore-rename: add config option to allow to cache renames
> - diffcore-rename: support rename cache
>
> I am moderately negative on this one in its current shape. We shouldn't
> have to be storing what can be recomputed (and recomputed differently in
> later software), and we shouldn't be keeping such cached result
> indefinitely.
Yeah.. having some way to deprecate the cache if you use a newer
version was something I thought about but haven't done. Anyway for all
the purposes I want it to do, injecting explicit renames may not work
if --find-copies-harder is not given. I think you should drop it.
--
Duy
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Pierre Habouzit @ 2008-11-16 9:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Chris Frey, Johannes Schindelin, Alex Riesen,
Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811140945000.3468@nehalem.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
On Fri, Nov 14, 2008 at 05:55:51PM +0000, Linus Torvalds wrote:
>
>
> On Fri, 14 Nov 2008, Linus Torvalds wrote:
> >
> > but if you already do
> >
> > gitk a..b
> >
> > then you're _already_ doing a revision limiter and forcing the revision
> > walk to be synchronous, so there would be no interactivity downside
> > between 'a..b' and '{a..b}'.
>
> Btw, the biggest problem (I think) is actually non-simple ranges and just
> the _syntax_ of these things.
>
> It's entirely reasonable to want to group a more complex expression than
> just a single range. IOW, something like
>
> gitk {..origin/pu ^origin/next} {HEAD~5..HEAD~2}
>
> to show a union of what is in 'pu' but not master or next, and the
> symmetrical difference of the current merge. It's a perfectly sensible
> thing to do. And we _can_ do it right now, just with a nasty syntax:
>
> gitk --no-walk $(git rev-list ..origin/pu ^origin/next) $(git rev-list HEAD~5..HEAD~2)
>
> actually works. But look again at how nasty it is to parse the '{x}'
> version, because the '{..}' thing now spans multiple arguments.
That would probably be a job that parseopt could take care of. to some
degree.
Also { } is a poor choice as it's an expansion thingy for many shells.
zsh even refuses ` { a.. b } ` as an argument, pretending there is a
syntax error at the closing brace. [ ] looks like a safer choice, it's
used for shells supporting arrays, but only when stuck after an
identifier which won't be our case ever, so we would be probably safe.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [BUG] git ls-files -m --with-tree does double output
From: Anders Melchiorsen @ 2008-11-16 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr65c3xn5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:
>
>> Junio C Hamano wrote:
>>
>>> What's the use case of using -m together with --with-tree to begin
>>> with?
>>
>> The script runs
>>
>> git ls-files -d -m -o -t --with-tree=HEAD
>>
>> to get a parseable "git status"-like output. If I leave out
>> --with-tree=HEAD, I do not get information about staged changes.
>
> [...]
> I lack the context to interpret what you mean by "The script", but in any
> case, the only use case --with-tree was designed for was to use it in
> conjunction with --error-unmatch inside the scripted version of "git
> commit", to see if the paths given by the users make sense as a request to
> create a partial commit. It is not entirely surprising if any other funny
> options do not work with it at all.
"The script" is just a random script I was writing when I found this issue.
If --with-tree is only meant for --error-unmatch, maybe update the help to
show it like this,
[--error-unmatch [--with-tree=<tree-ish>]]
I never read the description of --with-tree, I just found the parameter in
the top of the man page and tried it out. It did what I wanted, but gave
double output. And so I reported that in this thread, as I believed it to
be an error.
Now I understand that I am using ls-files in unintended ways, but I cannot
really fix that when no "git status" like plumbing tool is available.
> Having said all that, I think this would fix it.
That sure seems to fix my test case.
Anders.
^ permalink raw reply
* Re: Can git ignore parts of files
From: Daniel Barkalow @ 2008-11-16 8:37 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1226690252.6176.9.camel@rotwang.fnordora.org>
On Fri, 14 Nov 2008, Alan wrote:
> I have kind of an odd problem that is causing me grief in git. I figure
> someone has a good solution here. (Or not, they will soon.)
>
> I have a couple of kernel .config files that are checked into git. They
> are used to test kernel configurations for the nightly builds where I
> work.
>
> We have a bunch of kernel developers working on drivers. When they add
> a new driver, they add in the options in the test file to make it
> compile in the test builds.
>
> The problem is that the kernel config file has a timestamp at the top of
> the file that is generated by "make oldconfig" or "make config". Other
> than removing the timestamp each time manually, is there a way to get
> git to ignore the timestamp on a merge?
Try the "clean"/"smudge" filter feature documented in gitattributes(5).
You should be able to use that to remove the timestamp automatically.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [BUG] git ls-files -m --with-tree does double output
From: Junio C Hamano @ 2008-11-16 8:03 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <57320.N1gUGH5fRhE=.1226617873.squirrel@webmail.hotelhot.dk>
"Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:
> Junio C Hamano wrote:
>
>> What's the use case of using -m together with --with-tree to begin with?
>
> The script runs
>
> git ls-files -d -m -o -t --with-tree=HEAD
>
> to get a parseable "git status"-like output. If I leave out
> --with-tree=HEAD, I do not get information about staged changes.
I think a machine parsable "status equivalent" is a good thing to have,
but I do not think the internal machinery of ls-files is equipped to do
that. Didn't I send "here is how you would do it" patch some time ago, so
that interested parties can build on it to do that?
I lack the context to interpret what you mean by "The script", but in any
case, the only use case --with-tree was designed for was to use it in
conjunction with --error-unmatch inside the scripted version of "git
commit", to see if the paths given by the users make sense as a request to
create a partial commit. It is not entirely surprising if any other funny
options do not work with it at all.
Having said all that, I think this would fix it.
builtin-ls-files.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git c/builtin-ls-files.c i/builtin-ls-files.c
index b48327d..b28a185 100644
--- c/builtin-ls-files.c
+++ i/builtin-ls-files.c
@@ -227,6 +227,8 @@ static void show_files(struct dir_struct *dir, const char *prefix)
int dtype = ce_to_dtype(ce);
if (excluded(dir, ce->name, &dtype) != dir->show_ignored)
continue;
+ if (ce->ce_flags & CE_UPDATE)
+ continue;
err = lstat(ce->name, &st);
if (show_deleted && err)
show_ce_entry(tag_removed, ce);
^ permalink raw reply related
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Giuseppe Bilotta @ 2008-11-16 2:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811160213.43343.jnareb@gmail.com>
On Sun, Nov 16, 2008 at 2:13 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
>> The initially intended purpose for this patch was to group remote
>> heads by remotes, but an interesting side-effect of doing it this way
>> was that it allowed to group _local_ heads too, by using the
>> stuff/morestuff syntax. For example, I could group gitweb/pathinfo and
>> gitweb/allheads together (although I disabled this grouping for local
>> heads in the patchset).
>
> I'm not sure if it would be that useful. How many people have _many_
> stuff/morestuff branches for some values of stuff/? The convention of
> <initials>/<topic> of topic branches in git.git doesn't usually lead
> to many branches with the same <initials>/ prefix.
Well, even if it's just two of them, it would still be nice. Or even
better, we could make it so that the grouping is skipped unless there
are at least N (to be decided) entries. This, btw, would be true for
the remotes idea too.
> Now I thought about it a bit, I think your solution has merit.
>
> Splitting by remotes is hard and difficult to do right, especially if
> you consider than 'remote' prefix doesn't need to have anything in
> common with names (common prefix) of refs/remotes/* remote-tracking
> branches used. It is fairly easy to do it right in common case, but
> hard in uncommon one.
>
> So perhaps the idea of using first dirname as a kind of category for
> remotes is a good idea. And usually it would be also remote name.
>
> But it really needs explanation in commit message... and quite a bit
> of commit squashing.
I'll probably do a single commit with a rather different logic than
the current one, too.
>> It would also probably be a good idea to separate the actual head
>> grouping from the display of the grouped head lists. I wonder if Perl
>> has a 'tree' data structure that could be used to store the grouped
>> head lists ...
>
> Hash of hashes (well, hash references), see perldsc(1)?
Ah, good, I always get those wrong. Will be an interesting challenge 8-D
>> Would you say that in this case we want 'gsoc2008/gitweb-caching' as
>> the group head, or would you rather have nested groups [gsoc2008
>> [gitweb-caching [branches in gsoc2008/gitweb-caching] [etc]] ? I must
>> say that I think the latter would be quite interesting, but I _am_ a
>> little afraid we could turn up with way too much nested groups ...
>
> Now I think that having [gsoc2008] subgroup here might be a good
> thing...
And subgroups (one for each remote) therein?
My idea would be that, if you only have
gsoc2008/gitweb-caching/branch[1-n], then you'd have a
gsoc2008/gitweb-caching group, and branch1 ... branchn as entries. If
OTOH we have gsoc2007/{gitweb-caching,gitstats}/branch*, we'd have
gsoc2008 group with gitweb-caching and gitstats subgroups, each with
its list of branches.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v2 07/11] gitweb: add 'remotes' action
From: Giuseppe Bilotta @ 2008-11-16 2:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811160129.17319.jnareb@gmail.com>
On Sun, Nov 16, 2008 at 1:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
>> FWIW, I decided to scratch that additional ' remotes' string when
>> squashing this patch.
>
> Hmmm... I'm not sure if $project in git_print_header_div() for those
> two actions is good thing to have...
Considering it links back to summary view, it makes sense to say
$project in there. If we decide to make it link to something else, we
should change the text accordingly. Suggestions?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] git-gui: try to provide a window icon under X
From: Giuseppe Bilotta @ 2008-11-16 2:42 UTC (permalink / raw)
To: git; +Cc: Alexander Gavrilov, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226801378-25501-1-git-send-email-giuseppe.bilotta@gmail.com>
When running under X, we try to set up a window icon by providing a
hand-crafted 16x16 Tk photo image equivalent to the .ico. Wrap in a
catch because the earlier Tcl/Tk 8.4 releases didn't provide the 'wm
iconphoto' command.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Resend, forgot the signed-off line
git-gui/git-gui.sh | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index cf9ef6e..6ed6230 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -597,6 +597,28 @@ if {[is_Windows]} {
if {![info exists env(DISPLAY)]} {
set env(DISPLAY) :9999
}
+} else {
+ catch {
+ image create photo gitlogo -width 16 -height 16
+
+ gitlogo put #33CC33 -to 7 0 9 2
+ gitlogo put #33CC33 -to 4 2 12 4
+ gitlogo put #33CC33 -to 7 4 9 6
+ gitlogo put #CC3333 -to 4 6 12 8
+ gitlogo put gray26 -to 4 9 6 10
+ gitlogo put gray26 -to 3 10 6 12
+ gitlogo put gray26 -to 8 9 13 11
+ gitlogo put gray26 -to 8 11 10 12
+ gitlogo put gray26 -to 11 11 13 14
+ gitlogo put gray26 -to 3 12 5 14
+ gitlogo put gray26 -to 5 13
+ gitlogo put gray26 -to 10 13
+ gitlogo put gray26 -to 4 14 12 15
+ gitlogo put gray26 -to 5 15 11 16
+ gitlogo redither
+
+ wm iconphoto . -default gitlogo
+ }
}
######################################################################
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitk: try to provide a window icon
From: Giuseppe Bilotta @ 2008-11-16 2:41 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <cb7bb73a0811151814va151c32ud5e940820ff92011@mail.gmail.com>
Try to set up a 16x16 Tk photo image (based on the git logo) and use it
a window icon. Wrap the code in a catch because it may fail in earlier
Tcl/Tk 8.4 releases that don't provide 'wm iconphoto'.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitk-git/gitk | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..6b671a6 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10797,6 +10797,26 @@ set lserial 0
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
setcoords
makewindow
+catch {
+ image create photo gitlogo -width 16 -height 16
+
+ image create photo gitlogominus -width 4 -height 2
+ gitlogominus put #C00000 -to 0 0 4 2
+ gitlogo copy gitlogominus -to 1 5
+ gitlogo copy gitlogominus -to 6 5
+ gitlogo copy gitlogominus -to 11 5
+ image delete gitlogominus
+
+ image create photo gitlogoplus -width 4 -height 4
+ gitlogoplus put #008000 -to 1 0 3 4
+ gitlogoplus put #008000 -to 0 1 4 3
+ gitlogo copy gitlogoplus -to 1 9
+ gitlogo copy gitlogoplus -to 6 9
+ gitlogo copy gitlogoplus -to 11 9
+ image delete gitlogoplus
+
+ wm iconphoto . -default gitlogo
+}
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitk: try to set program icon
From: Giuseppe Bilotta @ 2008-11-16 2:14 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226792745-18408-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, Nov 16, 2008 at 12:45 AM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> We add the git icon in three formats (.xbm, .ico, .ppm), which we try to
> set as window icon.
[snip]
Scratch this. I've seen how it's done in git-gui, and I think that's a
better way to do it. I've provided a patch for git-gui to introduce
the icon under X, so I'll just use something like that, maybe using wm
iconphoto for all platforms.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] git-gui: try to provide a window icon under X
From: Giuseppe Bilotta @ 2008-11-16 2:09 UTC (permalink / raw)
To: git; +Cc: Alexander Gavrilov, Junio C Hamano, Giuseppe Bilotta
When running under X, we try to set up a window icon by providing a
hand-crafted 16x16 Tk photo image equivalent to the .ico. Wrap in a
catch because the earlier Tcl/Tk 8.4 releases didn't provide the 'wm
iconphoto' command.
---
git-gui/git-gui.sh | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index cf9ef6e..6ed6230 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -597,6 +597,28 @@ if {[is_Windows]} {
if {![info exists env(DISPLAY)]} {
set env(DISPLAY) :9999
}
+} else {
+ catch {
+ image create photo gitlogo -width 16 -height 16
+
+ gitlogo put #33CC33 -to 7 0 9 2
+ gitlogo put #33CC33 -to 4 2 12 4
+ gitlogo put #33CC33 -to 7 4 9 6
+ gitlogo put #CC3333 -to 4 6 12 8
+ gitlogo put gray26 -to 4 9 6 10
+ gitlogo put gray26 -to 3 10 6 12
+ gitlogo put gray26 -to 8 9 13 11
+ gitlogo put gray26 -to 8 11 10 12
+ gitlogo put gray26 -to 11 11 13 14
+ gitlogo put gray26 -to 3 12 5 14
+ gitlogo put gray26 -to 5 13
+ gitlogo put gray26 -to 10 13
+ gitlogo put gray26 -to 4 14 12 15
+ gitlogo put gray26 -to 5 15 11 16
+ gitlogo redither
+
+ wm iconphoto . -default gitlogo
+ }
}
######################################################################
--
1.5.6.5
^ permalink raw reply related
* Re: git rev-list ordering
From: Ian Hilt @ 2008-11-16 1:44 UTC (permalink / raw)
To: sverre; +Cc: Git Mailing List
In-Reply-To: <bd6139dc0811151727k605a3575hf409fed32a3a4baf@mail.gmail.com>
On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> The --reverse is applied after the --max-count, so you are seeing the
> reverse of one commit ;). For comparison, have a look at:
>
> $ git rev-list --reverse --max-count=2
Ah, I see. So if you didn't want the sorting to take a long time for
many commits, you would limit the output to n commits, then sort the
output. Is this the logic behind this design?
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Daniel Barkalow @ 2008-11-16 1:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491DE6CC.6060201@op5.se>
On Fri, 14 Nov 2008, Andreas Ericsson wrote:
> I've been working quite a lot on git -> libgit2 code moving,
> but the licensing stuff is a bit depressing, as I can't know
> if the work I'm doing is for nothing or not.
>
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?
I'm fine with it for all my code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git rev-list ordering
From: Sverre Rabbelier @ 2008-11-16 1:27 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811151922310.2935@sys-0.hiltweb.site>
On Sun, Nov 16, 2008 at 01:44, Ian Hilt <ian.hilt@gmx.com> wrote:
> Why is it that this command,
>
> git rev-list --reverse --max-count=1 <branch>
>
> results in the same SHA1 as,
>
> git rev-list --max-count=1 <branch>
>
> So far, the documentation and the mailing list archives haven't helped.
The --reverse is applied after the --max-count, so you are seeing the
reverse of one commit ;). For comparison, have a look at:
$ git rev-list --reverse --max-count=2
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Jakub Narebski @ 2008-11-16 1:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811150204v15463275sf63098b819c6d259@mail.gmail.com>
On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
> On Sat, Nov 15, 2008 at 12:59 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
>>
>>> The purpose of this function is to split a headlist into groups
>>> determined by the leading part of the refname, and call git_heads_body()
>>> on each group.
>>
>> What is the reason of this patch? Is it to split remote-tracking
>> branches ('remotes' references) into remotes, and group them by
>> the remote repository name?
>>
>> If it is true, then first: you should have wrote the _reason_ behind
>> this patch and not only what it does in this commit message. And use
>> better summary (commit title / subject of this patch).
>>
>> Second, this patch wouldn't do what you want from it if there are
>> remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
>> for Lea Wiemann repository with her GSoC 2008 work on adding caching
>> to gitweb. Because there are many ways to specify remotes due to
>> backwards compatibility (and simplicity, as some for example prefer
>> old 'branches/' way to specify remotes), namely config, files under
>> '.git/remotes', and (from Cogito) files in '.git/branches', you would
>> have to either reimplement/reuse parts of git-remote (there is old Perl
>> implementation in contrib/examples), or use "git remote" or
>> "git remote -v" command output[1].
>
> The initially intended purpose for this patch was to group remote
> heads by remotes, but an interesting side-effect of doing it this way
> was that it allowed to group _local_ heads too, by using the
> stuff/morestuff syntax. For example, I could group gitweb/pathinfo and
> gitweb/allheads together (although I disabled this grouping for local
> heads in the patchset).
I'm not sure if it would be that useful. How many people have _many_
stuff/morestuff branches for some values of stuff/? The convention of
<initials>/<topic> of topic branches in git.git doesn't usually lead
to many branches with the same <initials>/ prefix.
>
> However, as you remark, the current patch fails to achieve even its
> intended purpose, so it looks like going the 'git remote' way would be
> the right way to find at least the grouping keys: this has the benefit
> of allowing us to retrieve the remote URL as well by using 'git remote
> -v', although it has the underside of require one additional git call.
Now I thought about it a bit, I think your solution has merit.
Splitting by remotes is hard and difficult to do right, especially if
you consider than 'remote' prefix doesn't need to have anything in
common with names (common prefix) of refs/remotes/* remote-tracking
branches used. It is fairly easy to do it right in common case, but
hard in uncommon one.
So perhaps the idea of using first dirname as a kind of category for
remotes is a good idea. And usually it would be also remote name.
But it really needs explanation in commit message... and quite a bit
of commit squashing.
>
> It would also probably be a good idea to separate the actual head
> grouping from the display of the grouped head lists. I wonder if Perl
> has a 'tree' data structure that could be used to store the grouped
> head lists ...
Hash of hashes (well, hash references), see perldsc(1)?
>
> Ah yes, the code in this patch I was never actually really satisfied
> with, hopefully I can rewrite it more sensibly with the adittional
> experience I've accumulated this year.
Code... well, perhaps... commit messages also matter.
>
>>> +
>>> + # Split @$headlist into a hash of lists
>>> + map {
>>> + my %ref = %$_;
>>> + $ref{'hname'} = $ref{'name'};
>>> + if ($ref{'name'} =~ /\//) {
>>> + $ref{'name'} =~ s!^([^/]+)/!!;
>>
>> As I said, this would fail on for example "gsoc2008/gitweb-caching"
>> remote...
>
> Would you say that in this case we want 'gsoc2008/gitweb-caching' as
> the group head, or would you rather have nested groups [gsoc2008
> [gitweb-caching [branches in gsoc2008/gitweb-caching] [etc]] ? I must
> say that I think the latter would be quite interesting, but I _am_ a
> little afraid we could turn up with way too much nested groups ...
Now I think that having [gsoc2008] subgroup here might be a good
thing...
--
Jakub Narebski
Poland
^ permalink raw reply
* What's cooking in git.git (Nov 2008, #05; Sat, 15)
From: Junio C Hamano @ 2008-11-16 0:53 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* lt/preload-lstat (Thu Nov 13 16:36:30 2008 -0800) 1 commit
- Add cache preload facility
* cb/mergetool (Thu Nov 13 12:41:15 2008 +0000) 3 commits
- [DONTMERGE] Add -k/--keep-going option to mergetool
- Add -y/--no-prompt option to mergetool
- Fix some tab/space inconsistencies in git-mergetool.sh
Jeff had good comments on the last one; the discussion needs concluded,
and also waiting for comments from the original author (Ted).
* ta/quiet-pull (Sat Nov 15 01:14:24 2008 +0100) 1 commit
- Teach/Fix pull/fetch -q/-v options
This has my fixes to preserve "fetch -v -v" behaviour squashed in.
----------------------------------------------------------------
[Graduated to "master"]
* mk/maint-cg-push (Mon Nov 10 22:47:11 2008 +0100) 1 commit
+ git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Will need to further downmerge to 'maint'.
* jk/maint-commit-v-strip (Wed Nov 12 03:25:52 2008 -0500) 1 commit
+ commit: Fix stripping of patch in verbose mode.
Will need to further downmerge to 'maint'.
* st/maint-tag (Wed Nov 5 00:20:36 2008 +0100) 2 commits
+ tag: Add more tests about mixing incompatible modes and options
+ tag: Check that options are only allowed in the appropriate mode
Will need to further downmerge to 'maint'.
* jk/deny-push-to-current (Sat Nov 8 20:49:27 2008 -0500) 2 commits
+ receive-pack: detect push to current branch of non-bare repo
+ t5516: refactor oddball tests
* dl/xdiff (Fri Nov 7 21:24:33 2008 -0800) 1 commit
+ xdiff: give up scanning similar lines early
This performance fix may eventually need to be cherry-picked to 'maint'.
* lt/decorate (Wed Nov 12 11:51:28 2008 +0100) 7 commits
+ rev-list documentation: clarify the two parts of history
simplification
+ Document "git log --simplify-by-decoration"
+ Document "git log --source"
+ revision traversal: '--simplify-by-decoration'
+ Make '--decorate' set an explicit 'show_decorations' flag
+ revision: make tree comparison functions take commits rather than
trees
+ Add a 'source' decorator for commits
* gb/gitweb-snapshot-pathinfo (Sun Nov 2 10:21:39 2008 +0100) 3 commits
+ gitweb: embed snapshot format parameter in PATH_INFO
+ gitweb: retrieve snapshot format from PATH_INFO
+ gitweb: make the supported snapshot formats array global
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
+ gitweb: Better processing format string in custom links in navbar
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
+ enable textconv for diff in verbose status/commit
+ wt-status: load diff ui config
+ only textconv regular files
+ userdiff: require explicitly allowing textconv
+ refactor userdiff textconv code
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 1 commit
+ Avoid using non-portable `echo -n` in tests.
An update to the one above.
* np/pack-safer (Sun Nov 9 13:11:06 2008 -0800) 11 commits
+ t5303: fix printf format string for portability
+ t5303: work around printf breakage in dash
+ pack-objects: don't leak pack window reference when splitting
packs
+ extend test coverage for latest pack corruption resilience
improvements
+ pack-objects: allow "fixing" a corrupted pack without a full
repack
+ make find_pack_revindex() aware of the nasty world
+ make check_object() resilient to pack corruptions
+ make packed_object_info() resilient to pack corruptions
+ make unpack_object_header() non fatal
+ better validation on delta base object offsets
+ close another possibility for propagating pack corruption
* mv/remote-rename (Mon Nov 10 21:43:03 2008 +0100) 4 commits
+ git-remote: document the migration feature of the rename
subcommand
+ git-remote rename: migrate from remotes/ and branches/
+ remote: add a new 'origin' variable to the struct
+ Implement git remote rename
----------------------------------------------------------------
[Will merge to "master" soon]
* bc/maint-keep-pack (Thu Nov 13 14:11:46 2008 -0600) 1 commit
+ repack: only unpack-unreachable if we are deleting redundant packs
This makes "repack -A -d" without -d do the same thing as "repack -a -d",
which makes sense. This does not have to go to 'maint', though.
* jk/commit-v-strip (Wed Nov 12 03:23:37 2008 -0500) 4 commits
+ status: show "-v" diff even for initial commit
+ Merge branch 'jk/maint-commit-v-strip' into jk/commit-v-strip
+ wt-status: refactor initial commit printing
+ define empty tree sha1 as a macro
----------------------------------------------------------------
[Actively Cooking]
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
+ grep: skip files outside sparse checkout area
+ checkout_entry(): CE_NO_CHECKOUT on checked out entries.
+ Prevent diff machinery from examining worktree outside sparse
checkout
+ ls-files: Add tests for --sparse and friends
+ update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
+ update-index: refactor mark_valid() in preparation for new options
+ ls-files: add options to support sparse checkout
+ Introduce CE_NO_CHECKOUT bit
+ Extend index to save more flags
I think the basic idea and structure of this is sound. Let's see if
people who try this feature can find holes in what it currently does.
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
* ph/send-email (Tue Nov 11 00:54:02 2008 +0100) 4 commits
- git send-email: ask less questions when --compose is used.
- git send-email: add --annotate option
- git send-email: interpret unknown files as revision lists
- git send-email: make the message file name more specific.
* nd/rename-cache (Sat Nov 8 18:27:33 2008 +0700) 2 commits
- diffcore-rename: add config option to allow to cache renames
- diffcore-rename: support rename cache
I am moderately negative on this one in its current shape. We shouldn't
have to be storing what can be recomputed (and recomputed differently in
later software), and we shouldn't be keeping such cached result
indefinitely.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* git rev-list ordering
From: Ian Hilt @ 2008-11-16 0:44 UTC (permalink / raw)
To: Git Mailing List
Why is it that this command,
git rev-list --reverse --max-count=1 <branch>
results in the same SHA1 as,
git rev-list --max-count=1 <branch>
So far, the documentation and the mailing list archives haven't helped.
^ 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