* [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
* [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
* 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
* 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: 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: [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: [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: 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
* 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: [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
* 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
* 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
* 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
* [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
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