A couple branch questions

A couple branch questions

[Jay Soffian]

1) git-branch -d <branchname> complains if <branchname> hasn't been
merged to HEAD. Shouldn't it really only complain if <branchname>
hasn't been merged into any local branch? i.e., as long as
<branchname> has been merged, why care to which branch?

2) Why does --track work only for remote tracking branches? I think it
would be useful for setting up topic branches. I've actually got this
alias setup, but maybe a --topic option for git-checkout and
git-branch would be useful to others (?):

topic = "!sh -c 'branch=$(git symbolic-ref HEAD); test -n \"$branch\"
&& git co -b \"$1\" && git config branch.\"$1\".merge \"$branch\" &&
git config branch.\"$1\".remote . && git config branch.\"$1\".rebase
true' -"

j.

Re: A couple branch questions

[David Symonds]

On Feb 13, 2008 5:39 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> 1) git-branch -d <branchname> complains if <branchname> hasn't been
> merged to HEAD. Shouldn't it really only complain if <branchname>
> hasn't been merged into any local branch? i.e., as long as
> <branchname> has been merged, why care to which branch?

It's easy to mistype branch names, and you typically only delete them
after you merge them into your current branch. If you're really sure,
just pass -D instead of -d.


Dave.

Re: A couple branch questions

[Bill Lear]

On Wednesday, February 13, 2008 at 17:45:16 (-0800) David Symonds writes:
>On Feb 13, 2008 5:39 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> 1) git-branch -d <branchname> complains if <branchname> hasn't been
>> merged to HEAD. Shouldn't it really only complain if <branchname>
>> hasn't been merged into any local branch? i.e., as long as
>> <branchname> has been merged, why care to which branch?
>
>It's easy to mistype branch names, and you typically only delete them
>after you merge them into your current branch. If you're really sure,
>just pass -D instead of -d.

How does that answer the question posed?


Bill

Re: A couple branch questions

[David Symonds]

On Feb 13, 2008 6:24 PM, Bill Lear <rael@zopyra.com> wrote:
>
> On Wednesday, February 13, 2008 at 17:45:16 (-0800) David Symonds writes:
> >On Feb 13, 2008 5:39 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> >> 1) git-branch -d <branchname> complains if <branchname> hasn't been
> >> merged to HEAD. Shouldn't it really only complain if <branchname>
> >> hasn't been merged into any local branch? i.e., as long as
> >> <branchname> has been merged, why care to which branch?
> >
> >It's easy to mistype branch names, and you typically only delete them
> >after you merge them into your current branch. If you're really sure,
> >just pass -D instead of -d.
>
> How does that answer the question posed?

If I have four branches, a, b1, b2 and c, and I've merged b2 into c
(but planning to keep developing on b2), and just merged b1 into a
(which I have checked out), then I probably only want to delete b1,
not b2. The "current" branch is a useful notion because it
significantly simplifies merging/rebasing operations.


Dave.

Re: A couple branch questions

[Junio C Hamano]

"David Symonds" <dsymonds@gmail.com> writes:

> If I have four branches, a, b1, b2 and c, and I've merged b2 into c
> (but planning to keep developing on b2), and just merged b1 into a
> (which I have checked out), then I probably only want to delete b1,
> not b2. The "current" branch is a useful notion because it
> significantly simplifies merging/rebasing operations.

Not just "simplifies", but it tends to make it much safer.

People often mistake that the safety of "branch -d" is to not
lose the commit (i.e. not making it unreachable), but that is
not the case.  That safety already exists in HEAD reflogs.

The "branch -d" safety is about not losing the particular point.
The information we really are trying to protect is "this branch
points at _that commit_", which is just as important if not
more.

And immediately after merging that branch into your current
branch is where we can be fairly certain that you are truly done
with the branch and that did not make a typo, if we hear you say
"I do not need that branch anymore, delete it".  "If it is
merged in _some random branch_" does not give such an assurance
and an inappropriate test for this purpose.

I should point out that the current protection based on HEAD
predates the invention of the "branch --track".  If we were
designing the safety today, it would have taken the form of "if
the branch to be removed is fully merged in the branch that it
used to be tracking, or the current branch, then it is safe to
remove it.".

Keeping reflogs on branch deletion

[Brian Downing]

On Wed, Feb 13, 2008 at 07:43:21PM -0800, Junio C Hamano wrote:
> People often mistake that the safety of "branch -d" is to not
> lose the commit (i.e. not making it unreachable), but that is
> not the case.  That safety already exists in HEAD reflogs.
> 
> The "branch -d" safety is about not losing the particular point.
> The information we really are trying to protect is "this branch
> points at _that commit_", which is just as important if not
> more.

This actually brings up something I've been intending to ask.

When deleting a branch, is there any reason we can't add a deletion
entry into the reflog and keep the reflog around?  This would seem to be
a lot safer; I know I've been burned by expecting the reflog safety net
to be there, and surprised that it's not when I've deleted a branch.

I expect that the reflog entry would look something like this:

0000000000000000000000000000000000000000 4685dfedd47683a476e75166b5c273c0269b7e54 Brian Downing <bdowning@lavos.net> 1202996833 -0600   branch: Created from ubuntu-dapper
4685dfedd47683a476e75166b5c273c0269b7e54 0000000000000000000000000000000000000000 Brian Downing <bdowning@lavos.net> 1202996863 -0600   branch: Deleted

A couple of problems I've noticed that would have to be fixed for this
to work:

* git log -g (and anything else that can take a reflog) would have to be
  fixed or modified to allow for taking branches that no longer exist:

  :; ls .git/logs/refs/heads/foo
  .git/logs/refs/heads/foo
  :; git log -g foo
  fatal: ambiguous argument 'foo': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions

  My uneducated suspicion is that this may be somewhat hard.

* If the above did work, it would be nice for the deletion entry to
  result in a nice "branch was deleted" entry in log -g output.  Today,
  that entry is missing in its entirety.

-bcd

Re: Keeping reflogs on branch deletion

[Nicolas Pitre]

On Thu, 14 Feb 2008, Brian Downing wrote:

> On Wed, Feb 13, 2008 at 07:43:21PM -0800, Junio C Hamano wrote:
> > People often mistake that the safety of "branch -d" is to not
> > lose the commit (i.e. not making it unreachable), but that is
> > not the case.  That safety already exists in HEAD reflogs.
> > 
> > The "branch -d" safety is about not losing the particular point.
> > The information we really are trying to protect is "this branch
> > points at _that commit_", which is just as important if not
> > more.
> 
> This actually brings up something I've been intending to ask.
> 
> When deleting a branch, is there any reason we can't add a deletion
> entry into the reflog and keep the reflog around?  This would seem to be
> a lot safer; I know I've been burned by expecting the reflog safety net
> to be there, and surprised that it's not when I've deleted a branch.

No.  That would only accumulate dead reflog files in the repository.

And as Junio said above, the "HEAD" reflog contains everything you moved 
to, including detached heads, and of course branch heads that might now 
be deleted.  You can easily retrieve a deleted branch head from there.

For example, in my 'git log -g HEAD' output, I have:

|commit 40aab8119f38c622f58d8e612e7a632eb1f3ded2 
|Reflog: HEAD@{2} (Nicolas Pitre <nico@cam.org>) 
|Reflog message: checkout: moving from next to master

If I accidentally deleted my 'next' branch, I can retrieve it with 
HEAD@{3} which is the position HEAD was pointing to before moving away 
from 'next'.  So, doing 'git branch next HEAD@{3}' would restore it.


Nicolas

Re: Keeping reflogs on branch deletion

[Johannes Schindelin]

Hi,

On Thu, 14 Feb 2008, Nicolas Pitre wrote:

> On Thu, 14 Feb 2008, Brian Downing wrote:
> 
> > When deleting a branch, is there any reason we can't add a deletion 
> > entry into the reflog and keep the reflog around?  This would seem to 
> > be a lot safer; I know I've been burned by expecting the reflog safety 
> > net to be there, and surprised that it's not when I've deleted a 
> > branch.
> 
> No.  That would only accumulate dead reflog files in the repository.
> 
> And as Junio said above, the "HEAD" reflog contains everything you moved 
> to, including detached heads, and of course branch heads that might now 
> be deleted.  You can easily retrieve a deleted branch head from there.

Note that you do not necessarily update branches while they are HEAD:

	$ git push . to-fast-forward:HEAD

But that's too fabricated an example, I guess.

So I agree that HEAD reflog is enough.

Ciao,
Dscho

Re: Keeping reflogs on branch deletion

[Jeff King]

On Thu, Feb 14, 2008 at 10:00:58AM -0500, Nicolas Pitre wrote:

> > When deleting a branch, is there any reason we can't add a deletion
> > entry into the reflog and keep the reflog around?  This would seem to be
> > a lot safer; I know I've been burned by expecting the reflog safety net
> > to be there, and surprised that it's not when I've deleted a branch.
> 
> No.  That would only accumulate dead reflog files in the repository.

How is that any different than accumulating old entries in reflog files
for branches that _do_ exist? In both cases, they should be dealt with
via time-based pruning.

> And as Junio said above, the "HEAD" reflog contains everything you moved 
> to, including detached heads, and of course branch heads that might now 
> be deleted.  You can easily retrieve a deleted branch head from there.

By that rationale, why do we bother keeping any reflog besides HEAD in
the first place? I can think of two reasons:

  1. it's much more convenient to type branch@{1} than to sift through
     HEAD's reflog looking for checkout events and guessing which branch
     we were on
  2. it's possible to change a ref without it being on the HEAD, in
     which case the HEAD reflog doesn't contain the change.

In other words, I don't see "oops, I deleted this branch and its history
is valuable to me" as significantly less likely than "oops, I got rid of
this commit and its history is valuable to me."

-Peff

Re: Keeping reflogs on branch deletion

[Nicolas Pitre]

On Thu, 14 Feb 2008, Jeff King wrote:

> On Thu, Feb 14, 2008 at 10:00:58AM -0500, Nicolas Pitre wrote:
> 
> > > When deleting a branch, is there any reason we can't add a deletion
> > > entry into the reflog and keep the reflog around?  This would seem to be
> > > a lot safer; I know I've been burned by expecting the reflog safety net
> > > to be there, and surprised that it's not when I've deleted a branch.
> > 
> > No.  That would only accumulate dead reflog files in the repository.
> 
> How is that any different than accumulating old entries in reflog files
> for branches that _do_ exist? In both cases, they should be dealt with
> via time-based pruning.

Branches that do exist are more likely to be interesting to you than 
branches that, hopefully in 99% of all cases, you willfully deleted.

> > And as Junio said above, the "HEAD" reflog contains everything you moved 
> > to, including detached heads, and of course branch heads that might now 
> > be deleted.  You can easily retrieve a deleted branch head from there.
> 
> By that rationale, why do we bother keeping any reflog besides HEAD in
> the first place? I can think of two reasons:
> 
>   1. it's much more convenient to type branch@{1} than to sift through
>      HEAD's reflog looking for checkout events and guessing which branch
>      we were on

Exact.  But that doesn't apply to non existent branches, surely?  And 
what would you do with the reflog of a deleted branch when a new branch 
is created with the same name?

>   2. it's possible to change a ref without it being on the HEAD, in
>      which case the HEAD reflog doesn't contain the change.

And in those cases this can't be due to your own modifications, hence 
nothing valuable is lost if you then delete that branch.

> In other words, I don't see "oops, I deleted this branch and its history
> is valuable to me" as significantly less likely than "oops, I got rid of
> this commit and its history is valuable to me."

But you still have it, in the HEAD reflog, at least for your own 
changes. I therefore don't see the value of having to keep named branch 
reflogs around just for the small convenience, especially with the 
semantic issues that comes with it.


Nicolas

Re: Keeping reflogs on branch deletion

[Jeff King]

On Thu, Feb 14, 2008 at 11:16:20AM -0500, Nicolas Pitre wrote:

> > How is that any different than accumulating old entries in reflog files
> > for branches that _do_ exist? In both cases, they should be dealt with
> > via time-based pruning.
> 
> Branches that do exist are more likely to be interesting to you than 
> branches that, hopefully in 99% of all cases, you willfully deleted.

I agree that they tend to be more interesting, but the point of reflogs
is to have a log of operations performed for later examination. We
already have a well-defined boundary for "interesting": things that are
older than N days. Why introduce another such boundary? Are your reflogs
for deleted branches so large that you aren't willing to keep them?

(There is actually one reason I can think of to get rid of reflogs for
deleted branches. Branch naming rules depend on which branches exist.
Thus I can have "foo/bar" only if "foo" does not exist, which means that
I can only have a reflog for "foo/bar" if the one for "foo" has been
deleted. But that is a limitation of the current scheme for storing
reflogs).

> >   1. it's much more convenient to type branch@{1} than to sift through
> >      HEAD's reflog looking for checkout events and guessing which branch
> >      we were on
> 
> Exact.  But that doesn't apply to non existent branches, surely?  And 
> what would you do with the reflog of a deleted branch when a new branch 
> is created with the same name?

I think it does. Reflogs protect against changes in the "commit" space
within a ref (things like "git reset HEAD^"). But there is no protection
against changes in the "ref" space (like "git branch -D foo").

As for the behavior, I would just append. Your reflog would look like:

  branch@{0} - commit
  branch@{1} - create branch
  branch@{2} - delete branch
  branch@{3} - commit

The behavior would be identical for recently logged items. But instead
of there being no branch@{3}, it would go back into the deleted branch.

> >   2. it's possible to change a ref without it being on the HEAD, in
> >      which case the HEAD reflog doesn't contain the change.
> 
> And in those cases this can't be due to your own modifications, hence 
> nothing valuable is lost if you then delete that branch.

For one thing, just because a modification wasn't _yours_ doesn't mean
it isn't valuable. It entered your repository, and therefore it may be
of interest.

Secondly, you _can_ change a ref without it being the HEAD. Try

  git branch -f foo bar

> > In other words, I don't see "oops, I deleted this branch and its history
> > is valuable to me" as significantly less likely than "oops, I got rid of
> > this commit and its history is valuable to me."
> 
> But you still have it, in the HEAD reflog, at least for your own 
> changes. I therefore don't see the value of having to keep named branch 
> reflogs around just for the small convenience, especially with the 
> semantic issues that comes with it.

My HEAD reflog has almost 1000 items in it. Finding out which commit
would have been branch@{0} in there is non-trivial.

I agree that this information is less likely to be interesting than the
usual use of reflogs. But I don't agree that the semantics are that
difficult. What issues are you talking about?

-Peff

Re: Keeping reflogs on branch deletion

[Jakub Narebski]

Brian Downing <bdowning@lavos.net> writes:

> When deleting a branch, is there any reason we can't add a deletion
> entry into the reflog and keep the reflog around?  This would seem to be
> a lot safer; I know I've been burned by expecting the reflog safety net
> to be there, and surprised that it's not when I've deleted a branch.

There is techical problem with that, namely possibility of D/F
conflict. When you delete branch 'foo', you can later create branch
'foo/bar'. If reflog for 'foo' was not deleted, you couldn't create
reflog for 'foo/bar' because of directory / file conflict.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Keeping reflogs on branch deletion

[Nicolas Pitre]

On Thu, 14 Feb 2008, Jeff King wrote:

> On Thu, Feb 14, 2008 at 11:16:20AM -0500, Nicolas Pitre wrote:
> 
> > > How is that any different than accumulating old entries in reflog files
> > > for branches that _do_ exist? In both cases, they should be dealt with
> > > via time-based pruning.
> > 
> > Branches that do exist are more likely to be interesting to you than 
> > branches that, hopefully in 99% of all cases, you willfully deleted.
> 
> I agree that they tend to be more interesting, but the point of reflogs
> is to have a log of operations performed for later examination. We
> already have a well-defined boundary for "interesting": things that are
> older than N days. Why introduce another such boundary? Are your reflogs
> for deleted branches so large that you aren't willing to keep them?

I typically have lots of branches.  Many of those are fairly dynamic -- 
they come and go.  Keeping reflogs for them would only clutter the 
reflog space, especially when the same names are reused.  I prefer to 
have a clean reflog for the currently alive branch of a given name 
rather than having a log of anything that occurred under that name.  And 
if I really want to find out about that old branch then there is always 
the HEAD reflog.

> (There is actually one reason I can think of to get rid of reflogs for
> deleted branches. Branch naming rules depend on which branches exist.
> Thus I can have "foo/bar" only if "foo" does not exist, which means that
> I can only have a reflog for "foo/bar" if the one for "foo" has been
> deleted. But that is a limitation of the current scheme for storing
> reflogs).

Sure, and that limitation is IMHO quite sane.  I don't think it is worth 
stretching it just for the convenience of having refs for deleted 
branches elsewhere than from the HEAD reflog.

> For one thing, just because a modification wasn't _yours_ doesn't mean
> it isn't valuable. It entered your repository, and therefore it may be
> of interest.

And if you delete it then you can retrieve it again from its origin.  
If, on the other hand, you _checkout_ that branch (it now entered the 
HEAD reflog), and _commit_ to it (which commit would be unreachable 
from other sources) then _that_ is a ref worth keeping a log of.

> Secondly, you _can_ change a ref without it being the HEAD. Try
> 
>   git branch -f foo bar

Sure.  And what information would become unreachable if you delete 'foo' 
at that point?  The 'bar' commit is not lost, and likely to still exist 
in some other reflog.

> > > In other words, I don't see "oops, I deleted this branch and its history
> > > is valuable to me" as significantly less likely than "oops, I got rid of
> > > this commit and its history is valuable to me."
> > 
> > But you still have it, in the HEAD reflog, at least for your own 
> > changes. I therefore don't see the value of having to keep named branch 
> > reflogs around just for the small convenience, especially with the 
> > semantic issues that comes with it.
> 
> My HEAD reflog has almost 1000 items in it. Finding out which commit
> would have been branch@{0} in there is non-trivial.

This is trivial.

$ git log -g HEAD | grep -C2 "^Reflog.*moving from branch to"

If the first hit is HEAD@{x} then your branch@{0} is just HEAD@{x+1}.

> I agree that this information is less likely to be interesting than the
> usual use of reflogs. But I don't agree that the semantics are that
> difficult. What issues are you talking about?

The naming of deleted reflogs when new branches with same name are 
created, or the concatenation of entries for unrelated branches that 
might happen to have existed under the same name.

And because the relevant entries are already in the HEAD reflog anyway, 
and trivially retrieved as demonstrated above, I don't think it is worth 
adding any additional complexity for what is only a convenience feature 
that is not supposed to be used many times a day after all.


Nicolas

Re: Keeping reflogs on branch deletion

[Jeff King]

On Thu, Feb 14, 2008 at 12:32:07PM -0500, Nicolas Pitre wrote:

> I typically have lots of branches.  Many of those are fairly dynamic -- 
> they come and go.  Keeping reflogs for them would only clutter the 
> reflog space, especially when the same names are reused.  I prefer to 
> have a clean reflog for the currently alive branch of a given name 
> rather than having a log of anything that occurred under that name.  And 
> if I really want to find out about that old branch then there is always 
> the HEAD reflog.

OK, that is a fair argument. I totally disagree, but this is a question
of "what users would want" and you and I happen to want different
behavior. I suspect it has to do with how you name your branches.

> > For one thing, just because a modification wasn't _yours_ doesn't mean
> > it isn't valuable. It entered your repository, and therefore it may be
> > of interest.
> 
> And if you delete it then you can retrieve it again from its origin.  

In a system which touts totally independent operation of separate
repositories, saying "oh, you can just ask some other repository for it
again" seems silly. Who is to say the other repo still exists? Or that
it contains the information you're looking for (e.g., a git push from an
arbitrary commit at one repo may enter your branch at a specific point.
the information that is useful to you is where and when it landed in
your branch, which was never in the other repo in the first place).

> > Secondly, you _can_ change a ref without it being the HEAD. Try
> > 
> >   git branch -f foo bar
> 
> Sure.  And what information would become unreachable if you delete 'foo' 
> at that point?  The 'bar' commit is not lost, and likely to still exist 
> in some other reflog.

The fact that 'foo' was set to a particular sha1 at a particular point
in time? Isn't that the point of a reflog?

Of course the 'bar' commit is not lost. My point is not that you are
losing commits this way, it is that finding the commit you wanted
becomes more difficult (e.g., asking "what was at the tip of the branch
when it was deleted").

> This is trivial.
> 
> $ git log -g HEAD | grep -C2 "^Reflog.*moving from branch to"
> 
> If the first hit is HEAD@{x} then your branch@{0} is just HEAD@{x+1}.

That isn't too bad. But it really works only for branch@{0}, and it
doesn't handle any of the non-HEAD cases I mentioned above.

> The naming of deleted reflogs when new branches with same name are 
> created, or the concatenation of entries for unrelated branches that 
> might happen to have existed under the same name.

It seems like there are only 3 options: clear the log upon deletion,
clear the log upon making the new branch of the same name, or appending
to the old log. I think the third makes the most sense, but there is
probably room for a config option.

> And because the relevant entries are already in the HEAD reflog anyway, 
> and trivially retrieved as demonstrated above, I don't think it is worth 
> adding any additional complexity for what is only a convenience feature 
> that is not supposed to be used many times a day after all.

Fair enough. I actually also don't think it is personally worth my time
to implement, which I suppose means I agree with you. But I don't think
it's a bad idea, and I would have no objection if somebody else
implemented it (which I guess that you do). I was mainly responding to
Brian's post about whether it is a reasonable idea; I think it is.

-Peff

Re: Keeping reflogs on branch deletion

[Wincent Colaiuta]

El 14/2/2008, a las 18:57, Jeff King escribió:

> Of course the 'bar' commit is not lost. My point is not that you are
> losing commits this way, it is that finding the commit you wanted
> becomes more difficult (e.g., asking "what was at the tip of the  
> branch
> when it was deleted").

I agree that keeping around reflogs for deleted branches would be a  
nice convenience, provided they were pruned after an appropriate  
interval. Space isn't really the concern, but clutter is, and that can  
be fixed with pruning.

Cheers,
Wincent