[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: