* Re: [Edbrowse-dev] even more confused
2013-12-24 16:13 [Edbrowse-dev] even more confused Karl Dahlke
@ 2013-12-24 16:26 ` Chris Brannon
2013-12-24 16:36 ` Adam Thompson
2013-12-24 16:31 ` Adam Thompson
1 sibling, 1 reply; 5+ messages in thread
From: Chris Brannon @ 2013-12-24 16:26 UTC (permalink / raw)
To: edbrowse-dev
Karl Dahlke <eklhad@comcast.net> writes:
> and Chris did the same thingtoo, in another branch.
I discarded my changes after I saw that yours were pushed.
Sorry for all the confusion. I had some spare cycles this morning, and
I wanted to start moving forward.
> previous rebase directory /home/eklhad/progs/edbrowse/.git/rebase-apply still exists but mbox given.
>
You should run git am --abort to clear this up. My guess is that you
ran git am at some point in the distant past and it failed, leaving that
rebase-apply directory.
So after --abort, you should be able to apply both of these.
I've done it over here, so I can push them if need be.
As an aside, in patch 4/4, we should probably use JS_H, rather than
_JS_H.
> if both those branches have zillions of changes to essentially the same lines of code,
> which is already the case for us,
No, see above. My branch incorporates your eb_bool change, rather than
my aborted one.
-- Chris
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Edbrowse-dev] even more confused
2013-12-24 16:13 [Edbrowse-dev] even more confused Karl Dahlke
2013-12-24 16:26 ` Chris Brannon
@ 2013-12-24 16:31 ` Adam Thompson
2013-12-24 17:06 ` Chris Brannon
1 sibling, 1 reply; 5+ messages in thread
From: Adam Thompson @ 2013-12-24 16:31 UTC (permalink / raw)
To: Karl Dahlke; +Cc: Edbrowse-dev
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.
^ permalink raw reply [flat|nested] 5+ messages in thread