Re: git uncleaned history

[Reinhold Kainhofer]

-----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: address@hidden, 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-----