Re: problems with 3.0 format
On Mon, Mar 29 2010, Bernhard R. Link wrote:
> * Peter Krefting <peter@softwolves.pp.se> [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 <srivasta@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Reply to: