[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git uncleaned history

From: Trevor Daniels
Subject: Re: git uncleaned history
Date: Thu, 4 Sep 2008 08:42:46 +0100

Just to add a couple of points to this which may be helpful to

Creating new branches is easy and does not have a high overhead.
I usually have several on the go, one for each self-contained change
or set of changes currently under development.  This permits several
commits to be under development at any one time, as it is easy to
amend the top commit in any of the branches.  This approach is
especially useful for editing documents, as document changes are
usually quite independent.

I keep a special branch called "master" which I reserve for all
my pulls and pushes.  When a local change in one of my other
branches is ready to push I first update my "master" branch by
pulling from origin/master and merging it into "master", then I
cherrypick the local commits I want to push into it, and push my
"master" back to origin.  That way I never have any local merges
to push back.  Cherry-picking is a convenient alternative to
local merging and rebasing.

Finally I delete any local branches which are now no longer required,
and create new ones required for the next development based
on the latest copy of "master".


----- Original Message ----- From: "Reinhold Kainhofer" <address@hidden>
To: "Jean-Charles Malahieude" <address@hidden>
Cc: "lilypond-devel" <address@hidden>
Sent: Thursday, September 04, 2008 12:08 AM
Subject: Re: git uncleaned history

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
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.

- -- - ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden,
* Financial and Actuarial Mathematics, TU Wien,
* K Desktop Environment,, KOrganizer maintainer
* Chorvereinigung "Jung-Wien",
Version: GnuPG v1.4.6 (GNU/Linux)


lilypond-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]