What is our preferred gitorious workflow wrt merges and pushes?

[Andreas Pakulat]

On 10.10.10 18:32:14, Alexander Dymo wrote:
> >On 10.10.10 15:55:49, Alexander Dymo wrote:
> >You mean merge your branches into kdevelop/master and then push that,
> >right? So far thats what we've done, i.e. no need to specifically rebase
> >a branch against 'current' master to get a linear history.
> 
> Yeah, that was basically my question, do we care about linearity of
> our history?
> Looks like we don't (and git log --graph --all also suggests that we
> don't).
> 
> IMHO linear history is much simpler to understand,

Yes, sometimes non-linear history is not quite easy to understand, but
I've found gitk quite valuable with its various options for viewing the
graph in this area.

> 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 tend to work directly in the local master/stable branch as long as the
'thing' I'm working on will be done soon (within a day or two) so that
it is unlikely that I'm going to create a clone from my local master and
have local changes. That allows me to rebase my local master before
pusing and hence keep linear history most of the time. Anything thats
going to take longer lives in a separate branch that is branched off
when the local master matches the origin master and hence won't have the
problem of commits going mia because my local master is being rebased
later on. Works quite well for me and my colleagues, without creating
too much of a freight-yard-mess in gitk ;)

Andreas

-- 
You will live a long, healthy, happy life and make bags of money.