To get around the line ending issues you could enforce it with .gitattributes. Im not sure what git format-patch does with line endings
On 5 April 2014 12:28, Jens Geyer <jensge...@hotmail.com> wrote: > Hi all, > > Question 3: git am >> git format-patch -1 >> https://www.kernel.org/doc/Documentation/SubmittingPatches >> > > Cited from the linked doc: > > 7) No MIME, no links, no compression, no attachments. Just plain text. >> >> [...], all patches should be submitting e-mail "inline". >> WARNING: Be wary of your editor's word-wrap corrupting your patch, >> if you choose to cut-n-paste your patch. >> > > I have a bad feeeling regarding that specific part. We already experience > and waste time fighting strange problems from time to time, caused by > incorrect EOL styles, and whitespace changes. Sending a patch as plain text > mail sounds very much like adding a new problem source to the game. It > probably works for Linux only projects, but Thrift is the exact opposite of > $PLATFORM only, and we have to be careful with such things. However, > getting a patch as file attachment is probably ok, as long as we have a > reference to JIRA for everything. How can the latter be ensured? > > JensG > > > -----Ursprüngliche Nachricht----- From: Roger Meier > Sent: Saturday, April 5, 2014 2:34 AM > To: dev@thrift.apache.org > Subject: [DISCUSS] contribution and commit messages > > > All, > > We had several discussion about commit messages on multiple channels. > Let's discuss this here on the dev list. > > Question 1: Documentation > merge HowToCommit + HowToContribute into /CONTRIBUTE.md > and include it easily with our brand new Apache CMS on the web site? > > Question 2: Developer's Certificate of Origin > Today we have this commit style: > --- http://thrift.apache.org/docs/committers/HowToCommit --- > THRIFT-###:<Jira description> > Client: <component> > Patch: <Name of person contributing the patch> > > Description of what was fixed or addressed. > > <% > if this is a github pull request then copy the below block > from the GitHub email that came to dev@ list, this will > automatically close the GitHub pull request > %> > Github Pull Request: This closes #XX > --- http://thrift.apache.org/docs/committers/HowToCommit --- > Hmm, I did something wrong on the Lua commit...sorry! > > What do you think about git best practice known from other projects to > get *Developer's Certificate of Origin*, such as here: > - https://www.kernel.org/doc/Documentation/SubmittingPatches > - http://www.denx.de/wiki/U-Boot/Patches > > e.g. *git commit -s* automatically adds a Signed-off-by line to the > commit message. > Signed-off-by: Patch Creator <pa...@example.org> > > beside of the Signed-off-by tag the following are well known: > Tested-by: Tester <tes...@example.org> > Reviewed-by: Reviewer <revie...@example.org> > Suggested-by: Idea Creator <i...@example.org> > Acked-by: Component Maintainer <maintai...@example.org> > > > Question 3: git am > Would it make sense to start using this? > > Question 4: patch creation > What about that workflow: > git clone https://git-wip-us.apache.org/repos/asf/thrift.git thrift > cd thrift > git pull origin master > # create a local feature branch > git checkout -b THRIFT-1681 > # make the changes and commit to your local feature branch > git commit -a > # format patch > git format-patch -1 > # submit the patch or create a pull request > > > all the best! > roger > ;-r >
