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