From: Catalin Marinas <catalin.marinas@gmail.com>
To: Petr Baudis <pasky@suse.cz>
Cc: 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:04:32 +0000 [thread overview]
Message-ID: <b0943d9e0511150204h25417993l@mail.gmail.com> (raw)
In-Reply-To: <20051112125331.GB30496@pasky.or.cz>
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.
> - but before I would
> suggest dropping stg status, cg-status must be able to do conflicts
> tracking, so I will dedicate another mail to this sometime in the
> future, with a more detailed proposal.
The gitmergeonefile.py script in StGIT adds every conflict to the
.git/conflicts file which is read by 'stg status'. My goal is not to
leave any unmerged entried in the index even if there are conflicts.
Maybe this could be changed and .git/conflicts file avoided entirely.
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.
--
Catalin
next prev parent reply other threads:[~2005-11-15 10:04 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 [this message]
2005-11-15 15:29 ` Chuck Lever
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=b0943d9e0511150204h25417993l@mail.gmail.com \
--to=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).