4 ms·

> What if you make a mistake and remove a branch that you didn't want to remove? Threre are three cascading safeguards: * you cannot remove the current branch

by dexen 14y ago

> What if you make a mistake and remove a branch that you didn't want to remove? Threre are three cascading safeguards: * you cannot remove the current branch, you gotta check out some other branch. Thus you get to know what you leave behind and what you get into. * if you try to delete a branch not yet merged into another one (i.e., your changes would be lost), Git warns you and asks to use a different switch (-D rather than -d), * and the last line of defense: in normal configuration, Git stores history of all operations on HEAD (whatever is the current branch) in .git/logs/HEAD. If you remove or lose any branch or changeset you were working on by a mistake, you can easily find it in the log and git-checkout it (or git-cherry-pick or git-merge). At any rate, you can easily push your temporary branch to some other repo once in a while -- to have it thus backed up . You can easily remove it from the other repo once you are done. > What if you remove the branch and nobody has any idea where change 'x' came from or why? I describe that (the sense of changes) in the commit message. In my experience, branch names are somewhat ephemeral. I really don't want to carry baggage of 4 years of small featur branch into the future. Even the `big, official' branchech change ovre time; whatever is `devel' today, will be `stable' next week and `legacy' the next quarter. Keeping all that baggage in a long-running project would be distracting.

CJefferson 14y ago
While I agree with those safeguards, the big disadvantage (particularly when working with a large group of people) is that they are all defeatable by a stupid / uninformed team member, particularly if it isn't noticed for a couple of months. Of course you can argue that we shouldn't work with stupid / uninformed people, but often it is unavoidable.
- uxp 14y ago
  That's the beauty of a distributed VCS. If my team member deletes every commit inside his master and tries to force push that to GitHub, either by accident or by malice, I have the true history for my master sitting on my local machine. I can then revoke his push access to our upstream, re-push the true master history I have a copy of, and then write him up for being stupid and/or uninformed. It doesn't matter if he was able to do that in HG or Git. If no one notices that such a thing happened for a couple of months, then we need to use better code review practices. Git won't prevent humans from making mistakes. Git will, however, complain if I try to push my master to the upstream's master and the histories don't match (if someone else deleted a previously merged commit), which can at least tip me off to something fishy. Then, I can either force push, and then tell all my other co-workers that the history has changed, or I can revert the destructive commit and carry on.

by dexen 14y ago

CJefferson 14y ago

While I agree with those safeguards, the big disadvantage (particularly when working with a large group of people) is that they are all defeatable by a stupid / uninformed team member, particularly if it isn't noticed for a couple of months. Of course you can argue that we shouldn't work with stupid / uninformed people, but often it is unavoidable.

uxp 14y ago
That's the beauty of a distributed VCS. If my team member deletes every commit inside his master and tries to force push that to GitHub, either by accident or by malice, I have the true history for my master sitting on my local machine. I can then revoke his push access to our upstream, re-push the true master history I have a copy of, and then write him up for being stupid and/or uninformed. It doesn't matter if he was able to do that in HG or Git. If no one notices that such a thing happened for a couple of months, then we need to use better code review practices. Git won't prevent humans from making mistakes. Git will, however, complain if I try to push my master to the upstream's master and the histories don't match (if someone else deleted a previously merged commit), which can at least tip me off to something fishy. Then, I can either force push, and then tell all my other co-workers that the history has changed, or I can revert the destructive commit and carry on.