Should cg-mkpatch output be usable with cg-patch?

Should cg-mkpatch output be usable with cg-patch?

[Wolfgang Denk]

I wander what I should do with "cg-mkpatch" generated output;  I  had
the  impression that this should be usable with "cg-patch", but these
are incompatible with each other. Forexample. if  a  commit  contains
permission changes, my generated patch may look like this:

	...
	diff --git a/MAKEALL b/MAKEALL
	old mode 100644
	new mode 100755
	diff --git a/mkconfig b/mkconfig
	old mode 100644
	new mode 100755
	diff --git a/tools/img2brec.sh b/tools/img2brec.sh
	old mode 100644
	new mode 100755
	...

If I feed this into "cg-patch", I get:

	patch: **** Only garbage was found in the patch input.

-> rpm -q cogito
cogito-0.12.1-1


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I really hate this damned machine     It never does quite what I want
I wish that they would sell it.              But only what I tell it.

Re: Should cg-mkpatch output be usable with cg-patch?

[Junio C Hamano]

Wolfgang Denk <wd@denx.de> writes:

> I wander what I should do with "cg-mkpatch" generated output;  I  had
> the  impression that this should be usable with "cg-patch", but these
> are incompatible with each other. Forexample. if  a  commit  contains
> permission changes, my generated patch may look like this:

Yes, cg-patch does grok git extended diff headers, but does it
by hand and missing corner cases like this is understandable.

I only briefly looked at cg-patch, but I suspect that it can
lose 90% lines of its code by just using "git-apply --index".

I see cg-patch wants to be able to do reverse patch, which is
not supported by git-apply currently.

Do people find "cg-patch -R" useful?

Re: Should cg-mkpatch output be usable with cg-patch?

[Petr Baudis]

Dear diary, on Thu, Jul 21, 2005 at 05:57:49AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I only briefly looked at cg-patch, but I suspect that it can
> lose 90% lines of its code by just using "git-apply --index".

Can git-apply already deal with fuzzy patches?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: Should cg-mkpatch output be usable with cg-patch?

[Petr Baudis]

Dear diary, on Thu, Jul 21, 2005 at 01:49:04AM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> I wander what I should do with "cg-mkpatch" generated output;  I  had
> the  impression that this should be usable with "cg-patch", but these
> are incompatible with each other.

They certainly aren't.

> Forexample. if  a  commit  contains permission changes, my generated
> patch may look like this:
> 
> 	...
> 	diff --git a/MAKEALL b/MAKEALL
> 	old mode 100644
> 	new mode 100755
> 	diff --git a/mkconfig b/mkconfig
> 	old mode 100644
> 	new mode 100755
> 	diff --git a/tools/img2brec.sh b/tools/img2brec.sh
> 	old mode 100644
> 	new mode 100755
> 	...
> 
> If I feed this into "cg-patch", I get:
> 
> 	patch: **** Only garbage was found in the patch input.

And did the changes apply? :-)

The message is surely confusing, but appeared to be rather corner-casy
and after I imagined the required complexity of filtering this, I
decided to spend my time on something more useful for the time being. :)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: Should cg-mkpatch output be usable with cg-patch?

[Wolfgang Denk]

In message <20050722210352.GG11916@pasky.ji.cz> you wrote:
>
> > I wander what I should do with "cg-mkpatch" generated output;  I  had
> > the  impression that this should be usable with "cg-patch", but these
> > are incompatible with each other.
> 
> They certainly aren't.

Is this a problem with the current implementation, or intentional?

> > 	diff --git a/tools/img2brec.sh b/tools/img2brec.sh
> > 	old mode 100644
> > 	new mode 100755
> > 	...
> > If I feed this into "cg-patch", I get:
> > 	patch: **** Only garbage was found in the patch input.
> 
> And did the changes apply? :-)

No, they did not. No file modes were changed.

> The message is surely confusing, but appeared to be rather corner-casy
> and after I imagined the required complexity of filtering this, I
> decided to spend my time on something more useful for the time being. :)

I don't think this is a corner case. I think it is  pretty  important
to be able to promote permissiong changes.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Too many people are ready to carry the stool when the piano needs  to
be moved.

Re: Should cg-mkpatch output be usable with cg-patch?

[Petr Baudis]

Dear diary, on Sun, Jul 24, 2005 at 07:50:18PM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> In message <20050722210352.GG11916@pasky.ji.cz> you wrote:
> >
> > > I wander what I should do with "cg-mkpatch" generated output;  I  had
> > > the  impression that this should be usable with "cg-patch", but these
> > > are incompatible with each other.
> > 
> > They certainly aren't.
> 
> Is this a problem with the current implementation, or intentional?

Implementation. Should be fixed now, after rewriting part of it. ;-)

> > The message is surely confusing, but appeared to be rather corner-casy
> > and after I imagined the required complexity of filtering this, I
> > decided to spend my time on something more useful for the time being. :)
> 
> I don't think this is a corner case. I think it is  pretty  important
> to be able to promote permissiong changes.

Of course. By the corner case I meant "the external patch tool invoked
by cg-patch emits bogus error in case of patch containing only mode
changes and nothing else". I wasn't aware that the changes wouldn't
apply at all - actually, I was when I was writing the code, but
completely forgot about it later.

Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox