[Nix-dev] Re: new possible movement to git (?)

[Rok Garbas]

On 30/08/11 00:51, Peter Simons wrote:
> Hi,
> 
>  >> Given that branches are mere pointers, I don't see how to find out
>  >> what was stdenv-updates before after it has been merged into trunk
>  >> and re-created
>  >
>  > Yeah, it would be nice if git had information in commits about which
>  > branch the commit was initially performed on. This seems like a
>  > really simple feature, not sure why it doesn't exist.
> 
> personally, I don't see why that information is relevant. Branch names
> are a local affair in Git. It's quite possible for two repositories to
> track the same content using completely different branch names. So why
> bother recording the name if it doesn't have any significance outside of
> the repository? Other DVCS make a lot of fuss about branch names, like
> monotone, but I don't see any gain in a distributed project. 
> 
> The whole notion of having a "stdenv-updates" branch in the first place
> is obsolete in Git. Instead, we would have many small topic branches for
> specific features.
> 

if you want branch to show in history you would have to push that branch
ti remote repo as well (using --no-ff option).

but as Peter pointed, branches in git are matter of "local higene". You
name it however you want and make sure you merge them to remote branch.
Git doesn't force to you specific branching policy localy while still
playing nice with policy used on remote branch.


> Also, I'm not quite sure why there should be an extra "stable" branch.
> As far as I am concerned, "master" ought to be stable.

Or master is "unstable" and there is "stable" branch. As long as its
documented what is where it doesn't really matter. Maybe "master" being
"stable" makes more sense since usually newcomers always look there and
considered its stable they will have better first time experience (or
maybe this is not wanted :P).