* Re: Official Git Homepage change? Re: git-scm.com
From: Johannes Schindelin @ 2008-07-26 4:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Scott Chacon, git
In-Reply-To: <7v4p6dnv5k.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> It's also somewhat interesting to observe that several people I have
> never heard of in the git circle are simultaneously doing new git books,
> apparently never asking for much technical advice from core git people,
> by the way.
FWIW my criticism in the same direction was met with ridicule, which does
not let me expect much of them.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-26 4:25 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Miklos Vajna
In-Reply-To: <20080726055920.3a2fc8e7.chriscool@tuxfamily.org>
Hi,
On Sat, 26 Jul 2008, Christian Couder wrote:
> I suspect this patch may be usefull to simplify my
> "bisect: add merge bases check" series and perhaps
> also generally usefull.
s/usefull/useful/
> diff --git a/builtin-merge-base.c b/builtin-merge-base.c
> index 1cb2925..9c41849 100644
> --- a/builtin-merge-base.c
> +++ b/builtin-merge-base.c
> @@ -2,9 +2,14 @@
> #include "cache.h"
> #include "commit.h"
>
> -static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_all)
> +static struct commit *rev1, **prev2;
> +static size_t prev2_nr, prev2_alloc;
> +
> +
> +static int show_merge_base(int show_all)
> {
Changing the arguments to be static variables?
NACK!
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Documentation/git-submodule.txt: fix doubled word
From: Cesar Eduardo Barros @ 2008-07-26 4:17 UTC (permalink / raw)
To: git, gitster; +Cc: Cesar Eduardo Barros
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
Documentation/git-submodule.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 829b032..35efeef 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -63,7 +63,7 @@ COMMANDS
add::
Add the given repository as a submodule at the given path
to the changeset to be committed next to the current
- project: the current project is termed termed the "superproject".
+ project: the current project is termed the "superproject".
+
This requires two arguments: <repository> and <path>.
+
--
1.5.6.4
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 4:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, git
In-Reply-To: <20080726020951.GV32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> .... Of course, I would be transferring the control of the homepage
> from my hands so I would like to poll the community about how do people
> feel about this - opinion of core Git contributors would be especially
> welcome...
> ...
> - The new site is affiliated with a commercial entity - GitHub.
> The website maintainer also has commercial interest in some published
> Git learning materials, which might generate certain conflict of
> interests; we must trust them that they handle this well.
> - Both GitHub and Scott seem to be rather distanced from the "core"
> Git development community. This might or might not be an issue.
These two are directly related. They might be friendly and well-meaning
folks, but I agree that they haven't earned our trust yet.
But I do not think it matters that much.
The thing is, git.or.cz may have been the closest thing to the "official"
homepage we have had, but that is not because Linus or I or Shawn declared
the site is official and/or that the site is trustworthy. It was because
you put efforts preparing the contents worthy to be one-stop shop for git
related information, back when there was no such thing. And the members
of the comminity found it a good site. And you have the wiki there, where
there truly have been community participation to enhance the contents.
For me personally, pages outside the wiki have never felt like "the
official git homepage", not because the contents you prepared were
inadequate, but because I did not see much community participation to help
enrich it.
So I wish the new site success, but the definition of success from my
point of view is not how many random visitors it will attract, but how
well the site makes the contributors (both to git software itself, and to
the site's contents) feel welcomed. Maybe in time it will become
successful enough by _my_ definition of success, and I may recommend
kernel.org folks to point at it from http://git.kernel.org/ (link with
text "overview") if/when that happens, and I may start mentioning them in
the "Note". We'll see.
> The negatives section writeup is longer, but in fact I think the
> positives win here; I also have a bit of bad conscience about not giving
> git.or.cz the amount of time it would deserve...
Let me thank you for maintaining not just git.or.cz/ but also repo.or.cz/
and the wiki. I personally never visited the "Homepage" but the
repositories and the wiki are valuable services you gave back to the
community.
It's also somewhat interesting to observe that several people I have never
heard of in the git circle are simultaneously doing new git books,
apparently never asking for much technical advice from core git people, by
the way.
^ permalink raw reply
* [RFC/PATCH] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-26 3:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Miklos Vajna
Before this patch "git merge-base" accepted only 2 arguments, so
only merge bases between 2 references could be computed.
The purpose of this patch is to make "git merge-base" accept more
than 2 arguments so that the merge bases between the first given
reference and all the other references can be computed.
This is easily implemented because the "get_merge_bases_many"
function in "commit.c" already implements the computation.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-merge-base.c | 51 ++++++++++++++++++++++++++++++++++++-------------
commit.h | 2 +
2 files changed, 39 insertions(+), 14 deletions(-)
I suspect this patch may be usefull to simplify my
"bisect: add merge bases check" series and perhaps
also generally usefull.
I will add documentation and perhaps tests too if
people are ok with something like that.
By the way perhaps such a patch has already been
posted by someone else. In this case sorry for the
noise and thanks for any pointer to the previous
patch.
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 1cb2925..9c41849 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -2,9 +2,14 @@
#include "cache.h"
#include "commit.h"
-static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_all)
+static struct commit *rev1, **prev2;
+static size_t prev2_nr, prev2_alloc;
+
+
+static int show_merge_base(int show_all)
{
- struct commit_list *result = get_merge_bases(rev1, rev2, 0);
+ struct commit_list *result = get_merge_bases_many(rev1, prev2_nr,
+ prev2, 0);
if (!result)
return 1;
@@ -20,12 +25,24 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
}
static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>";
+"git merge-base [--all] <commit-id> <commit-id>...";
+
+static void append_rev2(struct commit *rev)
+{
+ ALLOC_GROW(prev2, prev2_nr + 1, prev2_alloc);
+ prev2[prev2_nr++] = rev;
+}
+
+static struct commit *get_commit_reference(const char *arg)
+{
+ unsigned char revkey[20];
+ if (get_sha1(arg, revkey))
+ die("Not a valid object name %s", arg);
+ return lookup_commit_reference(revkey);
+}
int cmd_merge_base(int argc, const char **argv, const char *prefix)
{
- struct commit *rev1, *rev2;
- unsigned char rev1key[20], rev2key[20];
int show_all = 0;
git_config(git_default_config, NULL);
@@ -38,15 +55,21 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
usage(merge_base_usage);
argc--; argv++;
}
- if (argc != 3)
+ if (argc < 3)
usage(merge_base_usage);
- if (get_sha1(argv[1], rev1key))
- die("Not a valid object name %s", argv[1]);
- if (get_sha1(argv[2], rev2key))
- die("Not a valid object name %s", argv[2]);
- rev1 = lookup_commit_reference(rev1key);
- rev2 = lookup_commit_reference(rev2key);
- if (!rev1 || !rev2)
+
+ rev1 = get_commit_reference(argv[1]);
+ if (!rev1)
return 1;
- return show_merge_base(rev1, rev2, show_all);
+ argc--; argv++;
+
+ do {
+ struct commit *rev2 = get_commit_reference(argv[1]);
+ if (!rev2)
+ return 1;
+ append_rev2(rev2);
+ argc--; argv++;
+ } while (argc > 1);
+
+ return show_merge_base(show_all);
}
diff --git a/commit.h b/commit.h
index 77de962..4829a5c 100644
--- a/commit.h
+++ b/commit.h
@@ -121,6 +121,8 @@ int read_graft_file(const char *graft_file);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
+extern struct commit_list *get_merge_bases_many(struct commit *one,
+ int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
extern int register_shallow(const unsigned char *sha1);
--
1.6.0.rc0.43.g62478.dirty
^ permalink raw reply related
* Re: [PATCH] Remove references to git-fetch-pack from "git clone" documentation.
From: Johannes Schindelin @ 2008-07-26 3:24 UTC (permalink / raw)
To: Steve Haslam; +Cc: git
In-Reply-To: <1217011068-1675-1-git-send-email-shaslam@lastminute.com>
Hi,
On Fri, 25 Jul 2008, Steve Haslam wrote:
> "git clone" no longer calls "git-fetch-pack",
So it calls it internally, avoiding fork() and exec(). But the code is
still git-fetch-pack's. The difference should be lost on the regular Git
user.
Ciao,
Dscho
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-26 3:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807211331390.31863@woody.linux-foundation.org>
Hi,
On Monday 21. July 2008, Linus Torvalds wrote:
> Read up on '--full-history'.
>
> By default, git simplifies the history for logs that have path
> simplification: only walking down the side of a merge that all the data
> came from (ie the unchanged side). So it only leaves merges around if
> there was changes from _all_ parents.
>
> So without --full-history, if any parent matches the state, it just
> removes the merge and picks that parent that contained all the state.
> Obviously, any changes to that file can be sufficiently explained by
> walking just that limited history, because they must have changed in
> _that_ history too!
Is that really a good default behaviour? Is there a way to change that
default?
I'm currently looking into converting the m68k CVS repository and I'd like to
properly regenerate it as two separate lines of development. The problem is
if I look at the file history, I often only see one side of the changes when
things got merged because of this default.
What makes this worse is that graphical front ends may inherit this behaviour.
I tested this with qgit and it only shows half of the history. giggle
retrieves the history like --full-history, but it lacks empty merges, so it
makes it harder to see what got merged when.
For example a history that actually looks this:
linux -+-----import----+-----------import----+------...
m68k \-commit-commit-\-merge-commit-commit-\-merge...
Without the merges it looks like this:
linux -+-----import----------------import--------------+...
m68k \-commit-commit---------commit-commit \...
And without --full-history these "loose ends" aren't visible as in qgit.
When researching historical changes one wants to know when something was
introduced and when it was merged, but this simplification makes it harder
than it really has to be.
IMO the default should be to show the complete history, so one doesn't miss
something by accident that might be important or as the original example
shows it might be confusing if one sees a change with "git log --stat id.."
and the change disappears when one looks at "git log path".
bye, Roman
^ permalink raw reply
* Re: [PATCH 1/2] Move launch_editor() from builtin-tag.c to editor.c
From: Stephan Beyer @ 2008-07-26 3:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807260456360.26810@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> On Fri, 25 Jul 2008, Stephan Beyer wrote:
>
> > To be kind to the maintainer, I've also run the test suite again, all
> > tests passed except t4116*.sh, but this is not my fault. It's the fault
> > of 9a885fac.
>
> You do understand that you cost everybody, who actually cared to take a
> look for herself, a few minutes?
Yes, now I see that I forgot to mention the subject.
I'm sorry.
> Dscho "who thinks that so many mails would be better if the posters would
> read the mails themselves and try to imagine how readers would perceive
> them"
You're right.
In my case I perhaps should've *first* looked if I could fix the TAR issue
and then first send the fix for the TAR stuff and then remove the text from
here. But I noticed the failure, wrote about it here, sent this mail, looked
for the reason of the error, ... the wrong order, as it seems.
I try to improve.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git-scm.com
From: Johannes Schindelin @ 2008-07-26 3:07 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Scott Chacon, git
In-Reply-To: <20080726025402.GF13539@leksak.fem-net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
> > I do not like the implication that Git eats trees.
>
> I still like the picture, though it can hurt environmentalists.
It's not just environmentalists. If I put myself in the shoes of a Git
newbie, I would get the impression that Git eats my trees, i.e. destroys
them.
Very good first impression.
Not,
Dscho
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Johannes Schindelin @ 2008-07-26 3:04 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Nicolas Pitre, spearce, git
In-Reply-To: <20080725171315.GA27285@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 213 bytes --]
Hi,
On Fri, 25 Jul 2008, Björn Steinbrink wrote:
> + // This object comes from outside the thin pack, so we need to
> + // initialize the size and type fields
Do not use C++ comments in Git. Ever.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Move launch_editor() from builtin-tag.c to editor.c
From: Johannes Schindelin @ 2008-07-26 3:00 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <1217003322-10291-1-git-send-email-s-beyer@gmx.net>
Hi,
On Fri, 25 Jul 2008, Stephan Beyer wrote:
> To be kind to the maintainer, I've also run the test suite again, all
> tests passed except t4116*.sh, but this is not my fault. It's the fault
> of 9a885fac.
You do understand that you cost everybody, who actually cared to take a
look for herself, a few minutes?
Just to see that the change you referenced (but did not describe at all)
is "tar -> $TAR".
And now, everybody who cared will be just puzzled. In the best case, he
will reply to you that your hint left to be wished for. I do not have to
describe the worst case, do I?
Ciao,
Dscho "who thinks that so many mails would be better if the posters would
read the mails themselves and try to imagine how readers would perceive
them"
^ permalink raw reply
* Re: git-scm.com
From: Stephan Beyer @ 2008-07-26 2:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807260422250.11976@eeepc-johanness>
Johannes Schindelin wrote:
> I do not like the implication that Git eats trees.
Eridius said on IRC:
"it's a Git", "he's a Blob that's Committed to storing Trees"
I still like the picture, though it can hurt environmentalists.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Avoid warning when From: is encoded
From: Johannes Schindelin @ 2008-07-26 2:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: sverre, Abhijit Menon-Sen, Peter Valdemar Mørch, git
In-Reply-To: <488A01B8.2010405@freescale.com>
Hi,
On Fri, 25 Jul 2008, Jon Loeliger wrote:
> Sverre Rabbelier wrote:
>
> > Acked-by is reserved for people who are "owners" of the area the patch
> > touches.
>
> I love pronouncements like this. While that may be exactly true
> for the Git project, it is not, in general, always true.
It may not be true in general, but from what I heard of the Kernel
community, even there it is considered rude if you just step in and say
ACK, when you clearly have no idea what you are talking about (which is
normally determined by your being involved in that area).
So you can love (or not) pronouncements like that, but the fact still
stands true: how can your ACK be of any value (or for that matter, how can
your ACK be taken seriously) when you haven't proven -- in code! -- that
you understand the code?
Hthab,
Dscho
^ permalink raw reply
* Re: how about removing --exec-path?
From: Johannes Schindelin @ 2008-07-26 2:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080725094015.GA22077@blimp.local>
Hi,
On Fri, 25 Jul 2008, Alex Riesen wrote:
> The thing has at least this problem: is not passed to upload-pack when
> running fetch.
It should be added to PATH, and so it is passed to upload-pack, amongst
others, in a sense.
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: david @ 2008-07-26 2:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, Patrick Aljord, git list
In-Reply-To: <20080726023707.GX32184@machine.or.cz>
On Sat, 26 Jul 2008, Petr Baudis wrote:
> Hi,
>
> On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
>> I am more concerned about the logo at the bottom, and Petr and I are
>> discussing this - I can remove the logo, but then I'd have to pay for
>> this out of my pocket instead of having a small logo on the page.
>
> I actually think that this is *one* reference to GitHub that is
> perfectly and 100% okay; if it is sponsoring the hosting, it deserves
> the logo, and it is fairly non-intrusive. I _am_ watching out warily
> for excessive GitHub references within the rest of the site - if only
> because I have kind of personal interest in a competitor of GitHub and
> thus don't want GitHub to get unwarranted free advertising. :-)
>
> Petr "Pasky" Baudis
since this is a Ruby on Rails site, could the 'five links' that have been
bothering people be randomly selected? if every time you go to the site
you get a different list of projects it show how broadly git is used. it's
not as 'in your face' as managing to select five that cause people to say
"wow, they're using this", but different people will react to different
sites.
if this table gets populated by GitHub, kernel.org, and a couple other
sources it should be vendor independant enough (and we need a table like
this anyway for the 'list of projects that use git', so it serves two
purposes)
David Lang
^ permalink raw reply
* Re: git-scm.com
From: Johannes Schindelin @ 2008-07-26 2:45 UTC (permalink / raw)
To: Scott Chacon; +Cc: Patrick Aljord, git list
In-Reply-To: <d411cc4a0807251928g75744b78vac2ce77bf07fbd81@mail.gmail.com>
Hi,
On Fri, 25 Jul 2008, Scott Chacon wrote:
> 5 links in the middle?
What 5 links in the middle?
*scrolls down*
Ah, the top-posting syndrome.
Old quote, but more valid than ever:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
I find it almost comical that people do not realize how unnaturally they
behave, and how hard they make it on their recipients, when they top-post.
Oh, and usually, I take top-posting as a clear sign that the poster is not
worth replying to. Take this mail as a sign that I take care of what you
said, _in spite of_ your top-posting.
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-26 2:37 UTC (permalink / raw)
To: Scott Chacon; +Cc: Patrick Aljord, git list
In-Reply-To: <d411cc4a0807251928g75744b78vac2ce77bf07fbd81@mail.gmail.com>
Hi,
On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
> I am more concerned about the logo at the bottom, and Petr and I are
> discussing this - I can remove the logo, but then I'd have to pay for
> this out of my pocket instead of having a small logo on the page.
I actually think that this is *one* reference to GitHub that is
perfectly and 100% okay; if it is sponsoring the hosting, it deserves
the logo, and it is fairly non-intrusive. I _am_ watching out warily
for excessive GitHub references within the rest of the site - if only
because I have kind of personal interest in a competitor of GitHub and
thus don't want GitHub to get unwarranted free advertising. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Johannes Schindelin @ 2008-07-26 2:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, Miklos Vajna, git
In-Reply-To: <7vvdyto3da.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> 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?
Yes, they can. Slowly, but they do.
But why should they? Efficient merging is such a prominent feature of
Git; I do not agree to let it remain a second-class feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-reset: Let -q hush "locally modified" messages
From: Johannes Schindelin @ 2008-07-26 2:34 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, Carlos Rica, git
In-Reply-To: <20080725213853.GD13539@leksak.fem-net>
Hi,
On Fri, 25 Jul 2008, Stephan Beyer wrote:
> Junio C Hamano wrote:
> > Stephan Beyer <s-beyer@gmx.net> writes:
> >
> > > git reset -q makes reset more quiet, but "locally modified" messages
> > > are still shown. This patch makes them disappear, too.
> >
> > 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.
But that is not about scripts. Scripts have no business calling pure
porcelain, so they still get "needs update" if done properly.
Hth,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-26 2:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807260422250.11976@eeepc-johanness>
Hi,
On Sat, Jul 26, 2008 at 04:25:16AM +0200, Johannes Schindelin wrote:
> On Fri, 25 Jul 2008, Scott Chacon wrote:
>
> > A followup on the post I did a few days ago about Git documentation.
> > I forked Petr's git.or.cz site and put up a version that I think is a
> > bit more accessible and newbie-friendly at git-scm.com.
>
> I do not like the implication that Git eats trees.
yes, I keep wondering about the logo as well. On one side it is rather
amusing, on the other side... somehow it didn't win my heart over and it
*does* look somewhat unprofessional.
> I also do not like that the link to "Documentation" looks more like a
> too-short cheat-sheet.
I personally don't find the idea of having direct links to the most
used commands bad, though I'm not sure how useful will it be in
practice.
> But then, I think that git.or.cz looks more professional (read: more
> respectful, less geekish), so I think there is not much harm in that.
Note that I tried to fix up a lot of bits that I felt were a little
too colloquial in my patch series I linked in a previous mail.
--
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: Scott Chacon @ 2008-07-26 2:28 UTC (permalink / raw)
To: Patrick Aljord; +Cc: git list
In-Reply-To: <6b6419750807251838h12ea4f19gdff107694e3797c4@mail.gmail.com>
5 links in the middle? You mean to the project links? I just choose
the biggest, most well known projects I could think of and stuck them
up there - many of them are at GitHub. If you have a list you like
better, I would be happy to add them, or discuss the final list, but I
hardly think that's an advertisement for GitHub. As for the link in
the footer, that's where I'm hosting my repo for the page, and it's at
the bottom of the page and tiny.
I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.
It's not bad to host a few webpages, but this will eventually have
diagrams and screencasts and whatever else I can do for comprehensive
documentation, which can add up in brandwidth costs (especially the
screencasts). The Githubbers have offered to pay for that and host
media and whatnot for the project, backed by a real team of sysadmins.
That seems like a pretty good deal for a small logo at the bottom of
the page. For newbies, that is likely even a good thing - makes them
see that there is some corporate interest in it - that it's not just
an obscure tool for the hard core.
I am open to discussion on that, but I can't change where Ruby on
Rails has decided to host their repo.
Scott
On Fri, Jul 25, 2008 at 6:38 PM, Patrick Aljord <patcito@gmail.com> wrote:
> 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.
> --
> 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: git-scm.com
From: Johannes Schindelin @ 2008-07-26 2:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Hi,
On Fri, 25 Jul 2008, Scott Chacon wrote:
> A followup on the post I did a few days ago about Git documentation.
> I forked Petr's git.or.cz site and put up a version that I think is a
> bit more accessible and newbie-friendly at git-scm.com.
I do not like the implication that Git eats trees.
I also do not like that the link to "Documentation" looks more like a
too-short cheat-sheet.
> I had meant to discuss this with Petr before posting it to you all, but
> I published a blog post that got a bit more attention than I expected,
> and I didn't want you all to think I didn't care about your opinion, as
> some have already accused me of.
My first reaction was: he could have given Pasky a little more time to
react.
But then, I think that git.or.cz looks more professional (read: more
respectful, less geekish), so I think there is not much harm in that.
Ciao,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 2:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <20080726015314.GU32184@machine.or.cz>
Hi,
oops, so I decided to unbundle this question from the previous post,
but forgot to modify the subject line...
When the git-scm.com site gets refined a bit further, it might make a
lot of sense to make http://git.or.cz/index.html a redirect to
http://git-scm.com/ and thus delegate the new site to the official Git
homepage. Of course, I would be transferring the control of the homepage
from my hands so I would like to poll the community about how do people
feel about this - opinion of core Git contributors would be especially
welcome; I find myself rather happy with the new site, so I will
implicitly take silence as an agreement.
Here is a breakdown of possible pros and cons that come on my mind:
+ The new site has much nicer and more catchy design.
+ The new site seems to have a lot of potential to grow to a rather
comprehensive resource.
+ The new site would probably have much more active maintainer. ;-)
- The new site is affiliated with a commercial entity - GitHub.
The website maintainer also has commercial interest in some published
Git learning materials, which might generate certain conflict of
interests; we must trust them that they handle this well.
- Both GitHub and Scott seem to be rather distanced from the "core"
Git development community. This might or might not be an issue.
- The new site is implemented in much more complicated way than the
old one, having a full-fledged Ruby on Rails machinery behind it and
linking to bunch of obfuscated JavaScript code; I don't think it's that
big a deal, though.
The negatives section writeup is longer, but in fact I think the
positives win here; I also have a bit of bad conscience about not giving
git.or.cz the amount of time it would deserve...
P.S.: To simplify matters, I talk only about index.html, but of course
it would make sense to transfer both the SVN Crash Course _AND_ the Git
Wiki along; we might keep the Cogito homepage for purely historical
interest too, I don't know.
--
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: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-26 2:09 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Dmitry Potapov, Avery Pennarun, Joshua Jensen, Junio C Hamano,
git
In-Reply-To: <42C252B2-85B9-4D05-B3A2-2A0250D7F5D6@orakel.ntnu.no>
Hi,
On Fri, 25 Jul 2008, Eyvind Bernhardsen wrote:
> That is an excellent argument for why setting "autocrlf=true" by default
> on Windows was a bad idea. Thanks! :)
Well, these days, I tend to give a flying nothing to opinions that are not
backed up by any effort toward the project.
In other words, if you have not participated in the community process to
find what is best for Git, you could just as well say that you want the
moon to be green, and I could not care less (in both cases).
Ciao,
Dscho
^ permalink raw reply
* 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
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