What is our preferred gitorious workflow wrt merges and pushes?

[Nicolás Alvarez]

On 10/10/2010, Alexander Dymo <alexander.dymo at gmail.com> wrote:
> IMHO linear history is much simpler to understand, but it does introduce
> some specifics wrt personal
> gitorious clone management (like I shown in example A1).
> For my own repos I usually try to keep history linear where possible.

I like to keep history linear when possible too.

One problem with rebasing is that previous commits in your branch end
up having code that you never actually tested (merge of your changes
and mainline repo changes), so those old revisions may not even
compile. If the latest revision doesn't work, you'll find out soon
enough, but you'd never know about the rest. Old revisions that don't
compile are especially annoying when trying to use "git bisect".

To avoid that problem, I wrote a shell script (attached) that will try
to compile every revision in a given range. I can run it right after a
rebase to make sure the entire new history still works. If some
intermediate commit doesn't work, I can use the rebase --interactive's
"edit" to fix it.

$ git rebase master && ./buildhistory master..HEAD

(I highly recommend using ccache with this script!)

-- 
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildhistory
Type: application/x-shellscript
Size: 611 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101010/36fb2141/attachment.sh>