[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 May 2012 02:16:42 +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 11:02:44PM +0200, Frank Dittrich wrote:
> On 05/20/2012 10:41 PM, 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.
> >
> > 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.
>
> Supporting "after action" reports is a definite plus.
We could use git only on the server just to make history (not using it
for file transfers).
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.
