* git blame --porcelain
From: Sverre Rabbelier @ 2008-07-20 20:28 UTC (permalink / raw)
To: Git Mailinglist
Heya,
Contrary to what one would expect, the '--porcelain' switch to 'git
blame' makes the output suitable for... plumbing use? As far as 'git
blame builtin-blame.c' tells me (gotta love the recursion there) it
has been this way since cee7f245 when the option was introduced. What
is the rationale behind this? Is it called '--porcelain' because it is
meant to be used by the plumbing to create new porcelain? That seems a
bit far-fetched though...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-07-20 20:33 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <bd6139dc0807201303u406484e2x127b2391a9920425@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> 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
>
> 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
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 20:33 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Miklos Vajna,
Nanako Shiraishi, git
In-Reply-To: <bd6139dc0807201303u406484e2x127b2391a9920425@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> Whatever happened to quotes?
>
> $ git merge -s subtree -Xpath="git-gui git-gui/master"
Nothing special needs to happen. That would naturally be passed to the
underlying strategy as the equivalent of:
$ git merge-subtree --path="git-gui git-gui/master"
but now "git-merge" is in C, it does not have to quote nor unquote
explicitly itself. Unquoting will be done by the shell when you call
"git-merge", and quoting is unneeded when you give each argument as a
separate string in **argv to call execv().
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Sverre Rabbelier @ 2008-07-20 20:34 UTC (permalink / raw)
To: Jay Soffian
Cc: Johannes Schindelin, Tarmigan, Junio C Hamano, git,
Michael J Gruber
In-Reply-To: <76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com>
On Sun, Jul 20, 2008 at 2:45 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Lastly, I point out that when I started with git, it became much
> clearer when I began reading "git add" as "git stage". I think my
> first alias was "staged => diff --cached". But I am someone who likes
> to learn how the things I use work early on.
I love it, and the great thing is that auto-complete works on it too!
"git diff --cached" 17 keystrokes
"git stag" 8 keystrokes
That's a 9 keystrokes improvement!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git blame --porcelain
From: Junio C Hamano @ 2008-07-20 20:34 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807201328i41aa7d09jf9a1c4dc6f60a367@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> Is it called '--porcelain' because it is
to help porcelain writers.
^ permalink raw reply
* [RFC] Stopping those fat "What's cooking in git.git" threads
From: Miklos Vajna @ 2008-07-20 20:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
Hi,
As far as I remember, it was Petr Baudis who first asked on IRC if
these threads (being so big and deep) are annoying for other people as
well or not.
I think it's just hard to follow the discussion as the subject is
usually not changed, so for example when the subject contains "merge", I
carefully read that mail, but I can easily miss such a mail if it's
still "What's cooking in".
An other problem with deep threads is that it just doesn't fit in one's
screen, so I had to use tricks for example to see if a mail was a reply
to my mail or to some other mail.
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.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Lars Noschinski @ 2008-07-20 20:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jay Soffian, Johannes Schindelin, Tarmigan, git, Michael J Gruber
In-Reply-To: <7v4p6k8l36.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [08-07-20 20:30]:
>So for such people who would find "add -A" useful, "commit -a" will not be
>"unrelated changes in the same commit". And for such people, I would even
>say "commit -A" would be even more useful, too.
There is one occasion I could use a "add -A": To shorten
git add -u; git add .; git commit -m "wip"; git checkout $stuff
So in my opinion, if one wants a "stage my whole workdir" option, it
would be suited best as an option to commit (and maybe stash).
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Stephan Beyer @ 2008-07-20 20:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080720205125.GP10347@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
Hi,
Miklos Vajna wrote:
> I think it's just hard to follow the discussion as the subject is
> usually not changed, so for example when the subject contains "merge", I
> carefully read that mail, but I can easily miss such a mail if it's
> still "What's cooking in".
I agree that changing a subject (with "(was: <oldsubject>)") is nicer to
find specific mails later.
> 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?
"Everyone should" bla usually does not work in open communities.
And why not vice versa?
A new "What's cooking in " mail with new cookings could start a new
thread instead of replying to old "What's cooking in" mails...
> If those large threads just annoys a few people and most people are
> happy with the current situation then sorry for the noise.
Hm, I don't really care.
Mutt is able to link and break threads with
# break-thread break the thread in two
& link-threads link tagged message to the current one
so I am able to design the threads as I like it ;)
(And I am also able to change subjects as I like, so I don't have a
problem.)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Junio C Hamano @ 2008-07-20 21:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080720205125.GP10347@genesis.frugalware.org>
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 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?
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Miklos Vajna @ 2008-07-20 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Sun, Jul 20, 2008 at 02:05:30PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
It was me as well, who did not change the subject; I'll try to pay
attention to do so.
> I do not know if stripping "In-reply-to" is a great idea, though. They
> are responses, aren't they?
Personally I'm fine with mutt's "break thread" feature, I just proposed
it because I saw it was mentioned multiple times that gmane does not
handle huge threads nicely. But yes, you have reason about keeping the
header makes sense as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* 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
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