Re: Access to CVS

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2012-12-13 at 08:20 -0800, Bart Schaefer wrote:
> Heck, I'd even like an example of the git command for creating a local
> feature branch.

You are normally on a branch called "master", which by strong convention
tracks the remote branch "origin/master" (with the tools making it easy
to reconcile).  HEAD is an alias for "tip of the current branch".

% git checkout -b feature_foo
% vi/emacs/ed/flamewar_bait path/to/files ...
% git commit -a                       # or git add, blah blah, git commit

The "checkout -b" basically switches the current working tree state to
be in the new branch named.  "commit -a" is "all".  You can use
"-i <files>" to name explicit files, or use "git add" manually and then
just "git commit".

The workflow described seems to not have code pushed centrally, so
instead when the changes are fixed you can use:
% git rebase -i master
to collapse changes since the branch-point where you split from master.

If you just have the one commit and you want to change the _latest_
commit to add files, then "git commit --amend" works.  This creates a
new commit, with a new id (SHA1 checksum) so the old commit is not
valid.

Thus the caution if you've pushed the changes to where others can see
and pull them, because you can end up requiring others to manually
reconcile "non fast-forward" changes.  Yes, you end up with stale
commits no longer referenced by a branch, and much like a file-system's
lost inodes, these hang around until cleaned up.  You can see them with
"git fsck --unreachable".  Note I've not yet _needed_ to use git-fsck
for anything other than curiosity and learning.  But it's there.

IF you want to make the code available on the server you cloned from as
a branch, and accept that this involves a non-linear history (eg, a
major feature change where it's worth keeping a more accurate history)
then:
  % git push origin feature_foo
  [ do mailing-list stuff here ]

  Switch back to master:
  % git checkout master
  and get the most recent changes:
  % git pull
  then bring in your changes:
  % git merge feature_foo
  % git commit
  % git push

Cleanup:
% git branch -d feature_foo
  % git push origin :feature_foo


It's worth understanding how git does what it does, because a lot of
this is surfaced in the presented abstractions.  The black boxes are
mostly translucent.  Until you learn the underlying layers "git reset"
vs "git checkout" to revert files is confusing as hell.  Or was for me.

git help tutorial
git help tutorial-2
git help gitcore-tutorial

-Phil