From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 0820177AD6 for ; Tue, 24 Dec 2013 08:32:04 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id z12so6117958wgg.27 for ; Tue, 24 Dec 2013 08:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WAzW66MwbXWUkl8ns4fEgnmTrHrGRDEGTxtpf683Chg=; b=QqLxISerXO8x74UmL534kMPPCN0EhHg+flus9lQVA1GWqc6yBlD+anWsknFSKr238g 0+Hmx/xWPH6FgpPf47fuxd1vHE198zEQB3tbgU3RToaBRCxcOXuJgPoQ+M24J1W6Z/10 8ZA126JPaflLyK+2GJmpK5BHvVEh+MYINpXarovT84yJa4hpv0JIMSgXADWPMSzTpzlv Yy0sLXuIX8Gjf4XnsM6fk9KXEp515raLIZ7CA8WxEzcTyDHeDxX/wSqnddPjD+Jsq6mM hfCpE0Xky6MXngZYi6xnPRnXTnAUDNdf0bOr/yohtkqTjJyqVdoLL7BCsI0uAhtfi2Hz jEvA== X-Received: by 10.180.86.9 with SMTP id l9mr23310629wiz.20.1387902718916; Tue, 24 Dec 2013 08:31:58 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id fu1sm36945513wib.9.2013.12.24.08.31.57 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 24 Dec 2013 08:31:58 -0800 (PST) Date: Tue, 24 Dec 2013 16:31:55 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20131224163155.GC18259@toaster.adamthompson.me.uk> References: <20131124111303.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131124111303.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] even more confused X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 16:32:05 -0000 On Tue, Dec 24, 2013 at 11:13:03AM -0500, Karl Dahlke wrote: > Ok, 2 of the 4 patches Adam sent I didn't need, cause I did the same thing, > and Chris did the same thingtoo, in another branch. > Jesus! Nice, I guess we *really* need to agree on a work flow. Preferably with some code review. > But the other two patches I need. > I tried to put in the one, to extern C the header file, > and I thought the command was > git am mail_file > but I got this response, and eb.h did not change at all. > > previous rebase directory /home/eklhad/progs/edbrowse/.git/rebase-apply still exists but mbox given. > > What????????????? > Never saw that message before! > And it's clear as mud, like most of git. Yep, which is why, when I was llooking at scm systems a few years ago to version my first major project I didn't go with git. > I could cut&paste Adam's patch out mannually and apply it, > that's not hard, but I just don't understand what is going on. > I'm glad people like git, but I think it can really confuse things, > at least it has confused me. Yep, I'm not sure how to apply a patch from email either. > > On a related note, even though I don't know much about git, > I do know about source control in general, and in general, > when you merge two branches together, as Chris is suggesting, > if both those branches have zillions of changes to essentially the same lines of code, > which is already the case for us, > the merge is probably going to be impossible. Not impossible, but seriously messy and full of conflicts. > In other words, we have already set these branches up to collide in a bad way. Agreed. > So what do we do now? > > Well I will hold these two patches in my hand, and not do anything with them, > until Chriss tells me what to do, > unless of course my git am command actually did something > with that first patch, but if it did I don't see it. > IDK For what it's worth (feel free to ignore the following), I think we basicly need to decide if we want to use branches for code review or use git tags to tag the most up-to-date released version, which can then be checked out anyway. For simplicity's sake I'd probably go with the tags approach as source code snapshots of the latest buildable release are provided, and it's already stated (I think) that the repository reflects the latest development code which, to me, doesn't always equate to buildable. I've seen both approaches used in open source projects. Chriss, as the repo maintainer, ultimately the process is up to you. I guess the best thing is to stop working on this until I get an answer. Cheers, Adam.