git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@gmail.com>
To: Petr Baudis <pasky@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Joel Becker <Joel.Becker@oracle.com>,
	Junio C Hamano <junkio@cox.net>,
	mason@suse.com, git@vger.kernel.org,
	Chuck Lever <cel@citi.umich.edu>
Subject: Re: hgmq vs. StGIT
Date: Tue, 1 Nov 2005 17:34:43 +0000	[thread overview]
Message-ID: <b0943d9e0511010934m8d32eb2i@mail.gmail.com> (raw)
In-Reply-To: <20051101101004.GD11618@pasky.or.cz>

On 01/11/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> > That's not too far away. Chuck Lever has a patch (and there were some
> > other discussions in the past) for tracking the history of a patch.
> > Basically, there would be another commit object, not reachable from
> > HEAD but only via an StGIT command, which would chain all the versions
> > of a patch. You would be able to view them with gitk for example.
>
> Perhaps you could emulate the topical branches - one patch == one head.
> E.g. for patch foo-bar on branch 'master', you would create head
> master/foo-bar, etc.

The patches need to be chained so a top patch would also refer to the
previously applied patches since they are its base. Anyway, I don't
like adding too many files to the refs/heads directory.

> > My main issue was whether we should store every state resulted from a
> > refresh  or use a separate command (somebody suggested 'freeze') to
> > mark the states that should be preserved in the history. Chuck's patch
> > implements the first. The drawback is that a future 'stg prune'
> > command would not be able to remove the history and some states of the
> > patch might not be useful (there are times when I do a refresh only to
> > pop the patch and modify a different one, without any logical meaning
> > for the state of the patch).
>
> I'd prefer the snapshotting being done in refresh anyway. Perhaps you
> would be asked for log message when you refresh by default, but when you
> refresh -n or something, only a temporary commit would be created and
> next refresh would mutate it instead of creating another commit.

The refresh -n should be the default and maybe just specifying an
option when you want to add a comment to that commit. But, by mutating
the temporary commit, wouldn't this mean that you lose the refresh
history?

> Anyway, "freeze" is confusing. Perhaps "snapshot" if anything...

You are right.

--
Catalin

  reply	other threads:[~2005-11-01 17:34 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
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 [this message]
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

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

  git send-email \
    --in-reply-to=b0943d9e0511010934m8d32eb2i@mail.gmail.com \
    --to=catalin.marinas@gmail.com \
    --cc=Joel.Becker@oracle.com \
    --cc=cel@citi.umich.edu \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=mason@suse.com \
    --cc=pasky@suse.cz \
    --cc=tytso@mit.edu \
    /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).