Clemens Buchacher [off-list ref] writes:
Pros and cons for "undeleting branches":
+ safety net
It should not be easy to lose information with git.
I am personally not very convinced by this argument when it comes to the
cases where the user actively asks us to remove something.
+ less dependant on git branch -d
Since git branch -d deletes branches which have been merged to a
remote tracking branch, it does no longer guarantee that the branch
is still available in history locally, and if the branch is also
deleted remotely, running git remote prune removes it entirely.
Sorry, I have no idea what you are talking about in this paragraph. I
cannot read "Who depends on git branch -d to achieve what" from your
description. All I read in the above description is that what the command
does is a good thing. If you want to keep the remote tracking branches
around, don't run "branch -d". If you do want to remove the history of a
branch, run "branch -d". Isn't it that simple?
Perhaps the missing "achieve what" may be that "output from 'git branch'
is too cluttered if I don't remove already merged branches as early as
possible, and forces me to run 'git branch -d' to clean things up too
often"? If that is the issue you are trying to address, perhaps we can
solve that in a more direct way, e.g. "git branch --no-merged" easier to
access?
- user interface complexity
How to prune deleted branches? Currently, it is enough to do "git
branch -D branch; git gc --prune" in order to get rid of the branch
objects, at least if the HEAD reflog does not contain it or has
expired. Consider for example adding a remote, and removing it
again. This operation would leave a bunch of deleted branches,
which potentially occupy a lot of disk space.
How to find and restore deleted branches? If the reflog is used to
record deleted branches, and a new branch of the same name is
created, the reflog contains entries from unrelated branches. [1]
If the deleted reflogs are stored in an attic, how do we reference
those?
This is the area I am most concerned about.
If you take an analogy in say a file server implementation, yes, it should
not be easy to lose information there. But it is and should be easy to
say "rm junk". How would people recover from a mistake if they typed a
wrong filename, "rm junio" to lose a precious file "junio", when they
meant to lose "junk"? They go to backups. Can't git users do the same?
After all, .git directory is stored on a filesystem of some sort, and
taking a backup (you do take backups, don't you?) and picking the stuff
you lost from there should be a standard procedure that can be learned
outside of the context of git.
This is pretty-much a tangent, but I recall from time to time people
wonder why the branch namespace is not flat. If that is a common wish,
your "tilde-suffix all the intermediate path components" trick could be
used in later versions of git (perhaps 1.8.X series) to improve the system
to allow "maint-1.7.0" branch and topic branches that forked from it
e.g. "maint-1.7.0/fix-frotz" and "maint-1.7.0/fix-nitfol" peacefully
co-exist.
On Mon, Jul 19, 2010 at 11:06:23AM -0700, Junio C Hamano wrote:
Clemens Buchacher [off-list ref] writes:
quoted
+ less dependant on git branch -d
Since git branch -d deletes branches which have been merged to a
remote tracking branch, it does no longer guarantee that the branch
is still available in history locally, and if the branch is also
deleted remotely, running git remote prune removes it entirely.
Sorry, I have no idea what you are talking about in this paragraph. I
cannot read "Who depends on git branch -d to achieve what" from your
description. All I read in the above description is that what the command
does is a good thing. If you want to keep the remote tracking branches
around, don't run "branch -d". If you do want to remove the history of a
branch, run "branch -d". Isn't it that simple?
So why do we have "branch -d" in the first place? Exactly because I
do _not_ want to reomve the history of a branch. I just want to
remove the reference to it, because it has already been merged and
is therefore of no interest any more.
Perhaps the missing "achieve what" may be that "output from 'git branch'
is too cluttered if I don't remove already merged branches as early as
possible, and forces me to run 'git branch -d' to clean things up too
often"? If that is the issue you are trying to address, perhaps we can
solve that in a more direct way, e.g. "git branch --no-merged" easier to
access?
That would only delay the need for cleanup. And when I do the
cleanup, I have typically forgotten what the branch contains
exactly. So I like to use "branch -d" to find out if the branch
potentially contains something interesting, and get rid of it
immediately if it does not. If that does not work I have no choice
but to look at the branch before deleting it blindly.
And I used to consider both "branch -d" and "remote prune" to be
safe, because I knew that at some point I would have had to use
"branch -D" in order to actually lose history. Now this is not true
any more due to the scenario described above. In that sense,
"branch -d" is now pointless, because it's hardly safer than
"branch -D".
So this process is where a cannot depend on "branch -d" any more.
quoted
- user interface complexity
How to prune deleted branches? Currently, it is enough to do "git
branch -D branch; git gc --prune" in order to get rid of the branch
objects, at least if the HEAD reflog does not contain it or has
expired. Consider for example adding a remote, and removing it
again. This operation would leave a bunch of deleted branches,
which potentially occupy a lot of disk space.
How to find and restore deleted branches? If the reflog is used to
record deleted branches, and a new branch of the same name is
created, the reflog contains entries from unrelated branches. [1]
If the deleted reflogs are stored in an attic, how do we reference
those?
This is the area I am most concerned about.
Below you explain that we not need this feature, because we can do
backups instead. I disagree. But even if I were to agree, why are
you concerned about that? Even if you do not use the feature
personally, does it do any harm?
The effort necessary to permanently delete a branch (delete,
expire, prune) will stay exactly the same. The reflog syntax can
also stay the same. We only really need new commands to list and
recreate deleted branches.
If you take an analogy in say a file server implementation, yes, it should
not be easy to lose information there. But it is and should be easy to
say "rm junk". How would people recover from a mistake if they typed a > wrong filename, "rm junio" to lose a precious file "junio", when they
meant to lose "junk"? They go to backups.
Backups are a good measure to protect against loss of large amounts
of data. They do not protect very well from an accidental "rm
junio", because that only works if junio was already in the latest
backup. Protecting against small-scale changes is exactly what a
version control system is good at. And they are much superior to
backups, because they keep history.
Can't git users do the same?
After all, .git directory is stored on a filesystem of some sort, and
taking a backup (you do take backups, don't you?) and picking the stuff
you lost from there should be a standard procedure that can be learned
outside of the context of git.
I usually use git for my more frequent backups. I put everything
that changes a lot and contains much personal work under version
control.
Clemens
On Mon, 19 Jul 2010, Junio C Hamano wrote:
If you take an analogy in say a file server implementation, yes, it should
not be easy to lose information there. But it is and should be easy to
say "rm junk". How would people recover from a mistake if they typed a
wrong filename, "rm junio" to lose a precious file "junio", when they
meant to lose "junk"? They go to backups.
First, I guess that many people have 'rm' aliased to 'rm -i', so it
asks for confirmation... though it only moves safety a bit, as
'rm -f junio' would be still dangerous.
Second, desktop environment have the notion of trashcan, where files
to be deleted are moved, and kept for some time or untill trashcan is
emptied (though it moves safety a bit to people using 'hard delete'
instead of moving to trashcan). Or use undeletefs,
Can't git users do the same?
After all, .git directory is stored on a filesystem of some sort, and
taking a backup (you do take backups, don't you?) and picking the stuff
you lost from there should be a standard procedure that can be learned
outside of the context of git.
People expect version control system to protect them more from mistakes.
Sidenote: there aere requests in last Git User's Survey (from 2009) to
have safety net against losing changes due to "git reset --hard", in the
form of automatically stashing blobs or something.
This is pretty-much a tangent, but I recall from time to time people
wonder why the branch namespace is not flat. If that is a common wish,
your "tilde-suffix all the intermediate path components" trick could be
used in later versions of git (perhaps 1.8.X series) to improve the system
to allow "maint-1.7.0" branch and topic branches that forked from it
e.g. "maint-1.7.0/fix-frotz" and "maint-1.7.0/fix-nitfol" peacefully
co-exist.
Hmmmmm... true, this would make having 'foo' and 'foo/bar' branches
coexists, whether they are loose or packed, and whether they have reflogs
or not.
--
Jakub Narebski
Poland
On Mon, Jul 19, 2010 at 18:06, Junio C Hamano [off-list ref] wrote:
Clemens Buchacher [off-list ref] writes:
quoted
Pros and cons for "undeleting branches":
+ safety net
It should not be easy to lose information with git.
I am personally not very convinced by this argument when it comes to the
cases where the user actively asks us to remove something.
I think it's mainly about user interface consistency. When you
"delete" stuff in with git reset (i.e. move the HEAD) it's recorded in
the reflog, but this isn't the case with branch deletions.
As Will Palmer pointed out, being able to tell newbies "Don't worry,
you aren't going to break it" is a very powerful thing to be able to
tell newbies and experienced users using Git.
It encourages experimentation, because you know that even if you botch
the rewrite and delete the wrong branch it's easy to recover your work
from the reflog in the morning.
I'd really like something like Joshua Jensen's suggestion for
recording a fake branch deletion commit in the reflog.