[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120520212930.GA18721@debian>
Date: Mon, 21 May 2012 01:29:30 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: file synchronization backend for MJohn
On Sun, May 20, 2012 at 10:41:24PM +0200, Simon Marechal wrote:
> On 05/20/2012 10:14 PM, Aleksey Cherepanov wrote:
> > Looking deeply in git I found that the conflict could be easily fixed:
> > git inserts lines '<<<<<<< HEAD', '=======' and '>>>>>>> <commit_id>'
> > into file, these lines could be easily replaced by one sed call, also
> > git inserts new lines from file that are ok as is. Though I think it
> > is rather a hack but it could work and it may be hard to do it better.
> > So I will try to use it first.
>
> Automatically resolving conflicts is exactly something you should not
> do. Why not do it how it should be done ? When you can't push because
> somebody else did just before you did, you can :
> - force push, destroying everything that was pushed by others and just
> be obnoxious, or
> - pull, hope for an automatic resolution and push the merge, or
> - fetch, rebase your patch and push.
git rebase says that there is a conflict too. So in any case I should
fix conflict somewhere. And as of I want to do it automatically for
.pot file it would be better to do it on server as I said because on
client it will born race condition because there could be new changes
on the server between our rebase and push according to the third algo
(as I could imagine; though maybe git could solve that somehow?).
Right?
> I like the git approach because you can explain the reason of every
> change in the commit log and link every change to someone. It helps a
> lot for after action report.
Yes, it could also be a nice resource of statistics.
In general to look onto newly cracked password like onto patches for
.pot file seems unnatural because cracked passwords are set and do not
regard order while patches are order sensitive.
Also there is a problem with distribution: while it seems ok to have
git where humans work it seems too heavy for nodes in cluster. So we
may consider to write something small and easy in c.
Regards,
Aleksey Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
