The fact that I'm mimicking two developers shouldn't make any difference to two actual developers.
No problem in forgetting branches... would love to at this stage (I don't argue that they have their use later on) but the problem is that I can't find a proper procedure with eGit that gives the disered result, not even with non-conflicting changes (ie. changes to different source members).
Al the rest is theory that I've read plenty of times in the mean while... but no one seems to be capable of providing real steps on how to accomplish this in Rational with the eGit plugin. Someone who effectively uses this combination should be able to step out of this theoretic approach.
Unfortunately I've seen only comments of people that use it in a single user mode.
________________________________________
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
midrange.com
