Re: gnome-shell moving to Git

[Owen Taylor <otaylor redhat com>]

On Mon, 2009-02-09 at 23:29 +0100, Milan Bouchet-Valat wrote:
> Le lundi 09 février 2009 à 12:09 -0500, Owen Taylor a écrit :
> > Very nice. I spent a little time playing around with it since I actually
> > hadn't tried creating an account or doing anything on gitorious
> > previously.
> > 
> > Maybe it might be good to start the project description off my
> > mentioning that it is a mirror and have the URLs to the upstream
> > git/cgit?
> Yes, I've just fixed it.
> 
> > It seems like it would be a cool gitorious feature if you could have a
> > project where the "mainline" was explicitly a mirror (and even
> > auto-updated). 
> > 
> > Right now it's a bit confusing that if I click "clone this repository" I
> > get a repository with just your feature branch. (I was then able to
> > delete your feature branch and push my own "feature branch" into it, but
> > it could be confusing to git neophytes.)
> Yes, this feature is really lacking, as far as I understand Gitorious,
> for now the repo will only be updated when I push commits that I fetched
> to my local repo from git.gnome.org. Not a big problem, but that can
> look a little inconsistent - hope they'll add this ability.

Maybe it would make sense to push a master branch to gitorious along with your 
feature branch? Though it doesn't really help, since if someone creates their 
own gnome-shell repository on gitorious it should only have their feature 
branches and not anything else...

I think a complete recipe for starting to publish work would look
something like:

 - Create an account on gitorious.org and add your ssh key

 - Click the "clone this repository" button in the GNOME Shell project
   name the new repository '<username>-features' (? just <username> ?)

 - In ~/gnome-shell/source/gnome-shell, do:

    git remote add <username>-features git gitorious org:gnome-shell/<username>-features
    git fetch <username>-features
 
 - Delete all existing refs/tags in the remote repository

    git push <username>-features `git ls-remote <username>-features | awk '{ print ":"$2 }'`

   [ Sort of scary to write that down, though it's really hard to actually lose data
     with git ]

 - Create a new feature branch in the remote repository as a copy of the current upstream
   sources, and create a local tracking branch for that remote branch

    git push <username>-features master:<new-feature-branch>
    git checkout -b <new-feature-branch> <username>-features/<new-feature-branch>

   [ Doing it this way avoids having to set up the branch as a tracking branch manually,
     though doesn't give insight into how to handle pushing an existing branch
     to gitorious ]

 - Edit, commit to the branch, use 'git push' to push to gitorious.

Might be nice to have on live.gnome.org/GnomeShell/Gitorious :-)

> > Hmm, supposedly git-bz is following pretty much the same steps as git to
> > determine the editor. It checks in sequence:
> >  
> >  GIT_EDITOR environment variable
> >  core.editor git preference
> >  EDITOR environment variable
> > 
> > Looking over the git docs it also looks like it might check the VISUAL
> > environment variable. Is that set for you? If not, do you have any idea
> > of git is finding out about nano?
> You're right, I read the editor.c file too. But I've found the
> explanation in the Debian diff file:
>  	if (!editor)
> -		editor = "vi";
> +		editor = "editor";
> 
> I guess this method is specific to Debian, else they would have sent it to upstream.
> But can't you just use the launch_editor () function? That seems more logical and would solve the problem (else I won't die from it, you knnow...).

Wow, wonder what was wrong with 'EDITOR=editor; export EDITOR'
in /etc/profile rather than hacking every package. There's probably some
obscure rational embedded in the Debian policy...

I can just make git-bz use 'editor' in preference to 'vi' if it exists,
in combination with a nasty comment :-)

- Owen