[Xastir-dev] Git question
km5vy Tom Russo
russo at bogodyn.org
Mon Apr 22 09:32:59 PDT 2019
On Mon, Apr 22, 2019 at 09:28:14AM -0700, we recorded a bogon-computron collision of the <curt.we7u at gmail.com> flavor, containing:
> However I didn't rebase. I only did "git pull upstream master". I shy away
> from any rebasing now.
OK, but you might have autorebase set in your git config file. If
~/.gitconfig has:
[branch]
autosetuprebase = always
then "git pull upstream master" did a rebase, even without your asking.
If you had not had this, then the behavior would have been different, and
worse --- you'd have gotten an ugly merge commit.
You should not be afraid of rebase. You just need to do it carefully.
> On Mon, Apr 22, 2019 at 9:19 AM Tom Russo <russo at bogodyn.org> wrote:
>
> > Ok, I see what you have done.
> >
> > This is what I have (my "origin" remote is what you have as upstream:
> >
> > * 34f7373b (HEAD -> master, origin/master, origin/HEAD) Add dependent
> > package
> > * e7f47a88 Rename OSX build
> > * 1247152f Fix overlooked unused result warning
> > * 6e14f284 Silence used result warning
> > * da55007d Silence gcc warnings about unused fread return result
> > * cb509f0f Remove three "stringop-overflow" warnings
> > * 1545996b (topic-removewarnings3) Remove some strncat stringop-overflow
> > warning
> >
> > Looks like you played around with the graphics magick issue by
> > tinkering on your clone's master branch, which you then pushed to your
> > fork to make Travis build it.
> >
> > It looks like you then did a "git pull --rebase" or somesuch after you
> > saw that I had committed and pushed to upstream/master. By rebasing your
> > two commits on top of mine, you changed their SHA-1 hashes --- and
> > therefore
> > you made your fork and the upstream repo diverge.
> >
> > So: don't do that. Leave your fork's master alone, always, so it never
> > is anything but a copy of upstream's. Do all work on your fork on side
> > branches, always. If you stick to that, this won't happen.
> >
> > Now, how to fix it:
> >
> > I have already gotten upstream fixed for graphicsmagick, so your additional
> > commits are now moot. So if I were in your position I'd force my clone
> > back
> > to match upstream by discarding those commits altogether and force pushing
> > upstream's master to origin:
> >
> > git checkout master
> > git reset --hard upstream/master
> > git push --force origin master
> >
> > This will discard your "work to add graphicsmagick properly" and "second
> > try
> > to get graphicsmagick into the build" commits, which should be unnecessary.
> >
> > If you hate to lose that work even though it's moot, and *really* want to
> > save
> > those two commits, you can force them onto a side branch:
> >
> > git checkout master
> > git checkout -b topic-savemycommits
> > git checkout master
> > git reset --hard upstream/master
> > git push --force origin master
> >
> > The two commits are now only on your "topic-savemycommits" branch, to which
> > you can do anything you like, such as pushing to your fork.
> >
> > The hard reset of master literally just moves the "master" ref back to
> > point
> > to the same SHA-1 as upstream/master, and then checks out that SHA-1
> > (discarding
> > any changes to tracked files in the process). When you did the checkout -b
> > up there, it simply created a new ref that points to the head of what
> > used to be your rebased master, thereby preventing git from garbage
> > collecting
> > the commits when you reset.
> >
> > And in the future, if you want to avoid problems like this, don't work on
> > master in your fork, ever. Work on side branches. This issue almost
> > certainly
> > came from you making commits and pushing them to master on your branch,
> > then seeing my commit and doing a pull and doing some sort of thing (pull
> > --rebase?) to get my commit into your branch *and then pushing the
> > resulting mangled master back to your fork*.
> >
> > When I was working on getting graphicsmagick right, I was doing it on a
> > branch in my fork. Only when I was actually sure it was working did I
> > cherry
> > pick the one commit that did the trick back to master, and then pushed that
> > to Xastir/Xastir. I never touched the master branch of my fork.
> >
> > For the record, what I did to get graphicsmagick into the 16.04 build was:
> > - make a new branch
> > - on the branch, insert "cat config.log" after "configure" in the
> > "script:"
> > section
> > - read config.log to see why it said it couldn't find WriteImage in
> > graphicsmagick libraries. Find that it was bitching that it couldn't
> > find "-lwebp".
> > - Discover that Ubuntu 16.04's graphicsmagick1-dev package is
> > missing a dependency on libwebp-dev.
> > - Add that package to the list of packages to install on my branch
> > - Confirm that it now works
> > - cherry-pick the "add that package" commit back to master and push to
> > upstream.
> >
> >
> > On Mon, Apr 22, 2019 at 08:25:49AM -0700, we recorded a bogon-computron
> > collision of the <curt.we7u at gmail.com> flavor, containing:
> > > I'll put my "gitv" output here to help Tom:
> > >
> > > * 9d631f5f (HEAD -> master) Second try to get GraphicsMagick into the
> > build
> > > * b0e2e82b Work to add GraphicsMagick properly
> > > * 34f7373b (upstream/master) Add dependent package
> > > | * 4f06ae45 (origin/master, origin/HEAD) Add dependent package
> > > | * b55a086c Second try to get GraphicsMagick into the build
> > > | * e6953131 Work to add GraphicsMagick properly
> > > |/
> > > * e7f47a88 Rename OSX build
> > >
> > >
> > > On Mon, Apr 22, 2019 at 8:24 AM Curt Mills <curt.we7u at gmail.com> wrote:
> > >
> > > > So... I have my we7u/Xastir repo in this state:
> > > >
> > > > $ git pull upstream master
> > > > From github.com:Xastir/Xastir
> > > > * branch master -> FETCH_HEAD
> > > > Current branch master is up to date.
> > > >
> > > > $ git status
> > > > On branch master
> > > > Your branch and 'origin/master' have diverged,
> > > > and have 3 and 3 different commits each, respectively.
> > > > (use "git pull" to merge the remote branch into yours)
> > > > Untracked files:
> > > > (use "git add <file>..." to include in what will be committed)
> > > > ...
> > > > nothing added to commit but untracked files present (use "git add" to
> > > > track)
> > > >
> > > > How do I easily resolve this? Do a "git pull origin master" and then
> > see
> > > > what I end up with?
> > > >
> > > > What's the easiest way to see what the top three commits are on
> > > > origin/master?
> > > >
> > > > Using gitk I see this at the top:
> > > >
> > > > * master Second try to get GraphicsMagick into the build
> > > > * Work to add GraphicsMagick properly
> > > > * remotes/upstream/master Add dependent package
> > > > * Rename OSX build
> > > > * Fix overlooked unused result warning
> > > >
> > > > I don't need the top two commits: Tom Russo fixed that properly on
> > > > "upstream". They were attempts to fix something for Travis-CI and I
> > had to
> > > > push them up to my origin/master to get Travis-CI to kick off to test
> > them.
> > > >
> > > > --
> > > > Curt, WE7U http://we7u.wetnet.net
> > > > http://www.sarguydigital.com
> > > >
> > >
> > >
> > > --
> > > Curt, WE7U http://we7u.wetnet.net
> > http://www.sarguydigital.com
> > > _______________________________________________
> > > Xastir-dev mailing list
> > > Xastir-dev at lists.xastir.org
> > > http://xastir.org/mailman/listinfo/xastir-dev
> >
> > --
> > Tom Russo KM5VY
> > Tijeras, NM
> >
> > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z]
> > [n-z][a-m]
> >
> > _______________________________________________
> > Xastir-dev mailing list
> > Xastir-dev at lists.xastir.org
> > http://xastir.org/mailman/listinfo/xastir-dev
> >
>
>
> --
> Curt, WE7U http://we7u.wetnet.net http://www.sarguydigital.com
--
Tom Russo KM5VY
Tijeras, NM
echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
More information about the Xastir-dev
mailing list