Re: Git Procedure for 2.0.5.1

[Nico Williams]

On Fri, Dec 28, 2012 at 6:15 AM, Vincent van Ravesteijn  wrote:
> Op 27-12-2012 23:27, Nico Williams schreef:
> On Dec 27, 2012 3:07 PM, "Vincent van Ravesteijn"  wrote:
>>> You can correct almost everything with git. Just don't push a wrong tag,
>>> ...
>
>> Right, because deleting a branch or tag, or making a branch name refer to a
>> completely different line of commits (e.g., rebase) are destructive
>> operations, but a) the commits remain in the repo, b) the reflog will track
>> these actions and let you find the old commit hashes, and that's enough to
>> recover.
>
>
> It's just "not done" to change a tag, because people should be able to trust
> the tags... (according to the git documentation)

Well, it depends on what the purpose of the tag is.  For _releases_
you really, really want to never change a tag.  (There's git
tag/commit signing tools out there, but this really should have been a
native feature in git.)

>> As long as you don't gc a repo...
>
>
> Luckily git runs the garbage collection itself, but you should *never* lose
> anything, because gc is very careful.

Argh, I meant git prune.  To me that's a garbage collection :/

>> But even so, it's best to not have to go look in the reflog, and a few
>> simple rules help with this:
>
>> - for dev branches, if you rebase then first create a copy of the branch and
> rebase the copy, not the original;
>
> Huh, you will end up with tons of copies of the same branch, just because
> you rebase them once in a while ?

Yes.  It's very useful for, e.g., documenting the work that you've
done.  Eventually I delete all those branches.  And one would never
push such branches to official repos.

There's really very many possible git workflows.  One of them involves
a hierarchy of repos into: official repo, project repos, and developer
repos, where developers push to project repos and the admins of the
project repos periodically rebase onto the master branches from the
official repos -- since rebasing is destructive the rebasing should be
done on new branches that the developers can then rebase --onto their
dev branches.  Finally a project repo will eventually push its work
onto the official repos.

Nico
-- 

Nico
--

Re: Git Procedure for 2.0.5.1

[Vincent van Ravesteijn]

Op 27-12-2012 23:27, Nico Williams schreef:



On Dec 27, 2012 3:07 PM, "Vincent van Ravesteijn" > wrote:
> You can correct almost everything with git. Just don't push a wrong 
tag, ...


Right, because deleting a branch or tag, or making a branch name refer 
to a completely different line of commits (e.g., rebase) are 
destructive operations, but a) the commits remain in the repo, b) the 
reflog will track these actions and let you find the old commit 
hashes, and that's enough to recover.




It's just "not done" to change a tag, because people should be able to 
trust the tags... (according to the git documentation)



As long as you don't gc a repo...



Luckily git runs the garbage collection itself, but you should *never* 
lose anything, because gc is very careful.


But even so, it's best to not have to go look in the reflog, and a few 
simple rules help with this:


- for dev branches, if you rebase then first create a copy of the 
branch and rebase the copy, not the original;


Huh, you will end up with tons of copies of the same branch, just 
because you rebase them once in a while ?



- just don't garbage collect you're repos.

This is done automatically (if you don't change some settings). Besides 
that, it cannot hurt.


Nico
--

Re: Git Procedure for 2.0.5.1

[Nico Williams]

On Dec 27, 2012 3:07 PM, "Vincent van Ravesteijn"  wrote:
> You can correct almost everything with git. Just don't push a wrong tag,
...

Right, because deleting a branch or tag, or making a branch name refer to a
completely different line of commits (e.g., rebase) are destructive
operations, but a) the commits remain in the repo, b) the reflog will track
these actions and let you find the old commit hashes, and that's enough to
recover.  As long as you don't gc a repo...  But even so, it's best to not
have to go look in the reflog, and a few simple rules help with this:

- never do non-fast-forward pushes to branches others might ever
legitimately pull from;

- never push branches to an official repo that you don't want the public to
see or use;

- never delete anything from official repos;

- keep dev work on separate repos;

- for dev branches, if you rebase then first create a copy of the branch
and rebase the copy, not the original;

- delete dev branches only when you're really done with them and they are
just cluttering the output of git branch;

- only use tags for official repo purposes, never tag in local clones
(there's only one tag namespace, whereas branches have per-remote
namespaces);

- just don't garbage collect you're repos.

Nico
--

Re: Git Procedure for 2.0.5.1

[Nico Williams]

On Dec 27, 2012 2:43 PM, "Richard Heck"  wrote:
>
> On 12/27/2012 03:27 PM, Nico Williams wrote:
>>
>> On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck  wrote:
>>>
>>> So the voting seems to be that we should release a 2.0.5.1, with just
the
>>> fix for the babel issue. The question now is how, in git, to do this.
>>>
>>> It's easy enough to do:
>>>  git checkout tags/2.0.5
>>> This puts me in "detached head", though, so I need to create a branch
if I
>>> want to save anything. So I can do:
>>>  git checkout -b 2.0.5.1
>>> which gives me a new branch and do everything there.
>>>
>>> This is fine, but it will leave us with this extra branch forever,
right? I
>>> thought maybe I should put it in a namespace, like: fixes/2.0.5.1, or
>>> something like that. Opinions?
>>
>> Well, the branch can be deleted when you've made the final release for
>> that branch, just tag the head first then delete the branch.  In any
>> case, my advice is to have no project branches in the official repo,
>> just master and release branches, thus the official repo is not
>> cluttered.  Project branches should live in clones of the official
>> repo, and should be merged into master before being pushed/pulled into
>> the official repo.  This approach works well for other projects using
>> git.
>
> Yes, that is what I am trying to achieve, but I was worried that deleting
the 2.0.5.1 branch would invalidate the tag. I guess not? I'm definitely
not a git expert.

Tags and branches are independent; your branch operations will not
interfere with tags and vice versa.

> Anyway, let's say I create the 2.0.5.1 branch, for this new release, and
do everything there (which is not much). Do I then need to push this branch
before I tag it? and then push the tag? How do I then delete the branch
from the main repo?

No, but you should.  You can always delete the branch later.  But it seems
better to me to keep release branches around.

> Obviously, I do not with to make mistakes here.

As long as you don't delete tags our branches, it garbage collect the repo
you won't be doing anything destructive.

Nico
--

Re: Git Procedure for 2.0.5.1

[Vincent van Ravesteijn]

Yes, that is what I am trying to achieve, but I was worried that 
deleting the 2.0.5.1 branch would invalidate the tag. I guess not? I'm 
definitely not a git expert. 

Considering this, there is not much difference between a branch and a tag.

"git prune" will prune all unreachable objects using all the refs 
available in refs/. Branches are in refs/heads, tags are in refs/tags. 
So, if there is a tag pointing at a commit, the commit will not be pruned.




Anyway, let's say I create the 2.0.5.1 branch, for this new release, 
and do everything there (which is not much). Do I then need to push 
this branch before I tag it? and then push the tag? 
You can branch and tag all locally. You would never need a branch 
actually, you can commit onto a detached HEAD as well (but you should 
remember the sha1, or branch or tag before you leave the commit, but 
then you still can use "git reflog" to find the sha1) and I think you 
never need to push the branch to the server.



How do I then delete the branch from the main repo?
But if you have pushed the branch, you can delete it with "git push 
:2.0.5.1". This means you are pushing 'nothing' to '2.0.5.1', hereby 
removing the branch.



Obviously, I do not with to make mistakes here.

You can correct almost everything with git. Just don't push a wrong tag, ...



Richard



Vincent

Re: Git Procedure for 2.0.5.1

[Richard Heck]

On 12/27/2012 03:27 PM, Nico Williams wrote:

On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck  wrote:

So the voting seems to be that we should release a 2.0.5.1, with just the
fix for the babel issue. The question now is how, in git, to do this.

It's easy enough to do:
 git checkout tags/2.0.5
This puts me in "detached head", though, so I need to create a branch if I
want to save anything. So I can do:
 git checkout -b 2.0.5.1
which gives me a new branch and do everything there.

This is fine, but it will leave us with this extra branch forever, right? I
thought maybe I should put it in a namespace, like: fixes/2.0.5.1, or
something like that. Opinions?

Well, the branch can be deleted when you've made the final release for
that branch, just tag the head first then delete the branch.  In any
case, my advice is to have no project branches in the official repo,
just master and release branches, thus the official repo is not
cluttered.  Project branches should live in clones of the official
repo, and should be merged into master before being pushed/pulled into
the official repo.  This approach works well for other projects using
git.
Yes, that is what I am trying to achieve, but I was worried that 
deleting the 2.0.5.1 branch would invalidate the tag. I guess not? I'm 
definitely not a git expert.


Anyway, let's say I create the 2.0.5.1 branch, for this new release, and 
do everything there (which is not much). Do I then need to push this 
branch before I tag it? and then push the tag? How do I then delete the 
branch from the main repo?


Obviously, I do not with to make mistakes here.

Richard

Re: Git Procedure for 2.0.5.1

[Nico Williams]

On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck  wrote:
> So the voting seems to be that we should release a 2.0.5.1, with just the
> fix for the babel issue. The question now is how, in git, to do this.
>
> It's easy enough to do:
> git checkout tags/2.0.5
> This puts me in "detached head", though, so I need to create a branch if I
> want to save anything. So I can do:
> git checkout -b 2.0.5.1
> which gives me a new branch and do everything there.
>
> This is fine, but it will leave us with this extra branch forever, right? I
> thought maybe I should put it in a namespace, like: fixes/2.0.5.1, or
> something like that. Opinions?

Well, the branch can be deleted when you've made the final release for
that branch, just tag the head first then delete the branch.  In any
case, my advice is to have no project branches in the official repo,
just master and release branches, thus the official repo is not
cluttered.  Project branches should live in clones of the official
repo, and should be merged into master before being pushed/pulled into
the official repo.  This approach works well for other projects using
git.

Nico
--