Debian packaging with git and conflicts resolution

[Sam Vilain]

Manoj Srivastava wrote:
>> This is all very interesting; I don't think anyone should doubt that
>> conflicts arise.  I think this sub-thread started with the desire to
>> have a moving merge commit that got re-written.  With git you could
>>     
>         I have no idea what you just said; so I couldn't possibly have
>  been participating in a discussion about that.
>   

I'm referring to this:

>       The problem I see with temoprary merge branches is that it would
> seem that any conflicts between topic branches would have to be
> resolved every single time we have a new upstream; I would find that an
> unacceptable burden.


All I was pointing out was that the method with which you produce the
merged tree doesn't have to correspond to how it is recorded in the
history.  It's not that complicated, really.

>         What intermediate merge commits? My current workflow is somewhat
>  like §5.4 on the page:
>    http://www.golden-gryphon.com/software/misc/packaging.html
>  except that I never to the rebase bit until I am ready to submit the
>  patch upstream. 
>
>         Does that explain the use case?
>   

I'm referring to the problem you describe in slide 5.1.  In a sense, you
throw away the merge commits before applying the new change, but keep
the tree.  So, you end up with a single merge commit for each topic
branch without having to rebase all the time, reducing the (subjectively
described) "clutter".  You're doing some things vaguely like this in
your slide 5.3, if a little haphazardly.  I'm sorry if these terms make
little sense, if they don't I suggest chapter 7 of the Git User Manual
that describes the object database.  It's a good half hour investment of
learning that will make working with git feel much less mystifying.

It probably makes sense to make sure that TopGit can deal with the use
cases you describe; it possibly is most of the way there already... Martin?

Sam.