[arch-releng] Iso tests

[Dan McGee]

On Wed, Apr 27, 2011 at 5:17 PM, Tom Willemsen
<tom.willemsen at archlinux.us> wrote:
>> It looks like you did a rebase which made it a straight line history,
>> but didn't actually rebase it onto master. The common base is still
>> f1e476373 (use gitk/qgit/git log -g/tig/etc. to see this), way back
>> from February 1st. Given that your public repository master branch is
>> still pointing at an old commit, I'm guessing you need to take just a
>> few more steps.
>
> I think I understand what you mean, but could you please explain how
> this could happen or why your steps fix this.

It likely happened because you did a rebase -i, but since your local
master branch "pointer" hadn't kept up with the actual master branch,
it wasn't based off the current master branch.

Not sure how to explain it more other than what I said before- look at
the visual and read 'man git-rebase' which is pretty extensive, and/or
find some tutorials on what rebase is and how it works on the
interwebs.

>> 1. Check in or git-stash all uncommitted changes to your branch.
>> 2. git fetch origin (or whatever the remote name is for the main
>> projects.archlinux.org remote)
>> 3. git branch -f master origin/master (once again, use the right
>> branch name, but I highly recommend making origin the upstream
>> repository)
>
> Why do you recommend against this?
This is where I think git hosting services confuse the original
intent. Before one click forks, you would clone a project's repo which
automatically sets up the origin remote and the remote tracking branch
master. Just think about the definition of "origin"- unless you have
commit access to a project, you will probably never be pushing to the
origin, in a sense.

> I've confused myself before this way,
> I'm so used to doing `git pull origin master` and `git push origin
> master` and everything origin master on my own projects that I barely
> think about what I'm doing most of the time (I know, this is terrible,
> but I've never really used git in a way that other people are involved
> as well so everything is almost always only origin) and just put origin
> master everywhere automatically.
The first thing you should do is take a step back so you don't have to
do "origin master" ever again. When I `git pull`, it pulls
origin/master automatically into master. When I `git push`, it
automatically pushes master to origin for me. This little bit in
.git/config does that for me, but you can set it up, it looks like, by
doing `git branch --set-upstream master origin/master`.

[branch "master"]
	remote = origin
	merge = refs/heads/master

> I've pull from the wrong remotes and
> tried pushing to the wrong remotes this way a couple of times and got
> very confused when this failed. But then I'm a total newbie in using git
> when other people involved.
>
>> 4. git rebase master testresults
>> 5. git push -f <yourremote> testresults
>
> I've taken these steps, please let me know if it went right (I don't
> actually know what I'm looking at with git log -g and gitk doesn't seem
> to work (can't find 'wish').
Looks totally right now. And optdepends are your friend:

$ pacman -Qi git
...
Optional Deps  : tk: gitk and git gui

-Dan