Re: 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).

________________________________________
From: WDSCI-L [wdsci-l-bounces@xxxxxxxxxxxx] on behalf of Wilson, Jonathan [piercing_male@xxxxxxxxxxx]
Sent: Tuesday, August 04, 2015 15:51
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Subject: Re: [WDSCI-L] EDi 9.1 and eGit

Perhaps because your test environment is not mimicking exactly "real
life". (You are trying to be three people at once.)

Forget branches for a moment, re-thinking about it thats probably more
relevant when doing major, multiple, changes to an existing program
(much more likely in a java/C++ environment where you are creating an
application consisting of hundreds of "programs"/program groups and
source files, the i is more hundreds of programs make an application...
unless you really get into creating giant application style programs
using hundreds of service programs all called by one initial, common,
program, and even then unless you have some massive build style system
that re-compiles all the programs when one change is made to one sub
program isn't really going to be an issue).

If you are creating a new program you would never get a merge conflict,
unless creating this new program required a change to an existing file.
If in the unlikely event someone had changed this file since your last
pull, rebasing your commits prior to pushing your changes centrally
would mean no conflicts as your changes would, now, be on an exact copy
of the files on the central repository, as if this conflict never
happened. (only push changes when _all_ is complete, commit often)

Likewise, if you cloned the repository (from what I can tell, either
cloning or rebasing frequently is a good idea) before you made the fix,
then the chances of a clash would be lower. If there was a clash, either
merge and commit, then push. (causing a double commit I think, 1 your
change- 2 the merge) or rebase then push (your original commit is now
changed to include the other changes, only 1 commit (or group of
commits) is then sent)

As you are prevented from pushing when a conflict arises, at least I
think you are unless you "push force", then the resolution is done
locally while the central repository remains "clean".

I'm not sure how a central repository handles things when your local
repository has done this extra commit when you merge instead of rebasing
and then push the commits. (does it actually push the invalid commit, or
only the final resolved commits? I get the feeling that your initial
rejected commit gets dropped and your merged commit(s) is the one sent?)

If invalid/conflicted commits are sent to the server then that would
mean you would end up with lots of commits on the server that if checked
out would be duff, but perhaps that then down to the user of git not to
checkout a commit (as apposed to a branch) that is "wrong" and start
working on the code as they would then have to go through the same
resolution all over again.

So I'm looking for a concrete example on how to do this with eGit as I posted recently (which BTW introduces an issue