Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 18 Apr 2015 14:17:32 +0300
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: Shinnok <admin@...nnok.com>
Cc: john-dev@...ts.openwall.com, Solar Designer <solar@...nwall.com>,
	Mathieu Laprise <mathlaprise@...il.com>
Subject: Re: Johnny repo

Hi Shinnok,

On Sat, Apr 18, 2015 at 12:45:22PM +0300, Shinnok wrote:
> 
> > On Apr 16, 2015, at 9:43 PM, Aleksey Cherepanov <aleksey.4erepanov@...il.com> wrote:
> > 
> > Hi Shinnok,
> > 
> > I moved that to john-dev.
> > 
> > On Thu, Apr 16, 2015 at 06:09:42PM +0300, Shinnok wrote:
> >> Hey Aleksey,
> >> 
> >> As previously mentioned, I messed up my repo by doing git pulls from your repo outside of Github's pull request policy. How I define messed up is that all your commits ended up with different hashes in my repo.
> >> 
> >> The choices are:
> >> 1. Reinit my repo with your repo, thus rewrite my Github repo history.
> >> 2. Kindly request Mathieu to rebase the translation feature branch on your repo and make a pull request to you.
> >> 
> >> Aleksey, are you satisfied with the idea of maintaining main repo ownership and having to do all the merges and such? If so then I'll happily purge my repo and start doing pull requests for yours. I think I already said that I'll be doing that, but I'd like to make this crystal clear, now that we have a third contributor.
> > 
> > As of you're going to be the main mentor (right?) during gsoc, I think
> > it will be more convenient if you maintain the main repo.
> > 
> > Also to have one set of hashes should be better. To consider who own
> > the repo to rebase, we to estimate work in third party projects. At
> > the moment, my repo is more likely to be used by others. So to reinit
> > repo and to rebase may be useful. Though usefulness should not be very
> > big, so I'd look at this as at an exercise in git-fu.
> > 
> > I hope there will not be users that will be hit by changing the main
> > repo because johnny never supported workflow with doing just `git
> > pull` in your local repo.
> > 
> > So you clean out your wrong commits, pull appropriately (do you need a
> > pull request from me to accomplish that?), then Mathieu rebases his
> > work on your repo and pull into your repo. Ok?
> > 
> 
> I resolved my repo, it turned out to be quite easy. I reset my head
> to your previous commitment timeframe, rewritten the remote history
> with push --force. Then I was able to create a pull request from
> within Github for your repo:master to mine and merge it back into
> mine(a one man show). I wasn't aware that you could do that from
> Github. Now our repos are fully in sync, with the same master
> history. I also added the few new commits I already had on top.

Ok. Mathieu will need to rebase his changes on that before merge into
your repo, otherwise your repo will have new and old commits at the
same time.

> I'm going to refrain from porting your branches/tags to my repo in
> order to avoid confusion for peers. I'll only tag newer versions as
> they become available.

I'd port tags. While branches are kept for convenience of users that
may use old information, tags are informative.

> In conclusion, at least until otherwise noted, my repo becomes the
> main development one starting with this e-mail, thus we can start
> integrating and collaborating using the usual Github practices.
> 
> https://github.com/shinnok/johnny

Ok. You may edit the wiki to list that newer changes will be in your
repo.

Thanks!

-- 
Regards,
Aleksey Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ