Github?
Wael Nasreddine
wael.nasreddine at gmail.com
Thu May 8 17:13:51 PDT 2014
I understand. Maybe we should convert the current Github to a real mirror,
mirroring all the branches and tags as is and a) add .Travis.yml upstream
or b) maintain a separate fork (maybe under my own profile) for Travis
integration
Would you be willing to add Travis.yml upstream?
In any case, all what I'm trying to do is help, help you with more CI
visibility, your users with a more familiar interface and hopefully attract
more hackers. I really do appreciate all the work done, this is am amazing
project!
On Thursday, May 8, 2014 4:49:47 PM, W. Trevor King <wking at tremily.us>
wrote:
> On Thu, May 08, 2014 at 11:18:23PM +0000, Wael Nasreddine wrote:
> > Well like I said in my first email, if you guys are interested in owning
> > and maintaining the GitHub repo it is yours, besides I have not done
> > anything with the history I only added one commit which will never
> conflict
> > with upstream unless you add a .Travis.yml file :)
>
> I don't think merge conflicts are the problem here. If the GitHub
> mirror claims to be a mirror but adds an additional commit B:
>
> -o---o---o---A notmuch/master
> \
> B github/master
>
> Someone who takes the “mirror” claim at face value may use
> github/master as the base for some feature:
>
> -o---o---o---A notmuch/master
> \
> B github/master
> \
> C---o---o some-feature
>
> Now when they submit the patches to this list, they might send a patch
> series that drags in B (probably not what the some-feature author
> wanted). Alternatively, they might send a patch series starting with
> C and say “this is based on B”, and anyone who's only following the
> main repo thinks, “What is B? I don't have that commit.”.
>
> You'll also have to continuously rebase github/master to keep A on top
> of notmuch/master, which means any feature branches built on
> github/master will *also* have to be continuously rebased:
>
> -o---o---o---A---D notmuch/master
> \
> A' github/master
> \
> B'---o---o some-feature
>
> Keeping a fork with commits that aren't upstream is fine, and
> maintaining a fork with an additional .Travis.yml file will probably
> be pretty easy, but calling that fork a mirror is going to cause
> needless confusion.
>
> Cheers,
> Trevor
>
> --
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/89808ba7/attachment.html>
More information about the notmuch
mailing list