git-rebase nukes multiline comments

git-rebase nukes multiline comments

[Matthias Hopf]

Hi all,

I'm using git-1.2.4 on SL10.1, in centralized style development (for X.org).

I wanted to commit a set of changes (4 local commits) upstream, so I had
to do a git-rebase first (in that particular case a git-pull would have
been possible as well, but git-rebase fits the CVS style development
better). After git-fetch, git-rebase origin, and git-push all my changes
had only the first line of the changelog comment, the remainder was
nuked.

To reproduce:

mkdir /var/tmp/blaup
cd /var/tmp/blaup
git-init-db
echo test > foo
git-add foo
git-commit      (any comment)
cd ..
git-clone /var/tmp/blaup bla
cd bla
echo test2 >>foo 
git-commit foo  (multiline comment)
cd ../blaup
echo test3 >bar
git-add bar
git-commit      (any comment)
cd ../bla
git-fetch
git-log         (shows multiline comment for 'test2')
git-rebase origin
git-log         (shows only the first line of the multiline comment!)


I doubt this is intended behavior.


Also, while trying to reproduce this with the original upstream
repository, I would have had to git-fetch my origin branch (upstream
master), but not to get _all_ new commits, but only up to a certain
revspec (the one *before* my own commits).

I tried "git-fetch <refspec>:", but this didn't work, neither did
anything else I tried.  This is clearly beyond my understanding of git,
so how can this be done?

Thanks

Matthias

-- 
Matthias Hopf <mhopf@suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de

Re: git-rebase nukes multiline comments

[David Kowis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Matthias Hopf wrote:
> Hi all,
> 
> I'm using git-1.2.4 on SL10.1, in centralized style development (for X.org).
> 
> I wanted to commit a set of changes (4 local commits) upstream, so I had
> to do a git-rebase first (in that particular case a git-pull would have
> been possible as well, but git-rebase fits the CVS style development
> better). After git-fetch, git-rebase origin, and git-push all my changes
> had only the first line of the changelog comment, the remainder was
> nuked.
> 
> To reproduce:
> 
> mkdir /var/tmp/blaup
> cd /var/tmp/blaup
> git-init-db
> echo test > foo
> git-add foo
> git-commit      (any comment)
> cd ..
> git-clone /var/tmp/blaup bla
> cd bla
> echo test2 >>foo 
> git-commit foo  (multiline comment)
> cd ../blaup
> echo test3 >bar
> git-add bar
> git-commit      (any comment)
> cd ../bla
> git-fetch
> git-log         (shows multiline comment for 'test2')
> git-rebase origin
> git-log         (shows only the first line of the multiline comment!)
> 
> 

I'm new to git, but I tried what you said.
my git log:
commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
Author: David Kowis <dkowis@kain.org>
Date:   Fri Jun 16 12:20:08 2006 -0500

    this is a multi

    line comment
    with three lines


I'm using git 1.4.0. It added a blank line in there...


David Kowis

ISO Team Lead - www.sourcemage.org
Source Mage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
  - Robert Heinlein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iQGVAwUBRJLo+cnf+vRw63ObAQomewv+L18ogJHgx3jQPt/B+K84GIAX5SugrSnZ
ASC2jm/sbMdidU1goOepXILw2DBOWKSpuDwTZXE0uDrldMTK4RW/2dDACbGVEQX/
Ter4cclIxNztaAwzXGHqKyOI24c5jQmlzW+yDcnErJZTexDA6xyp4xVZlySJpZev
tzfj1Di/uYNJ83lcgS9ID64JToZ5sYZjeqy5HjfEpEQR7xHSYoaR94LNjSHMrqU8
S32ryCMeBSX9SWP8lX7lv6YzIlPGYbOVIsskANVN4GyYVdoMXyXpNtDvziIXrxJj
FkSCloMq5bzVuykthPer0FQRXiySyM1bWsUt9i7Xf3fF8qzyVpIJghP3GAlwh4Gs
LRefaUkkVH61FmN+Uw65xxdx99L4ABoZJDpPBhQdOnY+BXbhNGM5p/lAi3iX72Bx
eIMmaWiwxF8XlIaLJFbDVtGA7lwJzneQQUyHHlTZhzu+VXf4ulKPE93NKEuWWqnL
FD9Tgmu5sFANq5iKSCyocvyAqiWljR8w
=hQWx
-----END PGP SIGNATURE-----

Re: git-rebase nukes multiline comments

[David Kowis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

David Kowis wrote:
<snip>
> 
> I'm new to git, but I tried what you said.
> my git log:
> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
> Author: David Kowis <dkowis@kain.org>
> Date:   Fri Jun 16 12:20:08 2006 -0500
> 
>     this is a multi
> 
>     line comment
>     with three lines
> 
> 
> I'm using git 1.4.0. It added a blank line in there...

I'm going to note that the xorg ML cc doesn't work for anyone not
subscribed... You may miss out on replies.

- --
David Kowis

ISO Team Lead - www.sourcemage.org
Source Mage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
  - Robert Heinlein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iQGVAwUBRJLwn8nf+vRw63ObAQqhmwv7BXLqVSJa2FV6RVhLnmARqh+MHBAX+XLu
zgg/kcYd97pXz9bUEFEmY9tp3afzghA6EQlrV/zRHe/R/e1ZFjvTE27mUe3CvtHu
dUPgx6b85vMLkT2k6jbZ5BoA9KtbNITQlZnQJcEAMBv7aUrclRFykABnXwfh3YxM
jVOGbqoNaKzeB5/Sccb27xnzU91UjztB5X7yNgJYosO6tTz164bQQQbIMGWGztPw
wTwQOPK2+v4oUqfvYbKlX/Fd/Fve6PPWOAj5cUjxPHf47oiF/HY3ir/V/k04qO34
KFKAr10ss/sVm7kbURyj7AWJ/putgy9zzYzSWjqh+4ahTwIFb2ciPsU64o1MsO1K
Mnwz0IowmUUZO57qV0gkYdZyPvudOpV2v52aqMEhMyq8GU56Fvsy0KJma235Sv0r
D0ucIrrorCG0FyY7wKpEM83GJDBaTzxb/Mv8bjCD9/av1uQMjmMvqcPFWsZL+nRx
igTF8LiWzBBEG5b+PPjKlS8uofj8cW5g
=90TM
-----END PGP SIGNATURE-----

Re: git-rebase nukes multiline comments

[Matthias Hopf]

On Jun 16, 06 12:55:43 -0500, David Kowis wrote:
> > I'm new to git, but I tried what you said.
> > my git log:
> > commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
> > Author: David Kowis <dkowis@kain.org>
> > Date:   Fri Jun 16 12:20:08 2006 -0500
> > 
> >     this is a multi
> > 
> >     line comment
> >     with three lines
> > 
> > 
> > I'm using git 1.4.0. It added a blank line in there...

O-key. Did this work w/o a blank line as well? Then we can assume this
solved in 1.4.0. Now there's still the question whether the log messages
in the upstream archive can be restored...

> I'm going to note that the xorg ML cc doesn't work for anyone not
> subscribed... You may miss out on replies.

I'm subscribed here as well :-)
I just CC'ed xorg so people over there know about the issue as well.

CU

Matthias

-- 
Matthias Hopf <mhopf@suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de

Re: git-rebase nukes multiline comments

[Matthias Hopf]

On Jun 19, 06 11:36:23 +0200, Matthias Hopf wrote:
> On Jun 16, 06 12:55:43 -0500, David Kowis wrote:
> O-key. Did this work w/o a blank line as well? Then we can assume this

Ignore my ignorance. I really should *read* before answering...

Sorry

Matthias

-- 
Matthias Hopf <mhopf@suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de

Re: git-rebase nukes multiline comments

[Junio C Hamano]

David Kowis <dkowis@shlrm.org> writes:

> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
> Author: David Kowis <dkowis@kain.org>
> Date:   Fri Jun 16 12:20:08 2006 -0500
>
>     this is a multi
>
>     line comment
>     with three lines
>
>
> I'm using git 1.4.0. It added a blank line in there...

Actually, this is an odd but intended behaviour ;-).

Re: git-rebase nukes multiline comments

[David Kowis]

On Fri, 16 Jun 2006 16:55, Junio C Hamano wrote:
> David Kowis <dkowis@shlrm.org> writes:
>
>>  commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>>  Author: David Kowis <dkowis@kain.org>
>>  Date:   Fri Jun 16 12:20:08 2006 -0500
>>
>>      this is a multi
>>
>>      line comment
>>      with three lines
>>
>>
>>  I'm using git 1.4.0. It added a blank line in there...
>
> Actually, this is an odd but intended behaviour ;-).

Why is this behaviour intended? Just because I'm curoius. :)
-- David Kowis - mobile

Re: git-rebase nukes multiline comments

[Junio C Hamano]

David Kowis <dkowis@shlrm.org> writes:

>>>  commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>>>  Author: David Kowis <dkowis@kain.org>
>>>  Date:   Fri Jun 16 12:20:08 2006 -0500
>>>
>>>      this is a multi
>>>
>>>      line comment
>>>      with three lines
>>>
>>>
>>>  I'm using git 1.4.0. It added a blank line in there...
>>
>> Actually, this is an odd but intended behaviour ;-).
>
> Why is this behaviour intended? Just because I'm curoius. :)

You are not alone; sorry for the terse and confusing initial
response (I am just back from a long flight, finished
unpacking and quite tired).

At the lowest level of git that defines the object format, a
commit object consists of structural header in fixed format,
followed by any binary blob you feed git-commit-tree from the
standard input.  I do not recall the details of the
implementation offhand, but we _might_ chomp at the first NUL
and if we did so I may say it is a bug -- commit-tree should not
care what "the log message" part consists of.

It is however quite a different story when it comes to the
higher level tools that come with git.  The log summarize
facilities to let humans interact with the commits expect that a
commit log message consists of a one-line "summary", a blank
line, and then the body of the message.  These "log listers" are:

 . git log --pretty=oneline
 . gitk
 . gitweb
 . gitview
 . git shortlog

The "one-line summary plus body of the message" has a strong
correlation with how we communicate patches via e-mail.  You do
not start a sentence on the "Subject: " header and continue on
to the body of the message, starting the body halfway of the
sentence.  Instead, you try to make sure you write something
sensible by itself on the "Subject: " header to help the
recipient when later scanning for it among bunch of messages,
and you write a full paragraph that you can understand without
reading the subject line first.  The following commands that
deal with e-mailed patches expect you to follow that convention:

 . git am
 . git applymbox
 . git format-patch

Now, answer to your question why rebase bahaves that way are
because:

 (1) I was lazy and reused the e-mailed patch machinery to
     implement it, although rebase is something that _should_
     work at a level closer to the core level than the human
     level (e.g. it should be able to commute a patch that
     affects binary content changes -- which it does).

 (2) The user should be following the convention to make the
     output from the log listers reasonable anyway, so the only
     people who are harmed by reusing the e-mailed patch
     machinery were people who did not finish a short-and-sweet
     summary sentence on the first line, and it is better to
     train users to do so anyway.

Having said that, I would say it is a bug.  We should be able to
rebase, cherry-pick and/or rebase a patch with an arbitrary
binary garbage in the commit log message (I think the latter two
command do).  But because of the reason (2) above, it is very
low on my priority to change it.

Re: git-rebase nukes multiline comments

[Matthias Hopf]

On Jun 16, 06 16:21:26 -0700, Junio C Hamano wrote:
> Having said that, I would say it is a bug.  We should be able to
> rebase, cherry-pick and/or rebase a patch with an arbitrary
> binary garbage in the commit log message (I think the latter two
> command do).  But because of the reason (2) above, it is very
> low on my priority to change it.

I understand. Many thanks for your explainations. I think this intended
log format should be documented somewhere, that would help a lot. I
don't think that many developers using git in CVS style know about this
convention.

Said that, I assume git nuking the multiline comment was a bug in 1.3.1
that has been (somewhat ;) solved.

Matthias

-- 
Matthias Hopf <mhopf@suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de