Re: the opposite of .gitignore, whitelist

On Fri, Oct 26, 2018 at 01:34:53PM +, Jason Cooper wrote: > On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote: ... > > I thought this was a bug: > > > > ( > > rm -rf /tmp/git && > > git ini

Re: the opposite of .gitignore, whitelist

On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Fri, Oct 26 2018, Jeff King wrote: > > On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote: > >> On 10/25/18 1:37 AM, Junio C Hamano wrote: > >> > "lhf...@163.com" writes

git filter-branch --filter-renames ?

All, I recently needed to extract the git history of a portion of an existing repository. My initial attempts using --subdirectory-filter, subtrees, etc weren't as successful as I'd hoped. The primary reason for my failures were due to the fact that this particular source repository has seen a

Re: the opposite of .gitignore, whitelist

Hi all, On 10/25/18 1:37 AM, Junio C Hamano wrote: > "lhf...@163.com" writes: > >> I have a good idea, add a file to git that is the opposite of .gitignore..., > Do negative patterns in .gitignore file help without inventing > anything new? I did this several years ago in an attempt to track

Re: [PATCH v4] technical doc: add a design doc for hash function transition

On Tue, Oct 03, 2017 at 02:40:26PM +0900, Junio C Hamano wrote: > Jonathan Nieder writes: ... > > +Meaning of signatures > > +~ > > +The signed payload for signed commits and tags does not explicitly > > +name the hash used to identify objects. If some day

Re: [PATCH v4] technical doc: add a design doc for hash function transition

On Fri, Sep 29, 2017 at 10:34:13AM -0700, Jonathan Nieder wrote: > Junio C Hamano wrote: > > Jonathan Nieder writes: ... > > If it is a goal to eventually be able to lose SHA-1 compatibility > > metadata from the objects, then we might want to remove SHA-1 based > > signature

Re: [PATCH v4] technical doc: add a design doc for hash function transition

+Transition plan > +--- ... > +Once a critical mass of users have upgraded to a version of Git that > +can verify NewHash signatures and have converted their existing > +repositories to support verifying them, we can add support for a > +setting to generate only NewHash signatures. This is expected to be at > +least a year later. > + > +That is also a good moment to advertise the ability to convert > +repositories to use NewHash only, stripping out all SHA-1 related > +metadata. This improves performance by eliminating translation > +overhead and security by avoiding the possibility of accidentally > +relying on the safety of SHA-1. There is a caveat here regarding old signatures. Those have value and shouldn't be lost. repos needing to prove the validity of the old sha1-only signatures should counter-hash all objects, and then counter-sign the corresponding newhash version of the original sha1-only tags. Reviewed-by: Jason Cooper <ja...@lakedaemon.net> thx, Jason.

Re: RFC v3: Another proposed hash function transition plan

Hi Jonathan, On Tue, Sep 26, 2017 at 04:51:58PM -0700, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > On Tue, 26 Sep 2017, Jason Cooper wrote: > >> For my use cases, as a user of git, I have a plan to maintain provable > >> integrity of existing objects sto

Re: RFC v3: Another proposed hash function transition plan

Hi Johannes, Thanks for the response. Sorry for the delay. Had a large deadline for $dayjob. On Wed, Sep 27, 2017 at 12:11:14AM +0200, Johannes Schindelin wrote: > On Tue, 26 Sep 2017, Jason Cooper wrote: > > On Thu, Sep 14, 2017 at 08:45:35PM +0200, Johannes Schindelin wrote: > &g

Re: RFC v3: Another proposed hash function transition plan

Hi all, Sorry for late commentary... On Thu, Sep 14, 2017 at 08:45:35PM +0200, Johannes Schindelin wrote: > On Wed, 13 Sep 2017, Linus Torvalds wrote: > > On Wed, Sep 13, 2017 at 6:43 AM, demerphq wrote: > > > SHA3 however uses a completely different design where it mixes a

Re: SHA1 collisions found

Hi Junio, On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > I was thinking we would need mixed mode support for smoother > transition, but it now seems to me that the approach to stratify the > history into old and new is workable. As someone looking to deploy (and having

Re: SHA1 collisions found

Hi, On Sat, Feb 25, 2017 at 01:31:32AM +0100, ankostis wrote: > That is why I believe that some HASH (e.g. SHA-3) must be the blessed one. > All git >= 3.x.x must support at least this one (for naming and > cross-referencing between objects). I would stress caution here. SHA3 has survived the

Re: SHA1 collisions found

Hi Ian, On Fri, Feb 24, 2017 at 03:13:37PM +, Ian Jackson wrote: > Joey Hess writes ("SHA1 collisions found"): > > https://shattered.io/static/shattered.pdf > > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ > > > > IIRC someone has been working on parameterizing git's SHA1 assumptions