On 1/28/12 5:43 PM, Alan M. Carroll wrote:
* Note - this contains only questions because I have no idea how to do any of
these things despite hours of online research on git. But I certainly ask them
of myself frequently. *
1) How do I get the revision control status of a specific file? I want to know
if the file is in the repository or not, and if in, whther it has been modified
in my current checkout and the last time / commit it was modified in the
repository.
git log for example. git status also shows stuff, but only for files in the
repo. git log on a file that's not in the repo should show nothing.
2) If I start making changes on master because it's just a quick little fix,
then find out it's not so trivial and I need a branch, how do I put those
changes on a branch without losing them?
git checkout -b bug/TS-666
That should both create the bug/TS-666 branch, and bring all your changes
with you over as you "check it out".
3) If I end up with a local branch with the same name as a remote branch, how
do I make my local branch a tracking branch for the remote one? Especially if I
have committed changes on the local branch?
It's quite likely your local branch (e.g. 3.0.x) would have the same names
as the remote (origin/3.0.x). If they were not branched off from the remote,
you can supposedly (with git v1.7 and later, I have not tried it), do:
| git branch --set-upstream foo origin/foo|
But in general, to create the 3.0.x branch, you want to do e.g.
git checkout origin/3.0.x
bit checkout -b 3.0.x
or probably better
| git checkout --track -b 3.0.x origin/3.0.x|
4) How are old branches to be culled? For instance, the ipv6, wccp, and ts-291
branches no longer make sense. In SVN, we could move those to an archive
directory so they could still be located if needed, but wouldn't create
clutter. What happens to commits on a branch that is deleted in git?
I think once you "remove" the branch on the remote, it's gone forever (but I
might be wrong). I sent a different email, but I'd like to start off by
cleaning up the branches that we have (remove the ones that are bogus, and
perhaps rename the rest). We should come up with some better naming scheme
for branches too. I personally like e.g. "bug" as a subtree for all bugs.
This is probably a discussion to make on a different thread though.
Note that branches in git are much (much) cheaper than in SVN. They won't
take up endless amounts of storage on the "local" repo for starters.
Switching between branches is virtually instant. I think to avoid clutter,
the best bet is to try to come up with a hierarchy, and honestly, prune
branches that are no longer necessary.
I hope that helps?
-- Leif
