Important: Change to recommended Typical Development Usage

[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

[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 . . .

[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. 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 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.

[Braids]

it seems rebasing is the answer. sorry, Snacko.

[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

[Braids]

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.

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.

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.

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.

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.