lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080215171508.GF20826@fieldses.org>
Date:	Fri, 15 Feb 2008 12:15:08 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Benny Halevy <bhalevy@...asas.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, jeff@...zik.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linville@...driver.com
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote:
> One idea that I thought about when debating rebase vs. merge (and it's
> far far from being fully baked) is versioned commits.  The gist of it
> is that patches are assigned an hash identifier like today when they
> are first committed into the tree, but, and this is the main change:
> if they mutate, e.g. by a rebase, or even git commit --amend, their
> version is bumped up rather than SHA changed.

The SHA1 is uniquely determined by the contents of that commit--commit
and author names and times, changelog message, snapshot of the tree at
that point, and parents--hence, recursively, by the entire history
leading up to that commit.

Naming objects by their content in that way has a lot of advantages--for
example, you can sign an entire history by signing just the SHA1 of the
commit at its tip.  So you can't break that link between the names of
commits and their contents without ending up with a fundamentally
different (and probably weaker, in some sense), system.

I suspect there's an unavoidable tradeoff--if you want to be able to
reliably and efficiently determine how two branches are related, then
you can't just throw away their (possibly messy) history.  The best you
may be able to do, if you want the advantages of both rebasing and
merging, is to maintain on your own the messier meta-history as a
superset of the simpler history that you end up submitting.

--b.

> This way all versions of the commit would be accessible and addressable using
> their respective SHA *and* version. I think that this can help keep
> the tree's history in a more intuitive way (since the patches' base identifier
> won't change, just its version number), and you get a bonus of seeing each
> commit's history, who changed it, and what was the change.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ