Hi,
can you at least read the replies I wrote on the merge requests yesterday?
I wrote there among other things, that I cherry-picked many things off of your fork repository, of which
most were adding @override.
I have the impression SF implemented them in a weird, halfdone way when copying from Github.
The website probably shows 0 commits if there was any other commit on the base repository
master branch.
If you have done work locally and maybe commited something on master, but not pushed it,
the careful repair mode for the person forgetting to make a branch goes:
$ git fetch
Argl there is something new downloading (if you used pull without --rebase option you would have got an
unwanted merge by now, like I saw in your history, which you may want to ask first how to repair, possibly
using temporary branches, checkout and dangerous reset --hard).
$ gitk --all&
Then find out if there are conflicts looking through the GUI.
If yes you better mark where your work is with a branch, using
$ git checkout -b temp
Then try
$ rebase origin/master
if there are conflicts
$ rebase --abort
then ask.
Preparing a merge request goes like this:
Be on the branch with your work.
Do a fetch to check for new commits.
Then rebase or cherry-pick only what you want to include in the request onto the latest origin/master,
maybe use rebase -i for reordering, squashing, fixing up commits or commit messages.
Rename the branch something adapted from bugfix/bugname or feature/featurename or whatever the
convention of the project is.
Do a push of the branch to your fork.
Go to SF website of your fork, check the new branch is there, choose it and edit the request.
Before sending the request triple check the request has no typos and shows the correct branch,
because there is no way to edit it later for you on the incomplete sourceforge website.
Send it and check it correctly got through on project website.
I'd suggest reading a git tutorial, because it is overcomplicated and intentionally made
different than older systems like SVN which automatically rebased and only had the trunk.
Regards
wintertime
Gesendet: Dienstag, 31. März 2015 um 00:52 Uhr
Von: "Caleb Williams" <cale...@gmail.com>
An: "FreeCol Developers" <freecol-developers@lists.sourceforge.net>
Betreff: [Freecol-developers] Fwd: First Successful Merge Request completed
Von: "Caleb Williams" <cale...@gmail.com>
An: "FreeCol Developers" <freecol-developers@lists.sourceforge.net>
Betreff: [Freecol-developers] Fwd: First Successful Merge Request completed
Forward.
---------- Forwarded message ----------
From: Caleb Williams <cale...@gmail.com>
Date: Mon, Mar 30, 2015 at 5:52 PM
Subject: Re: [Freecol-developers] First Successful Merge Request completed
To: "Michael T. Pope" <mp...@computer.org>
--
From: Caleb Williams <cale...@gmail.com>
Date: Mon, Mar 30, 2015 at 5:52 PM
Subject: Re: [Freecol-developers] First Successful Merge Request completed
To: "Michael T. Pope" <mp...@computer.org>
On Mon, Mar 30, 2015 at 5:29 PM, Michael T. Pope <mp...@computer.org> wrote:
On Mon, 30 Mar 2015 14:11:20 -0500
Caleb Williams <cale...@gmail.com> wrote:
> On Mon, Mar 30, 2015 at 3:06 AM, Michael T. Pope <mp...@computer.org> wrote:
>
> > On Mon, 30 Mar 2015 01:13:32 -0500
> > Caleb Williams <cale...@gmail.com> wrote:
> > > Plus it didn't help that I misinterpreted Michael's comment on the
> > > merge request.
> >
> > I should probably clarify here (rather than on the merge request) some
> > JavaDoc practices used in FreeCol. Obviously there are two consumers of
> > JavaDoc: humans reading the code, and JavaDoc-manipulating programs. The
> > former is more important IMHO:-), but the latter can not be ignored.
> >
>
> I understand that better now. Thanks. The issue is that I cannot access the
> Merge Request discussion in any way once it's been submitted. After that,
> email is the only recourse.
This is a surprise. I have kicked your Sourceforge FreeCol permissions,
hopefully improving your access.
No change. I cannot seem to access the discussion for the Merge Request after submission.
> That is the bulk of what I'm adding, which as I understand it hurts
> nothing, but *can* help the compiler do its job.
@Override is also a helpful reminder to the programmer. Its worth adding.
Perfect. I understand that what I'm doing won't make a huge difference to the end user, but hopefully can improve some things for the programmers.
However, please do not do this:
+ * @throws java.io.IOException
This is just silencing a warning without adding anything for the
programmer. The programmer can already see "throws IOException" in the
function's signature. The same applies to "@param foo". I much prefer to
see:
@throws IOException <Simple reason why the exception is thrown>
The quality of the explanation does not have to be high. What I hope
for is for a human to have looked at it and thought about it, however
briefly.
I do try to do so, but unfortunately quite a bit of the code is over my head. Now that I've changed the NetBeans code hint settings, I don't seen Java Doc related hints at this time, so I'll have to leave that for another time (when I know more about it) or for the next person to come along.
Now, do you think you could write some documentation of the Merge Request
system? doc/developer.tex would be the standard place for it. Just about
everyone who uses it finds it confusing.
If I could figure out how to do it, I could write some thing up. My issue is getting past the fact that I'm not used to working on a command line interface to such a degree that I almost need a GUI to get me through. Git just seems to not work the way I want it to. I want it to be an interface where I can see what I've submitted and remove any extraneous bits *before* I submit the request, then once it's submitted, all the admin would see is the proper merge request that will edit the existing FreeCol code.
While I am writing, just a warning that I am about to rework a bunch of
the messages. If you have looked at FreeColMessages.properties, you can
see that it is:
1. A mess
2. Has some naming conventions that are intermittently used
I am going to add some new sections, enforce a naming convention for
.../client.panel.*, and add a fair bit of comment. I have talked to the
translatewiki people about how to minimize impact on them. Its likely to
cause a lot of small changes all over the place, so beware if you have
private trees.
The other thing I'm not happy with is that Source Forge doesn't keep up with changes automatically to the main tree. I'd like to be more automatic in the way it clones out of FreeCol and into my own private repository.
Best,
Caleb R. Williams
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
