* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Matt Graham @ 2008-07-20 21:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: David Baldwin, git
In-Reply-To: <20080718103918.GO10151@machine.or.cz>
I like the existing icons with
---
+++
Please don't get rid of the minuses and pluses.
On Fri, Jul 18, 2008 at 6:39 AM, Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>> Hello Petr:
>> I hope you are doing well. I was looking at the git.or.cz site tonight and
>> thought it could perhaps use a little freshening up from a design
>> standpoint. Therefore, I messed around with the default stylesheet and the
>> home page a bit and made a logo. You can take a look at the experimental
>> design at this address...
>> http://baldwindev.com/git.or.cz/
>>
>> It's really just a few little changes. If you're interested in implementing
>> any of this into the current site, feel free to grab the changes from my
>> github git repository. You can see the few text changes in the diff...
>> http://github.com/bilson/gitorcz_redesign/tree/master
>
> I'm not sure if this is really an improvement on the current state,
> but then again, the current state pretty much matches my idea and maybe
> others will agree that your proposal is better. Thus, it's better to
> show this to the Git community at large. :-)
>
> If you or anyone is shooting for a re-design, I would suggest to
> somehow relate to the current "Git brandings" in use:
>
> http://git.or.cz/git-logo.png
> http://henrik.nyh.se/uploads/git-logo.png
>
> If you think you have a cooler logo, that's fine too, but then it's
> again better to present it explicitly, I believe. The latter is used
> especially within mSysGit, the former is used more widely - at the
> current homepage, as Gitweb logo, and in various modifications like
>
> http://git.nyh.se/git-favicon.png
> http://members.cox.net/junkio/git.png
> http://unfuddle.com/images/screens/source.big.jpg
> (top left ;)
>
> --
> Petr "Pasky" Baudis
> GNU, n. An animal of South Africa, which in its domesticated state
> resembles a horse, a buffalo and a stag. In its wild condition it is
> something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] git-merge -s theirs
From: Junio C Hamano @ 2008-07-20 21:22 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20080720192130.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> This patch steals much code from "git-merge-resolve" to add "theirs"
> strategy. Its purpose is to always fail and suggest using the preferred
> command "git reset --hard the-other-commit".
> ...
> +echo "If you wanted to say the other history is better than your history,"
> +echo "use 'git reset --hard $remotes' instead."
> +echo "If you want to keep a record of your failure, you can create a"
> +echo "new branch from the current HEAD before running the reset command."
> +
> +exit 2
That is certainly cute, but I do not like it for two reasons:
- This advertizes "theirs" as available when you ask "git merge -s whoa",
and then the user is told "don't use this stupid, go away". That is
not exactly a good diplomacy to earn friends.
- The message gives a rather long hexdecimal string in its suggestion to
run "git reset --hard". This is not exactly your fault, though. The
original refname the user gave to "git-merge" is not available to your
strategy.
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Johannes Sixt @ 2008-07-20 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200807202111.48332.johannes.sixt@telecom.at>
On Sonntag, 20. Juli 2008, Johannes Sixt wrote:
> -git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o
> strbuf.o usage.o wrapper.o shell.o
> +git-shell$X: abspath.o ctype.o
> exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_OBJS)
Unfortunately, that's only half the deal. If we compile with NO_PREAD=1, this
needs read_in_full(), which is in write_or_die.o. I don't know how to fix
this without insulting your good taste except for reverting the recent
commits that touch this line...
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Petr Baudis @ 2008-07-20 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <200807192107.56333.jnareb@gmail.com>
On Sat, Jul 19, 2008 at 09:07:55PM +0200, Jakub Narebski wrote:
> On Fri, 18 July 2008, Petr Baudis wrote:
> > On Tue, Jul 15, 2008 at 01:41:38AM +0200, Jakub Narebski wrote:
> > > On Mon, 14 July 2008, Petr Baudis wrote:
> > > > Here is an idea: Introduce Git::Command object that will have very
> > > > general interface and look like
> > > >
> > > > my $c = Git::Command->new(['git', '--git-dir=.', 'cat-file', \
> > > > '-p', 'bla'], {pipe_out=>1})
> > > > ...
> > > > $c->close();
> > >
> > > Errr... how do you read from such a pipe? <$c> I think wouldn't work,
> > > unless you would use some trickery...
> >
> > That's good point; it might either be done using some trickery, or
> > $c->pipe. The idea behind having a special object for it though is to
> > have *unified* (no matter how simple) error handling. You might not
> > detect the command erroring out at the open time.
> >
> > Is there a better approach for solving this?
>
> I don't know if it is _better_ approach, but the _alternate_ approach
> would be to use:
>
> my $c = Git::Command->new(['git', '--git-dir=.', 'cat-file', \
> '-p', 'bla'], {out=>my $fh, err=>undef})
> ...
> while (my $line = <$fh>) {
> ...
> $c->close();
I think this is horribly ugly, you would be *much* better keeping the
filehandle within $c if going this way.
> And trickery would be to use blessed filehandle, or what? Or perhaps
> extending IO::Handle (but not all like using object methods for I/O
> handles)?
Maybe blessed filehandle is the simplest way; it seems that in case we
need anything more complex later, it should be possible to replace it
with an IO::Handle subclass, but that feels like overengineering now.
> I forgot that we cannot obsolete / replace old interface. Nevertheless
> it would be nice to be able to use for example
>
> Git::Cmd->output_pipe('ls-remotes', $URL, '--heads');
>
> but also
>
> output_pipe('myscript.sh', <arg1>, <arg2>);
I think exported functions should have all a git_ prefix.
> > Well, this interface is almost identical to what I delineated, except
> > that I have the extra ->cmd-> step there. But maybe, we could go with
> > your API and instead have Git::CommandFactory as a base of Git::Repo?
> > The hierarchy would be
> >
> > Git::CommandFactory - provides the cmd_pipe toolkit
> > |
> > Git::Repo - provides repository model
> > |
> > Git::Repo::NonBare - additional working-copy-related methods
> >
> > I think I will post a sample implementation sometime over the weekend.
>
> Thanks.
>
> I think this is a very good idea. Although... you mix somewhat here
> relationships. Relationship between Git::CommandFactory (Git::Cmd?)
> is a bit different than relationship between Git::Repo and
> Git::Repo::NonBare. Git::Repo::NonBare is a case of Git::Repo which
> additionally knows where its working copy (Git::WC?) is, and where
> inside working copy we are (if we are inside working copy). Git::Repo
> uses Git::CommandFactory to route calls to git commands, and to
> provide default '--git-dir=<repo_path>' argument.
Yes, but that does not mean Git::Repo must not inherit from
Git::CmdFactory. Think of Git::CmdFactory as maybe a kind of Java-sense
interface to a degree.
> What I'd like to have is a way to easily set in _one_ place where git
> binary can be found, even if we are using different repositories, call
> git commands not related to git repository.
>
> Should we use
>
> Git::Cmd->output_pipe('ls-remotes', $URL, '--heads');
> or
> output_pipe(GIT, 'ls-remotes', $URL, '--heads');
> or
> output_pipe($GIT, 'ls-remotes', $URL, '--heads');
> or
> output_pipe($Git::GIT, 'ls-remotes', $URL, '--heads');
>
> we would want to be able to set where git binary is once (and for all),
> for example via
>
> Git::Cmd->set_git('/usr/local/bin/git');
>
> or something like that.
Yes, that should work fine, with the Git::Cmd subclasses looking into
the singleton.
BTW, I don't like Git::Cmd for the factory interface, since the methods
create Git::Command objects and then the naming does not make any sense.
So I'm going to use class names Git::CmdFactory and Git::Cmd for the
first prototype (since "Command" _is_ too long), unless you have better
but still clear names.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Jakub Narebski @ 2008-07-20 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > So here is what I thought about: What about if everyone (except Junio,
> > of course) would change the subject _and_ remove the In-Reply-To: header
> > when replying to those mails?
> >
> > If those large threads just annoys a few people and most people are
> > happy with the current situation then sorry for the noise.
>
> I could make "What's cooking" not a follow-up to the previous issue,
Or perhaps break it from time to time (on major release perhaps?).
> or perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
Very good idea.
> But I think it is a good idea to change the subject when responding to one
> part of the message to say which topic your response is about.
>
> I do not know if stripping "In-reply-to" is a great idea, though. They
> are responses, aren't they?
The problem with above is if you are replying to many points
simultaneously.
I think however that patches should rather start a new thread.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Petr Baudis @ 2008-07-20 21:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200807200216.37260.jnareb@gmail.com>
On Sun, Jul 20, 2008 at 02:16:36AM +0200, Jakub Narebski wrote:
> By the way, git-svn can use command(...) instead of $repo->command(...)
> because it sets $ENV{'GIT_DIR'} if it is unset... but I don't see
> where Git.pm inserts 'git' to commands list...
In _execv_git_cmd(), or did I misunderstand your question?
(I think that level of indirection is probably residuum of the XS
interface.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Jakub Narebski @ 2008-07-20 21:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: David Baldwin, git
In-Reply-To: <20080718103918.GO10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> If you or anyone is shooting for a re-design, I would suggest to
> somehow relate to the current "Git brandings" in use:
>
> http://git.or.cz/git-logo.png
> http://henrik.nyh.se/uploads/git-logo.png
>
> If you think you have a cooler logo, that's fine too, but then it's
> again better to present it explicitly, I believe. The latter is used
> especially within mSysGit, the former is used more widely - at the
> current homepage, as Gitweb logo, and in various modifications like
>
> http://git.nyh.se/git-favicon.png
> http://members.cox.net/junkio/git.png
> http://unfuddle.com/images/screens/source.big.jpg
> (top left ;)
By the way, if you find some git logo, please add it to git wiki:
http://git.or.cz/gitwiki/GitRelatedLogos
I think beside the one from Unfuddle all of them are present on
this page.
P.S. Do anybody remember how we came about current (old) git logo?
P.P.S. Petr, do you know what's the matter with Git Wiki? It looks
like moin4wiki (Wikipeda-like syntax) parser is installed halfway in.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Stephan Beyer @ 2008-07-20 21:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <m3sku4w822.fsf@localhost.localdomain>
Hi,
Jakub Narebski wrote:
> I think however that patches should rather start a new thread.
If a patch is a consequence of a discussion in a thread, I see no
reason, why the patch should not be in that thread.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Petr Baudis @ 2008-07-20 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 02:05:30PM -0700, Junio C Hamano wrote:
> I could make "What's cooking" not a follow-up to the previous issue, or
> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
> But I think it is a good idea to change the subject when responding to one
> part of the message to say which topic your response is about.
>
> I do not know if stripping "In-reply-to" is a great idea, though. They
> are responses, aren't they?
I think responses to the what's cooking mails per se should certainly
have in-reply-to set properly. I'm rather wondering if there's some
specific reasons why do you keep all the "What's cooking" mails in a
single thread? If there is nothing particular, keeping each "What's
cooking" report in a separate mail might be easier on a portion of
readers. I will use break-thread now (thanks, didn't know about it!) but
the practice seems strange to me.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Martin Langhoff @ 2008-07-20 21:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: David Baldwin, git
In-Reply-To: <20080718103918.GO10151@machine.or.cz>
On Fri, Jul 18, 2008 at 10:39 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>> http://baldwindev.com/git.or.cz/
> I'm not sure if this is really an improvement on the current state,
> but then again, the current state pretty much matches my idea and maybe
> others will agree that your proposal is better. Thus, it's better to
> show this to the Git community at large. :-)
FWIW, I like it. I like both the better font and whitespace layout and
the 3-color-spot-merge-to-white. As Petr says, we have had the
(apologies, but to me) ugly logo for a while, so it is widely used,
and perhaps it has even grown on people.
BazaarNG managed to grab the best concept logo of the lot, IMHO, with
the 'merge' roadsign.
> If you think you have a cooler logo, that's fine too, but then it's
> again better to present it explicitly, I believe.
Can we separate the 2 things? The better fonts and layout look like a win to me.
WRT the logo, the current one is not a particularly strong image, and
we haven't spent millions in plastering it over magazines or anything.
So a good new logo would be something to take on.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Jakub Narebski @ 2008-07-20 21:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <20080720213642.GE10151@machine.or.cz>
On Sun, 20 Jul 2008, Petr Baudis wrote:
> On Sat, Jul 19, 2008 at 09:07:55PM +0200, Jakub Narebski wrote:
> > I think this is a very good idea. Although... you mix somewhat here
> > relationships. Relationship between Git::CommandFactory (Git::Cmd?)
> > is a bit different than relationship between Git::Repo and
> > Git::Repo::NonBare. Git::Repo::NonBare is a case of Git::Repo which
> > additionally knows where its working copy (Git::WC?) is, and where
> > inside working copy we are (if we are inside working copy). Git::Repo
> > uses Git::CommandFactory to route calls to git commands, and to
> > provide default '--git-dir=<repo_path>' argument.
>
> Yes, but that does not mean Git::Repo must not inherit from
> Git::CmdFactory. Think of Git::CmdFactory as maybe a kind of Java-sense
> interface to a degree.
I agree. Nevertheless one inheritance is "interface", second
is "subclass"... but I don't think that matters at all. Just being
nitpicky.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Junio C Hamano @ 2008-07-20 22:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200807202334.36506.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Sonntag, 20. Juli 2008, Johannes Sixt wrote:
>> -git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o
>> strbuf.o usage.o wrapper.o shell.o
>> +git-shell$X: abspath.o ctype.o
>> exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_OBJS)
>
> Unfortunately, that's only half the deal. If we compile with NO_PREAD=1, this
> needs read_in_full(),...
Well, if compat/* implementations use anything outside compat/ left and
right, then all bets are off.
Why do we care about the size of git-shell so much in the first place
anyway to begin with?
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 22:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <7vhcak5o6n.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How about this instead?
> >
> > -- snipsnap --
> > diff --git a/connect.c b/connect.c
> > index 574f42f..7e7f4d3 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -603,7 +603,8 @@ struct child_process *git_connect(int fd[2], const char *url
> >
> > *arg++ = ssh;
> > if (port) {
> > - *arg++ = "-p";
> > + const char *opt = getenv("GIT_SSH_PORT_OPTION");
> > + *arg++ = opt ? opt : "-p";
> > *arg++ = port;
> > }
> > *arg++ = host;
>
> If you only care only about the ones we currently want to support, I do
> not htink it makes any difference either way, but if we are shooting for
> having a minimum-but-reasonable framework to make it easy to support other
> ones that we haven't seen, it feels very much like an inadequate hack to
> waste an envirnoment variable for such a narrow special case. With this,
> what you really mean is "Plink uses -P instead of -p", right?
Yeah. My first attempt was to allow "GIT_SSH='plink.exe -P %p %h'" to
work, and for that matter, "git config --global transport.ssh 'plink.exe
-P %p %h'", but I decided that it would be easier to do the patch I
posted.
Anyway, I think that this issue wasted enough of my time, as I will never
use plink anyway. As long as the patch does not have an adverse effect on
my use case, which happens to be the default case, I will just not bother
anymore, even if I think that GIT_SSH=wrapper would be better than special
case rarely exercized ssh programs in the source code.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-20 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <7vd4l85nv5.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I personally think -sstrategy=string1,string2,... is simply a bad taste.
> >>
> >> Why force yourself to parse things by having the users to concatenate
> >> something that the user could give us separated? If you care about the
> >> order and association between strategy and their options, you can always
> >> do:
> >>
> >> -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> >> -s strategy2 -X option-1-for-strategy-2 ...
> >
> > You mean something like
> >
> > $ git merge -s subtree -X --path -X git-gui/ git-gui/master
> >
> > Wow. :-)
>
> I would envision it to be more like:
>
> $ git merge -s subtree -Xpath=git-gui git-gui/master
>
> which git-merge internally would turn into:
>
> $ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS
>
> That way both the external command line (that the end users do care about)
> and the internal one (that the strategy programmer would care about) look
> a lot more sensible than your command line, don't they?
I still find it a lot easier to explain
$ git -s subtree=git-gui git-gui/master
to a new user than your command line, especially since
$ git -X path=git-gui -s subtree git-gui/master
would be a not so obvious mistake, _and_ especially since the
implementation of your option parsing would be rather ugly.
But the subject has been discussed to death, and you seem to still prefer
the -X way, so I give up.
You win,
Dscho "who can adapt even to a syntax he does not like"
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-20 22:29 UTC (permalink / raw)
To: git
Cc: Sam Vilain, Joshua Roys, 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>
On Tue, 8 July 2008, Jakub Narebski wrote:
> I'd very much like to have (or perhaps to wrote) some sort of interim
> progress report for Google Summer of Code 2008 projects on
> http://git.or.cz/gitwiki/SoC2008Projects. Therefore I'd like you to
> expand and/or correct those mini-summaries below.
Here is a bit late summary of this thread (and of information gathered
elsewhere). I'll try to add this information to wiki page in approx
two days from now... of course unless project student or mentor wouldn't
do it first.
1. GitTorrent
Student: Joshua Roys
Mentor: Sam Vilain
I never got more response than "it is going slower than I would like,
[...] Other than that, it's going well, I think." from Joshua Roys.
Mailing list archives for gittorrent mailing list doesn't show anything
interesting, either (last post is from 2007).
http://lists.utsl.gen.nz/pipermail/gittorrent/
Besides canonical repository gitweb
http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
there is also mirror at
http://repo.or.cz/w/VCS-Git-Torrent.git
There is some activity there... but no summary of it anywhere I could
find. (I wonder if this was the project Johannes and Shawn were talking
about of "going dark" in GSoC 2008 podcast 018...)
2. git-statistics
Student: Sverre Rabbelier
Mentor: David Symonds
There were some posts about how git-statistics can be used:
http://thread.gmane.org/gmane.comp.version-control.git/81534
http://thread.gmane.org/gmane.comp.version-control.git/82027
There is post with link to different git.git statictics:
"[GitStats] Bling bling or some statistics on the git.git repository"
http://thread.gmane.org/gmane.comp.version-control.git/88174
A short listing of metrics done:
* stats.py author -d: Shows file activity of a specific developer
measured in how often they made a modification to a file and total
lines added/removed (much like a diffstat, but now for a specific
developer instead of one commit).
* stats.py author -f: Shows file activity of a specific file measured
in how often they made a modification to a file, could be extended to
also count changes like "author -d"
* stats.py branch -b: Shows which branch a specific file belongs to,
for more information on this metric see below
* stats.py commit -v: Shows all commits that are reverted by the
specified commit, will be extended to allow detection of partial
reverts
* stats.py diff -e: Shows whether two specific commits introduce the
same changes
* stats.py diff -e -n: ditto, but ignores what changes were made, only
looks at the changed lines
* stats.py diff -e -i: ditto, but inverts the comparison, instead of
comparing addition with addition and deletions with deletions, the
additions of the first diff are compared with the deletions of the
second diff, and vise versa. This way a revert is easily detected.
* stats.py index -t: Shows which commits touched the same paths as the
staged changes
3. Gitweb caching
Student: Lea Wiemann
Mentor: John 'warthog' Hawley
Lea has chosen caching data and memcached as example (primary) caching
engine, wrote Git::Repo object-oriented Perl interface to git, used
it in gitweb, and added caching to gitweb.
Additionally tests for old Git.pm (simple), Git::Repo and friends, and
Mechanize based gitweb test were added. Mechanize tests detected a few
bugs in current gitweb code: using Git::Repo and adding caching didn't
create any new errors.
Currently first round of patches were send, and second version
incorporating comments from is in progress. There is a test site
(live demo) up and running on one of the kernel.org machines:
http://odin3.kernel.org/git-lewiemann/
You can find first version of patches in 'pu' branch.
4. Eclipse plugin push support
Student: Marek Zawirski
Mentor: Shawn O. Pearce
Thus far Marek has completed generation of packs, including delta
re-use from packs using either v1 or v2 index, including taking
advantage of the CRC inside the v2 index to accelerate a safe reuse.
This code permits jgit to write a valid pack.
The packing code does not (yet) search for a delta base, or create
a new delta for an undeltified object. Packing loose objects packs
them as whole objects in the pack file, resulting in little to no
reduction over their loose object size. This is not a limitation
of Java. Marek and I simply decided that protocol support was more
important than really tight network transport at this point in time.
As a result of being able to create pack files Marek was able to
implement the client side of git-push for the native pack transfer
service, aka push over SSH, push to another local repository (by
forking 'git receive-pack') and push over anonymous git://.
Using Marek's pack generation code Shawn added support for push over
the dumb sftp:// and amazon-s3:// protocols, with the latter also
supporting transparent client side encryption.
5. git-merge builtin
Student: Miklos Vajna
Mentor: Johannes Schindelin
> In "What's cooking in git.git (topics)" Junio C Hamano wrote:
>
> It already is beginning to become clear what 1.6.0 will look like.
> [...]
> * git-merge will be rewritten in C.
It is already in git as 1c7b76b (Build in merge).
In Documentation/RelNotes-1.6.0.txt you can find the following:
"* git-merge has been reimplemented in C."
6. git-sequencer
Student: Stephan Beyer
Mentor: Christian Couder, Daniel Barkalow
It started with discussion over TODO file format:
http://thread.gmane.org/gmane.comp.version-control.git/84230
Now there is prototype shell script implementation (which has some
limitations because it is prototype) in "git sequencer prototype"
http://thread.gmane.org/gmane.comp.version-control.git/86985
http://thread.gmane.org/gmane.comp.version-control.git/88754
The latter thread includes migration of git-am, git-rebase, and
interactive rebase to sequencer.
> Stephan Beyer wrote:
> I'm using sequencer-based git-am and git-rebase-i and also
> git-sequencer itself for around 2-3 weeks now. So, for me, it is
> reality-proven [...]
There were some problems with sequencer based implementation of
"git am --rebasing", or sequencer based patch application driven
ordinary rebase, but I think there were resolved.
Stephen have started the builtin sequencer (but till now no patches
were sent to list: seems to be work in progress).
Some performance benchmarks:
* applying 45 patches with git-am
- 3 seconds using the original
- 8 seconds using the (scripted) sequencer-based one
* rebasing 100 commits
- 4.8 seconds using the original
- 10.1 seconds using the (scripted) sequencer-based one
- 1.7 seconds using builtin sequencer
SUMMARY:
========
From those projects, "git-merge builtin" did what it was meant to do
already. "Eclipse plugin push support" and "git-statistics" did
minimum what it was meant to do already, and it looks like it would be
finished before August 11. "Gitweb caching" is after first round of
patches, "git-sequencer" looks like already done; I don't know what is
the state of "GitTorrent" project.
Please correct any mistakes in this summary / writeup. Thanks in
advance.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Johannes Schindelin @ 2008-07-20 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vzloc2odx.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Why do we care about the size of git-shell so much in the first place
> anyway to begin with?
It was not me who proposed it, but I guess it was for auditing purposes:
git-shell is often the only point of entry for certain untrusted ssh
users, and the less code is linked, the less code has to be analyzed for
reachability (and then for security holes).
Ciao,
Dscho
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Petr Baudis @ 2008-07-20 22:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Baldwin, git
In-Reply-To: <m3od4sw7qj.fsf@localhost.localdomain>
On Sun, Jul 20, 2008 at 02:44:54PM -0700, Jakub Narebski wrote:
> P.P.S. Petr, do you know what's the matter with Git Wiki? It looks
> like moin4wiki (Wikipeda-like syntax) parser is installed halfway in.
As I try to mention frequently, I don't really maintain the Wiki at all.
The Wikipedia syntax is a manual hack that has a weird history across
random moinwiki upgrade on the machine, randomly disappearing as Debian
decides to upgrade the moinwiki package. I have readded the hack now.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Junio C Hamano @ 2008-07-20 22:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807210034050.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 20 Jul 2008, Junio C Hamano wrote:
>
>> Why do we care about the size of git-shell so much in the first place
>> anyway to begin with?
>
> It was not me who proposed it, but I guess it was for auditing purposes:
> git-shell is often the only point of entry for certain untrusted ssh
> users, and the less code is linked, the less code has to be analyzed for
> reachability (and then for security holes).
That's a rather misguided approach, isn't it?
After all, the work requested by the end user will be handled by code in
the main git executable by spawning a subprocess, and you are auditing the
codepath that leads to the spawning anyway.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Petr Baudis @ 2008-07-20 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am5iae8.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 19, 2008 at 06:58:55PM -0700, Junio C Hamano wrote:
> * pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
> . t7403: Submodule git mv, git rm testsuite
> . git rm: Support for removing submodules
> . git mv: Support moving submodules
> . submodule.*: Introduce simple C interface for submodule lookup by
> path
> . git submodule add: Fix naming clash handling
> . t7400: Add short "git submodule add" testsuite
> . git-mv: Remove dead code branch
>
> Long overdue usability improvement series for submodule. Very much
> welcomed. It would be nice to have some submodule improvements in 1.6.0,
> but it would take us a few more rounds to hit 'next' with this, and it
> will not be in 'master' when 1.6.0 ships.
Do you think this would create serious problems?
One thing this patch series depends on now is changing the git mv
semantics in a rather non-trivial way, which is something we might want
to do in a major release instead of within the 1.6 series.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Sverre Rabbelier @ 2008-07-20 22:43 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, David Symonds, Lea Wiemann,
John Hawley, Marek Zawirski, Shawn O. Pearce, Miklos Vajna,
Johannes Schindelin, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <200807210029.31543.jnareb@gmail.com>
On Mon, Jul 21, 2008 at 12:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Here is a bit late summary of this thread (and of information gathered
> elsewhere). I'll try to add this information to wiki page in approx
> two days from now... of course unless project student or mentor wouldn't
> do it first.
I've been feeling guilty about not writing a summary yet, sorry for that :(.
> 2. git-statistics
>
> Student: Sverre Rabbelier
> Mentor: David Symonds
>
> There were some posts about how git-statistics can be used:
> http://thread.gmane.org/gmane.comp.version-control.git/81534
> http://thread.gmane.org/gmane.comp.version-control.git/82027
> There is post with link to different git.git statictics:
> "[GitStats] Bling bling or some statistics on the git.git repository"
> http://thread.gmane.org/gmane.comp.version-control.git/88174
>
> A short listing of metrics done:
> * stats.py author -d: Shows file activity of a specific developer
> measured in how often they made a modification to a file and total
> lines added/removed (much like a diffstat, but now for a specific
> developer instead of one commit).
> * stats.py author -f: Shows file activity of a specific file measured
> in how often they made a modification to a file, could be extended to
> also count changes like "author -d"
* stats.py bug -t: Calculates a 'score' for a specific commit,
representing how likely it is to be a bugfix. There are four metrics
used to determine this: "Commits x reverts another commit y", "Commit
x belongs to one of the specified branches (e.g., 'maint')", "The diff
for commit x contains a specific phrase", "The msg for commit x
contains a specific phrase". A rating can be given to each metric by
the user.
* stats.py bug -a: Aggregates the 'bug -t' metric over a range of
commits. The default is the last 10 commits on HEAD. This routine is
optimized to not recalculate metrics/to not redo work that was
already done in a 'bug -t' call for another commit. As such there is a
set setup time to determine the type of the first commit, after which
calculation time increases at a much lower pace. (So 'bug -a' on 10
commits might take 4 seconds, and running it over 11 commits might
take only 4.5".)
> * stats.py branch -b: Shows which branch a specific file belongs to,
a commit 'belongs to' a branch when the commit is made on that branch.
> * stats.py commit -v: Shows all commits that are reverted by the
> specified commit, will be extended to allow detection of partial
> reverts
This has been moved to 'diff -r'.
> * stats.py diff -e: Shows whether two specific commits introduce the
> same changes
> * stats.py diff -e -n: ditto, but ignores what changes were made, only
> looks at the changed lines
> * stats.py diff -e -i: ditto, but inverts the comparison, instead of
> comparing addition with addition and deletions with deletions, the
> additions of the first diff are compared with the deletions of the
> second diff, and vise versa. This way a revert is easily detected.
> * stats.py index -t: Shows which commits touched the same paths as the
> staged changes
I think the rest is a nice summary of what I've been doing :).
> SUMMARY:
> ========
> [...] "git-statistics" did a minimum what it was meant to do already, and it looks like it would be finished before August 11. [..]
My deadline is August 1 since my vacation starts then and I can't work
during my vacation (all hail American tax laws), but David is
confident that I will have a finished product before then, and I plan
not to let him down on that expectation.
> Please correct any mistakes in this summary / writeup.
I tried to as best as I could :).
> Thanks in advance.
No, thank you! Thanks for writing up this summary, very nicely done.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Sverre Rabbelier @ 2008-07-20 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I could make "What's cooking" not a follow-up to the previous issue, or
> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
The downside of this is that it'll be less easy to see the difference
with the previous version. GMail tries to mark text that appeared a
previous mail in purple, so new text 'stands out' in the regular black
(it's not that good at it though).
So WRT to not making them follow ups, an improvement would be a diff
with the previous version online somewhere, although I guess the
http://tinyurl.com/todobranch is exactly that modulo your (Junio's)
comments on the topics.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Junio C Hamano @ 2008-07-20 22:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <7vzloc2odx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> On Sonntag, 20. Juli 2008, Johannes Sixt wrote:
>>> -git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o
>>> strbuf.o usage.o wrapper.o shell.o
>>> +git-shell$X: abspath.o ctype.o
>>> exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_OBJS)
>>
>> Unfortunately, that's only half the deal. If we compile with NO_PREAD=1, this
>> needs read_in_full(),...
>
> Well, if compat/* implementations use anything outside compat/ left and
> right, then all bets are off.
If compat/ layer tries to really be about "compatibility", they should not
be using things like xmalloc() that call release_pack_meory() that is in
sha1_file.c. From a quick glance, mingw.c, mmap.c, pread.c are major
offenders, but others such as setenv.c seem to be carefully written.
Perhaps we should apply a variant of your patch to allow linking from
compat/ routines to git-shell, so that people affected by the compat layer
functions that call outside compat layer have incentive to fix them.
Makefile | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 2b670d7..551bde9 100644
--- a/Makefile
+++ b/Makefile
@@ -324,6 +324,7 @@ endif
export PERL_PATH
LIB_FILE=libgit.a
+COMPAT_LIB = compat/lib.a
XDIFF_LIB=xdiff/lib.a
LIB_H += archive.h
@@ -1203,8 +1204,11 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^)
+$(COMPAT_LIB): $(COMPAT_OBJS)
+ $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(COMPAT_OBJS)
+
+git-shell$X: abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_LIB)
+ $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(COMPAT_LIB)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
@@ -1402,7 +1406,7 @@ distclean: clean
clean:
$(RM) *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
- $(LIB_FILE) $(XDIFF_LIB)
+ $(LIB_FILE) $(XDIFF_LIB) $(COMPAT_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
^ permalink raw reply related
* [PATCH] Add a notice to the doc of git-ls-tree.
From: Steve Frécinaux @ 2008-07-20 22:25 UTC (permalink / raw)
To: git; +Cc: Steve Frécinaux
The notice covers this behaviour:
if you are in the git/ subdirectory of your repository, it will pick
the tree corresponding to that directory instead of the root one if you
specify the root tree object id.
Compare the output of both of those commands:
git-ls-tree cb44e6571708aa2792c73a289d87586fe3c0c362
git-cat-file -p cb44e6571708aa2792c73a289d87586fe3c0c362
---
Documentation/git-ls-tree.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 1cdec22..7cba394 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -21,6 +21,10 @@ though - 'paths' denote just a list of patterns to match, e.g. so specifying
directory name (without '-r') will behave differently, and order of the
arguments does not matter.
+Note that if you give ls-tree the sha1 id of a parent of the tree
+corresponding to the directory you're in, it will resolve that tree and list
+its contents instead of listing the contents of the tree you gave.
+
OPTIONS
-------
<tree-ish>::
--
1.5.6.2
^ permalink raw reply related
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Stephan Beyer @ 2008-07-20 22:57 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807210029.31543.jnareb@gmail.com>
Hi,
what you write is quite detailed :)
Jakub Narebski wrote:
> 6. git-sequencer
>
[...]
> There were some problems with sequencer based implementation of
> "git am --rebasing", or sequencer based patch application driven
> ordinary rebase, but I think there were resolved.
They were resolved, but there is a new problem that occured in the
am --abort thread of Junio: the sequencer-based git-am does not work
on dirty working tree.
I've also fixed some other minor issues and have not yet sent this to
the list (because I think I stumble over even more while writing the
builtin-sequencer.)
> Stephen have started the builtin sequencer (but till now no patches
> were sent to list: seems to be work in progress).
Right.
> Some performance benchmarks:
> * applying 45 patches with git-am
> - 3 seconds using the original
> - 8 seconds using the (scripted) sequencer-based one
> * rebasing 100 commits
> - 4.8 seconds using the original
> - 10.1 seconds using the (scripted) sequencer-based one
> - 1.7 seconds using builtin sequencer
:)
I think I'm going to format-patch the same 100 test commits and then I
change the "applying 45 patches with git-am" part on the Wiki.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Sverre Rabbelier @ 2008-07-20 22:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <20080720203306.GO10347@genesis.frugalware.org>
On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>> Whatever happened to quotes?
>>
>> $ git merge -s subtree -Xpath="git-gui git-gui/master"
>
> Read again what did you wrote. ;-)
>
> The current form is
>
> git merge -s subtree git-gui/master, so at most it could be
>
> $ git merge -s subtree -Xpath="git-gui" git-gui/master
Meh, what I ofcourse mean was:
$ git merge -s subtree -X"path=git-gui" git-gui/master
But that looks rather awkward, which is probably why I typed it the
way I did? Maybe something like....
$ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master
--
Cheers,
Sverre Rabbelier
^ 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