Guess I found my issue (and I start to get a grab on it as well).
My pull which resulted in the rebase was fine (it shows the conflicts that can be solved with the merge tool). BTW you can either choose the rebase or merge as an option for such conflicts (lots of Google reading about pro/contra).
While I found that I needed to add the source again to the index (mark it as resolved) I missed the "rebase --continue".
If you forget this step the rebase is not completed... so after the add to index use a rebase continue (which is hidden on the Git staging view).
Once this is done your master is clean again and you can push the changes upstream.
What helped me in understanding this was first of all
http://eclipsesource.com/blogs/tutorials/eclipse-git-tutorial-a-rebase-workflow-with-egit/ however it doesn't talk about the rebase continue (which is something that I got from someone else).
BTW regarding your other remarks... guess having a 1-to-1 mapping with a repository and a IBM i Project is mandatory. This project will then contain all sources (RPG, service programs, CL, DDS, ...) of a single library (I don't see you a single repository can hold sources from multiple libraries). This opens other questions like how to deal with having multiple source libraries (ex. customer specific versions).
________________________________________
From: WDSCI-L [wdsci-l-bounces@xxxxxxxxxxxx] on behalf of Wilson, Jonathan [piercing_male@xxxxxxxxxxx]
Sent: Tuesday, August 04, 2015 17:54
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Subject: Re: [WDSCI-L] EDi 9.1 and eGit
On Tue, 2015-08-04 at 14:11 +0000, Paul Nicolay wrote:
Unfortunately I've seen only comments of people that use it in a single user mode.
Here's how I would do it in command line git, which eGit calls. It has 1
basic assumption that is very important...
A central repository exists, you are not working on a clone of someone
else’s local repository within their working directory (1).
Two people start work, they both clone from the central repository. This
central repository at some point was created with "git --bare init" (or
on github for example, which does a bare init. A bare repository, even
if it now contains files, does not live within a "working
directory" (a .git directory inside the projects folder (3)) some git
commands fail to work when issued within a repository folder) It may, or
not, have files in it. Convention is to name a bare repository directory
with .git in the name (/MyCentralRepo.git/)
Person one:
change, commit, change, commit, change, commit. (2) (what is changed can
be one or many files, with one commit done when happy with the current
set of changes)
Person two also does the same...
Person one pushes the multiple commits, up they go to the central
repository - no problem.
Person two carries on:
change, commit, change, commit, change, commit.
Person two tries to push, push fails.
Person two gets a copy of the current state of the central repository,
and rebases (I'm sure thats the term) all his commits. He still has the
same number of commits and they are still not pushed.
Now he pushes the rebased commits, up they go no problem.
One possible reason for manual intervention might be that if two people
start work on a totally new blank file with the same name. Should the
files be merged? Which set of new code should come before the other,
should all the new code from both files be interspersed, or should one
set of changes be dropped or moved to another uniquely named file. As
this resolution is done at the commit where the problem was first
noticed, what ever resolution was chosen will now (should) be reflected
in all subsequent commits.
(1) It is possible to create a clone of a repository (.git directory) in
someones working directory, although there is nothing preventing this
and git will still work it is not advised - strongly.
(2) Small changes, commit often, push once. eg:
Fix spelling, commit. Amend procedure interface include file, commit.
Amend stock calculation - test, commit. Change procedure interface file
to fix mistake, commit. Amend price calculation - test, commit... push.
(3) I don't know how eGit stores its repository. On my setup I have 3
projects, but the .git lives outside these projects. My setup is very
different to the standard way of projects being self contained, because
PC projects relate multiple files but on the "400" often source is
stored in a large multi-member file but copied into a smaller projects
to be worked on... eg. Project 1 is changing the customer maint program
and just that programs source would be moved to a working library...
If I were to do it all over again, and assuming wdsc could do it I would
probably have just created one project and then used views to limit the
number of programs listed into sub groups such as "Program I'm working
on", "SERVPGMs" etc. But I wanted my "project" to be broken into smaller
units and at the time the only way I could see of doing that (both git
and wdsc) was to have multiple github "projects" or one stonking big
project. Even branches wouldn't have worked as even though I wanted my
"big project" broken down, swapping between branches would have meant I
couldn't work on multiple branches at the same time (I'm writing service
programs in the project service programs, while also writing the
programs that will use them in the programs project, and my data file
sources reside in the data project, just like how I would do it on the
i :-/ multiple screens and multiple things worked on at once).
midrange.com
