I see we're talking past each other on some points and are in violent
agreement on others, probably because the discussion overheated.
On Tue, Mar 2, 2010 at 11:20 AM, John Denker <j...@av8n.com> wrote:
> On 03/02/2010 01:08 AM, Tim Moore wrote:
>
> > Furthermore, I can't parse the "suspend development" comment. It is
> coming
> > from some alternate reality of git usage.
>
> We are definitely talking about two different realities.
>
> > First off, I did identify the
> > commit id where you made changes to use getline: d5e6aa6235f7.
>
> That's a commit to the "FG source tree". Until that hex
> number was mentioned, I thought we were talking about the
> code over in the simgear tree.
>
Sorry, I thought I made that clear when I said:
> I'm looking at io/sg_file.cxx in the sport branch. I see the old
> implementation of readline inside an
> "execrable_readline" #ifdef. I don't see any other implementation of
> readline.
>
> I.e., I've checkout out the sport branch of simgear and have looked at your
changes there.
> Perhaps my question would go away if I fetched your sport flightgear repo
> too; since I don't have a commit id for the patch where you presumably
> changed "readline" to "getline", I haven't. But it seems to me that you
> could easily implement the old "execrable" readline interface in terms of
> your spiffy getline and save yourself the trouble of changing "readline"
> calls to "getline."
I.e., I'm now looking for where you replaced uses of "readline" with
"getline." I thought it was clear that I was looking in the flightgear repo.
This process isn't made any easier by having separate flightgear and simgear
repositories, and unfortunately that's not going to change anytime soon.
>
> > There aren't
> > any more yet. You could have just told me that!
>
> You could have asked!
>
> If "not any more yet" is the answer, I still don't know
> what the question is (or was).
>
> > At the start of this very thread
> > you sent us the commit id of a change you wished to share and have
> committed
> > to the sources. In the specific case of getline changes to flightgear,
> you
> > have so far only made one commit which uses getline. How hard is it to
> send
> > us that?
>
> It's not hard. If you want me to send it, all you have to
> do is ask. But I'm pretty sure that's not what you want ...
> and I still don't know what you do want.
>
It is what I wanted, but I have it now :)
>
> I don't routinely send patches to this list, for multiple
> reasons. One reason is the fact that most list-members are
> not interested in the details. I assume anybody who wants
> the details will ask ... or look at the git-logs ... or
> whatever.
>
I think patches are completely appropriate to send to the list. If they are
in unified diff form, it is very easy to do a quick review and see if the
patch is interesting, on the right track, well written, etc. Saves me the
trouble of asking, looking in logs, etc.
>
> Another reason is the fact that at the time of the first
> announcement it is quite impossible to know what further
> developments will take place. As of today I can answer a
> specific question by saying "not any more yet" or some such,
> but it is impossible in principle to answer such questions
> in advance.
>
> You are suggesting something that should be committed in some specific
form, right?
> Also, when I am told "the code looks OK" followed by
> suggestions for further developments, it is hard for
> me to translate that into a question that could be
> answered by saying "not any more yet" or into a wish
> that could be granted by emailing a patch.
>
> I agree that my commentary was a bit vague. But it looks like that you in
fact did further work on readline/getline...
> > If you're saying that you might make several commits
> > in implementing a change and can't identify a specific commit that
> contains
> > it, then you need to reconsider how you're working in light of git
> workflow.
>
> That's not even remotely what I'm saying. I know how to
> make git branches. I grow a lot more branches than I
> push to gitorious. I suspect you do too.
>
> > I'm not going to look at the global state of your repo at a
> > point in time and tease out the changes related to some feature you'd
> like
> > merged.
>
> I understand that. Really I do.
>
> Now, it's your turn. You need to understand that I cannot
> continually rebase eleventeen different bits of work so that
> "X" is sitting on top of the tree, on the off-chance that
> somebody will want to look at "X" today ... without any way
> for me to know what "X" is.
>
Of course not! That's why I was asking for a specific commit to look at in
your sport repo. Because your sport repos are gitorious clones of the repos
I maintain, it's easy for me work with specific commits or branches, rebase
them at *my* leisure, modify them, etc. It's true that a patch becomes less
interesting as the files it affects change upstream and it requires more and
more effort to merge, but that's not a problem here. I don't care what's
going on at the head of your development branch.
If it's the case that you have made an improvement but may make further
changes to it, stick those changes in a branch. Easy for you, definitely
easier for me to look at.
>
> If you want cooperation, all you need to do is ask. For
> example, if you want me to put "X" into a special branch and
> push it somewhere, let me know what "X" is and I'll see what
> I can do.
>
Ok. Hopefully I've clarified how I like to work, especially with patches
that are in a public git repo.
Tim
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
