denny@xxxxxxxxxxxxxxxxxx wrote:
> I am still looking through your replies and getting familiar with
> git commands.
By the way, please ignore that GIT_WORK_TREE stuff I did. It
probably works, but it's ugly. :) That example could have been
written better as
git init everything
GIT_DIR=$(pwd)/everything/.git; export GIT_DIR
(
cd common-ancestor
git add -A
git commit
git branch -m ancestor
)
(
cd project1
git checkout -b project1 ancestor
git add -A
git commit
)
... etc ..
unset GIT_DIR
cd everything
git checkout project1
[...]
> From a developer's point of view, working on projectX means making
> some changes and committing them to the repo for that project. The
> developer may not be aware of other pojects existing.
For concreteness, I am imagining these directories represent various
versions of the Almquist shell. The common ancestor is the BSD4.3/Net-2
version and various projects may have built from there in different
directions: NetBSD sh, FreeBSD sh, dash. (Yes, I am oversimplifying. :))
Now suppose they have diverged so wildly that it is never possible to
synchronize code with each other. Instead, they can copy fixes, and
this is especially convenient when the fixes are phrased as diffs to
the common ancestor.
To facilitate this, Alice revives the BSD4.3/Net-2 sh project with a
"fixes only" policy. Her daily work might look like this:
$ git fetch netbsd
$ git log netbsd/for-alice@{1}..netbsd/for-alice; # any good patches today?
$ git cherry-pick -s 67fd89980; # a good patch.
... quick test ...
$ git cherry-pick -s 897ac8; # another good patch.
... quick test ...
...
$ git fetch freebsd
... and similarly for the rest of the patch submitters ...
$ git am emailed-patch
Then to more thoroughly test the result:
$ git checkout -b throwaway; # new throw-away branch.[1]
$ git merge netbsd/master; # will the changes work for netbsd?
... thorough test ...
$ git reset --keep master
$ git merge freebsd/master; # how about freebsd?
... etc ...
And finally she pushes the changes out.
> Without knowing anything about git for a moment, one ideal workflow
> is where a developer makes changes to projectX that touch the base
> and projectX specific features. Then the developer commits them and
> pushes them to the main repo. The main repo contains all projects.
> During the commit, chages to the base automagically get pushed to
> all projects that share that base
If it is a matter of what files are touched, then maybe the base is
actually something like a library, which should be managed as a
separate project. See the "git submodule" manual if you would like to
try something like this but still keep the projects coupled.
On the other hand, remaining in the situation from before:
Suppose Sam is the NetBSD sh maintainer. The first step in working on
a new release might be
$ git fetch ancestor
$ git log -p HEAD..FETCH_HEAD; # fixes look okay?
$ git pull ancestor
since Alice tends to include only safe, well tested fixes.
Many changes Sam makes are specific to his project, but today he comes
up with a fix that might be useful for other ash descendants.
So instead of commiting directly, he can try:
$ git checkout for-alice; # carry the fix to the for-alice branch
... test ...
$ git commit -a; # commit it.
If it is not an urgent fix, at this point he might do
$ git checkout master; # back to the main NetBSD branch, without the fix
and give the other projects some time to work on the patch and come up
with a better fix. Or he might cherry-pick the commit from for-alice,
and even publish it and encourage others to cherry-pick directly from
him to get the fix out ASAP.
Notice that not all changes to the base files are necessarily useful
for other descendants of the ancestral program. So in this example,
propagation of changes between projects is fairly explicit.
[1] "git checkout HEAD^0" would be more convenient.
See DETACHED HEAD in the git checkout manual if interested.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html