git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Pearce <spearce@spearce.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Junio C Hamano <junkio@cox.net>,
	Linus Torvalds <torvalds@osdl.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: A series file for git?
Date: Sun, 25 Jun 2006 20:44:26 -0400	[thread overview]
Message-ID: <20060626004426.GA7193@spearce.org> (raw)
In-Reply-To: <m1r71exww5.fsf@ebiederm.dsl.xmission.com>

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> Junio C Hamano <junkio@cox.net> writes:
[snip]
> > I am not sure about that.  What does the series file contain,
> > and what other things the meta data branch contain?  If you are
> > listing commit SHA1 in the series file, you _do_ have the risk
> > of losing things -- git-fsck-objects needs to look at such blob
> > object and consider that as the root of reachability chain; to
> > me that seems too specialized hack.
> 
> When described that way I agree.   The best I can imagine
> is to list those commits as ancestors of the current commit.
> Hmm.  Or possibly I could collect up tag objects and work
> with them.  In any case representing this in a non-hackish
> way is my goal.

I did this in pg.  It didn't work out very well as the GIT diff
tools (e.g. the diff in gitk) show the diff in a very odd way.
It did not work out as well as I had hoped.

> > I have a feeling that I really should study how well StGIT does
> > things before talking about this further.  It may suit your
> > needs perfectly.  What do you feel is lacking in StGIT that you
> > need?
> 
> What I want and what I see lacking in the git and StGit is
> the ability to record the history of editing the history
> of a branch. 
> 
> A mundane example.  It would be nice if I rebased a branch if
> I could record in some fashion what that branch was before
> I rebased it.

Use the new reflog code.  Its in 1.4.  Check the documentation for
git-update-ref for some details.  git-commit, git-rebase and git-am
should track history on a ref in the reflog.  However a reflog
won't anchor a commit into your repository and thus a prune may
remove it if no other commit/ref/tag mentions it.

-- 
Shawn.

      reply	other threads:[~2006-06-26  0:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 19:15 [PATCH 0/10] re-based and expanded tree-walker cleanup patches Linus Torvalds
2006-05-29 19:16 ` [PATCH 1/10] Make "struct tree" contain the pointer to the tree buffer Linus Torvalds
2006-05-29 19:16 ` [PATCH 2/10] Make "tree_entry" have a SHA1 instead of a union of object pointers Linus Torvalds
2006-05-29 19:17 ` [PATCH 3/10] Switch "read_tree_recursive()" over to tree-walk functionality Linus Torvalds
2006-05-29 19:18 ` [PATCH 4/10] builtin-read-tree.c: avoid tree_entry_list in prime_cache_tree_rec() Linus Torvalds
2006-05-29 19:18 ` [PATCH 5/10] Remove "tree->entries" tree-entry list from tree parser Linus Torvalds
2006-05-29 19:19 ` [PATCH 6/10] fsck-objects: avoid unnecessary tree_entry_list usage Linus Torvalds
2006-05-29 19:29   ` Linus Torvalds
2006-05-29 19:19 ` [PATCH 7/10] Remove unused "zeropad" entry from tree_list_entry Linus Torvalds
2006-05-29 19:20 ` [PATCH 8/10] Convert "mark_tree_uninteresting()" to raw tree walker Linus Torvalds
2006-05-29 19:20 ` [PATCH 9/10] Convert fetch.c: process_tree() " Linus Torvalds
2006-05-29 19:21 ` [PATCH 10/10] Remove last vestiges of generic tree_entry_list Linus Torvalds
2006-05-29 22:31 ` [PATCH 0/10] re-based and expanded tree-walker cleanup patches Junio C Hamano
2006-05-30  0:42   ` Linus Torvalds
2006-05-30  3:04     ` Junio C Hamano
2006-05-30  4:17       ` Linus Torvalds
2006-05-30  4:26         ` Junio C Hamano
2006-05-31 22:53         ` Junio C Hamano
2006-06-01  3:11           ` Shawn Pearce
2006-06-23 11:37           ` A series file for git? Eric W. Biederman
2006-06-23 21:52             ` Junio C Hamano
2006-06-24  9:01             ` Junio C Hamano
2006-06-24 17:54               ` Eric W. Biederman
2006-06-26  0:44                 ` Shawn Pearce [this message]

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=20060626004426.GA7193@spearce.org \
    --to=spearce@spearce.org \
    --cc=ebiederm@xmission.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --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).