Keep in mind that there was one overall design goal of git: Whenever there was 
more than one right way to do something, do the opposite of svn.

That is not a joke or exaggeration. 

Branches in git are dirt cheap -- they consist of creating a 40 byte file.
"git add" to put stuff into git is moderately expensive -- the hash of the file 
needs to be calculated, and a copy of the file made.
"git commit" is cheap -- all the information needed has been calculated and 
updated by git add, except for two hashes on short files (your commit message, 
and the list of hashes already in the cache). (This is slightly simplified, but 
close enough).

On the assumption that curl and libpng are unrelated, my first thought would be 
that they would have different repositories. I.e. -- work done on curl is in 
one place, work done on libpng is in another place. If they are in the same 
repository for administrative purposes, ... (ick) ... then I'd suggest using a 
feature of git that I just recently found: worktrees.

"git worktree" can make a second working directory backed by the same 

This lets you have one working directory for libpng, and one working directory 
for curl. You can switch between them with a "pushd", and treat them entirely 

Beyond that? If your model is "one working directory", and one repository?

Then "master" would only contain stuff that you want to publish.

To start work on a curl item:

git checkout master
git checkout -b curl-item-name
.. work work owkr test fix work test happy ...
git commit
git checkout master
git merge curl-item-name

At any time in the "work" cycle, you can just say

git commit -m "Work in progress -- blah blah blah"
git checkout master

git checkout -b libpng-item-name

To see the status of your active branches:
gitk --all

macports-dev mailing list

Reply via email to