newb questions: post-cherry-pick status cleanup, shared local repository permissions

newb questions: post-cherry-pick status cleanup, shared local repository permissions

[Aaron Davies]

hi, i'm new to git, and have a couple questions which are probably
very stupid and/or indicate that i've been doing it wrong.

first, a couple words about my setup/workflow: i'm currently sole
developer on a project which may at some point get some other coders.
the environment is three linux boxes, one for development and two for
production, and three accounts, mine, dev, and prod. all homedirs are
hosted on the network and are accessible from all three boxen.

i have a "central" (i.e. bare) repository stored in dev's homedir, and
regular copies in all three homedirs. the language involved is
interpreted, so the code tree is the deployment.

my main workflow is to hack on a branch in my homedir, then merge and
push when i have a feature ready. then i go to the dev account and
pull, which constitutes dev deployment. once it's thoroughly tested, i
do the same in the prod account.

now, the questions: an exception to this workflow occurred a couple
months ago, when i made some urgent bugfixes that needed to move to
prod before other stuff that was currently being tested in dev. this
was done via cherry-picking some specific commits into prod. now, in
prod, when i do "git status", it says "# Your branch is ahead of
'origin/master' by 8 commits." is there an easy way to get rid of
this? last time i tried it on my own, i attempted some sort of push
from prod back to dev, wiped out most of the changes since those
cherry-picks, and had to recover by restoring my repository from
backup.

second, the ownership structure i currently have for the "central"
repository feels wrong to me--the whole thing is owned by my personal
account, depsite being hosted in dev's account. since i'm the only one
who ever pushes into it, this is not currently a problem, but it's
caused permissions issues on the rare occasions i've tried to push
from other accounts (e.g. prod, above), and will presumably cause many
more if anyone else ever starts coding on this project.

advice?
-- 
Aaron Davies
aaron.davies@gmail.com

Re: newb questions: post-cherry-pick status cleanup, shared local repository permissions

[Nicolas Sebrecht]

On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:
> 
> hi, i'm new to git, and have a couple questions which are probably
> very stupid and/or indicate that i've been doing it wrong.
> 
> first, a couple words about my setup/workflow: i'm currently sole
> developer on a project which may at some point get some other coders.
> the environment is three linux boxes, one for development and two for
> production, and three accounts, mine, dev, and prod. all homedirs are
> hosted on the network and are accessible from all three boxen.
> 
> i have a "central" (i.e. bare) repository stored in dev's homedir, and
> regular copies in all three homedirs. the language involved is
> interpreted, so the code tree is the deployment.
> 
> my main workflow is to hack on a branch in my homedir, then merge and
> push when i have a feature ready. then i go to the dev account and
> pull, which constitutes dev deployment. once it's thoroughly tested, i
> do the same in the prod account.

Looks sane. 

That said, you could also work on branches (all in "homedir") for the
    'working on feature' -> testing (dev) -> ready (prod) 
workflow.

> now, the questions: an exception to this workflow occurred a couple
> months ago, when i made some urgent bugfixes that needed to move to
> prod before other stuff that was currently being tested in dev. this
> was done via cherry-picking some specific commits into prod. now, in
> prod, when i do "git status", it says "# Your branch is ahead of
> 'origin/master' by 8 commits." is there an easy way to get rid of
> this?

What I would do is working on "TOPIC" branches. By this way, the bare,
dev and prod repositories would not "know" of all the commits from mine
but only the urgent fixes.

in "mine":
- step 1
    $ git checkout -b bugfixes master

- step 2
    $ git cherry-pick blabla
    (and/or <hack, hack, hack>)

- step 3
    $ git checkout master
    $ git merge bugfixes

- step 4
    $ git push origin master:master (to the bare repo)

- step 5
    $ git branch -d bugfixes
    $ git checkout myworking
    $ git rebase myworking master


At step 1, we create the new bugfixes branch from master:
      (bugfixes)
     /
o-o-o          (master)
     \
      a-b-c-d  (myworking)

At step 2, we fix the bugs (cherry-picking and hack):
      a-c-y-z  (bugfixes)
     /
o-o-o          (master)
     \
      a-b-c-d  (myworking)

At step 3, we merge the urgent fixes into master:
      a-c-y-z  (bugfixes)
     /
o-o-o-a-c-y-z  (master)
     \
      a-b-c-d  (myworking)

At step 4, we push the urgent work as usual pushes.
At step 5, we come back to the usual work:

o-o-o-a-c-y-z  (master)
             \
              b'-d'  (myworking)

>From here, you update dev and prod as usual.

-- 
Nicolas Sebrecht

Re: newb questions: post-cherry-pick status cleanup, shared local repository permissions

[Nicolas Sebrecht]

On Mon, Mar 30, 2009 at 06:22:26AM +0200, Nicolas Sebrecht wrote:
> 
> 
> On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:
> > 
> > hi, i'm new to git, and have a couple questions which are probably
> > very stupid and/or indicate that i've been doing it wrong.
> > 
> > first, a couple words about my setup/workflow: i'm currently sole
> > developer on a project which may at some point get some other coders.
> > the environment is three linux boxes, one for development and two for
> > production, and three accounts, mine, dev, and prod. all homedirs are
> > hosted on the network and are accessible from all three boxen.
> > 
> > i have a "central" (i.e. bare) repository stored in dev's homedir, and
> > regular copies in all three homedirs. the language involved is
> > interpreted, so the code tree is the deployment.
> > 
> > my main workflow is to hack on a branch in my homedir, then merge and
> > push when i have a feature ready. then i go to the dev account and
> > pull, which constitutes dev deployment. once it's thoroughly tested, i
> > do the same in the prod account.
> 
> Looks sane. 
> 
> That said, you could also work on branches (all in "homedir") for the
>     'working on feature' -> testing (dev) -> ready (prod) 
> workflow.
> 
> > now, the questions: an exception to this workflow occurred a couple
> > months ago, when i made some urgent bugfixes that needed to move to
> > prod before other stuff that was currently being tested in dev. this
> > was done via cherry-picking some specific commits into prod. now, in
> > prod, when i do "git status", it says "# Your branch is ahead of
> > 'origin/master' by 8 commits." is there an easy way to get rid of
> > this?
> 
> What I would do is working on "TOPIC" branches. By this way, the bare,
> dev and prod repositories would not "know" of all the commits from mine
> but only the urgent fixes.
> 
> in "mine":
> - step 1
>     $ git checkout -b bugfixes master
> 
> - step 2
>     $ git cherry-pick blabla
>     (and/or <hack, hack, hack>)
> 
> - step 3
>     $ git checkout master
>     $ git merge bugfixes
> 
> - step 4
>     $ git push origin master:master (to the bare repo)
> 
> - step 5
>     $ git branch -d bugfixes
>     $ git checkout myworking
>     $ git rebase myworking master

My bad:
     $ git rebase master

> At step 1, we create the new bugfixes branch from master:
>       (bugfixes)
>      /
> o-o-o          (master)
>      \
>       a-b-c-d  (myworking)
> 
> At step 2, we fix the bugs (cherry-picking and hack):
>       a-c-y-z  (bugfixes)
>      /
> o-o-o          (master)
>      \
>       a-b-c-d  (myworking)
> 
> At step 3, we merge the urgent fixes into master:
>       a-c-y-z  (bugfixes)
>      /
> o-o-o-a-c-y-z  (master)
>      \
>       a-b-c-d  (myworking)
> 
> At step 4, we push the urgent work as usual pushes.
> At step 5, we come back to the usual work:
> 
> o-o-o-a-c-y-z  (master)
>              \
>               b'-d'  (myworking)

Then, you update dev and prod as usual from bare.

-- 
Nicolas Sebrecht