[Edbrowse-dev] even more confused

[Edbrowse-dev] even more confused

[Karl Dahlke]

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!
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.

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.

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.
In other words, we have already set these branches up to collide in a bad way.
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

Karl Dahlke

Re: [Edbrowse-dev] even more confused

[Chris Brannon]

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

Re: [Edbrowse-dev] even more confused

[Adam Thompson]

On Tue, Dec 24, 2013 at 08:26:03AM -0800, Chris Brannon wrote:
> Karl Dahlke <eklhad@comcast.net> writes:
> Sorry for all the confusion.  I had some spare cycles this morning, and
> I wanted to start moving forward.

Same here, I've got some time for at least the next couple of weeks,
but after then I don't know.

> As an aside, in patch 4/4, we should probably use JS_H, rather than
> _JS_H.

Sorry, that was my fault not looking properly at the way we've been defining 
these so far.
Please change, or I can.

Cheers,
Adam.

Re: [Edbrowse-dev] even more confused

[Adam Thompson]

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.

Re: [Edbrowse-dev] even more confused

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Nice, I guess we *really* need to agree on a work flow.
> Preferably with some code review.

Part of the problem is that it is hard to divide up this work among three
people.  Everything affects everything else.
If we knew how to split this up into manageable independent tasks, each
of us could just pick something and work on it.
If someone has ideas, I'm all ears.

Yeah, code review can be a good thing.
So, do we require that every change needs to be reviewed and
okayed by someone before it is pushed?
I'm fine with whatever we decide here.

> 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,

We already have tags for released versions.
I'm fine with commits that won't build, I suppose.  And I doubt we'll
have very many of them.

-- Chris