git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).