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. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
