* [take 2] revision parsing made incremental
From: Pierre Habouzit @ 2008-07-08 13:19 UTC (permalink / raw)
To: git; +Cc: torvalds, gitster, peff, Johannes.Schindelin
Following Dscho's remarks, I reworked the series to avoid changing
setup_revisions semantics for now, and only exposed the part that groks
options (and keep pseudo revision arguments out).
It indeed makes the series smaller, even if the first patch is quite
long to read, and is just enough for simplifying git-blame in a very
satisfying way.
The series passes the testsuite, has no know blanks issues, and is
pushed to my public repository.
^ permalink raw reply
* git-rebase eats empty commits
From: Michael J Gruber @ 2008-07-08 13:59 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
"git commit" allows empty commits with the "--allow-empty" option, i.e.
commits which introduce no change at all. This is sometimes useful for
keeping a log of untracked work related to tracked content.
"git rebase" removes empty commits, for the good reason that rebasing
may make certain commits obsolete; but I don't want that in the case
mentioned above. Is there any way to specify "--preserve-empty" or similar?
The attached script and log show the effect: a series A B C D of commits
is rebased onto A'; the result is A' C', with the empty commits B and D
disappearing.
grafts and filter-branch helped me solve a particular case of that
effect, but I think it will show up again, so an option for rebase would
be useful.
Michael
P.S.: I also noticed that 'Switched to a new branch "temp"' is written
to stderr, everything else to stdout. Is that as intended?
[-- Attachment #2: empty.log --]
[-- Type: text/x-log, Size: 816 bytes --]
Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit b3104c1: 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Created commit 7265e0c: empty 1
Created commit 9b67221: 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
Created commit 0778af2: empty 2
0778af2a5003df310cb9dc3c4fff1f8992619610 empty 2
9b67221a363103ebc78fc052c382637a87ef04e6 2
7265e0c1a35c95bd6fcf739a9f815b300ba9d9cc empty 1
b3104c148e1dd6ce8fd23cddb71734e45e7d9132 1
Switched to a new branch "temp"
Created commit d9ad4bc: rewritten 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
First, rewinding head to replay your work on top of it...
Applying 2
d81ec616edd3ed600a60dbd63d4d0f4a7263387f 2
d9ad4bcd2fb5e78f2f430733f2dc36453a653221 rewritten 1
[-- Attachment #3: empty.sh --]
[-- Type: application/x-shellscript, Size: 400 bytes --]
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-08 14:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080708042607.GC7186@sigill.intra.peff.net>
On Jul 8, 2008, at 12:26 AM, Jeff King wrote:
> On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:
>
>> I personally expected @{1} to be identical to HEAD@{1}. Since
>> omitting a
>> ref usually refers to HEAD, why shouldn't omitting it when
>> referring to
>> the reflogs mean the HEAD log? The definition of @{1} is useful
>> since
>> there's no other easy way to get "current branch's reflog", but I
>> think
>> it's non-obvious. (Since HEAD@{1} is something completely
>> different, I
>> think the only other way to refer to @{1} is $(git symbolic-
>> ref)@{1}.)
>
> FYI, there was much discussion about this exact point:
>
> http://thread.gmane.org/gmane.comp.version-control.git/38379
>
> (I don't know that it has that much bearing on the current discussion,
> but since I went to the trouble of digging it up, I thought you might
> find it useful).
Oh, it is useful. And, thinking about it, I agree completely. The
syntax isn't immediately obvious, but clear and useful. The need to
distinguish between HEAD@{} and $branch@{} is apparent after a
moment's reflection, and the chosen solution is fairly obvious at that
point. I just never took that moment in my day-to-day working with git.
There's even documentation for it that is clear and understandable.
If I was a new user to git, I would have read the documentation and
found it. Having used git for a while, I don't bother to look things
up and instead try to alter git to match my three years of
experience. ;-)
That said, I still want clear and consistent semantics for ORIG_HEAD.
And since that now (IMNSHO) exists in next, I'm happy.
~~ Brian
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Stephan Beyer @ 2008-07-08 14:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Christian Couder, Daniel Barkalow
In-Reply-To: <200807080939.31216.jnareb@gmail.com>
Hi,
Jakub Narebski wrote:
> > Yes, you are right that am --rebasing is a no-op.
> > That option was a little mystery to me, because it seemed to do nothing
> > special, but I'll check again (bash-completion etc) and do appropriate
> > changes.
>
> Undocumented option '--rebasing' to git-am is internal option changing
> git-am behavior to be better used by git-rebase, namely it does not
> change commit message even if it doesn't follow git commit message
> convention,
Ah yes, I've seen it now.
It is taking the commit message from the commit in the "From <commit> .*"
line, does *not* change it in any way and then applies the changes using
threeway merge.
Keeping that in mind what about dealing with --rebasing like that:
if --rebasing is given, git am simply generates
pick <commit>
lines, instead of
patch -3 -k <msg>
as it is now (and this is not enough, as it seems).
Does someone have strong objections against that?
Speed could be one point in the case that git-apply just works without
needing threeway-fallback, but in the case of the fallback this will be
slower than pick, I think. So I'd not value that too high, but perhaps
there are opinions against my view.
Perhaps I am missing another point, too?
The alternative for doing "pick" is teaching git-sequencer's "patch"
insn an option that emulates the --rebasing behavior.
For me this feels somehow unclean. But perhaps there are good reasons.
> for example if it begins not with single line summary
> of commit, separated by empty line, but by multi-line paragraph.
> See also t/t3405-rebase-malformed.sh
Well, I have a test script that runs
for i in t0023* t3350* t340* t3901* t4014* t4150* t5520* t7402*
and I run that script before I do a commit and after I rebased.
And I ran the whole test suite before I posted the patchset to the list.
What I want to say is: t3405 did not fail with my --rebasing no-op.
That's perhaps one reason why I forgot about implementing --rebasing
correctly.
> Although I am not sure if when rebase is rewritten using git-sequencer
> implementing "git am --rebasing" would be truly needed.
I didn't want to touch that behavior for several reasons.
Of course, somehow I think that rebase and rebase-i should be merged,
calling sequencer directly, with the main difference that -i will
invoke an editor to allow editing of the TODO file.
But nobody is hurt, if I put such a change far far away.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-08 16:12 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080708144239.GJ6726@leksak.fem-net>
Stephan Beyer wrote:
> Jakub Narebski wrote:
>>> Yes, you are right that am --rebasing is a no-op.
>>> That option was a little mystery to me, because it seemed to do nothing
>>> special, but I'll check again (bash-completion etc) and do appropriate
>>> changes.
>>
>> Undocumented option '--rebasing' to git-am is internal option changing
>> git-am behavior to be better used by git-rebase, namely it does not
>> change commit message even if it doesn't follow git commit message
>> convention,
>
> Ah yes, I've seen it now.
>
> It is taking the commit message from the commit in the "From <commit> .*"
> line, does *not* change it in any way and then applies the changes using
> threeway merge.
Not exactly. "git am --rebasing" still tries to first just *apply*
the patch, then (I think) it falls back on blob-id based 3way merge.
> Keeping that in mind what about dealing with --rebasing like that:
> if --rebasing is given, git am simply generates
> pick <commit>
> lines, instead of
> patch -3 -k <msg>
> as it is now (and this is not enough, as it seems).
It is not.
Nevertheless it would be I think better for ordinary patch based rebase
to fall back not on git-am 3way merge, but on cherry-pick based merge
(i.e. on pick).
> The alternative for doing "pick" is teaching git-sequencer's "patch"
> insn an option that emulates the --rebasing behavior.
>
> For me this feels somehow unclean. But perhaps there are good reasons.
Why unclean?
But I agree that it would be nice to simplify '--rebasing' logic, for
example using patch or 2way merge to generate tree, and commit message
taken directly from commit, not via 'format-patch | am' pipeline.
> Of course, somehow I think that rebase and rebase-i should be merged,
> calling sequencer directly, with the main difference that -i will
> invoke an editor to allow editing of the TODO file.
> But nobody is hurt, if I put such a change far far away.
rebase-m and rebase-i can be merged; ordinary rebase uses other
mechanism: git-am pipeline, and not cherry-picking.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Joshua Roys @ 2008-07-08 16:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807080227.43515.jnareb@gmail.com>
Hello,
On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 1. GitTorrent (???)
>
> Student: Joshua Roys
> Mentor: Sam Vilain
>
> There was short thread of me asking about project
> http://thread.gmane.org/gmane.comp.version-control.git/83611
> where I got gittorrent mailing list (no activity at least according to
> list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> for project repo / gitweb... which is currently down, so I cannot check
> if there is anything here.
>
> What is the status of this project, please?
>
> http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
>
It's going slower than I would like, in part due to a two-week period
when I was out of the country. Other than that, it's going well, I
think. Sam had a lot of the framework stuff done at the start, and
I've just been working my way through it. My schedule has cleared up
for the remaining time, so things should move a little faster now.
The gitweb randomly gives 500/internal server errors, not sure why.
Joshua Roys
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Stephan Beyer @ 2008-07-08 16:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Christian Couder, Daniel Barkalow
In-Reply-To: <200807081812.15651.jnareb@gmail.com>
Hi,
Jakub Narebski wrote:
> > It is taking the commit message from the commit in the "From <commit> .*"
> > line, does *not* change it in any way and then applies the changes using
> > threeway merge.
>
> Not exactly. "git am --rebasing" still tries to first just *apply*
> the patch, then (I think) it falls back on blob-id based 3way merge.
That's of course totaly right and what I've meant, but unfortunately not
what I've written ;-)
> > Keeping that in mind what about dealing with --rebasing like that:
> > if --rebasing is given, git am simply generates
> > pick <commit>
> > lines, instead of
> > patch -3 -k <msg>
> > as it is now (and this is not enough, as it seems).
>
> It is not.
>
> Nevertheless it would be I think better for ordinary patch based rebase
> to fall back not on git-am 3way merge, but on cherry-pick based merge
> (i.e. on pick).
Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
am --rebasing... But cherry-pick should only be chosen if a simple git-apply
failed first. Right?
I just got another idea which could easily be done and perhaps is the
right thing :)
Generating
patch -C <commit> -3 <file>
This takes authorship and message from <commit> and does the usual
threeway-fallback behavior.
What do you think?
> But I agree that it would be nice to simplify '--rebasing' logic, for
> example using patch or 2way merge to generate tree, and commit message
> taken directly from commit, not via 'format-patch | am' pipeline.
That's right, but that would require me to hack around in git-rebase
which I tried to avoid for now. :)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Johannes Schindelin @ 2008-07-08 16:45 UTC (permalink / raw)
To: Joshua Roys
Cc: Jakub Narebski, git, Sam Vilain, Sverre Rabbelier,
Sverre Rabbelier, David Symonds, Lea Wiemann, John Hawley,
Marek Zawirski, Shawn O. Pearce, Miklos Vajna, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <19b271a20807080931w75430148u8c9778117c9fb6cc@mail.gmail.com>
Hi,
On Tue, 8 Jul 2008, Joshua Roys wrote:
> Hello,
>
> On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > 1. GitTorrent (???)
> >
> > Student: Joshua Roys
> > Mentor: Sam Vilain
> >
> > There was short thread of me asking about project
> > http://thread.gmane.org/gmane.comp.version-control.git/83611
> > where I got gittorrent mailing list (no activity at least according to
> > list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> > for project repo / gitweb... which is currently down, so I cannot check
> > if there is anything here.
> >
> > What is the status of this project, please?
> >
> > http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
> >
>
> It's going slower than I would like, in part due to a two-week period
> when I was out of the country. Other than that, it's going well, I
> think. Sam had a lot of the framework stuff done at the start, and
> I've just been working my way through it. My schedule has cleared up
> for the remaining time, so things should move a little faster now.
>
> The gitweb randomly gives 500/internal server errors, not sure why.
I thought you were working on the torrent stuff? What is the status on
that?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] bash: offer only paths after '--'
From: SZEDER Gábor @ 2008-07-08 16:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Shawn O. Pearce, Eric Raible, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807081335470.4319@eeepc-johanness>
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
On Tue, Jul 08, 2008 at 01:36:43PM +0200, Johannes Schindelin wrote:
> It shows two bugs, actually: completions do not care about "--",
I think I have found and corrected all the places where '--' was not
handled properly, but might have overlooked something.
Hope that I got the commit message right (;
contrib/completion/git-completion.bash | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6a15522..e7d8a75 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -451,6 +451,18 @@ __git_find_subcommand ()
done
}
+__git_has_doubledash ()
+{
+ local c=1
+ while [ $c -lt $COMP_CWORD ]; do
+ if [ "--" = "${COMP_WORDS[c]}" ]; then
+ return 0
+ fi
+ c=$((++c))
+ done
+ return 1
+}
+
__git_whitespacelist="nowarn warn error error-all strip"
_git_am ()
@@ -497,6 +509,8 @@ _git_apply ()
_git_add ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
@@ -511,6 +525,8 @@ _git_add ()
_git_bisect ()
{
+ __git_has_doubledash && return
+
local subcommands="start bad good skip reset visualize replay log run"
local subcommand="$(__git_find_subcommand "$subcommands")"
if [ -z "$subcommand" ]; then
@@ -612,6 +628,8 @@ _git_cherry_pick ()
_git_commit ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
@@ -631,6 +649,8 @@ _git_describe ()
_git_diff ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
@@ -733,6 +753,8 @@ _git_ls_tree ()
_git_log ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--pretty=*)
@@ -1088,6 +1110,8 @@ _git_remote ()
_git_reset ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
@@ -1100,6 +1124,8 @@ _git_reset ()
_git_shortlog ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
@@ -1157,6 +1183,8 @@ _git_stash ()
_git_submodule ()
{
+ __git_has_doubledash && return
+
local subcommands="add status init update"
if [ -z "$(__git_find_subcommand "$subcommands")" ]; then
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -1362,6 +1390,8 @@ _git ()
_gitk ()
{
+ __git_has_doubledash && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
local g="$(git rev-parse --git-dir 2>/dev/null)"
local merge=""
--
1.5.6.1.118.g82b2fef
^ permalink raw reply related
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Petr Baudis @ 2008-07-08 17:00 UTC (permalink / raw)
To: Joshua Roys
Cc: Jakub Narebski, git, Sam Vilain, Sverre Rabbelier,
Sverre Rabbelier, David Symonds, Lea Wiemann, John Hawley,
Marek Zawirski, Shawn O. Pearce, Miklos Vajna,
Johannes Schindelin, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <19b271a20807080931w75430148u8c9778117c9fb6cc@mail.gmail.com>
Hi,
On Tue, Jul 08, 2008 at 12:31:45PM -0400, Joshua Roys wrote:
> On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > 1. GitTorrent (???)
> >
> > Student: Joshua Roys
> > Mentor: Sam Vilain
> >
> > There was short thread of me asking about project
> > http://thread.gmane.org/gmane.comp.version-control.git/83611
> > where I got gittorrent mailing list (no activity at least according to
> > list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> > for project repo / gitweb... which is currently down, so I cannot check
> > if there is anything here.
> >
> > What is the status of this project, please?
> >
> > http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
> >
>
> It's going slower than I would like, in part due to a two-week period
> when I was out of the country. Other than that, it's going well, I
> think. Sam had a lot of the framework stuff done at the start, and
> I've just been working my way through it. My schedule has cleared up
> for the remaining time, so things should move a little faster now.
>
> The gitweb randomly gives 500/internal server errors, not sure why.
there's now a mirror at
http://repo.or.cz/w/VCS-Git-Torrent.git
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-08 17:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joshua Roys, git, Sam Vilain
In-Reply-To: <alpine.DEB.1.00.0807081745040.18205@racer>
Johannes Schindelin wrote:
> On Tue, 8 Jul 2008, Joshua Roys wrote:
>> On Mon, Jul 7, 2008 at 8:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> 1. GitTorrent (???)
>>> There was short thread of me asking about project
>>> http://thread.gmane.org/gmane.comp.version-control.git/83611
>>> where I got gittorrent mailing list [...] and URL
>>> for project repo / gitweb... which is currently down, so I cannot check
>>> if there is anything here.
[cut]
>>
>> The gitweb randomly gives 500/internal server errors, not sure why.
(I think it was web server error, as error message didn't look like
it was coming from gitweb; besides gitweb up to some time ago didn't
use "500 Internal Server Error" HTTP error status code.)
> I thought you were working on the torrent stuff? What is the status on
> that?
I think Jushua was referring here to the fact that gitweb for
GitTorrent project repository[1] is sometimes down (it was down
when I was writing initial email in this thread).
[1] http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
--
Jakub Narebski
Poland
^ permalink raw reply
* [HACK] gitweb: Support hiding of chosen repositories from project list
From: Petr Baudis @ 2008-07-08 16:56 UTC (permalink / raw)
To: git
This makes it possible to hide certain repository from project list
(while still keeping it accessible, so it's not just an inverse of
export-ok). By default the file that needs to be created in the
repository is '.hide'.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I used this for something at repo.or.cz, but it is actually lying around
unused in my patch queue now; before removing it, I'm going to archive it on
the mailing list, maybe someone will find it useful.
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3314dd6..b7c7f42 100644
--- a/Makefile
+++ b/Makefile
@@ -195,6 +195,7 @@ GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
GITWEB_PROJECT_MAXDEPTH = 2007
GITWEB_EXPORT_OK =
+GITWEB_HIDE_REPO = .hide
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
GITWEB_LIST =
@@ -1130,6 +1131,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
-e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
+ -e 's|++GITWEB_HIDE_REPO++|$(GITWEB_HIDE_REPO)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
-e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3b02d87..7ad0faa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -90,6 +90,11 @@ our $default_projects_order = "project";
# (only effective if this variable evaluates to true)
our $export_ok = "++GITWEB_EXPORT_OK++";
+# hide repository from the list if this file exists
+# (the repository is still accessible, just not shown in the project list)
+# (only effective if this variable evaulates to true)
+our $hide_repo = "++GITWEB_HIDE_REPO++";
+
# only allow viewing of repositories also shown on the overview page
our $strict_export = "++GITWEB_STRICT_EXPORT++";
@@ -1796,7 +1801,8 @@ sub git_get_projects_list {
# we check related file in $projectroot
if ($check_forks and $subdir =~ m#/.#) {
$File::Find::prune = 1;
- } elsif (check_export_ok("$projectroot/$filter/$subdir")) {
+ } elsif ((!$hide_repo or ! -e "$projectroot/$filter/$subdir/$hide_repo")
+ and check_export_ok("$projectroot/$filter/$subdir")) {
push @list, { path => ($filter ? "$filter/" : '') . $subdir };
$File::Find::prune = 1;
}
@@ -1846,7 +1852,8 @@ sub git_get_projects_list {
next PROJECT;
}
}
- if (check_export_ok("$projectroot/$path")) {
+ if ((!$hide_repo or ! -e "$projectroot/$path/$hide_repo")
+ and check_export_ok("$projectroot/$path")) {
my $pr = {
path => $path,
owner => to_utf8($owner),
^ permalink raw reply related
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-08 17:31 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080708163430.GK6726@leksak.fem-net>
Hi!
On Wed, 8 July 2008, Stephan Beyer wrote:
> Jakub Narebski wrote:
>> Stephan Beyer wrote:
>>>
>>> It is taking the commit message from the commit in the "From <commit> .*"
>>> line, does *not* change it in any way and then applies the changes using
>>> threeway merge.
>>
>> Not exactly. "git am --rebasing" still tries to first just *apply*
>> the patch, then (I think) it falls back on blob-id based 3way merge.
>
> That's of course totaly right and what I've meant, but unfortunately not
> what I've written ;-)
>
>>> Keeping that in mind what about dealing with --rebasing like that:
>>> if --rebasing is given, git am simply generates
>>> pick <commit>
>>> lines, instead of
>>> patch -3 -k <msg>
>>> as it is now (and this is not enough, as it seems).
>>
>> It is not.
>>
>> Nevertheless it would be I think better for ordinary patch based rebase
>> to fall back not on git-am 3way merge, but on cherry-pick based merge
>> (i.e. on pick).
>
> Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
> am --rebasing... But cherry-pick should only be chosen if a simple git-apply
> failed first. Right?
Right.
> I just got another idea which could easily be done and perhaps is the
> right thing :)
> Generating
> patch -C <commit> -3 <file>
>
> This takes authorship and message from <commit> and does the usual
> threeway-fallback behavior.
>
> What do you think?
Very good idea (I have proposed something similar either here on in
another thread). It would avoid some unnecessary "marshalling" and
"unmarshalling" which is needed to transfer commit message [unchanged]
through git-format-patch -> git-am pipeline, namely putting first
paragraph into subject line, generating then parsing RFC-2822 date,
using quoted printable encoding for first paragraph / subject header
(I think).
It would be still better to fallback to _pick_, not "git am --3way",
as the latter IIRC use _shortened_ _blob_ identifiers for pre- and
post-image to find common ancestor (merge base) for 3way merge.
Which is not necessary as we can find merge base and base commits
easier.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [take 2] revision parsing made incremental
From: Linus Torvalds @ 2008-07-08 17:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster, peff, Johannes.Schindelin
In-Reply-To: <1215523175-28436-1-git-send-email-madcoder@debian.org>
On Tue, 8 Jul 2008, Pierre Habouzit wrote:
>
> The series passes the testsuite, has no know blanks issues, and is
> pushed to my public repository.
Ack. Looks good to me.
Linus
^ permalink raw reply
* git-svn dcommit and setting svn properties
From: Tim Prouty @ 2008-07-08 17:30 UTC (permalink / raw)
To: git
Hi,
My internal subversion repository has a pre-commit script that
requires the svn:mime-type and svn:eol-style properties to be set on
any new file before it can be added to the repository. If these
properties aren't set, the commit fails. When using git-svn dcommit
to commit a patch that adds a new file, the dcommit also fails with
the error below. I have added auto-props rules in my ~/.subversion/
config file to automatically set these properties based on file
extension, so an svn commit doesn't require explicitly setting them.
I tried adding the --config-dir=~/.subversion option to the dcommit
command, but it didn't seem to make a difference.
Is there any way to set these properties or consult subversion auto-
props so that git-svn knows how to set them during the dcommit? Would
it be difficult to add this capability if it doesn't already exist?
Example command and subsequent error:
# git-svn dcommit --verbose --config-dir=~/.subversion
Committing to https://svn/repo/foo ...
A bar.c
A repository hook failed: MERGE request failed on '/repo/foo': 'pre-
commit' hook failed with error output:
/svnrepo/hooks/check-mime-type.pl:
foo/bar.c : svn:mime-type is not set
Every added file must have the svn:mime-type property set. In
addition text files must have the svn:eol-style property set.
For binary files try running
svn propset svn:mime-type application/octet-stream path/of/file
For text files try
svn propset svn:mime-type text/plain path/of/file
svn propset svn:eol-style native path/of/file
You may want to consider uncommenting the auto-props section
in your ~/.subversion/config file. Read the Subversion book
(http://svnbook.red-bean.com/), Chapter 7, Properties section,
Automatic Property Setting subsection for more help.
at /usr/bin/git-svn line 461
Thanks!
-Tim
^ permalink raw reply
* Re: [PATCH] bash: offer only paths after '--'
From: Eric Raible @ 2008-07-08 17:46 UTC (permalink / raw)
To: git
In-Reply-To: <20080708165614.GB8224@neumann>
SZEDER Gábor <szeder <at> ira.uka.de> writes:
>
> Many git commands use '--' to separate subcommands, options, and refs
> from paths. However, the programmable completion for several of these
> commands does not respect the '--', and offer subcommands, options, or
> refs after a '--', although only paths are permitted. e.g. 'git bisect
I like this change, but how about also offering a plain '--' as one
of the completion choices as a way of reminding newbies that the
command in question is one of the ones that takes filenames after
all options?
^ permalink raw reply
* [PATCH] Git.pm: Add remote_refs() git-ls-remote frontend
From: Petr Baudis @ 2008-07-08 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch also converts the good ole' git-remote.perl to use it.
It is otherwise used in the repo.or.cz machinery and I guess other
scripts might find it useful too.
Unfortunately,
git-ls-remote --heads .
is subtly different from
git-ls-remote . refs/heads/
(since the second matches anywhere in the string, not just at the
beginning) so we have to provide interface for both.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
This is resend after another year. ;-)
contrib/examples/git-remote.perl | 5 +--
perl/Git.pm | 56 +++++++++++++++++++++++++++++++++++++-
2 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/contrib/examples/git-remote.perl b/contrib/examples/git-remote.perl
index b30ed73..36bd54c 100755
--- a/contrib/examples/git-remote.perl
+++ b/contrib/examples/git-remote.perl
@@ -129,10 +129,7 @@ sub update_ls_remote {
return if (($harder == 0) ||
(($harder == 1) && exists $info->{'LS_REMOTE'}));
- my @ref = map {
- s|^[0-9a-f]{40}\s+refs/heads/||;
- $_;
- } $git->command(qw(ls-remote --heads), $info->{'URL'});
+ my @ref = map { s|refs/heads/||; $_; } keys %{$git->remote_refs($info->{'URL'}, [ 'heads' ])};
$info->{'LS_REMOTE'} = \@ref;
}
diff --git a/perl/Git.pm b/perl/Git.pm
index 97e61ef..d99e778 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -56,7 +56,8 @@ require Exporter;
@EXPORT_OK = qw(command command_oneline command_noisy
command_output_pipe command_input_pipe command_close_pipe
command_bidi_pipe command_close_bidi_pipe
- version exec_path hash_object git_cmd_try);
+ version exec_path hash_object git_cmd_try
+ remote_refs);
=head1 DESCRIPTION
@@ -668,6 +669,59 @@ sub get_color {
return $color;
}
+=item remote_refs ( REPOSITORY [, GROUPS [, REFGLOBS ] ] )
+
+This function returns a hashref of refs stored in a given remote repository.
+The hash is in the format C<refname =\> hash>. For tags, the C<refname> entry
+contains the tag object while a C<refname^{}> entry gives the tagged objects.
+
+C<REPOSITORY> has the same meaning as the appropriate C<git-ls-remote>
+argument; either an URL or a remote name (if called on a repository instance).
+C<GROUPS> is an optional arrayref that can contain 'tags' to return all the
+tags and/or 'heads' to return all the heads. C<REFGLOB> is an optional array
+of strings containing a shell-like glob to further limit the refs returned in
+the hash; the meaning is again the same as the appropriate C<git-ls-remote>
+argument.
+
+This function may or may not be called on a repository instance. In the former
+case, remote names as defined in the repository are recognized as repository
+specifiers.
+
+=cut
+
+sub remote_refs {
+ my ($self, $repo, $groups, $refglobs) = _maybe_self(@_);
+ my @args;
+ if (ref $groups eq 'ARRAY') {
+ foreach (@$groups) {
+ if ($_ eq 'heads') {
+ push (@args, '--heads');
+ } elsif ($_ eq 'tags') {
+ push (@args, '--tags');
+ } else {
+ # Ignore unknown groups for future
+ # compatibility
+ }
+ }
+ }
+ push (@args, $repo);
+ if (ref $refglobs eq 'ARRAY') {
+ push (@args, @$refglobs);
+ }
+
+ my @self = $self ? ($self) : (); # Ultra trickery
+ my ($fh, $ctx) = Git::command_output_pipe(@self, 'ls-remote', @args);
+ my %refs;
+ while (<$fh>) {
+ chomp;
+ my ($hash, $ref) = split(/\t/, $_, 2);
+ $refs{$ref} = $hash;
+ }
+ Git::command_close_pipe(@self, $fh, $ctx);
+ return \%refs;
+}
+
+
=item ident ( TYPE | IDENTSTR )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
^ permalink raw reply related
* GiT and CentOS 5.2
From: James B. Byrne @ 2008-07-08 17:46 UTC (permalink / raw)
To: git
OS = CentOS-5.2
perl = 5.8.8
I get git from the yum repository at kernel.org. Up until the most recent
update I had no problems. Now I am getting these dependency errors:
Error: Missing Dependency: libcurl.so.4 is needed by package git
Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
package perl-Git
Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
Error: Missing Dependency: libexpat.so.1 is needed by package git
Error: Missing Dependency: libcrypto.so.7 is needed by package git
Are these dependencies actually meaningful? By that I mean, are there
features used in the latest release of GiT that depend upon features of
GLIBC 2.7 that are not part of glibc-2.5? Similarly, are there features
of curl used in the latest git that are not present or work differently in
curl 7.15.2? Ditto for OpenSSL and libxpat.
I would like to stay current with git but I cannot if these dependencies
are actually required.
Regards,
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Mike Hommey @ 2008-07-08 18:37 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
On Tue, Jul 08, 2008 at 01:46:40PM -0400, James B. Byrne wrote:
> OS = CentOS-5.2
> perl = 5.8.8
>
> I get git from the yum repository at kernel.org. Up until the most recent
> update I had no problems. Now I am getting these dependency errors:
>
> Error: Missing Dependency: libcurl.so.4 is needed by package git
> Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
> package perl-Git
> Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
> Error: Missing Dependency: libexpat.so.1 is needed by package git
> Error: Missing Dependency: libcrypto.so.7 is needed by package git
>
>
> Are these dependencies actually meaningful? By that I mean, are there
> features used in the latest release of GiT that depend upon features of
> GLIBC 2.7 that are not part of glibc-2.5? Similarly, are there features
> of curl used in the latest git that are not present or work differently in
> curl 7.15.2? Ditto for OpenSSL and libxpat.
This only means the rpms in the yum repository at kernel.org were built
on a system more recent than yours, and that run-time dependencies (as
opposed to build dependencies) require some libraries to be newer than
what your system provides.
Mike
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Jay Soffian @ 2008-07-08 18:51 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
On Tue, Jul 8, 2008 at 1:46 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote:
> OS = CentOS-5.2
> perl = 5.8.8
>
> I get git from the yum repository at kernel.org. Up until the most recent
> update I had no problems. Now I am getting these dependency errors:
>
> Error: Missing Dependency: libcurl.so.4 is needed by package git
> Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
> package perl-Git
> Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
> Error: Missing Dependency: libexpat.so.1 is needed by package git
> Error: Missing Dependency: libcrypto.so.7 is needed by package git
>
>
> Are these dependencies actually meaningful? By that I mean, are there
> features used in the latest release of GiT that depend upon features of
> GLIBC 2.7 that are not part of glibc-2.5? Similarly, are there features
> of curl used in the latest git that are not present or work differently in
> curl 7.15.2? Ditto for OpenSSL and libxpat.
>
> I would like to stay current with git but I cannot if these dependencies
> are actually required.
Junio switched to FC9 for building the git RPMs on kernel.org recently.
Probably the best thing to do if you want a CentOS 5.x RPM is to grab
the source tgz and build the RPM yourself. :-(
There are quite a few build-time dependencies, but those are easy to
take care of with yum.
j.
^ permalink raw reply
* [Fwd: Re: GiT and CentOS 5.2]
From: James B. Byrne @ 2008-07-08 18:51 UTC (permalink / raw)
To: git
On Tue, July 8, 2008 14:37, Mike Hommey wrote:
>
> This only means the rpms in the yum repository at kernel.org were built
> on a system more recent than yours, and that run-time dependencies (as
> opposed to build dependencies) require some libraries to be newer than
> what your system provides.
I understand the meaning of the error messages. What I am asking is
whether or not any of these dependencies is substantive. If they are then
I am stuck at the immediately previous release of GiT. If not then I have
the option to either build from source or force an rpm update. If I force
then I can no long use yum but at least I have the applicate managed by
rpm. If I build from source then I lose that as well.
So, my question still remains: are these dependencies only artifacts of
the build environment or do they supply actual features that the latest
release of GiT depends upon and which are not available in the earlier
version of the software?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
^ permalink raw reply
* Re: [Fwd: Re: GiT and CentOS 5.2]
From: Jay Soffian @ 2008-07-08 18:58 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <50493.216.185.71.22.1215543081.squirrel@webmail.harte-lyne.ca>
On Tue, Jul 8, 2008 at 2:51 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote:
> So, my question still remains: are these dependencies only artifacts of
> the build environment or do they supply actual features that the latest
> release of GiT depends upon and which are not available in the earlier
> version of the software?
You could of course answer this yourself. Download the latest RPM, rpm
--nodeps or rpm2cpio it and see if it works.
But from the looks of it, the git binary links against libraries not
on your system and it will not work.
j.
^ permalink raw reply
* Re: [Fwd: Re: GiT and CentOS 5.2]
From: Jakub Narebski @ 2008-07-08 19:12 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <50493.216.185.71.22.1215543081.squirrel@webmail.harte-lyne.ca>
"James B. Byrne" <byrnejb@harte-lyne.ca> writes:
> On Tue, July 8, 2008 14:37, Mike Hommey wrote:
> >
> > This only means the rpms in the yum repository at kernel.org were built
> > on a system more recent than yours, and that run-time dependencies (as
> > opposed to build dependencies) require some libraries to be newer than
> > what your system provides.
>
> I understand the meaning of the error messages. What I am asking is
> whether or not any of these dependencies is substantive. If they are then
> I am stuck at the immediately previous release of Git. If not then I have
> the option to either build from source or force an rpm update. If I force
> then I can no long use yum but at least I have the applicate managed by
> rpm. If I build from source then I lose that as well.
>
> So, my question still remains: are these dependencies only artifacts of
> the build environment or do they supply actual features that the latest
> release of Git depends upon and which are not available in the earlier
> version of the software?
They are artifact of the build environment (which picks up the
libraries that they are here); till 1.5.6.1 I have compiled git
and used git succesfully on Fedora Core 4 based dostribution
(Aurox 11.1).
I am now compiling[1] 1.5.6.2, and so far don't have any problems
(now it is at building documentation; it would be nice to be
able to use pre-build documentation from SRPM).
[1] $ rpmbuild --rebuild git-1.5.6.2-1.fc9.src.rpm
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [Fwd: Re: GiT and CentOS 5.2]
From: James B. Byrne @ 2008-07-08 19:15 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490807081158v5acb6e6co670597d5e08db6c1@mail.gmail.com>
On Tue, July 8, 2008 14:58, Jay Soffian wrote:
> You could of course answer this yourself. Download the latest RPM, rpm
> --nodeps or rpm2cpio it and see if it works.
>
> But from the looks of it, the git binary links against libraries not
> on your system and it will not work.
Yes, it appears so. Having just converted our projects from subversion to
git I am reluctant to beat my brains out trying to maintain yet another
moving target that is, in the end, only a support tool. The most recent
GiT source builds without complaint on my development system so the
dependencies are purely build environment artifacts and are not
substantive. This change to the rpm build platform is unfortunate for me
since I now lose a very convenient update process and have to choose
between rebuilding at each release or stabilizing at 1.5.6.1.
Nonetheless, I will no doubt live through this... Sigh.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Junio C Hamano @ 2008-07-08 19:23 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
"James B. Byrne" <byrnejb@harte-lyne.ca> writes:
> OS = CentOS-5.2
> perl = 5.8.8
>
> I get git from the yum repository at kernel.org. Up until the most recent
> update I had no problems. Now I am getting these dependency errors:
>
> Error: Missing Dependency: libcurl.so.4 is needed by package git
> Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
> package perl-Git
> Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
> Error: Missing Dependency: libexpat.so.1 is needed by package git
> Error: Missing Dependency: libcrypto.so.7 is needed by package git
As described in the announcement for 1.5.6.2, the machine at kernel.org I
cut x86_64 RPM on switched to FC9 early this month, and I updated my
personal bochs installation to FC9 to be consistent for producing i386
RPMs.
By the way, these RPMs are not in any way official. I have been guessing
(without even bothering to confirm) that even for FC, distro people do not
use the RPM packages I have at kernel.org, but they build and distribute
their own to their users. I could stop generating these RPMs, in other
words, but I've been doing this forever and they are still produced as
courtesy, even though I am not a FC user myself.
You could send a preconfigured CentOS 5.2 box to me and ask me to produce
yet another set of RPMs. The release procedure already takes long enough
time out of my git day, however, and I doubt I can afford the time to do
so in practice, without reducing the time I spend on other git activities
such as reviewing and accepting changes from others or writing patches
myself.
People on other platforms like Debian, Macintosh, and Windows (Cygwin and
Msys) generate their own packages from the official tarballs and
distribute the result to help other users on their platforms. Perhaps you
and other CentOS users can get together and do the same to help each
other? That would be a great help to the community.
Thanks.
^ 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