[I wasn't Cc:ed, hence I see your message only now, and I am replying after manually quoting the text from the web archive and manually setting the In-Reply-To field: I hope this won't break the thread; apologies if it does!]
On Sat, 9 Oct 2010 12:02:15 +0800 Paul Wise wrote: > On Sat, Oct 9, 2010 at 4:58 AM, Francesco Poli <f...@firenze.linux.it> wrote: > > > However, I still need confirmation that the git work-flow I am planning > > to follow won't mess everything up. > > Could someone please review it (see <http://bugs.debian.org/588636#39>)? > > A few minor issues, but it looks good. Thanks a lot for the review! :-) > > > $ git clone git://git.debian.org/git/apt-listbugs/apt-listbugs.git > > $ git remote add alioth > > ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git > > You should not need to add a second remote, it feels weird to have two > remotes to the same repository. I would just do the initial clone over > ssh. What if I already have the cloned repository (I've used it so far to prepare patches that I've sent to Ryan via e-mail...) and it was cloned via the git protocol at the time? Please take into account that I also already have a local branch waiting to be pushed to the public repository as a new series of commits for the "master" branch... Should I start from scratch, clone the public repository over ssh, and then somehow transfer my local commits from my old cloned repository to the newly cloned one? How? Or is there a better way to deal with this situation? > > > $ git checkout -b $MY_COOL_BRANCH_NAME origin > > You want origin/master here. I thought that "origin" was a shortcut for "origin/HEAD": http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#how-git-stores-references and "origin/HEAD" seems to be equivalent to "origin/master" on my cloned repository: $ git branch -r origin/HEAD -> origin/master origin/compare-version-accelerator origin/make_list_work origin/master origin/try-index-with-soap origin/update-po origin/vimbts Anyway, if I understand correctly, your suggestion is to use "origin/master", since it is a more general strategy. Right? > > > $ git checkout $MY_COOL_BRANCH_NAME && git rebase origin > > Probably s/origin/master/ "origin" and "master" should be identical at this point, since I've just pulled while on branch "master". Or am I wrong? Anyway, since I am then going to pull the rebased branch on the "master" branch, you're probably right that the most correct rebase is a "git rebase master". Could you please confirm that this is what you meant? > > > $ git push alioth ${MY_COOL_BRANCH_NAME}:master > > I've never used that syntax before, interesting. I hope it works as intended! ;-) > > I would also suggest that before you push, either judicious use of git > add -p for preparing commits into logical changes or use of git rebase > -i after the fact to reorganise them into logical changes. Also, > ensuring that each commit builds and passes any test suite helps folks > doing bisects etc on the repo at a later date. I'll do my best to ensure this! ;-) -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpKE5bWh74iB.pgp
Description: PGP signature