On Mon, Mar 29 2010, Bernhard R. Link wrote:
> * Peter Krefting <[email protected]> [100328 18:25]:
>> Unfortunately, such a workflow can't easily be translated back into a set
>> of patches to apply on top of the current upstream.
>
> I think it is a worse problem than only the impossiblity to create the
> patches. That is only a consequence of the version control system
> missing information about what the changes are.
>
> Not having that information also means that when you want to look for
> what was changed for some bugfix, one has to look at the whole history
> and collect the initial change and all the adoptions to newer upstream
> versions. The information about what is changed is burried in the
> information when it was changed. It also means one cannot tell upstream
> or some other project to just cherry-pick a specific commit to get the
> fix.
I am working on a script that given two tree-ish objects, forks
off a temporary branch of the first tree-ish object, rebases it onto
the second tree-ish object, Creates a patch series, and deletes the
temporary branch. I am doing this partially for work (which uses a
hacked together git-to-perforce kludge), and partially to feed feature
branches upstream more easily, while preserving history.
It would be nice f I can also detect and squash merge nodes from
the temporary branch.
With this script, I think that merge workflow would become more
viable.
manoj
--
Drop the vase and it will become a Ming of the past. The Adventurer
Manoj Srivastava <[email protected]> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
