-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Mittwoch, 3. September 2008 schrieb Jean-Charles Malahieude:
I do all my "traffic" (translating and building) in Traduc, where I do a
"git pull" quite often as you have noticed. Once I'm ready, I do:
cd ..
git branch (to be sure I'm on the right one)
I do a "git status" instead... It also shows the branch, but also shows
which
files were not yet
git checkout lilypond/translation (if necessary)
git pull trans (shorthand for "lilypond/translation")
cd Traduc
git pull
This creates a merge commit if you have done a local commit before, which
was
not yet pushed to the server. The order of the patches in git is now:
- -) old lilypond/translation status
- -) your local commit
- -) merge commit, merging in changes to lilypond/translation from the
server
git fsck
git gc (and then if nothing seems wrong)
both not needed
git-status and commit (within emacs)
git format-patch origin
Not needed
Before pushing, you should now do:
git rebase origin/lilypond/translation
This takes your previous local commit(s), removes it from before the merge
commit and instead appends it after the current lilypond/translation
branch
on the server. The new order of the commits will then be:
- -) old lilypond/translation status
- -) new lilypond/translation status from the server
- -) your previous local commit
As you can see, the merge commit created by the pull will be removed and
the
order of the patches will be as if you did that commit now rather than a
while ago.
You can do this also if you have several local commits.
git push
This simply copies your local structure to the server. If you have lots of
merge commits locally already, you should try to rebase before pushing.
I usually take a look at the structure of the commit tree with qgit before
pushing and try to resolve things before pushing.
When I'm working on a feature / translation, the sequence of commands I
use is
as follos. Here I'm assuming, I have already done some local changes and
committed them locally, so a pull would create a merge commit. If there
were
no previous local commits, which are not yet pushed to the server, I do a
merge instead of the rebase (although a rebase works just as well):
git fetch -- only download changes from the server, don't merge
in
git rebase origin/branch/on/server -- moves local commit to the very
end
(the rebase also updates your local checkout to the latest version
from
the server, plus your local commit)
(doing some local changes, finishing a section of the translation,
etc.)
git status -- to see what I have changed.
(Now I'm doing either:)
git commit -a -- commits all my changes as a new commit
(or:)
git commit --amend -a -- adds my changes to my previous patch
(of course, if I want to commit only particular files, I don't use -a,
but list only those files instead)
(Just to be sure, I do a:)
git fetch -- downloads possible changes in the meantime on the
server
(if there were changes, I have to rebase again:)
git rebase origin/branch/on/server
(I can now safely do a)
git push origin branch/on/server
Some other useful git commands (not necessarily to "fix" the problems from
above, but I find them usefull in many cases and it took me a while to
figure
out some):
- -) "git reset --hard origin/lilypond/translation" -- resets all local
commits,
your local copy will be exactly what is on the server. You can then apply
patches you have created before.
- -) "git am your_patch.patch" -- apply a patch you created before / was
mailed
to you. This is useful after a reset --hard. I usually use qgit to apply
patches rather than the command line, though.
- -) "git checkout filename" -- discards all non-committed changes to the
file.
- -) "git fetch" -- just downloads the changes from the server and stores
them
locally, but does not apply them to the files you see. After that you can
do "git rebase origin/branch/on/server " or "git merge
origin/branch/on/server" (the difference between merge and pull is that
pull
download the status from the server and then tries to merge, while merge
takes what was downloade before by a git fetch and merges that)
- -) "git commit --amend files" -- Adds the changes to the files to your
previous commit rather than creating a new commit. I use this e.g. when I
forgot to change the committish. This should only be used before you push
to
the server.
- -) "git add -p" -- Goes through all your not-yet-committed changes to
your
files and asks you for each change wheter you want to commit it. After
that
do a "git commit", which will create a commit for only the selected
changes.
All other changes will of course remain in your files as non-commited
changes. This is useful if you work on more than one thing at the same
time.
Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIvxkLTqjEwhXvPN0RAosXAJ9i8e/HLTIQg282aW2Tp/57IPXL7wCfYMno
N/nu1qtN9A9Q7/gJqPZ9ACo=
=ldBT
-----END PGP SIGNATURE-----
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
