so I've implemented "true" git merge in git-pasky, using core git's
merging capabilities. It seems to even work. :-)

  I tested it briefly, and even did one non-conflicting and one
conflicting merge with Linus with this, but I'd like to hear your
comments and possibly more testing before releasing it.

  To get the lastest git-pasky, get the tarball at


unpack, build, install, do

        git pull

rebuild and reinstall.

  The semantics is trivial (and it might get changed so that you would
do git update instead of git pull at most of places). If you don't have
a given GIT repository ready yet, do

        git init rsync://example.com/repo

in a new directory. It is by default tracking, therefore if you do

        git pull

anytime later, git merge will be automatically invoked. If you want to
prevent this, do

        git track

which will untrack your tree; the remote branch you were tracking is
called "origin", shall you want to pull/merge it later. You might want
to also merge with someone else. Do

        git addremote elsewhere rsync://example.org/another
        git pull elsewhere
        git merge elsewhere

(Note that merge won't pull automatically; you must do that on your own
if you want to pull.)

If the merge didn't succeed and you have conflicts, don't panic. The
merge told you about the conflicts, you can also do

        git diff

to see the changes, you'll probably spot the conflict markers. Resolve
the conflicts and then simply do

        git commit

to commit the pending merge.

Now you decided to do a little bit of parallel development and stick
your patches not ready for 2.6.12 to a separate tree. That's fine, do

        git fork experimental ~/linux-2.6.experimental

and get some coffee. (It takes about 8 minutes here, but I think git
isn't at fault - it is probably all spent in

        read-tree $(tree-id)
        checkout-cache -a
        update-cache --refresh

and you pretty much need to call that.)

Then, do some work there, syncing with your main tree periodically:

        git merge master

(that's how your first init'd branch is called). You decide to make it
more fun for Linus and push your experimental stuff into your master
tree. Fine, cd there and do

        git merge experimental

and there you go!

Have fun,

                                Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to