git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Joel Becker <Joel.Becker@oracle.com>
Cc: Martin Langhoff <martin.langhoff@gmail.com>,
	Linus Torvalds <torvalds@osdl.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	walt <wa1ter@myrealbox.com>,
	git@vger.kernel.org
Subject: Re: git versus CVS (versus bk)
Date: Tue, 1 Nov 2005 18:35:02 +0100	[thread overview]
Message-ID: <20051101173502.GA16528@pasky.or.cz> (raw)
In-Reply-To: <20051101161730.GV11488@ca-server1.us.oracle.com>

Dear diary, on Tue, Nov 01, 2005 at 05:17:30PM CET, I got a letter
where Joel Becker <Joel.Becker@oracle.com> told me that...
> On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:
> > Personally, from my POV it is the intended mode of development only if
> > you keep strictly topical branches (a single logical change and fixes of
> > it on top of that). Otherwise, this is horrid because it loses the
> > _precious_ history and bundles us different changes to a single commit,
> > which is one of the thing that are wrong on CVS/SVN merging.
> 
> 	Here we have the "precious" history vs the "throwaway" history
> argument again.  You are correct, this does look like CVS/Subversion
> merging.  But I'm quite capable of keeping my patches single-topic.
> Anything that requires multiple patches in a logical separation still
> needs that extra love.

Well, ok, so I assume you are indeed using strictly topical branches.
.

> > That said, with a big warning, I would be willing to do something like
> > cg-merge -s and cg-update -s (s as squash), with a big warning that this
> 
> 	Wouldn't it be cg-pull?  I guess I'm not conversant enough of
> all ways to merge branches in cogito.

cg-pull just fetches stuff, no merging done.

Ok, in theory you do not actually need to fetch the intermediate history
in case you are going to squash (unless you are going to default the
final commit message to concatenation of the intermediate ones), but
arranging that would not be easy to arrange with the current git tools,
I think. And neither feasible. But actually, I would like to do
something like this later, support for CVS/SVN-like tracking by always
having only the latest tree and no intermediate states, so that people
who just want to run the latest and want to do no development are not
forced to download anything useless for them.

> > is suitable only for topical branches. And I think it'd be still much
> > better to spend the work making StGIT able to track history of changes
> > to a particular patch.
> 
> 	I like quilt for certain work, and what I read from you and
> Caitlin makes me interested in StGIT for those large changes that
> require split-out patches.  But for simple tasks, I just want to use the
> SCM, you know?

Well, if you are already going to deform the history, StGIT (able to
track patch history) is just the best tool for that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

  reply	other threads:[~2005-11-01 17:35 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-31  1:50 git versus CVS (versus bk) walt
2005-10-31  1:59 ` Martin Langhoff
2005-10-31  2:03 ` H. Peter Anvin
2005-10-31  2:35 ` Linus Torvalds
2005-10-31 10:24   ` Johannes Schindelin
2005-10-31 16:18     ` Linus Torvalds
2005-10-31 18:18       ` wa1ter
2005-10-31 19:44         ` Randal L. Schwartz
2005-10-31 23:41           ` walt
2005-11-01  0:15           ` Daniel Barkalow
2005-11-01  0:21             ` Linus Torvalds
2005-10-31 19:50       ` Joel Becker
2005-10-31 20:28         ` Martin Langhoff
2005-10-31 21:30           ` Joel Becker
2005-11-01  9:15             ` Petr Baudis
2005-11-01 16:17               ` Joel Becker
2005-11-01 17:35                 ` Petr Baudis [this message]
2005-11-07 22:56               ` Petr Baudis
2005-11-08 10:50                 ` Josef Weidendorfer
2005-11-08 12:04                   ` Petr Baudis
2005-11-01  2:17           ` Randal L. Schwartz
2005-11-01  2:23             ` Linus Torvalds
2005-11-01  2:34               ` Randal L. Schwartz
2005-11-01  2:47                 ` Linus Torvalds
2005-11-01  2:35               ` Junio C Hamano
2005-11-01 23:56           ` Horst von Brand
2005-11-02  8:54             ` Andreas Ericsson
2005-11-02  9:26               ` Junio C Hamano
2005-10-31 21:00         ` Junio C Hamano
2005-10-31 21:36           ` Joel Becker
2005-10-31 21:53             ` Linus Torvalds
2005-10-31 22:14             ` Junio C Hamano
2005-10-31 22:42               ` Joel Becker
2005-11-01  0:20                 ` Junio C Hamano
2005-11-01  0:42                   ` Joel Becker
2005-11-01  1:02                     ` Martin Langhoff
2005-11-01  1:29                       ` Joel Becker
2005-11-01  1:48                         ` Linus Torvalds
2005-11-01  9:17                         ` Petr Baudis
2005-11-01 13:25                       ` Catalin Marinas
2005-11-01  0:25                 ` Theodore Ts'o
2005-11-01  9:08                   ` hgmq vs. StGIT Petr Baudis
2005-11-01  9:23                     ` Catalin Marinas
2005-11-01 10:10                       ` Petr Baudis
2005-11-01 17:34                         ` Catalin Marinas
2005-11-01 15:20                       ` Chuck Lever
2005-11-01 15:36                         ` Chris Mason
2005-11-01 17:18                           ` Catalin Marinas
2005-11-01 18:13                             ` Chris Mason
2005-11-01 21:30                               ` Catalin Marinas
2005-11-02 15:41                                 ` Chris Mason
2005-11-05 20:23                                   ` Catalin Marinas
2005-11-09 23:32                                     ` Petr Baudis
2005-11-10  0:08                                       ` Pavel Machek
2005-11-10 16:20                                       ` Catalin Marinas
2005-11-01 14:11                     ` Chris Mason
2005-11-01 16:00                       ` Linus Torvalds
2005-11-01 17:13                         ` Catalin Marinas
2005-11-01 17:29                       ` Catalin Marinas
2005-11-01 17:59                         ` Chris Mason
2005-11-01 21:22                           ` Catalin Marinas
2005-11-01  0:31                 ` git versus CVS (versus bk) Daniel Barkalow
2005-10-31 21:35         ` Linus Torvalds
2005-10-31 13:00   ` wa1ter

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051101173502.GA16528@pasky.or.cz \
    --to=pasky@suse.cz \
    --cc=Joel.Becker@oracle.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=martin.langhoff@gmail.com \
    --cc=torvalds@osdl.org \
    --cc=wa1ter@myrealbox.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).