threads / discuss / 18624

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

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

## tl;dr

3 messages between Mar 30, 2009 and Mar 30, 2009.

replies: 2people: 2as markdown or json

Aaron Davies· Mar 30, 2009, 03:03 UTC · lore

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
Nicolas Sebrecht· Mar 30, 2009, 04:22 UTC · re: Aaron Davies · lore

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

On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:
Show 18 quoted lines
> 
> 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.
Show 7 quoted lines
> 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
Nicolas Sebrecht· Mar 30, 2009, 04:30 UTC · re: Nicolas Sebrecht · lore

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

On Mon, Mar 30, 2009 at 06:22:26AM +0200, Nicolas Sebrecht wrote:
Show 59 quoted lines
> 
> 
> 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
Show 27 quoted lines
> 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

← back to recent threads