From: Chuck Lever <cel@citi.umich.edu>
To: Petr Baudis <pasky@suse.cz>
Cc: Catalin Marinas <catalin.marinas@gmail.com>,
Martin Langhoff <martin.langhoff@gmail.com>,
Junio C Hamano <junkio@cox.net>,
Ryan Anderson <ryan@michonline.com>,
Linus Torvalds <torvalds@osdl.org>,
git@vger.kernel.org
Subject: Re: [PATCH] GIT commit statistics.
Date: Tue, 15 Nov 2005 10:29:37 -0500 [thread overview]
Message-ID: <4379FEE1.9080407@citi.umich.edu> (raw)
In-Reply-To: <b0943d9e0511150204h25417993l@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
Catalin Marinas wrote:
> On 12/11/05, Petr Baudis <pasky@suse.cz> wrote:
>
>>On the same note, I would like StGIT to drop functionality not really
>>belonging to patch stack manager (stg add, stg rm, stg status, ...) so
>>that its commandset gets smaller and more focused
>
>
> This was the case with the first StGIT implementations but I slowly
> began to want to only use StGIT and not switch to something else for
> trivial SCM operations. I eventually added 'stg commit' which stores
> the patches permanently into the base of the stack to enable some kind
> of maintainer mode for StGIT. My main use for this was to import
> patches directly into the main branch and not keep a separate one and
> pull between them.
...
> Anyway, while I'll try not to add more SCM functionality to StGIT, I
> don't think I should remove the existing add/rm/status functionality.
> It's just handy not to use a different command when you want a new
> file added to a patch.
petr,
currently it isn't recommended to use StGIT with other porcelains.
so either: make it completely safe to use StGIT with other porcelains,
or add a minimal amount of SCM-like functionality so users don't miss it
and try to use other porcelains and trash their repositories.
overall i agree with catalin-- it's just easier to use a single tool.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
next prev parent reply other threads:[~2005-11-15 15:30 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-07 16:48 Comments on recursive merge Linus Torvalds
2005-11-07 16:56 ` Linus Torvalds
2005-11-07 23:19 ` [PATCH] merge-recursive: Only print relevant rename messages Fredrik Kuivinen
2005-11-07 23:54 ` Junio C Hamano
2005-11-09 10:36 ` Fredrik Kuivinen
2005-11-07 22:58 ` Comments on recursive merge Fredrik Kuivinen
2005-11-08 0:13 ` Junio C Hamano
2005-11-08 0:33 ` Linus Torvalds
2005-11-08 0:59 ` Junio C Hamano
2005-11-08 11:58 ` Johannes Schindelin
2005-11-08 21:02 ` Fredrik Kuivinen
2005-11-08 21:47 ` Junio C Hamano
2005-11-08 21:52 ` Linus Torvalds
2005-11-08 22:36 ` Fredrik Kuivinen
2005-11-08 23:05 ` Linus Torvalds
2005-11-08 23:18 ` Johannes Schindelin
2005-11-09 0:18 ` Linus Torvalds
2005-11-09 6:10 ` Junio C Hamano
2005-11-09 0:32 ` Petr Baudis
2005-11-09 0:51 ` Linus Torvalds
2005-11-09 0:59 ` Junio C Hamano
2005-11-09 1:22 ` Linus Torvalds
2005-11-09 1:42 ` Junio C Hamano
2005-11-09 10:20 ` Junio C Hamano
2005-11-09 14:59 ` Petr Baudis
2005-11-09 16:30 ` Linus Torvalds
2005-11-09 20:13 ` Junio C Hamano
2005-11-09 21:58 ` Linus Torvalds
2005-11-09 22:56 ` Junio C Hamano
2005-11-09 23:34 ` Linus Torvalds
2005-11-11 2:58 ` merge-base: fully contaminate the well Junio C Hamano
2005-11-11 5:36 ` Linus Torvalds
2005-11-11 6:04 ` Junio C Hamano
2005-11-11 16:18 ` Linus Torvalds
2005-11-11 8:28 ` Junio C Hamano
2005-11-08 23:04 ` Comments on recursive merge Johannes Schindelin
2005-11-08 16:21 ` [RFC/PATCH] Make git-recursive the default strategy for git-pull Junio C Hamano
2005-11-11 22:25 ` Comments on recursive merge Junio C Hamano
2005-11-11 22:53 ` Linus Torvalds
2005-11-12 0:42 ` Junio C Hamano
2005-11-12 6:35 ` Ryan Anderson
2005-11-12 7:44 ` [PATCH] GIT commit statistics Junio C Hamano
2005-11-12 12:19 ` Martin Langhoff
2005-11-12 12:53 ` Petr Baudis
2005-11-15 10:04 ` Catalin Marinas
2005-11-15 15:29 ` Chuck Lever [this message]
2005-11-12 19:04 ` Johannes Schindelin
2005-11-13 10:59 ` Junio C Hamano
2005-11-13 20:42 ` Martin Langhoff
2005-11-14 3:33 ` Junio C Hamano
2005-11-14 4:01 ` Martin Langhoff
2005-11-14 6:06 ` Junio C Hamano
2005-11-14 8:51 ` Martin Langhoff
2005-11-14 9:25 ` Petr Baudis
2005-11-14 21:25 ` Martin Langhoff
2005-11-14 9:27 ` Junio C Hamano
2005-11-15 3:00 ` Junio C Hamano
2005-11-13 11:11 ` Petr Baudis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4379FEE1.9080407@citi.umich.edu \
--to=cel@citi.umich.edu \
--cc=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=martin.langhoff@gmail.com \
--cc=pasky@suse.cz \
--cc=ryan@michonline.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).