* Re: Author name and e-mail address in .stgitrc
From: Catalin Marinas @ 2006-11-11 23:02 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061111141530.GF11224@diana.vm.bytemark.co.uk>
On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> Is there any particular reason to have the author and committer names
> in ~/.stgitrc? Simply taking them from the same place git does would
> probably be a usability enhancement (unless they're specified on the
> command line, of course).
At the time I added these to .stgitrc, the only place git was taking
them from was the environment variables and I wanted to put them in a
single place. I also didn't like the idea of having the committer
e-mail address be some username@local-machine as I don't think the
name of the machine where I create patches is relevant. I also define
the committer/author per repository in the .git/stgitrc file (i.e. I
use @arm.com for Linux patches and @gmail.com for StGIT).
I use StGIT almost exclusively, even in "maintainer" mode and I would
like not to spread the configuration options over many files. It is on
my todo list to use the same configuration file as git (with a [stgit]
section) since it has a format that should be understood by the Python
config module.
--
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Martin Langhoff @ 2006-11-11 22:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, jnareb, git
In-Reply-To: <7vac2xkdgi.fsf@assigned-by-dhcp.cox.net>
On 11/11/06, Junio C Hamano <junkio@cox.net> wrote:
> I think Martin Langhoff promised to make his presentation done
> in Mexico available to us sometime ago, but I wonder what
> happened to it...
Hola! You are right, I never published anything... The Mexico
presentation was a combination of your original slides (I ended up
using the PDF directly as I didn't have OOv2) plus a version of my
older talk notes, updated and in Spanish. So I swapped the two
around.... "live".
The old, outdated talk is based on Cogito, and can be found here. I
still use it for my inhouse team --
http://wellington.pm.org/archive/200510/git/
cheers,
^ permalink raw reply
* Re: StGIT repository not clonable?
From: Jakub Narebski @ 2006-11-11 22:48 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0611111359t994d688w9bc6aae8e9183fd3@mail.gmail.com>
Catalin Marinas wrote:
> IIRC, there was some advise in some GIT document
> or e-mail saying that you shouldn't pack if the export is over a dumb
> protocol. That's good for people pulling regularly but bad for
> cloning.
By the way, does dumb protocols download _whole_ packs only? Or do they
download parts of packs (curl can do that, I think)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: StGIT repository not clonable?
From: Karl Hasselström @ 2006-11-11 22:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Horst H. von Brand, git
In-Reply-To: <b0943d9e0611111359t994d688w9bc6aae8e9183fd3@mail.gmail.com>
On 2006-11-11 21:59:32 +0000, Catalin Marinas wrote:
> I've never packed it. IIRC, there was some advise in some GIT
> document or e-mail saying that you shouldn't pack if the export is
> over a dumb protocol. That's good for people pulling regularly but
> bad for cloning.
It's _extremely_ bad when cloning. There's a separate HTTP request for
each object in the repository, which means lots of time and lots of
web server load. It's just about doable to clone the StGIT repository
now because it's so small.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Author name and e-mail address in .stgitrc
From: Karl Hasselström @ 2006-11-11 22:30 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Catalin Marinas, git
In-Reply-To: <200611112126.32380.robin.rosenberg.lists@dewire.com>
On 2006-11-11 21:26:31 +0100, Robin Rosenberg wrote:
> lördag 11 november 2006 15:57 skrev Karl Hasselström:
>
> > But I haven't gotten the impression that specifying them in
> > ~/.stgitrc is deprecated. The example stgitrc has a section with
> > author name and committer name, for example.
>
> The only docs I know of that mentions stgitrc also states that it
> isn't required, so why use it unless you have to (or for some reason
> want to)? Just because there are many ways, doesn't mean all but one
> have to be deprecated.
No, but having a config option for something that git already provides
several ways to specify can't possibly be a good idea, especially
usability-wise. The only use I can think of is if you _want_ to have
different identities for git and stgit in the same repository, and
that's just mad.
I'm preparing a patch to fix this. Stay tuned. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: StGIT repository not clonable?
From: Catalin Marinas @ 2006-11-11 21:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Horst H. von Brand, git
In-Reply-To: <20061111123634.GD11224@diana.vm.bytemark.co.uk>
On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-11-11 00:56:47 -0300, Horst H. von Brand wrote:
> > I'm trying to update my StGIT repo here, and get a crash from
> > git-http-fetch (git 1.4.3.4). Trying to clone it anew gives:
>
> It works for me, with
>
> $ git --version
> git version 1.4.3.3.g8387
>
> But it's horribly slow. Catalin, have you ever packed that repository?
I've never packed it. IIRC, there was some advise in some GIT document
or e-mail saying that you shouldn't pack if the export is over a dumb
protocol. That's good for people pulling regularly but bad for
cloning.
Anyway, thanks to Pasky, you can now pull/clone it over the git
protocol directly - git://repo.or.cz/stgit.git. This repository is up
to date. I have a plan to move the main StGIT repository to Pasky's
server but I'm a bit busy with other things at the moment.
--
^ permalink raw reply
* Re: [PATCH] Build in shortlog
From: Junio C Hamano @ 2006-11-11 21:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Alex Riesen
In-Reply-To: <Pine.LNX.4.63.0610221322370.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/path-list.c b/path-list.c
> index 0c332dc..f8800f8 100644
> --- a/path-list.c
> +++ b/path-list.c
> @@ -57,7 +57,7 @@ struct path_list_item *path_list_insert(
> int index = add_entry(list, path);
>
> if (index < 0)
> - index = 1 - index;
> + index = -1 - index;
>
> return list->items + index;
> }
This part looks like a genuine bugfix and unrelated to
shortlog.
Many callers of path_list_insert() seem to ignore its return
value, but merge_recursive.c seems to use it in three places, to
find an entry to hang cached rename information to in
insert_stage_data().
I haven't come up with an example to demonstrate the breakage of
not having this fix in the existing git-merge-recursive, but I
think this needs to be applied to even 'maint'.
^ permalink raw reply
* Re: Author name and e-mail address in .stgitrc
From: Robin Rosenberg @ 2006-11-11 20:26 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20061111145708.GH11224@diana.vm.bytemark.co.uk>
lördag 11 november 2006 15:57 skrev Karl Hasselström:
> On 2006-11-11 15:31:15 +0100, Robin Rosenberg wrote:
> > lördag 11 november 2006 15:15 skrev Karl Hasselström:
> > > Is there any particular reason to have the author and committer
> > > names in ~/.stgitrc? Simply taking them from the same place git
> > > does would probably be a usability enhancement (unless they're
> > > specified on the command line, of course).
> >
> > AFAIK StGit already does that, at least if you (like me) do not have
> > a .stgitrc.
>
> But I haven't gotten the impression that specifying them in ~/.stgitrc
> is deprecated. The example stgitrc has a section with author name and
> committer name, for example.
The only docs I know of that mentions stgitrc also states that it isn't
required, so why use it unless you have to (or for some reason want to)? Just
because there are many ways, doesn't mean all but one have to be deprecated.
^ permalink raw reply
* Re: check if a commit is ascendent of a specific commit
From: Junio C Hamano @ 2006-11-11 20:12 UTC (permalink / raw)
To: Tom Prince; +Cc: git
In-Reply-To: <20061111192321.GJ4862@socrates.priv>
Tom Prince <tom.prince@ualberta.net> writes:
> On Sat, Nov 11, 2006 at 10:43:47AM -0800, Junio C Hamano wrote:
>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>>
>> > Hi,
>> > I want to create "git-amend-commit" to be able to amend commits before
>> > HEAD. So I need to check whether the commit I'm going to amend is
>> > ascendent of HEAD. Is there any way to check that?
>>
>> Ascendant is a word from astorology -- you mean ancestor ;-).
>
> Or antecedent.
Sorry, there is no "or" here -- check our documentation ;-).
^ permalink raw reply
* Re: check if a commit is ascendent of a specific commit
From: Tom Prince @ 2006-11-11 19:23 UTC (permalink / raw)
To: git
In-Reply-To: <7virhlken0.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 11, 2006 at 10:43:47AM -0800, Junio C Hamano wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > Hi,
> > I want to create "git-amend-commit" to be able to amend commits before
> > HEAD. So I need to check whether the commit I'm going to amend is
> > ascendent of HEAD. Is there any way to check that?
>
> Ascendant is a word from astorology -- you mean ancestor ;-).
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Junio C Hamano @ 2006-11-11 19:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: jnareb, git
In-Reply-To: <ej4teo$bjo$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Petr Baudis wrote:
>
>> and http://git.or.cz/gitwiki/GitLinks for links to plenty
>> of "using git" pages for various projects and other introductory
>> articles.
>
> GitLinks has now links to junio, jdl and pasky slides from OLS,
> and junio slides from OSDL Japan Linux Symposium.
The OSDL Japan one is much more suitable for stealing tutorial
material from than the OLS one, but they took the pages on old
seminars down without telling me, it seems. I've updated the
link in GitLinks page. The presentation is designed to be run
in 25 minutes using the first half of slides (pretty pictures),
followed by a 25 minutes demo (reproducing the second half of
slides).
I think Martin Langhoff promised to make his presentation done
in Mexico available to us sometime ago, but I wonder what
happened to it...
^ permalink raw reply
* Re: check if a commit is ascendent of a specific commit
From: Junio C Hamano @ 2006-11-11 18:43 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0611110308l577d70bfo5046d7d7eb09ac58@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> Hi,
> I want to create "git-amend-commit" to be able to amend commits before
> HEAD. So I need to check whether the commit I'm going to amend is
> ascendent of HEAD. Is there any way to check that?
Ascendant is a word from astorology -- you mean ancestor ;-).
"git-merge-base A B === A" when A is an ancestor of B.
Provided if the history between A and B is linear, and you do
not have trouble making your co-workers adjusting to your
history change after A (including the cases where you do not
have any co-workers or you have not made history between A and B
public), you could do one of these three things:
- use "stg uncommit" until you pop A, make a change there and
"stg refresh", and then "stg push" everything back.
- "git format-patch A && git reset --hard A", edit the patches
and then "git am" them.
- "git tag -f Anchor && git reset --hard A", edit and "git
commit --amend". Look at "git show-branch Anchor HEAD", and
repeatedly "git cherry-pick Anchor~$n" from older to newer
from Anchor, and then "git tag -d Anchor".
^ permalink raw reply
* [PATCH] Remove unneeded parameters in diff_unmerge() and diff_get_patch_id()
From: Michael @ 2006-11-11 17:55 UTC (permalink / raw)
To: git
Signed-off-by: Michael <barra_cuda@katamail.com>
---
diff-lib.c | 4 ++--
diff.c | 7 +++----
diff.h | 3 +--
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index fc69fb9..df5c793 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -97,7 +97,7 @@ int run_diff_files(struct rev_info *revs
* Show the diff for the 'ce' if we found the one
* from the desired stage.
*/
- diff_unmerge(&revs->diffopt, ce->name);
+ diff_unmerge(ce->name);
if (ce_stage(ce) != diff_unmerged_stage)
continue;
}
@@ -299,7 +299,7 @@ static int diff_cache(struct rev_info *r
break;
/* fallthru */
case 3:
- diff_unmerge(&revs->diffopt, ce->name);
+ diff_unmerge(ce->name);
break;
default:
diff --git a/diff.c b/diff.c
index fb82432..6fda65b 100644
--- a/diff.c
+++ b/diff.c
@@ -2448,7 +2448,7 @@ static void patch_id_consume(void *priv,
}
/* returns 0 upon success, and writes result into sha1 */
-static int diff_get_patch_id(struct diff_options *options, unsigned char
*sha1)
+static int diff_get_patch_id(unsigned char *sha1)
{
struct diff_queue_struct *q = &diff_queued_diff;
int i;
@@ -2540,7 +2540,7 @@ int diff_flush_patch_id(struct diff_opti
{
struct diff_queue_struct *q = &diff_queued_diff;
int i;
- int result = diff_get_patch_id(options, sha1);
+ int result = diff_get_patch_id(sha1);
for (i = 0; i < q->nr; i++)
diff_free_filepair(q->queue[i]);
@@ -2794,8 +2794,7 @@ void diff_change(struct diff_options *op
diff_queue(&diff_queued_diff, one, two);
}
-void diff_unmerge(struct diff_options *options,
- const char *path)
+void diff_unmerge(const char *path)
{
struct diff_filespec *one, *two;
one = alloc_filespec(path);
diff --git a/diff.h b/diff.h
index b48c991..65a14e6 100644
--- a/diff.h
+++ b/diff.h
@@ -138,8 +138,7 @@ extern void diff_change(struct diff_opti
const unsigned char *sha2,
const char *base, const char *path);
-extern void diff_unmerge(struct diff_options *,
- const char *path);
+extern void diff_unmerge(const char *path);
extern int diff_scoreopt_parse(const char *opt);
--
1.4.3.3
^ permalink raw reply related
* Re: gitk feature request..
From: Petr Baudis @ 2006-11-11 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Pierre Marc Dumuid
In-Reply-To: <7vslgu28do.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 07, 2006 at 11:34:59PM CET, Junio C Hamano wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > Good idea. Junio, is there a canonical place under .git where gitk
> > should put such things?
>
> Well, we do not design things in advance but tend to let things
> evolve, which probably is a bad habit but I am not sure how else
> we can avoid overdesigning before knowing the needs.
>
> The existing state-keeping programs seem to keep their stuff
> immediately under $GIT_DIR. Examples are:
>
> .git/description (gitweb)
> .git/cvs-authors (cvsimport)
> .git/gitcvs.<branch>.sqlite (cvsserver)
>
> So, .git/gitk-<foo> (or .git/gitk/<bar>) would be in line with
> others. We _might_ want to have a standard plan to keep
> Porcelains stepping on each other's toes, and probably migrating
> everybody to .git/aux/{common,gitcvs,gitk,...}/<foo> would be a
> sane thing to do. description and cvs-authors could probably be
> shared across Porcelains, so I do not think we mind leaving them
> in the current place or throw them in .git/aux/common/
I think the porcelains tend to use pretty specific names for their stuff
and a risk of conflict is pretty small, so I don't think it's worth the
compatibility problems. Also, over time it's bound that qgit will
something like start to peek and poke at some gitk stuff and learn about
CVS imports so it'll peek at gitcvs as well, etc., so I'm not sure if
the net benefit would really be that large or rather give the porcelains
a false illusion of safety and privacy.
Except for cg-merge which is quite a pig when it comes to its state and
.git files; I guess it should use a .git/cg-merge-state/ directory
instead. And the hooks space where cg sort of hoped that git would reuse
its hooks names but it didn't play out.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Randal L. Schwartz @ 2006-11-11 16:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ej4teo$bjo$1@sea.gmane.org>
This is all great. Thank you. And I hope to have a presentation
worthy of placing on that page within a week.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Jakub Narebski @ 2006-11-11 16:24 UTC (permalink / raw)
To: git
In-Reply-To: <20061111143304.GA7201@pasky.or.cz>
Petr Baudis wrote:
> and http://git.or.cz/gitwiki/GitLinks for links to plenty
> of "using git" pages for various projects and other introductory
> articles.
GitLinks has now links to junio, jdl and pasky slides from OLS,
and junio slides from OSDL Japan Linux Symposium.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* LDFLAGS ignored from the environment
From: Serge van den Boom @ 2006-11-11 15:33 UTC (permalink / raw)
To: git
GIT's configure ignores LDFLAGS in the environment.
To solve the issue, add
LDFLAGS = @LDFLAGS@
to config.mak.in
^ permalink raw reply
* Re: gitk feature request..
From: Jakub Narebski @ 2006-11-11 15:20 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550611110708r1ad9559ewf35b8abaceb21cc4@mail.gmail.com>
Marco Costalba wrote:
> Regarding the local / private views problem, perhaps we could use a
> local, i.e. out of .git directory, config file that _extends_ and
> _overrides_ the repository config file.
~/.gitconfig ? Since quite a bit of time, undocumented.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitk feature request..
From: Marco Costalba @ 2006-11-11 15:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Pierre Marc Dumuid
In-Reply-To: <7vslgu28do.fsf@assigned-by-dhcp.cox.net>
On 11/7/06, Junio C Hamano <junkio@cox.net> wrote:
>
> Having said that, is the gitk view supposed to be shared across
> users of a single repository?
>
Perhaps I misunderstand, but aren't gitk views a command line
arguments set for git-rev-list?
Couldn't be defined as aliases and stored in .git/config? so to be
used also with other git commands, as example git log...and of course
other GUI tools ;-).
If I understand correctly the git documentation, aliases store both
the git command and the argument list. Perhaps for views the command
could be git-rev-parse.
Regarding the local / private views problem, perhaps we could use a
local, i.e. out of .git directory, config file that _extends_ and
_overrides_ the repository config file.
What I mean is that an alias, or also, in general, a config variable
could be searched by git, first in the local file, then if not found
in the .git/config file.
Of course the problem of per-repository _and_ private views stay open
(we could use sub-sections identified by repo path in private .config
file???) but I think this is a more general and porcelain agnostic
approach and could be better reused and extended.
^ permalink raw reply
* Re: Author name and e-mail address in .stgitrc
From: Karl Hasselström @ 2006-11-11 14:57 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Catalin Marinas, git
In-Reply-To: <200611111531.16304.robin.rosenberg.lists@dewire.com>
On 2006-11-11 15:31:15 +0100, Robin Rosenberg wrote:
> lördag 11 november 2006 15:15 skrev Karl Hasselström:
>
> > Is there any particular reason to have the author and committer
> > names in ~/.stgitrc? Simply taking them from the same place git
> > does would probably be a usability enhancement (unless they're
> > specified on the command line, of course).
>
> AFAIK StGit already does that, at least if you (like me) do not have
> a .stgitrc.
But I haven't gotten the impression that specifying them in ~/.stgitrc
is deprecated. The example stgitrc has a section with author name and
committer name, for example.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Double From:s in StGIT's patch email template
From: Karl Hasselström @ 2006-11-11 14:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061111113553.GA11224@diana.vm.bytemark.co.uk>
On 2006-11-11 12:35:53 +0100, Karl Hasselström wrote:
> StGIT's default patch email template has both "From: %(maintainer)s"
> in the e-mail header, and "From: %(authname)s <%(authemail)s>" in
> the e-mail body. Why?
Ah, I just figured it out. "maintainer" is the person sending the
mail, and "author" is the person who wrote the patch. In general, they
are not the same.
Hmm. It would be nice to omit the second From: in case they really are
the same.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Petr Baudis @ 2006-11-11 14:33 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <8664dmxdrf.fsf@blue.stonehenge.com>
Hi,
On Sat, Nov 11, 2006 at 03:24:20PM CET, Randal L. Schwartz wrote:
> Apparently, in a fit of confusion, I agreed to present a 60-minute "intro to
> git" for the Portland (Oregon) Linux Advanced Topics meeting on 20 November.
>
> Since I haven't even started it, I guess it's time to start writing. I know
> about the Documentation/* directory, but have any of you also written
> tutorials or presentations on git for your organization? If so, I'd like to
> steal, I mean observe what you've done. I will make my slides available as
> well, under the GFDL or equivalent.
see
http://news.gmane.org/find-root.php?message_id=<7vvepqi6x6.fsf@assigned-by-dhcp.cox.net>
and replies for some slides from OLS (dunno if jdl's made his
available?), and http://git.or.cz/gitwiki/GitLinks for links to plenty
of "using git" pages for various projects and other introductory
articles. There are also few crash courses at git.or.cz but they go by
the Cogito path; the general outline just with different commands might
be still somewhat useful, though. Also, someone from #git was presenting
lately and is planning on making his presentation available, too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Author name and e-mail address in .stgitrc
From: Robin Rosenberg @ 2006-11-11 14:31 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20061111141530.GF11224@diana.vm.bytemark.co.uk>
lördag 11 november 2006 15:15 skrev Karl Hasselström:
> Is there any particular reason to have the author and committer names
> in ~/.stgitrc? Simply taking them from the same place git does would
> probably be a usability enhancement (unless they're specified on the
> command line, of course).
AFAIK StGit already does that, at least if you (like me) do not have
a .stgitrc.
^ permalink raw reply
* information for a 60-minute "intro to git" needed
From: Randal L. Schwartz @ 2006-11-11 14:24 UTC (permalink / raw)
To: git
Apparently, in a fit of confusion, I agreed to present a 60-minute "intro to
git" for the Portland (Oregon) Linux Advanced Topics meeting on 20 November.
Since I haven't even started it, I guess it's time to start writing. I know
about the Documentation/* directory, but have any of you also written
tutorials or presentations on git for your organization? If so, I'd like to
steal, I mean observe what you've done. I will make my slides available as
well, under the GFDL or equivalent.
And Linus, if you're in town on the 20th, you should come to the meeting to
make a fool of me and give the real scoop. :) (Only half joking... if you
could make it there, it'd be a real help to me.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Author name and e-mail address in .stgitrc
From: Karl Hasselström @ 2006-11-11 14:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061111113553.GA11224@diana.vm.bytemark.co.uk>
Is there any particular reason to have the author and committer names
in ~/.stgitrc? Simply taking them from the same place git does would
probably be a usability enhancement (unless they're specified on the
command line, of course).
--
Karl Hasselström, kha@treskal.com
^ 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