* Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 1:53 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Hi,
On Fri, Jul 25, 2008 at 10:35:43AM -0700, Scott Chacon wrote:
> Anyhow, I'm discussing with Petr about where we want to go from here -
> what changes he'd like to make, etc, but I obviously value your
> opinion as well, so please let me know what you think. The content
> has barely changed, it's really just a usability overhaul. I want to
> make sure that whatever someone is looking for (especially someone
> new), they can find in a few clicks and a few seconds.
when the initial NIH reaction passes, I have to admit that I do rather
like it - and it's not only because you keep mentioning how awesome I am
in your blog post. ;-)
I wonder if all the Git users find the heading rather funny as I did,
instead of unprofessional - but maybe we don't care about users without
a particular sense of humor. I'm also not overly fond of the color theme
but I'm perhaps just too heavy of a blue fan.
Plenty of minor fixes are available for pull at
git://github.com/pasky/learn-github.git
(http://github.com/pasky/learn-github/tree/master)
(Note that I didn't test whether the pages still look ok with my changes
since I have no Ruby on Rails setup; hopefully they should, though.)
Other non-trivial nits:
* I'm feeling a bit uneasy about listing so many projects using Git;
I haven't heard about quite a few of these and I'm not sure on what
merit should we list projects. "Prototype" or "Liftweb" and probably
even "Rubinius", is that going to ring a bell for major part of visitors
so that they say "oh, even _those_ guys are using Git"?
* Cut the contributors list at 4 or 5 commits? Below that, the list
is getting fairly useless anyway and you have trouble with keeping the
names reasonably well-formed.
* Reusing captions from command manpages in the Documentation page
shows nicely how awful they sometimes are. :-) This is probably something
to fix upstream, though.
* Is "Git for the lazy" really unique in some regard to deserve to be
listed among the other resources? I think we should minimalize
redundancy at the documentation page, the amount of material is already
overwhelming and it should be obvious for the visitor which document to
choose based on his needs. I have similar doubts about the 37signals
resources.
In other words, "let's keep the resources orthogonal!"
* There is no reference to the Wiki in the documentation, only to the
[GitDocumentation] page; I think there should be a reference to the
[GitFaq] page too - a lot of important points that are not obvious
to newcomers are covered there. I'm just not sure where exactly to put
the link.
* I would go as far as put the link to the Wiki itself to the
navigation bar, simply since it is such a crucial resource.
* A guide on maintaining third-party patches is currently missing.
* The development page is not referenced anywhere; the missing
information are mailing list details (how to subscribe) and a link to
SubmittingPatches. Also, I have recently talked with Junio about adding
a link to the Note from the Maintainer, but we didn't yet figure out
where to stabilize the location of that page.
> Next, I will be working on the larger end-user documentation project,
> which will linked to from the documentation page of this site, and
> probably the main page too. I'll keep this list updated as I go,
> since people tend to think I don't care about the community when I try
> not to waste your time. :)
How does that compare with the Git user manual? Have you considered
collaborating on that one, or what are your reasons not to? Or are you
trying to do something different?
--
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-scm.com
From: Patrick Aljord @ 2008-07-26 1:38 UTC (permalink / raw)
To: git list
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Looks fine but this page looks like a big advertising for Github with
five links on the middle of the front page + one big logo at the
bottom.
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Junio C Hamano @ 2008-07-26 1:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0807260250480.11976@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ... especially since I hope that we have them builtin soon, and not only
> that, but have builtin-merge call them as C functions, not with fork() and
> exec().
Because builtin-merge.c does not directly use fork/exec but uses
run_command() interface, non POSIX platforms can spawn subprocesses just
fine, can't they?
I do not think at this point it is of any high priority to call strategies
internally, avoiding fork/exec. We may apply hundreds of patches per
minute, but would fork/exec overhead matter for merges?
Especially because some strategies (recursive and perhaps the rumored
"blame" even more so) are quite data intensive operations, libifying them
is not worth it, compared to the nice isolation between processes we get
from running them as a separate program. We get the necessary clean-up
after strategy did its thing for almost free (well, "at the cost of
fork/exec").
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-26 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3alxr0fd.fsf@gitster.siamese.dyndns.org>
Thanks Junio,
I fixed the things you mentioned here, except for the list ordering,
only because I kinda think you big contributors should be at the top
there, and also because it's slightly more difficult to populate an
html table that way :) If everyone feels strongly about that, though,
I will change it.
Scott
On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think counting merges in "The Authors of Git" statistics give quite
> skewed numbers. If you are generating it with "shortlog", you probably
> would want to give --no-merges to the command line as well. Also it
> appears that you are not using .mailmap to avoid counting the same person
> as different people.
>
> I find a tabular list like this list easier to read if it were sorted like
> this:
>
> A D G
> B E H
> C F
>
> i.e. not like this:
>
> A B C
> D E F
> G H
>
>
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Johannes Schindelin @ 2008-07-26 0:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20080725055547.GA3699@blimp.local>
Hi,
On Fri, 25 Jul 2008, Alex Riesen wrote:
> But, given the fact, that somewhere sometimes its very-very annoying to
> have even one (un)changed file, something must be done about it. Maybe
> just direct
>
> [...]
> trustctime = false
... which is all Junio and I were asking all along: a separate way to ask
for ignoring ctime; not just DWIM it on top of the executable bit.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Johannes Schindelin @ 2008-07-26 0:55 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4889EF3A.6040605@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 452 bytes --]
Hi,
On Fri, 25 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
>
> > We rely on shared_repository == 0 for non-shared repositories _almost
> > everywhere_.
>
> I think we rely on the fact that PERM_UMASK == 0 and not on the value of
> shared_repository. Not the same thing.
Just look at all the cases where we ask for "if (shared_repository)".
And then look where PERM_UMASK is assigned to. It _is_ the same thing.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Johannes Schindelin @ 2008-07-26 0:53 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4889EF22.6020604@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 321 bytes --]
Hi,
On Fri, 25 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
> >
> > That would be a bugfix. As such, it belongs into a different commit.
>
> I thought, for that kind of trivial bug that probably never hit anyone,
> a line in the commit message was enough.
So bisectability goes down the gutter?
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Johannes Schindelin @ 2008-07-26 0:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, Miklos Vajna, git
In-Reply-To: <7viqutpjqq.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>
> > On Fri, Jul 25, 2008 at 13:33, Miklos Vajna <vmiklos@frugalware.org> wrote:
> >> 1) Maintain a list of commands that has a git-merge- prefix, but not a
> >> strategy. This list would currently contain "base, file, index,
> >> one-file and tree".
> >
> > Sounds a bit error prone, and could lead to unexpected results if/when
> > someone creates a new command ('git merge status' anyone?) which is
> > then suddenly treated as a merge strategy.
> >
> >> 2) Require custom strategies to have a different naming scheme, like
> >> if "foo" is a custom strategy, then it would have to be named
> >> git-merge-custom-foo, _not_ git-merge-foo.
> >
> > I think this is cleaner, what would be even nicer is to change the
> > current names too, so name them all "git-merge-stragegy-foo".
>
> I think you could retroactively impose "git-merge-strategy-" prefix rule
> and grandfather the existing ones by maintaining a list of them that by
> definition will not grow anymore.
... especially since I hope that we have them builtin soon, and not only
that, but have builtin-merge call them as C functions, not with fork() and
exec().
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Junio C Hamano @ 2008-07-26 0:33 UTC (permalink / raw)
To: sverre; +Cc: Miklos Vajna, git, Johannes Schindelin
In-Reply-To: <bd6139dc0807250450m25a932b8h68fcee13f8c343dc@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Fri, Jul 25, 2008 at 13:33, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> 1) Maintain a list of commands that has a git-merge- prefix, but not a
>> strategy. This list would currently contain "base, file, index,
>> one-file and tree".
>
> Sounds a bit error prone, and could lead to unexpected results if/when
> someone creates a new command ('git merge status' anyone?) which is
> then suddenly treated as a merge strategy.
>
>> 2) Require custom strategies to have a different naming scheme, like
>> if "foo" is a custom strategy, then it would have to be named
>> git-merge-custom-foo, _not_ git-merge-foo.
>
> I think this is cleaner, what would be even nicer is to change the
> current names too, so name them all "git-merge-stragegy-foo".
I think you could retroactively impose "git-merge-strategy-" prefix rule
and grandfather the existing ones by maintaining a list of them that by
definition will not grow anymore.
^ permalink raw reply
* Re: [PATCH 5/6] archive: allow --exec and --remote without equal sign
From: Junio C Hamano @ 2008-07-26 0:31 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <1216982486-5887-6-git-send-email-rene.scharfe@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Convert git archive to parse_options(). The parameters --remote and --exec
> are still handled by their special parser. Define them anyway in order for
> them to show up in the usage notice.
>
> Note: in a command like "git archive --prefix --remote=a/ HEAD", the string
> "--remote=a/" will be interpreted as a remote option, not a prefix, because
> that special parser sees it first. If one needs such a strange prefix, it
> needs to be specified like this: "git archive --prefix=--remote=a/ HEAD"
> (with an equal sign).
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> archive.c | 110 +++++++++++++++++++++++++++++++++++++-----------------------
> 1 files changed, 68 insertions(+), 42 deletions(-)
Hmph, somewhat dubious.
The real point of parse-options was to make the code smaller, easier to
maintain and command line handling more consistent. At least this patch
seems to fail on the two out of three counts.
All of the other patches made obvious sense to me and are queued for -rc1
but I'd like to backburner this one.
^ permalink raw reply
* Re: [PATCH 5/6] archive: allow --exec and --remote without equal sign
From: Junio C Hamano @ 2008-07-26 0:28 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <1216982486-5887-5-git-send-email-rene.scharfe@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Allow "--remote repo" and "--exec cmd" in addition to "--remote=repo" and
> "--exec=cmd" to make their usage consistent with parameters handled by
> parse_options().
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> builtin-archive.c | 20 +++++++++++++++++---
> 1 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/builtin-archive.c b/builtin-archive.c
> index 4dd2716..22445ac 100644
> --- a/builtin-archive.c
> +++ b/builtin-archive.c
> @@ -15,7 +15,7 @@ static int run_remote_archiver(const char *remote, int argc,
> int fd[2], i, len, rv;
> struct child_process *conn;
> const char *exec = "git-upload-archive";
> - int exec_at = 0;
> + int exec_at = 0, exec_value_at = 0;
>
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> @@ -24,7 +24,14 @@ static int run_remote_archiver(const char *remote, int argc,
> die("multiple --exec specified");
> exec = arg + 7;
> exec_at = i;
> - break;
Interesting... With this "break", we would have never triggered the
multiple --exec error, wouldn't we?
The patch itself looked fine. Thanks.
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-25 23:47 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
I think counting merges in "The Authors of Git" statistics give quite
skewed numbers. If you are generating it with "shortlog", you probably
would want to give --no-merges to the command line as well. Also it
appears that you are not using .mailmap to avoid counting the same person
as different people.
I find a tabular list like this list easier to read if it were sorted like
this:
A D G
B E H
C F
i.e. not like this:
A B C
D E F
G H
^ permalink raw reply
* Re: statistics
From: Kevin Ballard @ 2008-07-25 22:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Rene Herman, git
In-Reply-To: <4889B912.9040006@viscovery.net>
On Jul 25, 2008, at 4:29 AM, Johannes Sixt wrote:
> Rene Herman schrieb:
>> Hi.
>>
>> Is there a (non-depressing) way of getting "which files did not
>> change
>> since <rev>" out of git?
>
> What is "non-depressing"?
>
> Try this if you are using bash:
>
> comm -13 <(git diff --name-only your-rev-here) <(git ls-files)
Neat, I never knew about comm before. I probably would have come up
with something like
cat <(git ls-tree -r $REV) <(git ls-tree -r HEAD) | sort | uniq -d
| cut -f 2 | sort
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Petr Baudis @ 2008-07-25 22:15 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jakub Narebski, Junio C Hamano, Johannes Schindelin,
Marek Zawirski, git
In-Reply-To: <20080725215707.GC23202@spearce.org>
On Fri, Jul 25, 2008 at 04:57:07PM -0500, Shawn O. Pearce wrote:
> Cogito has also been deprecated, and maybe should be removed from
> the list, but it did have a larger user base so maybe we keep it
> on this survey and we remove it from the next?
Even recently, I've found a lot of people still using Cogito. I would
keep it in the survey in this round and in next years, decide based on
the share it gets this time.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-25 22:15 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080725220217.GE13539@leksak.fem-net>
Thanks - we're working on validating the pages now. This should be
fixed shortly.
Scott
On Fri, Jul 25, 2008 at 3:02 PM, Stephan Beyer <s-beyer@gmx.net> wrote:
> Hi,
>
> Just a very short note: I like it ;-)
> Amusing picture.
>
> You perhaps should switch the page encoding to utf-8, since many
> names of contributors are broken without.
> I've just taken a view at the XHTML. You have:
> <?xml version="1.0" encoding="iso-8859-1" ?>
> But:
> <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
>
> And the HTTP server does not set an encoding, as it seems, which is ok.
> So please change the first line to
> <?xml version="1.0" encoding="UTF-8"?>
>
> Thanks,
> Stephan
>
> --
> Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
>
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-25 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <7vabg5r4vy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> >
> >> 27. Which of the following features do you use?
> >> (zero or more: multiple choice)
> >> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
> >> ...
> >>
> >> What question about egit/jgit would you like to have in the survey?
> >
> > I'm not certain what else I would want to ask that is egit/jgit
> > specific.
>
> If you do not have any specific questions you would want to see answers
> to, then my point was moot, which is fine.
Actually I'd like the editor integration to be broken out (if
it isn't already) so we can see which editors (and thus which
integrations) are popular among users. I think it would help all
of the integration authors, as well as make it clear to end-users
where we have integration available/under development, in case they
were not aware of it previously.
--
Shawn.
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-25 22:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <20080725215707.GC23202@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> On Fri, 25 Jul 2008, Junio C Hamano wrote:
>> >
>> > What I meant was that we might want to have a few more questions about
>> > e/jgit as an independent entity in the survey, as it is a completely
>> > different re-implementation of the same git theme.
>>
>> There are two questions about egit/jgit planned for the survey:
>>
>> 16. Which porcelains / interfaces / implementations do you use?
>> (zero or more: multiple choice)
>> - core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
>> Pyrite, Easy Git, IsiSetup, _jgit_, my own scripts, other(*)
>
> pg should come out of this list in this version of the survey.
> It never had a large user base and all of those users should have
> moved away to something else by now.
>
> Cogito has also been deprecated, and maybe should be removed from
> the list, but it did have a larger user base so maybe we keep it
> on this survey and we remove it from the next?
>
>> 27. Which of the following features do you use?
>> (zero or more: multiple choice)
>> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
>> ...
>>
>> What question about egit/jgit would you like to have in the survey?
>
> I'm not certain what else I would want to ask that is egit/jgit
> specific.
If you do not have any specific questions you would want to see answers
to, then my point was moot, which is fine.
^ permalink raw reply
* Re: [PATCH] git-reset: Let -q hush "locally modified" messages
From: Junio C Hamano @ 2008-07-25 22:07 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Carlos Rica, Johannes Schindelin, git
In-Reply-To: <20080725213853.GD13539@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> writes:
> Junio C Hamano wrote:
> ...
>> Files being "locally modified" is not and error, so I think it is in line
>> with the spirit of what -q is meant to do.
>>
>> It is an interface change, though.
>
> Yes, as "needs update" -> "locally modified" was.
>
> However, scripts, that rely on filenames when doing -q (whyever),
> will break.
I was not worried about scripts. "reset" is a Porcelain, and it is Ok for
the scripts to use it and rely on what it does (e.g. "git reset HEAD^"
will move the HEAD one commit back and match your index to it), but they
should not be depending on its output to be parsable. Perhaps it is Ok
for them to detect if there is any change by observing if it spits out
anything, but that is about it. So the earlier change to use "locall
modified" does not really matter in that sense, but squelching the output
altogether is a change with bigger impact. With your patch, we declare
that the scripts should not assume anything about its output.
I was more worried about expectation from human users. We used to get a
reminder of the paths that are different from the HEAD/index, even with
the "-q" option, in the form of human-readable list of paths. Your patch
changes that.
Having said all that (the only reason I said the above is not because I
think this particular interface change is a big deal, but because I wanted
to explain what kind of interface change I do and do _not_ care about when
we talk about Porcelain), when the user explicitly gives "-q" to the
command, I think it is Ok to assume that the user does not want to hear
anything back. I do not see any fundamental problem with your patch in
that sense.
It still is an interface change, though ;-)
^ permalink raw reply
* Re: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Shawn O. Pearce @ 2008-07-25 22:05 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: Murphy, John, git
In-Reply-To: <20080724132853.GA25313@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> wrote:
> At 2008-07-24 09:01:48 -0400, john.murphy@bankofamerica.com wrote:
> >
> > I presume this was just an oversight when git- commands were removed
> > from the bin directory.
>
> Looks like it. The following patch fixes it for me. Does it work for
> you on Windows?
Thanks.
This patch is obviously correct on any platform except Mac OS X.
On Mac OS X it gets confusing because [info nameofexecutable] is
a wrapper .app which loads its own main script. That main script
needs to use the gitk location it receives from git-gui, and not
the location it computes from gitexecdir. So I'm following up
your patch with this:
diff --git a/macosx/AppMain.tcl b/macosx/AppMain.tcl
index 41ca08e..ddbe633 100644
--- a/macosx/AppMain.tcl
+++ b/macosx/AppMain.tcl
@@ -7,7 +7,7 @@ if {[string first -psn [lindex $argv 0]] == 0} {
}
if {[file tail [lindex $argv 0]] eq {gitk}} {
- set argv0 [file join $gitexecdir gitk]
+ set argv0 [lindex $argv 0]
set AppMain_source $argv0
} else {
set argv0 [file join $gitexecdir [file tail [lindex $argv 0]]]
--
Shawn.
^ permalink raw reply related
* Re: git-scm.com
From: Stephan Beyer @ 2008-07-25 22:02 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Hi,
Just a very short note: I like it ;-)
Amusing picture.
You perhaps should switch the page encoding to utf-8, since many
names of contributors are broken without.
I've just taken a view at the XHTML. You have:
<?xml version="1.0" encoding="iso-8859-1" ?>
But:
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
And the HTTP server does not set an encoding, as it seems, which is ok.
So please change the first line to
<?xml version="1.0" encoding="UTF-8"?>
Thanks,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-25 21:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <200807252352.09751.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 25 Jul 2008, Junio C Hamano wrote:
> >
> > What I meant was that we might want to have a few more questions about
> > e/jgit as an independent entity in the survey, as it is a completely
> > different re-implementation of the same git theme.
>
> There are two questions about egit/jgit planned for the survey:
>
> 16. Which porcelains / interfaces / implementations do you use?
> (zero or more: multiple choice)
> - core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
> Pyrite, Easy Git, IsiSetup, _jgit_, my own scripts, other(*)
pg should come out of this list in this version of the survey.
It never had a large user base and all of those users should have
moved away to something else by now.
Cogito has also been deprecated, and maybe should be removed from
the list, but it did have a larger user base so maybe we keep it
on this survey and we remove it from the next?
> 27. Which of the following features do you use?
> (zero or more: multiple choice)
> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
> ...
>
> What question about egit/jgit would you like to have in the survey?
I'm not certain what else I would want to ask that is egit/jgit
specific.
--
Shawn.
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-25 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <7vr69hsss1.fsf@gitster.siamese.dyndns.org>
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>> On Thu, 24 Jul 2008, Marek Zawirski wrote:
>>>> Junio C Hamano wrote:
>>>
>>>>> I am not sure how and where, but I think j/egit should also be
>>>>> mentioned and/or asked about.
>>>>
>>>> There is no separate mailing list for j/egit, we just used private mails
>>>> for some discussions/less important notifications.
[cut]
>
> Sorry for causing confusion in the discussion, but I was not talking about
> "mailing list on e/jgit".
>
> What I meant was that we might want to have a few more questions about
> e/jgit as an independent entity in the survey, as it is a completely
> different re-implementation of the same git theme.
There are two questions about egit/jgit planned for the survey:
16. Which porcelains / interfaces / implementations do you use?
(zero or more: multiple choice)
- core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
Pyrite, Easy Git, IsiSetup, _jgit_, my own scripts, other(*)
27. Which of the following features do you use?
(zero or more: multiple choice)
- Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
...
What question about egit/jgit would you like to have in the survey?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-25 21:49 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200807252336.13555.johan@herland.net>
Actually, that's directly from git.or.cz - I thought about removing
the Cygwin one, but perhaps swapping the order would be better. Any
thoughts?
Scott
On Fri, Jul 25, 2008 at 2:36 PM, Johan Herland <johan@herland.net> wrote:
> On Friday 25 July 2008, Scott Chacon wrote:
>> Hey all,
>
> Thanks for the update. Looks good.
>
> Minor niggle: On the download page, in the Binaries table, Cygwin is listed
> before msysGit. I'm under the impression that msysGit is what we really
> want to be pushing on Windows (it's faster, smaller, and less strange to
> Windows-people (i.e. less Unix-y)), so you might want to switch the order
> around.
>
>
> Have fun!
>
> ...Johan
>
> --
> Johan Herland, <johan@herland.net>
> www.herland.net
>
^ permalink raw reply
* Re: [PATCH] Propagate -u/--upload-pack option of "git clone" to transport.
From: Junio C Hamano @ 2008-07-25 21:48 UTC (permalink / raw)
To: Steve Haslam; +Cc: git, Daniel Barkalow
In-Reply-To: <1217008311-27916-1-git-send-email-shaslam@lastminute.com>
Looks correct; thanks.
^ permalink raw reply
* Re: [StGit PATCH] Fixed default install location
From: Catalin Marinas @ 2008-07-25 21:46 UTC (permalink / raw)
To: Daniel White; +Cc: git
In-Reply-To: <20080724202031.55dec8e8@whitehouse.id.au>
2008/7/24 Daniel White <daniel@whitehouse.id.au>:
> Originally broken by addition of Debian package support.
>
> Signed-off-by: Daniel White <daniel@whitehouse.id.au>
> ---
>
> The default installation direction is actually /usr at present despite
> what 'INSTALL' says.
>
> The 'debian/rules' makefile specifies the prefix as /usr so doesn't
> seem to depend on this. I've tested the resulting debian package and
> everything is still installed correctly under /usr.
I also use "python setup.py bdist_rpm" when releasing, I think it will
get confused by a different prefix.
--
Catalin
^ 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