* 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: [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: [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
* [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
* [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 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 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 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
* Conflict-free merging (i.e. concat) of conflicting branches?
From: Richard Hartmann @ 2008-11-16 13:50 UTC (permalink / raw)
To: git; +Cc: markus.heidelberg
Please keep the CC intact if possible.
Hi all,
the vim_extended repo, a collection of patchsets against Vim,
allows users to merge different patchsets on top of a current
vanilla Vim. To keep track of which patches are merged, we
would want to use a special variable designated by Vim for
this purpose.
For example, branch a would have file foo with line 100:
$patches .= " with_patch_a";
branch b would have file foo with line 100:
$patches .= " with_patch_b";
etc, etc.
The question is if there is a way to to merge these
branches in a way that is conflict-free and includes
all lines. Obviously, the order of the lines is irrelevant
and can be random.
Thanks for all thoughts,
Richard
^ permalink raw reply
* git svn problem with malformed svn revision
From: Martin @ 2008-11-16 14:18 UTC (permalink / raw)
To: git
Hi,
I'm using git svn to access a subversion repository and committing to it.
Unfortunately this svn repository contains a malformed commit:
There's an empty file with svn-property svn:special *. It was created
using a windows client.
If you try to checkout this revision using svn on linux you get an
error. But using svn you have the possibility to checkout the next
revision which corrects the content of the file to "link foo/bar". So
the symlink is added to the working copy.
But with git svn I get an error when running git svn rebase. Is there
any way to skip this revision when running git svn rebase?
Thanks,
Martin
^ permalink raw reply
* Re: Conflict-free merging (i.e. concat) of conflicting branches?
From: Samuel Tardieu @ 2008-11-16 14:19 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git, markus.heidelberg
In-Reply-To: <2d460de70811160550g75e50e00gb50d3b2045c460af@mail.gmail.com>
>>>>> "Richard" == Richard Hartmann <richih.mailinglist@gmail.com> writes:
Richard> The question is if there is a way to to merge these branches
Richard> in a way that is conflict-free and includes all
Richard> lines. Obviously, the order of the lines is irrelevant and
Richard> can be random.
You can use a custom merge driver especially designed for this case.
See gitattributes(5) man page for an explanation of how it works.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Jakub Narebski @ 2008-11-16 14:21 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <cb7bb73a0811160426g1e56faa7ia9b1f398fea039a8@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> 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.
A bit of complication is that you would have then series of
'uncategorized' (not in any subsection) entries / remote-tracking
branches.
>> 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.
That is I think a good idea.
P.S. I think that sending this patch series for review, even if it was
not perfect was a very good idea... well, perhaps some patches could
be marked as RFC.
It is hard work to prepare good patches, then wait for review, then
wait a bit that there is no further review, working on the patches,
resend and wait for review, or for Ack and merge-in... Keep up good
work.
--
Jakub Narebski
Poland
^ permalink raw reply
* Help merging two repo without connection
From: Luca Siciliano Viglieri @ 2008-11-16 14:59 UTC (permalink / raw)
To: git
Hi,
i'm trying to keep synched two repositories without always having a
direct connection.
My situation is the following:
I have a project on my computer with GIT repo.
Another developer visited me and cloned my repository connecting the
two computer (for example via SSH).
Than i sent him for the next days patched of my changes but when he
came and we merged i got the following tree:
/
-------------------------------------------(my patch)--(my second
patch)--\
/ \
-- (first commit) -- (second
commit
) (merge
) --
\ /
\ (my
patch)--(my second patch)--------------------------------------------/
I don't thinks its right to have double (or more?) commits. I would
have expected something like:
-- (first commit) -- (second commit) -- (my patch)--(my second
patch) -- (merge?) --
The patches were created with git-format-patch and merged with git-am.
I know that the commits have different sha1 but how can i keep with
patches or something similar the two repositories exactly synched?
Thanks
Luca Siciliano
^ permalink raw reply
* Re: Help merging two repo without connection
From: Sverre Rabbelier @ 2008-11-16 15:06 UTC (permalink / raw)
To: Luca Siciliano Viglieri; +Cc: git
In-Reply-To: <AB681AEE-D229-4F1C-8D7B-8E60E0ED8E96@web.de>
On Sun, Nov 16, 2008 at 15:59, Luca Siciliano Viglieri
<lsiciliano@web.de> wrote:
> Hi,
> i'm trying to keep synched two repositories without always having a direct
> connection.
> My situation is the following:
> I have a project on my computer with GIT repo.
> Another developer visited me and cloned my repository connecting the two
> computer (for example via SSH).
> Than i sent him for the next days patched of my changes but when he came and
> we merged i got the following tree:
I suspect 'git rebase' might help you out. When you apply the patches,
apply them to the branch they were based off (instead of to the most
recent master), and then rebase -that- branch (with your 'git am'-ed
patches from your other box) onto your most recent master. That way
you should be able to keep a linear history :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Giuseppe Bilotta @ 2008-11-16 15:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200811161521.53993.jnareb@gmail.com>
On Sun, Nov 16, 2008 at 3:21 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>>> 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.
>
> A bit of complication is that you would have then series of
> 'uncategorized' (not in any subsection) entries / remote-tracking
> branches.
We'll put them in their own group 8-)
>> 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.
>
> That is I think a good idea.
>
> P.S. I think that sending this patch series for review, even if it was
> not perfect was a very good idea... well, perhaps some patches could
> be marked as RFC.
That's what they were when I first sent them last year 8-)
> It is hard work to prepare good patches, then wait for review, then
> wait a bit that there is no further review, working on the patches,
> resend and wait for review, or for Ack and merge-in... Keep up good
> work.
Thanks.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-16 15:30 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226759165-6894-1-git-send-email-giuseppe.bilotta@gmail.com>
Forgot the sign-off line
On Sat, Nov 15, 2008 at 3:26 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> The gitweb_check_feature routine was being used for two different
> purposes: retrieving the actual feature value (such as the list of
> snapshot formats or the list of additional actions), and to check if a
> feature was enabled.
>
> For the latter use, since all features return an array, it led to either
> clumsy code or subtle bugs, with disabled features appearing enabled
> because (0) evaluates to 1.
>
> We fix these bugs, and simplify the code, by separating feature (list)
> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
> retrieving the first/only item in the feature value list). Usage of
> gitweb_check_feature across gitweb is replaced by the appropriate call
> wherever needed.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Help merging two repo without connection
From: Peter Harris @ 2008-11-16 15:33 UTC (permalink / raw)
To: Luca Siciliano Viglieri; +Cc: git
In-Reply-To: <AB681AEE-D229-4F1C-8D7B-8E60E0ED8E96@web.de>
On Sun, Nov 16, 2008 at 9:59 AM, Luca Siciliano Viglieri wrote:
> Hi,
> i'm trying to keep synched two repositories without always having a direct
> connection.
...
> I don't thinks its right to have double (or more?) commits. I would have
> expected something like:
>
>
> -- (first commit) -- (second commit) -- (my patch)--(my second patch) --
> (merge?) --
>
>
> The patches were created with git-format-patch and merged with git-am.
> I know that the commits have different sha1 but how can i keep with patches
> or something similar the two repositories exactly synched?
If you use "git bundle" instead of format-patch, you will have an
unreadable binary blob instead of a human-readable patch, but the
sha1s will not change (since the commiter information will be the
same). The remote side will "git pull" the bundle file instead of "git
am"ing it.
Peter Harris
^ permalink raw reply
* Re: git-daemon: single-line logging
From: Thomas Harning @ 2008-11-16 16:08 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0811131749420.16134@fbirervta.pbzchgretzou.qr>
On Nov 13, 2008, at 11:51 AM, Jan Engelhardt wrote:
> I wrote this patch for my git-daemon to make it much easier to parse
> /var/log/git-daemon.log -- namely reducing the output from three lines
> per connected client to just one.
I think that this is a pretty good change, I'll have to try it out...
One thing I noticed was that there was some information lost in-
transition...
The immediate information lost that I see is the port used.
^ permalink raw reply
* Re: Conflict-free merging (i.e. concat) of conflicting branches?
From: Junio C Hamano @ 2008-11-16 16:28 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git, markus.heidelberg
In-Reply-To: <2d460de70811160550g75e50e00gb50d3b2045c460af@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> The question is if there is a way to to merge these
> branches in a way that is conflict-free and includes
> all lines. Obviously, the order of the lines is irrelevant
> and can be random.
gitattributes(5) and look for "union"?
^ permalink raw reply
* [PATCH 1/2 resend] Documentation: user-manual: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-16 17:10 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
It seems that this patch and the following one have not
been applyed.
Here are some more detailed reasons why I think such a patch
would be useful:
- neither user-manual.txt nor gitutorial.txt talk, in their
current state, about "git help",
- there is a high probability that "man" does not work on
Windows, though it seems that some work has been done for
"git help" to work on this platform,
- "git help" without argument and "git help -a" may be useful
and have no "man" equivalent, "git help -w" (or "git help -i")
may also be usefull/friendlier for some people,
- it seems that "git help" also resolves git aliases,
- some people still tell that git is not user friendly and
even develop separate porcelains (like eg) to do a better job
at helping newbies,
- at GitTogether'08 many people seemed to agree that "git help"
should be improved to have more newby friendly features,
- I don't see the point of trying to improve "git help" any
further if we don't make it more visible first.
So, Junio, could you please tell me what is wrong with this patch?
Thanks in advance,
Christian.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..48f7189 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -17,13 +17,27 @@ People needing to do actual development will also want to read
Further chapters cover more specialized topics.
-Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone <repo>", just use
+Comprehensive reference documentation is available through either the
+linkgit:git-help[1] command or the man pages. For a command such as
+"git clone <repo>", you can use:
+
+------------------------------------------------
+$ git help clone
+------------------------------------------------
+
+or:
------------------------------------------------
$ man git-clone
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
--
1.6.0.4.617.g39d03
^ permalink raw reply related
* [PATCH 2/2 resend] Documentation: tutorial: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-16 17:10 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Also add a few links to git-help(1) in "See also" sections.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 1 +
Documentation/gittutorial-2.txt | 1 +
Documentation/gittutorial.txt | 14 ++++++++++++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 61fc5d7..96bf353 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1693,6 +1693,7 @@ SEE ALSO
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index bab0f34..a057b50 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -425,6 +425,7 @@ linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 384972c..2859a21 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -23,9 +23,22 @@ First, note that you can get documentation for a command such as
`git log --graph` with:
------------------------------------------------
+$ git help log
+------------------------------------------------
+
+or:
+
+------------------------------------------------
$ man git-log
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
way to do so is:
@@ -653,6 +666,7 @@ linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
--
1.6.0.4.617.g39d03
^ permalink raw reply related
* Re: [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Junio C Hamano @ 2008-11-16 17:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226842089-1159-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> With this feature enabled, remotes are retrieved (and displayed)
> when getting (and displaying) the heads list.
Wouldn't it be easier to read if you just said: "Include 'remotes' in the
heads_list", because:
- "heads list" does not sound like a proper English phrase but you are
referring to the sub "heads_list";
- it is obvious and unnecessary to say "when getting, they are retrieved,
when displaying, they are displayed", which is what your parenthesized
parts of the sentence is about;
I am also suggesting to drop "With this feature enabled"; I do not think
of a case where somebody runs gitweb on a repository with refs/remotes and
does not want to show them.
> 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.
When proofreading what you've written, it is usually a good idea to read
it without anything you wrote in parentheses once, and then re-read it
with parentheses removed (but the stuff in your parentheses kept), and
compare which one you like better. More often than not, you'd find that
either parenthesized parts are unnecessary, or they are important enough
that you shouldn't put them in parentheses.
In this case, because you made it clear that you are giving just an
example and not trying to be exhaustive by saying "e.g.", I think dropping
the parenthesized part from the description is better.
Also I think the description is better without "to check...originating
remotes.", because:
- "to check the repository status"? what status? it is too broad to be
a meaningful description;
- "relation between tracking vs origin" is one thing gitweb is very bad
at doing, because it flattens the history, compared to things like
gitk, which you need to compete with especially because you are
advocating the feature to help local browsing.
> 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 = (
> ...
> @@ -410,6 +422,18 @@ sub feature_pickaxe {
> ...
> +sub feature_remote_heads {
> ...
> +}
When would somebody want to disable this? Please explain; I'd like to
understand the motivation behind it.
One argument for making this feature optional I can think of is to retain
backward compatibility because we didn't show them before, but I would say
that is a weak argument. Before release 1.5.0 made the separate remotes
layout the default, everything was in refs/heads/, so you could even argue
that this "fixes" the gitweb bug introduced in that release that stopped
showing the branches you copied from elsewhere.
> @@ -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;
Imagine a later version of git may introduce 'refs/frotz/nitfol' namespace
hierarchy that is commonly known as the 'xyzzy class' and is also useful
to show. Wouldn't it be easier to update gitweb to match such a change if
this part of the code were written like this?
my %head_class = ('refs/heads' => 'head');
$head_class{'refs/remotes'} = 'remote'
if ( this feature is used );
$head_class{'refs/frotz/nitfol'} = 'xyzzy'
if ( the xyzzy class is used);
open my $fd, ... (keys %head_class);
> @@ -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;
And then outside the loop, you'd prepare:
my $headpat = join('|', map { quotemeta($_) } keys %head_class);
and inside the loop you would do:
if ($name =~ s{^($headpat)/}{}) {
$ref_item{'class'} = $head_class{$1};
...
Only one place to configure the list of classes, and make everybody use
that list instead of hardcoding the assumption that there are two and only
two kinds of things "head" vs "remote".
^ permalink raw reply
* Re: [PATCHv3 2/4] gitweb: git_get_heads_list accepts an optional list of refs.
From: Junio C Hamano @ 2008-11-16 17:29 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226842089-1159-3-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> 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;
Makes sense, except that I'd suggest passing a hash of "refs/$path" =>
$class as I illustrated in my comments to [1/4], instead of passing a list
of ("head", "remote"), because that will later allow you to have
multi-level $path that does not necessarily limited to a $class that is a
substring of $path, and doing so does not make the code any more complex.
There is another reason to do so I'll mention in I comment on [3/4].
^ permalink raw reply
* Re: [PATCHv3 3/4] gitweb: separate heads and remotes lists
From: Junio C Hamano @ 2008-11-16 17:34 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226842089-1159-4-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> 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') : ();
Wasteful to run one for-each-ref for each list.
You earlier introduced $ref_item{'class'} so that you can differenciate
what you got from git_get_heads_list(); make use of it, perhaps like:
my @heads_list = git_get_heads_list(16, \%head_class);
my @headlist = grep { $_->{'class'} eq 'head' } @heads_list;
my @remotelist = grep { $_->{'class'} eq 'remote' } @heads_list;
By the way, your [2/4] used "heads" and "remotes" as class, while your
[1/4] stored 'head' and 'remote' in $ref_item{'class'}. Notice the above
suggestion corrects this discrepancy as well.
^ permalink raw reply
* Re: [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Giuseppe Bilotta @ 2008-11-16 17:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vvdun3827.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 6:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> With this feature enabled, remotes are retrieved (and displayed)
>> when getting (and displaying) the heads list.
>
> Wouldn't it be easier to read if you just said: "Include 'remotes' in the
> heads_list", because:
[snip]
> I am also suggesting to drop "With this feature enabled"; I do not think
> of a case where somebody runs gitweb on a repository with refs/remotes and
> does not want to show them.
[snip]
> When proofreading what you've written, it is usually a good idea to read
> it without anything you wrote in parentheses once, and then re-read it
> with parentheses removed (but the stuff in your parentheses kept), and
> compare which one you like better. More often than not, you'd find that
> either parenthesized parts are unnecessary, or they are important enough
> that you shouldn't put them in parentheses.
Good points, I'll rewrite the commit messagge following the suggestions.
>> 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 = (
>> ...
>> @@ -410,6 +422,18 @@ sub feature_pickaxe {
>> ...
>> +sub feature_remote_heads {
>> ...
>> +}
>
> When would somebody want to disable this? Please explain; I'd like to
> understand the motivation behind it.
>
> One argument for making this feature optional I can think of is to retain
> backward compatibility because we didn't show them before, but I would say
> that is a weak argument. Before release 1.5.0 made the separate remotes
> layout the default, everything was in refs/heads/, so you could even argue
> that this "fixes" the gitweb bug introduced in that release that stopped
> showing the branches you copied from elsewhere.
For example, because the only remote for the tree is the author's own
private tree, or because the only remotes are the mirrors on gitorious
or github. In both cases, there would be no reaso to waste resources,
bandwidth and screen estate loading and displaying the remote
references.
OTOH, it might make sense to make remote_heads enabled by default (and
overridable).
>> @@ -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;
>
> Imagine a later version of git may introduce 'refs/frotz/nitfol' namespace
> hierarchy that is commonly known as the 'xyzzy class' and is also useful
> to show. Wouldn't it be easier to update gitweb to match such a change if
> this part of the code were written like this?
>
> my %head_class = ('refs/heads' => 'head');
> $head_class{'refs/remotes'} = 'remote'
> if ( this feature is used );
> $head_class{'refs/frotz/nitfol'} = 'xyzzy'
> if ( the xyzzy class is used);
> open my $fd, ... (keys %head_class);
>
>> @@ -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;
>
> And then outside the loop, you'd prepare:
>
> my $headpat = join('|', map { quotemeta($_) } keys %head_class);
>
> and inside the loop you would do:
>
> if ($name =~ s{^($headpat)/}{}) {
> $ref_item{'class'} = $head_class{$1};
> ...
>
> Only one place to configure the list of classes, and make everybody use
> that list instead of hardcoding the assumption that there are two and only
> two kinds of things "head" vs "remote".
Ah, good point. This change, and the one about extending
git_get_heads_list, could also be turned into prelliminary patches to
the actual remote_heads feature.
--
Giuseppe "Oblomov" Bilotta
^ 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