"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote: > Junio C Hamano <junkio@xxxxxxx> 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. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html