× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Mon, 2015-08-03 at 18:57 +0000, Paul Nicolay wrote:
The whole idea of branches (both on the repository and local) and the need for them is still a bit unclear to me (Subversion was easier in that context).

In both projects (which simulate two users) I just cloned the github repository... after which I started the test scenario.

Project 1: Change source A
Project 1: Commit and push
Project 2: Change source A
Project 2: Commit and push (not allowed)
Project 2: Pull

... and here I've seen already various things (I restared several times all over).

What I would expect is the red marks for conflicts on source A but that doesn't happen (currently it does happen but I get the rebase stuff).

Yeah, thats why I think that creating a branch on which to work is the
way to go as it keeps the "older/master" branch away from your
development work.


I also have the impression that it does show up in Project Explorer but not in the I projects Navigator view ?

With my setup I have the following in the .gitignore file within the
working directory:
# The folowing works at WDSC7* however later versions may increase or
change the root directory structure.
#
# Ignoring these files means they will not be saved/restored by git so
that your current settings will not be changed.
#
# Ignore the directory .metadata in root which is used by eclipse/WDSC
to store settings (display, layout, etc.)
/.metadata/
# Ignore the RemoteSystems* directories in root (used by WDSC to store
connection and remote file details)
/RemoteSystems*/
# Ignore .settings (directory), .iseries_project_properties
(file), .project (file) only if they are one level up.
/*/.settings/
/*/.iseries_project_properties
/*/.project

This way only the data files, library (directory)/file
(directory)/member (.rpgle) files are archived to the git repository.

The files related to the running of eclipse and wdsc are all excluded,
including the project (.iseries_project_properties) files but obviously
in a known end user set up some of these files can be included.

One thing I found was a lot of the "run time" set up of wdsc (/.metadata
& /*/.settings/) is part of how the project looks and is open on screen
so is not part of "the project" as such, which also include things like
explorer/project views. But if you try and keep some of the files within
the Git repository it gets very messy with files the program
creates/re-creates/changes being pulled from underneath eclipse when
checking out older commits for review.

I'm guessing that the default for egit probably includes some of the
above which might be why the i navigator view doesn't change.

I have found that if I clone and just create empty "holding" projects
that point to the directories git is tracking then just doing a refresh,
squirly arrows, sees what is in the directories and re-builds the
outline projects explorer view.






Guess I'm gonna delete my respository once more and start all over (lost the count).


-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilson, Jonathan
Sent: maandag 3 augustus 2015 19:13
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Subject: Re: [WDSCI-L] EDi 9.1 and eGit


Reading that again, did you create a new branch on each "machine" (directory) then push the changes from "machine one, branch A"
and merge it into the master, then on "machine two" re-pull the master branch which should, in theory, merge/roll forward the changes from "master" into your "branch A". (Personally I would even call the two local "machines" branches by different names as well).

I think, but am not totally sure, that two developers creating commits to the master branch (Git clone, git checkout _master_, do stuff, commit, more stuff, commit, push - done on two "machines") becomes more complex to handle as both users are working directly on one branch (the
master) so that when you pull the now changed master you must integrate the changes into your own master path instead of just updating "the master" and its new state being reflected (applied) to all your commits.

Sorry I can't be much more help, as that's about where my knowledge runs out.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.