Page 1 of 1

Important: Change to recommended Typical Development Usage

PostPosted: 26 Jul 2011, 15:38
by Braids
with git (and EGit), i've discovered it's better to commit before pulling. i made changes to this section of the Getting Started document: http://www.slightlymagic.net/wiki/Forge:How_to_Get_Started_Developing_Forge#Typical_Development_Usage

Re: Important: Change to recommended Typical Development Usa

PostPosted: 02 Aug 2011, 22:04
by Braids
actually, it seems that we should Add before we Commit. i updated the section at the above url.

if we should be using Merge instead of Pull, someone please tell me where . . .

Re: Important: Change to recommended Typical Development Usa

PostPosted: 05 Aug 2011, 19:40
by Braids
i have yet another change. don't pull until you've committed or reset everything locally. in other words, there must not be any items bearing the white asterisk on charcoal square symbol.{1} otherwise you'll get a partial pull, and it's a mess to clean up without using the command line. there is a url in the Typical Development Usage section that explains why.

after committing everything, you might want to merge instead of pull. i'm not sure yet. i really am trying to figure out EGit merging. please stay tuned.

edit {1} nor should there be any items with a greater than ( > ) in front of them, which git calls "dirty". either commit those or reset them to HEAD.

Re: Important: Change to recommended Typical Development Usa

PostPosted: 05 Aug 2011, 21:07
by Braids
it seems rebasing is the answer. sorry, Snacko.

Re: Important: Change to recommended Typical Development Usa

PostPosted: 06 Aug 2011, 08:29
by Snacko
1) Git pull
if you have any uncommitted work this only does fetch
2) Commit / Reset if you want
3) If you really reset / commited then
4) Git pull
depending if your changes can be fast forward merged
5) if yes done -> check Team -> Show in History that you have a single history line with merge
6) no -> you need to resolve conflicts and merge http://wiki.eclipse.org/EGit/User_Guide ... e_conflict

For the wiki
Cautions -> everything's right; fetch updated your local copy (you got the commits / history), but pull overall failed, this means it didn't get merged

10. Yes you can merge at this point, however if somone pushed something into the remote repo then you get history like
Code: Select all
   /E
A-B-D
  \C/
Where C is your change and D is your merge, while E is the change in remote repository. This means you will have to merge once more anyway after a pull. Also if you push without a pull this creates a dangling commit that wont be merged automatically by git pull because the HEAD has moved to D (Same problem you had before when you 'zapped' commits).


My Pull Failed
hard reset wont vaporize your local commits however you change the commit your working on let me draw
before hard reset, * represents where you are
Code: Select all
A-B-C-D-E (HEAD)
     \F-G-H* (your local commits)
after hard reset HEAD
Code: Select all
A-B-C-D-E* (HEAD)
     \F-G-H (your local commits)
To get back to your local commits you have to use git checkout via Team-> Show in History, find your commit right click Checkout, then it looks like
Code: Select all
A-B-C-D-E
     \F-G-H* (your local commits, HEAD)
git checkout changes HEAD pointer! http://www.kernel.org/pub/software/scm/ ... ached_head

Re: Important: Change to recommended Typical Development Usa

PostPosted: 06 Aug 2011, 14:03
by Braids
Snacko wrote:1) Git pull
if you have any uncommitted work this only does fetch
2) Commit / Reset if you want
3) If you really reset / commited then
4) Git pull
depending if your changes can be fast forward merged
ok, but none of this trigger's EGit's merge tool. in fact, i haven't found a way of invoking it yet. git is fine, but i think EGit has problems.

Snacko wrote:5) if yes done -> check Team -> Show in History that you have a single history line with merge
6) no -> you need to resolve conflicts and merge http://wiki.eclipse.org/EGit/User_Guide ... e_conflict
see my previous statement. i've never seen those merge icons in EGit.

Snacko wrote:For the wiki
Cautions -> everything's right; fetch updated your local copy (you got the commits / history), but pull overall failed, this means it didn't get merged
but after rebasing, pull succeeds.

Snacko wrote:10. Yes you can merge at this point, however if somone pushed something into the remote repo then you get history like
Code: Select all
   /E
A-B-D
  \C/
Where C is your change and D is your merge, while E is the change in remote repository. This means you will have to merge once more anyway after a pull. Also if you push without a pull this creates a dangling commit that wont be merged automatically by git pull because the HEAD has moved to D (Same problem you had before when you 'zapped' commits).
ok, i'll advise against push without successful pull.

Snacko wrote:My Pull Failed
hard reset wont vaporize your local commits however you change the commit your working on let me draw
before hard reset, * represents where you are
Code: Select all
A-B-C-D-E (HEAD)
     \F-G-H* (your local commits)
after hard reset HEAD
Code: Select all
A-B-C-D-E* (HEAD)
     \F-G-H (your local commits)
To get back to your local commits you have to use git checkout via Team-> Show in History, find your commit right click Checkout, then it looks like
Code: Select all
A-B-C-D-E
     \F-G-H* (your local commits, HEAD)
git checkout changes HEAD pointer! http://www.kernel.org/pub/software/scm/ ... ached_head
the commits i vaporized never showed up in that history again.