On 9 April 2013 18:01, Jeff King wrote:
> On Tue, Apr 09, 2013 at 08:03:24AM +0200, Johannes Sixt wrote:
>> If A mentions B (think of cherry-pick -x), then you must ensure that the
>> branch containing B was traversed first.
>
> Yeah, you're right. Multiple passes are necessary to get it
> complet
On Tue, Apr 09, 2013 at 08:03:24AM +0200, Johannes Sixt wrote:
> Am 4/8/2013 23:54, schrieb Jeff King:
> > Yeah, it would make sense for filter-branch to have a "--map-commit-ids"
> > option or similar that does the update. At first I thought it might take
> > two passes, but I don't think it is n
Am 4/8/2013 23:54, schrieb Jeff King:
> Yeah, it would make sense for filter-branch to have a "--map-commit-ids"
> option or similar that does the update. At first I thought it might take
> two passes, but I don't think it is necessary, as long as we traverse
> the commits topologically (i.e., you
On Mon, Apr 08, 2013 at 08:40:36AM -0700, Junio C Hamano wrote:
> With or without the security issue, leaving old object names that
> will become irrelevant in the rewritten history will make the
> resulting history less useful, simply because people cannot look at
> the objects these messages ref
Roberto Tyley writes:
> Here's an unmodified repo, in which the user unwisely committed a
> database password:
>
> https://github.com/bfg-repo-cleaner-demos/gma-demo-repo-original/commit/8c9cfe3c
>
> The unwise commit is reverted with a second commit using 'git revert',
> which obviously leaves t
This is a demonstration of a mildly-interesting security concern
relating to Git & git-filter-branch - not a vulnerability in Git
itself, just in the way it can be used. I thought it was interesting
to demonstrate that there is sometimes an avenue of attack for
recovering sensitive data that's been
6 matches
Mail list logo
