[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rescue Plan for apt-listbugs

Paul Wise <pabs@debian.org> writes:

> On Sat, Oct 9, 2010 at 4:58 AM, Francesco Poli <frx@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.
>> $ 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.
>> $ git checkout -b $MY_COOL_BRANCH_NAME origin
> You want origin/master here.
>> $ git checkout $MY_COOL_BRANCH_NAME && git rebase origin
> Probably s/origin/master/
>> $ git push alioth ${MY_COOL_BRANCH_NAME}:master
> I've never used that syntax before, interesting.

Wouldn't you merge ${MY_COOL_BRANCH_NAME} to the local master and then
just push that?

> 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'm always unsure on how this is supposed to work. On the one hand you
split up changes into many commits. On the other hand each commit should
be functional so bisect works. Somehow the two ideas conflict in my

> Also chuck in git stash and git bisect.


Reply to: