* Re: Git user survey and `git pull`
From: Nicolas Pitre @ 2006-09-21 17:02 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060921162401.GD3934@spearce.org>
On Thu, 21 Sep 2006, Shawn Pearce wrote:
> I think its probably too late to change the UI[*1*] but I think
> it is definately an issue for folks learning Git. Calling push
> push, fetch fetch and fetch+merge pull is probably a design flaw.
> IMHO it probably should have been something like:
>
> Current Shoulda Been
> --------------- ----------------
> git-push git-push
> git-fetch git-pull
> git-pull . foo git-merge foo
> git-pull git-pull --merge
> git-merge git-merge-driver
>
> in other words pull does the download and doesn't automatically
> start a merge unless --merge was also given and git-merge is a
> cleaner wrapper around the Grand Unified Merge Driver that makes
> it easier to start a merge.
I must say that I second this. Although I'm rather familiar with GIT I
still feel unconfortable with the current naming and behavior.
Nicolas
^ permalink raw reply
* Re: Git Survey summary
From: Jakub Narebski @ 2006-09-21 16:49 UTC (permalink / raw)
To: git
In-Reply-To: <20060921163452.GW8259@pasky.or.cz>
Petr Baudis wrote:
>> When reading the mailing list via the web I do tend to read through
>> GMane more than MARC but I can't state why I have that preference.
>> It just happens. Maybe I prefer white backgrounds over black ones?
>
> Surprisingly few web mailing list interfaces are actually usable for
> reading threads. Gmane is, MARC isn't (you don't see the list of
> references and replies to the current mail, and the next/prev in thread
> links somehow don't seem to be very reliable). That's a killer feature
> for me, if MARC had that I'd have preferred it (I like black background
> and dislike frames).
From what I guessed, MARC groups threads by _title only_, while GMane
seems to parse In-Reply-To:/References: headers for threading.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git Survey summary
From: Petr Baudis @ 2006-09-21 17:00 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0609210949l3d7e6e1ch825d2ef31caae89a@mail.gmail.com>
Dear diary, on Thu, Sep 21, 2006 at 06:49:52PM CEST, I got a letter
where Nguyen Thai Ngoc Duy <pclouds@gmail.com> said that...
> Anyway it's still good to clearly state the git mailing list is for
> discussion, bug reports and feature requests in git.7 man page
> (together with git homepage maybe)
Ok, I tried to clarify that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Git Survey summary
From: Nguyen Thai Ngoc Duy @ 2006-09-21 16:49 UTC (permalink / raw)
To: git
In-Reply-To: <eeuapj$mgn$1@sea.gmane.org>
On 9/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Nguyen Thai Ngoc Duy wrote:
>
> > - A place to post bugs and feature requests (if bugzilla is too big,
> > maybe mantis?)
>
> Isn't this mailing list the place to post bugreports and feature requests
> (and of course patches)?
Because it's harder to keep track of a long-living bug/request which
spans many threads. I think git mailing list is for git development
and helping users. It's not clear it should be a place to request
features. I'm still wondering why people requested a lot in the survey
while more than half subscribed to the mailing list. I personally feel
the mailing list is a place for _contributing_ features (thoughtful
ideas or patches) not just requesting features (desires without no
clear idea how to implement it).
Anyway it's still good to clearly state the git mailing list is for
discussion, bug reports and feature requests in git.7 man page
(together with git homepage maybe)
> Any bugtracker has to be tied to mailing list, and
> perhaps also two-way to gitweb (gitweb making links to bugtracker issues,
> bugtracker having links to gitweb; perhaps incrementing revision
> numbers...).
Ruby (or YARV, I don't remember exactly) uses a bug tracking system
that depends heavily on mailing lists (open bug with a mail, close bug
with a mail ...). The benefit is that we have at least bug numbers :-)
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
--
Duy
^ permalink raw reply
* Re: Git Survey summary
From: Shawn Pearce @ 2006-09-21 16:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20060921163732.GX8259@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Sep 21, 2006 at 05:56:17PM CEST, I got a letter
> where Shawn Pearce <spearce@spearce.org> said that...
> > I'm all for hyperlink integration of gitweb and bug tracking systems
>
> Actually, Trac might be interesting if you want tight VCS web interface
> and bugtracking web interface integration, although Trac is not very
> powerful. I think the OLPC people did some work on integrating Trac and
> Git.
>
> People will think I'm weird, but I have to admit that I rather do like
> Bugzilla.
Your not weird. I also like Bugzilla for some projects; its rather
simple and somewhat easy to use... I also know a lot of people
who hate it.
> I think we are doing fine as it is for now, though.
Oh I agree completely. But that's the Git project.
However I think it would be nice if we had native hooks shipped
with core Git to connect to some popular bug tracking systems such
as Bugzilla and Trac. Nothing incredibly fancy, but like how we
currently ship some default example hooks (and even install them into
every repo with `git init-db`!) we should at least ship some basic
examples and documentation for integrating to some popular systems.
Integrate with at least 2 and it should be easy for users to add
others...
Eh, its just more stuff for an ever growing wishlist. :-)
I probably won't do it as its not high on my wish list for Git.
I don't currently use any bug tracking systems.
--
Shawn.
^ permalink raw reply
* Re: Git Survey summary
From: Jakub Narebski @ 2006-09-21 16:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060921162724.GE3934@spearce.org>
Shawn Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Shawn Pearce wrote:
>>
>>> Since Git uses a mailing list model it would be nice if the gitweb
>>> hyperlinks were into the marc and GMane archives by Message-ID;
>>
>> Planned (as an example committag support).
>>
>> Would it be better ti use MARC or GMane interface:
>> http://marc.theaimsgroup.com/?i=200609200739.48732.alan%20()%20chandlerfamily%20!%20org%20!%20uk
>> http://news.gmane.org/find-root.php?message_id=<200609200739.48732.alan@chandlerfamily.org.uk>
>
> Well, the GMane link worked and displayed the thread; the MARC
> one didn't. The GMane link is also less mangled.
Both links works for me, although MARC one is incompatibile with
most of MUA marking of text/plain link. And probably those "%20"
can be entered simply as " "... yes, they can.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Petr Baudis @ 2006-09-21 16:40 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060921162401.GD3934@spearce.org>
Dear diary, on Thu, Sep 21, 2006 at 06:24:01PM CEST, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> in other words pull does the download and doesn't automatically
> start a merge
This is artifact of the BitKeeper terminology. This is the meaning in
most other VCSes but in BitKeeper, pull meant "get changes and merge
them", not just "get changes". So the BitKeeper legacy lives on. :-)
The route I took for Cogito is to just avoid calling _any_ command
"pull". It's too confusing. "update" does the same as "cvs update" or
"svn update" and I didn't notice people having much problem with that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Git Survey summary
From: Petr Baudis @ 2006-09-21 16:37 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20060921155617.GB3934@spearce.org>
Dear diary, on Thu, Sep 21, 2006 at 05:56:17PM CEST, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> I'm all for hyperlink integration of gitweb and bug tracking systems
Actually, Trac might be interesting if you want tight VCS web interface
and bugtracking web interface integration, although Trac is not very
powerful. I think the OLPC people did some work on integrating Trac and
Git.
People will think I'm weird, but I have to admit that I rather do like
Bugzilla.
I think we are doing fine as it is for now, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Git Survey summary
From: Petr Baudis @ 2006-09-21 16:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20060921162724.GE3934@spearce.org>
Dear diary, on Thu, Sep 21, 2006 at 06:27:24PM CEST, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Shawn Pearce wrote:
> >
> > > Since Git uses a mailing list model it would be nice if the gitweb
> > > hyperlinks were into the marc and GMane archives by Message-ID;
> >
> > Planned (as an example committag support).
> >
> > Would it be better ti use MARC or GMane interface:
> > http://marc.theaimsgroup.com/?i=200609200739.48732.alan%20()%20chandlerfamily%20!%20org%20!%20uk
> > http://news.gmane.org/find-root.php?message_id=<200609200739.48732.alan@chandlerfamily.org.uk>
>
> Well, the GMane link worked and displayed the thread; the MARC
> one didn't. The GMane link is also less mangled.
>
> When reading the mailing list via the web I do tend to read through
> GMane more than MARC but I can't state why I have that preference.
> It just happens. Maybe I prefer white backgrounds over black ones?
Surprisingly few web mailing list interfaces are actually usable for
reading threads. Gmane is, MARC isn't (you don't see the list of
references and replies to the current mail, and the next/prev in thread
links somehow don't seem to be very reliable). That's a killer feature
for me, if MARC had that I'd have preferred it (I like black background
and dislike frames).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Git Survey summary
From: Shawn Pearce @ 2006-09-21 16:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeudn6$400$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn Pearce wrote:
>
> > Since Git uses a mailing list model it would be nice if the gitweb
> > hyperlinks were into the marc and GMane archives by Message-ID;
>
> Planned (as an example committag support).
>
> Would it be better ti use MARC or GMane interface:
> http://marc.theaimsgroup.com/?i=200609200739.48732.alan%20()%20chandlerfamily%20!%20org%20!%20uk
> http://news.gmane.org/find-root.php?message_id=<200609200739.48732.alan@chandlerfamily.org.uk>
Well, the GMane link worked and displayed the thread; the MARC
one didn't. The GMane link is also less mangled.
When reading the mailing list via the web I do tend to read through
GMane more than MARC but I can't state why I have that preference.
It just happens. Maybe I prefer white backgrounds over black ones?
--
Shawn.
^ permalink raw reply
* Git user survey and `git pull`
From: Shawn Pearce @ 2006-09-21 16:24 UTC (permalink / raw)
To: git
I just saw this comment under question 20:
git-pull's behavior of merging in the first refspec to the
current branch is very bad and has caused us serious repository
issues in xorg.
Most of the folks I've been teaching Git to recently have found `git
fetch` to be a very counterintuitive command for fetching things.
Especially since `git push` is what's used to send changes to
the remote repository. They also find `git pull . foo` as a
counterintuitive way to merge changes.
Basically I'm seeing users run `git pull` when they probably
should have run just `git fetch`; the pull obviously also merges
the first refspec in .git/remotes/origin to the current branch
and that's usually not what the user wanted, especially when the
upstream remote has several branches that the user may be tracking
(e.g. stable, dev, experimental).
I think its probably too late to change the UI[*1*] but I think
it is definately an issue for folks learning Git. Calling push
push, fetch fetch and fetch+merge pull is probably a design flaw.
IMHO it probably should have been something like:
Current Shoulda Been
--------------- ----------------
git-push git-push
git-fetch git-pull
git-pull . foo git-merge foo
git-pull git-pull --merge
git-merge git-merge-driver
in other words pull does the download and doesn't automatically
start a merge unless --merge was also given and git-merge is a
cleaner wrapper around the Grand Unified Merge Driver that makes
it easier to start a merge.
[*1*] I bet a lot of scripts are currently based on the core
Git Poreclain level functions. I try to avoid them myself
in scripts and go right to the plumbing but not everyone
does that.
--
Shawn.
^ permalink raw reply
* Re: Git Survey summary
From: Jakub Narebski @ 2006-09-21 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <20060921155617.GB3934@spearce.org>
Shawn Pearce wrote:
> Since Git uses a mailing list model it would be nice if the gitweb
> hyperlinks were into the marc and GMane archives by Message-ID;
Planned (as an example committag support).
Would it be better ti use MARC or GMane interface:
http://marc.theaimsgroup.com/?i=200609200739.48732.alan%20()%20chandlerfamily%20!%20org%20!%20uk
http://news.gmane.org/find-root.php?message_id=<200609200739.48732.alan@chandlerfamily.org.uk>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Make git_get_hash_by_path check type if provided
From: Jakub Narebski @ 2006-09-21 16:09 UTC (permalink / raw)
To: git
In-Reply-To: <200609211423.29729.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch depends textually (as context) from the previous patch.
It can be applied using -C1 without applying previous patch first.
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 403bba1..7ed963c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -718,6 +718,7 @@ # get hash of given path at given ref
sub git_get_hash_by_path {
my $base = shift;
my $path = shift || return undef;
+ my $type = shift;
$path =~ s,/+$,,;
@@ -728,6 +729,10 @@ sub git_get_hash_by_path {
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
$line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/;
+ if (defined $type && $type ne $2) {
+ # type doesn't match
+ return undef;
+ }
return $3;
}
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH 0/6] packed deltas with offset to base instead of sha1
From: Shawn Pearce @ 2006-09-21 16:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v4pv1eqgl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > The following patches are the result of my work to allow deltas to have
> > their base specified as an offset within a pack instead of a 20 byte
> > sha1.
> >
> > This turned to be somewhat more involved than I originally expected.
> > Given the relative pack reduction resulting from that, I might have
> > decided against doing this if I had known beforehand how much work was
> > needed.
> >
> > But since it is done now I think it is worth merging nevertheless. Some
> > parts are still pure code cleanups anyway.
> >
> > Overall the larger projects are likely to benefit more as they have a
> > larger proportion of deltas. On the historic Linux archive the pack
> > reduction is about 5%.
>
> Nice, although I suspect this would make it a bit more involved
> to merge a few outstanding stuff.
If you are talking about my mmap window code merge in Nico's
work first. Nico posted before me and did so with a working
implementation that looks good (at first glance anyway, I didn't
study it in detail). I have yet to finish merging my mmap code
onto your verify delta before reuse (106d710b) commits. I've just
been too busy with classes and research work to get around to it.
However I have looked at the merge and I more or less need to
rewrite a good chunk of it just to get it onto 106d7; rewriting it
onto Nico's work here is probably going to be about the same amount
of effort. I'd prefer to rewrite it only once, given how limited
my time has suddenly become.
--
Shawn.
^ permalink raw reply
* Re: Git Survey summary
From: Shawn Pearce @ 2006-09-21 15:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeuapj$mgn$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Nguy?n Thái Ng?c Duy wrote:
>
> > - A place to post bugs and feature requests (if bugzilla is too big,
> > maybe mantis?)
>
> Isn't this mailing list the place to post bugreports and feature requests
> (and of course patches)? Any bugtracker has to be tied to mailing list, and
> perhaps also two-way to gitweb (gitweb making links to bugtracker issues,
> bugtracker having links to gitweb; perhaps incrementing revision
> numbers...).
Its funny, some communities are based around their bug tracking
systems (Mozilla) and others around their mailing lists (kernel, git).
Both work, but only if those participating make it so. Trying to
force one type of community into another model can kill it.
I'm all for hyperlink integration of gitweb and bug tracking systems
but bug tracking tends to be a personal preference; there's so
many choices. So whatever support is in gitweb needs to be pretty
modular to allow users to drop in the configuration for whatever
bug tracking system a given repository uses.
Since Git uses a mailing list model it would be nice if the gitweb
hyperlinks were into the marc and GMane archives by Message-ID; but
that would also require that commits start including the Message-ID
of the thread which spawned the patches. It would also be nice
if the links were able to jump to the discussion about the patch,
as sometimes the patch thread is different from the spawning thread.
--
Shawn.
^ permalink raw reply
* Re: Git Survey summary
From: Jakub Narebski @ 2006-09-21 15:23 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0609210712i125822c4gf8af3ecccdbd3d13@mail.gmail.com>
Nguy?n Thái Ng?c Duy wrote:
> - A place to post bugs and feature requests (if bugzilla is too big,
> maybe mantis?)
Isn't this mailing list the place to post bugreports and feature requests
(and of course patches)? Any bugtracker has to be tied to mailing list, and
perhaps also two-way to gitweb (gitweb making links to bugtracker issues,
bugtracker having links to gitweb; perhaps incrementing revision
numbers...).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] git-pack-refs --prune
From: Linus Torvalds @ 2006-09-21 15:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64fhd7ns.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Sep 2006, Junio C Hamano wrote:
>
> Ok, so I did these and the result is a 4-patch series.
Looks good to me. I would have combined 2/3, since the bulk of them is the
calling conversion change, and they both add a new argument to the same
function, so combining them would make just one patch that isn't even
noticeably larger than either of the two originals, but that's just a
small nitpick.
Having callback data is clearly good, and the "flags" may end up being
useful for other things in the future too (ie if we add attributes to
branches, we could at some point have "hidden" and "read-only" etc flags)
Linus
^ permalink raw reply
* Re: Git Survey summary
From: Nguyễn Thái Ngọc Duy @ 2006-09-21 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0609120205m38a44571we21e05864c04a731@mail.gmail.com>
FYI, I've completed the survey summary (except Q13, repo size, which I
don't know how to handle it. And there was no Q14 in GitSurveyData).
You may be interested in Q20 and Q31.
Some thought after completing this summary:
- Documentation is still most wanted (as a comprehensive book or
examples/use-cases). There were many answers indicated that users
didn't know about existing git features. We should advertise git
features more.
- Git homepage and Git wiki (and sometimes git mailing list) are
unknown to many users. Perhaps we should put them in git.7 man page?
- Plumbings/Porcelains confustion. Is it about time to move all git-*
into /usr/lib/git? Also some probably wants to integrate cogito into
git.
- A place to post bugs and feature requests (if bugzilla is too big,
maybe mantis?)
- (This comment is mine) Git should ship NEWS file in release
tarballs. An auto generated ChangeLog in tarballs is also great (maybe
make git-changelog to generate the changelog)
--
Duy
^ permalink raw reply
* [PATCH] gitweb: Strip trailing slashes from $path in git_get_hash_by_path
From: Jakub Narebski @ 2006-09-21 12:23 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
While
git ls-tree $base -- dirname
shows dirname entry (that's what we want)
git ls-tree $base -- dirname/
shows directory _contents_.
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index fb8d37e..403bba1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -719,7 +719,7 @@ sub git_get_hash_by_path {
my $base = shift;
my $path = shift || return undef;
- my $tree = $base;
+ $path =~ s,/+$,,;
open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path
or die_error(undef, "Open git-ls-tree failed");
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Andy Whitcroft @ 2006-09-21 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt7yij12.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
>>> About the quoting and parsing, language specific quoting mode is
>>> meant for git-for-each-ref to produce a string that can be eval'ed
>>> in the host language. Think of the command as a tool to write a
>>> short program for you.
>> Thanks for the education. Very simple, and very powerful. I knew there
>> was a reason for it out there. Will respin a V3 patch in a bit.
>
> This probably showed that my initial description and example for
> the feature found in Documentation/git-for-each-ref was lacking.
>
> I would appreciate a separate patch to enhance it if you are so
> inclined.
Actually the description in that manual page is pretty good. But I
thought it was undocumented as the standard install does not install the
manual pages and I was getting the ones from my stable install to fool
me into thinking they were installed. New developer error, doh.
That said I've taken the liberty of updating and clarifying the language
to make it very obvious from the outset that the language specific
output formats are for generating eval'able snippets and added a simple
example of it to complement your complex one.
Patch to follow.
-apw
^ permalink raw reply
* Re: [PATCH] gitweb: Fix showing of path in tree view
From: Petr Baudis @ 2006-09-21 11:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eetjp0$22n$1@sea.gmane.org>
Dear diary, on Thu, Sep 21, 2006 at 10:50:46AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > Dear diary, on Thu, Sep 21, 2006 at 01:32:42AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
>
> >> But I think the older one was visually nicer and more intuitive
> >> in one very small detail that I think matters. Slashes between
> >> path components were not part of the anchor elements, so it was
> >> clear that there were two links in "gitweb / gitweb.perl" page
> >> title, not just one link. Now it is not obvious that clicking
> >> different parts of the path string in "/stgit/commands/mail.py"
> >> would lead to different places. And as you are aware, losing
> >> the leading "/" would be nicer as well ;-).
> >
> > Well, this was the best I could come up without introducing "[root] /"
> > or something in front of the path, which would be IMHO even uglier.
> > Alternative ideas welcomed. :-)
>
> "[$project] /", or "~ /" instead of "[root] /".
Yes, the former is what repo.or.cz uses now and in a patch I've sent
privately to Junio (since my StGIT configuration at repo.or.cz is messed
up and I had no time to fix it).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Fix showing of path in tree view
From: Jakub Narebski @ 2006-09-21 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <20060920231224.GN13132@pasky.or.cz>
Petr Baudis wrote:
> This patch fixes two things - links to all path elements except the last
> one were broken since gitweb does not like the trailing slash in them, and
> the root tree was not reachable from the subdirectory view.
Wouldn't it be better to fix git_get_hash_by_path to have it strip trailing
slash? Gitweb don't like trailing slash in pathname (directory name)
because while
git ls-tree $base -- dirname
shows dirname entry
git ls-tree $base -- dirname/
shows directory _contents_.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] add receive.denyNonFastforwards config variable
From: Junio C Hamano @ 2006-09-21 9:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.63.0609211103130.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Jeff King <peff@peff.net> writes:
>>
>> >> X - a - b - c - Y
>> >> / /
>> >> o - d - e - f
>
> And no, I am not aware of any such example.
>
> Probably because X would mark all ancestors (_including_ all other
> possible merge bases) as uninteresting.
True. Paint me convinced, too.
^ permalink raw reply
* [PATCH] git for each ref improve the documentation on scripting modes
From: Andy Whitcroft @ 2006-09-21 9:19 UTC (permalink / raw)
To: git
git-for-each-ref: improve the documentation on scripting modes
When reading the synopsis for git-for-each-ref it is easy to miss
the obvious power of --shell and family. Call this feature out in
the primary paragragh. Also add more description to the examples
to indicate which features we are demonstrating. Finally add a
very simple eval based example in addition to the very complex one
to give a gentler introduction.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 6649f79..d5fdcef 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -17,7 +17,7 @@ according to the given `<format>`, after
to the given set of `<key>`s. If `<max>` is given, stop after
showing that many refs. The interporated values in `<format>`
can optionally be quoted as string literals in the specified
-host language.
+host language allowing their direct evaluation in that language.
OPTIONS
-------
@@ -97,7 +97,8 @@ returns an empty string instead.
EXAMPLES
--------
-Show the most recent 3 tagged commits::
+An example directly producing formatted text. Show the most recent
+3 tagged commits::
------------
#!/bin/sh
@@ -112,7 +113,23 @@ Ref: %(*refname)
' 'refs/tags'
------------
-A bit more elaborate report on tags::
+
+A simple example showing the use of shell eval on the output,
+demonstrating the use of --shell. List the prefixes of all heads::
+------------
+#!/bin/sh
+
+git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
+while read entry
+do
+ eval "$entry"
+ echo `dirname $ref`
+done
+------------
+
+
+A bit more elaborate report on tags, demonstrating that the format
+may be an entire script::
------------
#!/bin/sh
@@ -156,7 +173,7 @@ Its message reads as:
fi
'
-eval=`git-for-each-ref -s --format="$fmt" \
+eval=`git-for-each-ref --shell --format="$fmt" \
--sort='*objecttype' \
--sort=-taggerdate \
refs/tags`
^ permalink raw reply related
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-21 9:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ees6hl$jdv$1@sea.gmane.org>
Hi,
On Wed, 20 Sep 2006, Jakub Narebski wrote:
> Petr Baudis wrote:
>
> > Dear diary, on Wed, Sep 20, 2006 at 05:28:08PM CEST, I got a letter
> > where Linus Torvalds <torvalds@osdl.org> said that...
>
> >> However, you can tell git that Jeff is being difficult by marking such
> >> branches individually as being rebased.
> >
> > This is really a wrong way of describing the problem - I'd say that Git
> > is being difficult here. The point is, the subsystem maintainers need to
> > maintain stacks of patches and rebase against the main kernel branch
> > regularily, and they want to still publish their current state. So it's
> > not really any of them being strange or difficult, but Git being so
> > because it has no seamless support for tracking those branches.
>
> There was idea around moving remotes configuration to config file to have
> some per branch configureation, including readonly for protecting tracking
> branches, marking default branch for merge with (and which tracking
> branch(es) to merge)...
If you want it, go ahead, propose something.
> ...and that included marking branch _on the server side_ as being rebased,
> i.e. without preserved history. Unfortunately, the discussion petered out
> without changes to git.
Not true. We have the [branch "StrangeCase Sensitive/Name"] syntax as a
consequence.
But I agree, nothing came out of the discussion about per-branch settings,
maybe because nobody cared enough?
Ciao,
Dscho
^ 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