Posted by matijs
24/05/2025 at 08h49
You want to work on some project, but they use a branch named dog and you
want to use cat instead. So you go:
git checkout dog
git switch -c cat
git branch --set-upstream-to=origin/dog
git branch -d dog
Your local branch is now cat and it tracks dog. Whenever your dog-loving
friends push their work, you can just use
git pull --rebase
and your cat branch will be updated with the new commits in origin/dog.
Now, the time comes to push your own work, and you go:
git push
Now, however, something perhaps unexpected happens. Instead of your commits
getting pushed to dog, a new branch cat is created in the remote
repository. That’s not what you wanted!
To make this work properly, you have to change git’s configuration:
git config set --global push.default upstream
From the git config man page, this setting will:
push the current branch back to the branch whose changes are usually
integrated into the current branch
In other words this pushes to the branch set with --set-upstream-to, which
normally only affects pulling.
Now git push will push your cat branch to the remote origin/dog branch,
allowing cat people and dog people to work together peacefully.
PS: With this push setting, pushing a branch without an equivalent upstream
will fail. To instead make git push create an upstream branch for you, set:
git config set --global push.autoSetupRemote true
Tags
git, TIL
no comments
no trackbacks
Posted by matijs
17/02/2013 at 20h15
I love Travis CI. I love git bisect. I used both recently to track down
a bug in GirFFI.
Suddenly, builds were failing on JRuby. The problem did not occur on my
own, 64 bit, machine, so it seemed hard to debug. I tried making Travis
use different JVMs, but that didn’t help, apart from crashing in a
different way (faster, too, which was nice).
Building a Travis box
Using the travis-boxes repository, I created a VM as used by Travis.
This is currently not documented well in the READMEs, so I’m writing it
down here, slightly out of order of actual events.
I cloned the following three repositories:
travis-cookbooks
travis-boxes
veewee-definitions
First, I created a base box in veewee-definitions, according to its
README. In this case, I created a precise32 box, since that’s the box
Travis uses for the builds. The final, export, stage creates a
precise32.box file.
Then, I moved the precise32.box file to travis-boxes/boxes, making a
base box available there. There is a Thor task to create just such a
base box right there, but it doesn’t work, and seems to be deprecated
anyway, since veewee is no longer supposed to be used in that
repository.
So, a base box being available in travis-boxes, I used the following to
create a fully functional box for testing Rubies:
bundle exec thor travis:box:build -b precise32 ruby
Oddly, this didn’t produce a box travis-ruby, but it did produce
travis-development, which I could then manipulate using vagrant.
Hunting down the bug
I ssh’d into my fresh travis box using vagrant ssh. After a couple of
minutes getting to know rvm (I use rbenv myself), I was able to confirm
the crash on JRuby. After some initial poking around trying to pin down
the problem to one particular test case and failing, I decided to use
git bisect. As my check I used the test:introspection task, which
reliably crashed when the problem was present.
While it’s possible to automate git bisect, I like to use it manually,
since a particular test used may fail for unrelated reasons. Also, since
git bisect is a really fast process, there is a pleasent lack of tedium.
Anyway, after a couple of iterations, I was able to locate
the problematic commit.
By checking the different bits of the commit I then found the culprit: I
accidentally broke the code that creates layout definitions, in
particular the one used by GValue. Going back to master, I added
a simple test and fix.
I will have to revisit the code later to clean it up and make it more
robust.
Tags
GirFFI, git, github, software, travis
no comments
no trackbacks