From: greened@obbligato.org Date: Tue, 21 Aug 2012 01:52:15 GMT Subject: Re: [PATCH/RFC] [git-subtree.sh] Use raw subject and body modifier "%B" instead of "%s%n%n%b" for commit Message-ID: <87628df1v4.fsf@waller.obbligato.org> In-Reply-To: <1344561358-2953-1-git-send-email-techlivezheng@gmail.com> Techlive Zheng writes: > I don't know if it is the right place to post this patch, I have sended > an email to the original author apenwarr and have no response. According > to , > this is the place, but says > different, which is really confusing. Anyway, here I am. This is the place. > Recently, I imported a foreign git project as a sub directory into a > main repo which I intend to maintain as primary. Ok. > Due to the project I imported has its own remote repo which hosted > on the github, I expected after a 'git-subtree.sh split' the newly > generated subtree branch would be exactly identical to the original > branch. I would have thought so too. > Unfortunately, it is not. I have fixed the committer date and make > everything looks the same with the original branch, but they just did > not end up with same commit sha1 hash. Then, I used `git cat-file -p` > to view the raw output of the both commits and found that the commit > generate by git-subtree has a extra 'new-line' character appended at > the end of the subject which causes the problem. Hmm. > I checked the source and found "%s%n%n%b" were used to generate the > commit message, this works the fine when a commit has a subject as > well as a body, but most of my commits only have a subject under > which condition a extra 'new-line' character is appended. Ah. Yes, we should fix this. > Instead, a raw subject and body message modifier '%B' should be used. Ok. > Though I think this patch should be applied by default, but the mistake > has been there for a long time, applying this patch may cause the patched > git-subtree generate a different branch for those whose subtree branch > has already been generated using the old git-subtree. Maybe this should > be explained in the help or man page, and add a condition check or a > compatible mode somehow. The problem is in the split code? I'm not sure this is a big issue. I can run some experiments. -Dave