Just a notice.
I rebased my readytopull branch from paul's upstream, so it should be much easier for paul to pull changes from me... but it might cause issues for anybody that is currently tracking my repos.
You will probably just need to do a `git fetch --force` to squelch the complaining git will probably do.
:)
eliott wrote:
Just a notice.
I rebased my readytopull branch from paul's upstream, so it should be much easier for paul to pull changes from me... but it might cause issues for anybody that is currently tracking my repos.
You will probably just need to do a `git fetch --force` to squelch the complaining git will probably do.
I'm still slow at git and fumbling around, but have you pushed your readytopull to your public repo? If I clone you, I don't see it:
[pjmattal@pedantic eliott.git]$ git branch -r origin/HEAD origin/clean origin/master origin/testing
I don't know how this thing typically works.. do people usually have a branch that is ready to pull? I was originally thinking people would merge stuff into their master when it was ready, and work in branches until then, but I also see how having a special separate readytopull could be handy.
In any case, should we adopt a convention to eliminate confusion?
- P
I'm still slow at git and fumbling around, but have you pushed your readytopull to your public repo? If I clone you, I don't see it:
it should be there now paul. I had some goofery that I just nuked locally. In that cloned repo, try a `git fetch -f origin`. That should pull in my changes, and force updates.
I don't know how this thing typically works.. do people usually have a branch that is ready to pull?
Generally, yes. That way people know which branch to pull things from.. not a 'messy test branch'. It is usually the person's responsability to ensure that their readytopull branch is fairly usable for people pulling from upstream.
I was originally thinking people would merge stuff into their master when it was ready, and work in branches until then, but I also see how having a special separate readytopull could be handy.
In any case, should we adopt a convention to eliminate confusion?
It wouldn't hurt.
... you mentioned cloning... The following is FYI, if you don't already know it.
###### You can track other people's repos internally, whithout having to have separate repo dirs..
Lets say I clone your repo.
git clone git://git.mattal.com/aur.git aur > lots out output cd aur git branch -a > * master > origin/HEAD > origin/aur2 > origin/master > origin/origin > origin/testing
Ok. Now I think...loui is doing some neat stuff...I want to check it out. I don't have to clone 'rawly'. I can add a new remote repo to track.
git remote add -f loui http://louipc.dontexist.org/aur/.git git branch -a > * master > loui/experimental > loui/master > origin/HEAD > origin/aur2 > origin/master > origin/origin > origin/testing
Then I checkout a branch to work in.
git checkout -b local-loui loui/experimental
This is nice because you can `git diff`, and `git cherry-pick` from one named repo to another, rebase, and do all kinds of other tom-foolery. ######
eliott wrote:
I'm still slow at git and fumbling around, but have you pushed your readytopull to your public repo? If I clone you, I don't see it:
it should be there now paul. I had some goofery that I just nuked locally. In that cloned repo, try a `git fetch -f origin`. That should pull in my changes, and force updates.
I don't know how this thing typically works.. do people usually have a branch that is ready to pull?
Generally, yes. That way people know which branch to pull things from.. not a 'messy test branch'. It is usually the person's responsability to ensure that their readytopull branch is fairly usable for people pulling from upstream.
That part makes sense. I was just wondering if the convention was that the ready to pull branch *was* the master. This is clean, because it scales.. if everyone does that, everyone pulling from everyone else's master, that's the most current reliable developed state of the world.
... you mentioned cloning... The following is FYI, if you don't already know it.
###### You can track other people's repos internally, whithout having to have separate repo dirs..
Lets say I clone your repo.
git clone git://git.mattal.com/aur.git aur > lots out output cd aur git branch -a > * master > origin/HEAD > origin/aur2 > origin/master > origin/origin > origin/testingOk. Now I think...loui is doing some neat stuff...I want to check it out. I don't have to clone 'rawly'. I can add a new remote repo to track.
git remote add -f loui http://louipc.dontexist.org/aur/.git git branch -a > * master > loui/experimental > loui/master > origin/HEAD > origin/aur2 > origin/master > origin/origin > origin/testingThen I checkout a branch to work in.
git checkout -b local-loui loui/experimentalThis is nice because you can `git diff`, and `git cherry-pick` from one named repo to another, rebase, and do all kinds of other tom-foolery.
Thanks, I had some of this but not all of it, especially some of the neater syntax for it all, so it is useful. Just getting the hang of remote refs.
I wouldn't normally have cloned your repo, but I wondered if it was something I was doing wrong that was causing me not to see the branch, so I wanted to do a brain-dead simple clone and branch -r first to be sure before asking!
- P
Rebasing on a published repo isn't a good thing to do since it creates conflicts with whoever has already pulled your repo. Instead use merge (It's more verbose in the log, but at least it's smooth).
On 9/22/07, Xilon xilonmu@gmail.com wrote:
Rebasing on a published repo isn't a good thing to do since it creates conflicts with whoever has already pulled your repo. Instead use merge (It's more verbose in the log, but at least it's smooth).
meh. Rebasing is normal. It relays your new patches on top of upstream (or whatever you rebase from).
In my case I did more than that..I was fiddling around with my revision history and screwed something up. Which is why it *might* cause problems. But it isn't a big deal by any means.
arch-projects@lists.archlinux.org