On Tue, 2015-08-04 at 11:51 +0000, Paul Nicolay wrote:
But it doesn't even answer the most basic question... why should I branch for just a small fix in a program, or even for writing an additional program ? To me it feels like doing lots of useless work since the chance of conflicts is so small (but maybe that's the nature of RPG programming which is non intrusive) that a warning on a merge is more than sufficient.
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 when different members are changed by both users).
I just don't understand that something as simple as I'm trying to do causes me so many headaches :-(
________________________________________
From: WDSCI-L [wdsci-l-bounces@xxxxxxxxxxxx] on behalf of Wilson, Jonathan [piercing_male@xxxxxxxxxxx]
Sent: Tuesday, August 04, 2015 12:45
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 09:13 +0000, Paul Nicolay wrote:
I have found this site
https://git-scm.com/book/en/v2/Git-Branching-Rebasing to be really good,
nice and simple and point by point.
midrange.com
