My theory is this:
1. I pushed change
2. You made local change
3. You pulled (which is a fetch then merge)
This resulted in a merge commit since there was probably conflict
during merge. If you did rebase the history would probably be different
4. If you look at :
https://github.com/uDig/udig-platform/commit/155579ddd1cb27b6ebc4ee3ad411a9f7e644459cIt
is essentially the same commit as you. But it is the original
Do a gitk on your local repository and you will see the paths.
If you want a clean mainline you need to do
git fetch origin
git rebase origin master
I think that is right. That has its downsides though and is generally
frowned upon as it hides what is actually going on and also is a little
trickier for beginners to find there way out of a conflict since you can get
onto a virtual branch which can scare beginners.
jesse
On Fri, Jun 17, 2011 at 9:45 AM, Jody Garnett <[email protected]>wrote:
> I just had a bad experience with github and could use a hand.
>
> I was stuck unable to push a simple change (the header for the udig code
> template). I used git pull to be up to date; and then git push ... and it
> went through.
>
> Here is the confusing part:
> -
> https://github.com/uDig/udig-platform/commit/856845a076ab5ead2a095e093d3b4cc69d031ae4
>
> The above represents a change with my name on it; that I don't think I did?
> The diff shows changes to the installer scripts of the form:
>
> InstallDir "$PROGRAMFILES\uDig\1.2-teradata"
>
> So have I managed to just trip up as you were working Jesse?
>
> --
> Jody Garnett
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
