Re: Help with git/wip

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

One of the first things I learnt about git was to not use 'git pull'
(this was when documentation consisted of being yelled at by linux
kernel engineers :-) it does too much.  I personally view 'git pull
-r' the same way as I view 'alias rm='rm -i''.

Just erase "git pull" it from your command cache and use commands that
manipulate your repo in somewhat understandable ways:

git fetch origin
this updates your local pristine copy of upstream; no harm done - you
have your local changes in the branch "master" while "origin"
(origin/master) contains upstream
At this point you should look around, for instance "git log origin" to
list what is new; and more fancy "git log origin ^master" to list what
is in "origin" (upstream) but not master (your local changes); and
"git log master ^origin" to list the reverse

git status
this, among other things, will tell you how far apart your code and
upstream are; it will also tell you if you forgot to commit something;
remember "git log master ^origin" will list your local changes
(hopefully you have only one :-)

git rebase origin
this tries to replay each of your local changes onto the top of the
upstream tree (I'd start with just one); this is what CVS would
effectively do, except with CVS there is no going back.  What happens
next depends:
- a change applies without conflict and all is good, and git goes to
the next change untill it is finished
- a change has a conflict and git throws up TMI about the problem;
type 'git rebase --abort' and go for a really long walk, no harm done
- a change has a conflict and git throws up TMI about the problem; you
take a big breath, "git status" will (re)list the files you need to
fix and tell you to "git add" them, then type "git rebase --continue"
(or "git rebase --abort" and take another long walk, still no harm
done), and the process repeats
(the one thing that can go wrong here is to forget that a rebase is in
progress - always read git status carefully)

git push
so the changes are published; if it fails, got back to 'git fetch
origin' and start again :-)

Andrew

PS: a better reference is the online gitpro book

PPS: While I might detest GIT, it can be made workable.  OTOH, SVN
isn't "acid compliant", and the lack of real branches means that every
project I've encountered has rolled their own messed up branch/tag
conventions (yes, multiple conventions per project) :-(


On 26 July 2017 at 06:23, D'Arcy Cain <darcy%netbsd.org@localhost> wrote:
> I seem to be suffering from https://xkcd.com/1597/.  I have already done the
> delete and restart but I still can't seem to make it work.
>
> $ git commit
> On branch master
> Your branch is ahead of 'origin/master' by 2 commits.
>   (use "git push" to publish your local commits)
> Changes not staged for commit:
>         modified:   Makefile
>
> no changes added to commit
> git push
> Counting objects: 4, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 549 bytes | 0 bytes/s, done.
> Total 4 (delta 2), reused 0 (delta 0)
> remote: Merge commit detected: 76a391009afefb5022670512c11b8d91cb9a09e1
> remote: In general, please use 'git pull -r'
> remote: and now make the history straight using 'git rebase -i'
> To wip.pkgsrc.org:/pkgsrc-wip.git
>  ! [remote rejected]       master -> master (pre-receive hook declined)
> error: failed to push some refs to 'darcy%wip.pkgsrc.org@localhost:/pkgsrc-wip.git'
> $ git pull -r
> error: cannot pull with rebase: You have unstaged changes.
> error: please commit or stash them.
>
> Can someone please give me the magic incantation.
>
> For the record what I changed was removing pkgin (git rm -r pkgin) and
> edited the Makefile.
>
> --
> D'Arcy J.M. Cain <darcy%NetBSD.org@localhost>
> http://www.NetBSD.org/ IM:darcy%Vex.Net@localhost