Re: git merge --date --author
Hi, Le vendredi 07 mars 2014 à 11:43 -0800, Junio C Hamano a écrit : > Andreas Schwab writes: > > > Yann Droneaud writes: > > > >> But I'd like to know if there's a specific reason for git merge to not > >> support --date and --author ? > > > > It's rather unusual that a merge is performed on behalf of a different > > author. > > Yes. Michael's "Nobody bothered to implement it" is also correct > but the reason why nobody bothered to most likely is due to "why > would you want to lie?". > When was Git changed in some kind of TSA agent one has to bribe to get allowed to cross^Wcommit ? Why git lawyer is not implemented ? I want a fair trial ! And before adding to Git a perfect lie detector (how will it able to make the difference between truth and lie ? then, will it be able to make the difference between good and bad ?, oh god, no !), I would prefer to have it detect bugs before one could commit instead. You seems to think I'm lying, but I'm not a liar: I just need to make some arrangements with the history under another identity, as I could be legally bound to. So it may sound like a lie for you, but ultimately, it's the plain truth. So as the tool is not in position to distinguish lie from truth, I'd prefer to not see this concept brought here. > If the use case is to rebuild history, you would need to be able to > also lie about the committer, so > > >> git merge \ > >> --date "2013-12-31 23:59:59 +" \ > >> --author "Happy New Year " \ > >> current-year > > in such a history-rebuild script would not be sufficient. The > script can set necessary environment variables to lie about both > author and commiter, though, of course. > Thanks for reminding this: I have to use GIT_COMMITER_DATE, GIT_COMMITER_NAME and GIT_COMMITER_EMAIL. As I'm not calling for adding --date and --author, I will continue to use the environment variables: they're good enough for the job. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git merge --date --author
Hi, I was trying to rebuild some history and found myself trying to use some options with git merge which are available in git commit: git merge \ --date "2013-12-31 23:59:59 +" \ --author "Happy New Year " \ current-year But unfortunately, unlike git commit, git merge doesn't support either --date or --author. I can work around with environment variables: GIT_AUTHOR_DATE="2013-12-31 23:59:59 +" \ GIT_AUTHOR_NAME="Happy New Year" \ GIT_AUTHOR_EMAIL="happy.new-year@gregorian.calendar" \ git merge current-year But I'd like to know if there's a specific reason for git merge to not support --date and --author ? Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git fetch --reference
Hi, I surprised myself trying to run git fetch --reference in the hope git would use my to resolve objects present in but not in my current repository ... just like git clone --reference directory> : --reference If the reference repository is on the local machine, automatically setup .git/objects/info/alternates to obtain objects from the reference repository. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. git fetch --reference would set up a temporary objects/info/alternates ... and skrew everything up. Having a git fetch --reference option would be great, so that I could fetch one remote and the other related one in a row without any special setup. [At this point, you're likely to suggest me to use a local mirror that I would git clone/fetch from, and your probably right, but for a one time hack, it's cumbersome.] In the end I've read http://git-blame.blogspot.fr/2012/08/bringing-bit-more-sanity-to-alternates.html First I thought having "git alternatives add" would enable me to temporary add the --reference before running git fetch ... But it seems --reference doesn't work as I first understand it: git clone --reference don't *copy* object from the --reference instead of *copying* them from the cloned , eg. using --reference as kind of mirror. Instead --reference seems to add a kind of a symlink. And if the --reference disappear, things are going to be lost. See this : http://randyfay.com/content/git-clone-reference-considered-harmfu So setting a temporary alternate with git fetch --reference is a non-sense ... To achieve what I intend to do with this option, a git repack would need to be issued to actually copy the objects from the --reference . So what's the best way to do a git fetch , copying objects from another local repository to resolve delta ? Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Another core.safecrlf behavor with git diff/git status
Hi, Le 24.06.2013 18:55, Junio C Hamano a écrit : Yann Droneaud writes: - Why git diff does not always report the CRLF/LF mismatch ? Most likely because you are telling safecrlf not to error out but just warn, and then you are not fixing the cause of the warning? So diff would say "Ok, you must know what you are doing, so I trust what is in the index", perhaps? - Why git status does not report about the CRLF/LF mismatch before updating the index: My suspicion is the same as "diff". I'm ok with theses answers regarding the test case provided first: the warning was emitted when the files were commited. (But still I would like git diff/git status to behave the same regarding the "index": emit the warning and update the index, I suppose it's not related to core.safecrlf but inner Git way of working). Could you have a look at the other test case I've sent later in this thread / the rebase problem I've sent earlier in another thread. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Another core.safecrlf behavor with git diff/git status
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes "text" flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
[...]
- Why git diff does not always report the CRLF/LF mismatch ?
- Why git status does not report about the CRLF/LF mismatch before
updating the index:
it silently hide the CRLF/LF warning.
git add, git commit report the warning. git status should probably
do the same.
One last try for today, still under Linux, with git 1.8.1.4:
$ git init
Initialized empty Git repository in
/home/ydroneaud/src/tmp/onemore/work1/.git/
$ git commit --allow-empty -m "root"
[master (root-commit) 89c2ff9] root
$ CRLF="\r\n"
$ printf "Hello World 1${CRLF}Hello World 2${CRLF}Hello World
3${CRLF}Hello World 4" > test
$ git add test
$ git commit -m "test"
[master 36d4628] test
1 file changed, 4 insertions(+)
create mode 100644 test
$ echo "test text" > .gitattributes
$ git add .gitattributes
$ git commit -m ".gitattributes"
[master 3b9f3cc] .gitattributes
1 file changed, 1 insertion(+)
create mode 100644 .gitattributes
$ git diff # print nothing
$ git status
# On branch master
nothing to commit, working directory clean
$ touch test
$ git diff
warning: CRLF will be replaced by LF in test.
The file will have its original line endings in your working
directory.
diff --git a/test b/test
index b043836..63ba10f 100644
--- a/test
+++ b/test
@@ -1,4 +1,4 @@
-Hello World 1
-Hello World 2
-Hello World 3
+Hello World 1
+Hello World 2
+Hello World 3
Hello World 4
\ No newline at end of file
- commiting .gitattributes should have trigger a warning about CRLF
conversion
- doing git diff after commiting .gitattributes should have reported the
warning about CRLF/LF.
I dislike complaining all the time about such unusual corner cases, I
apologize not having patches
to provides to Git to try to "fix"/improve this.
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Another core.safecrlf behavor with git diff/git status
Le 24.06.2013 18:37, Yann Droneaud a écrit : I'm still trying to use .gitattributes "text" flag with CRLF line ending files under Linux. I'm surprised about the interaction between the index and the working directory, more specificaly about the interaction between git diff and git status: [...] - Why git diff does not always report the CRLF/LF mismatch ? - Why git status does not report about the CRLF/LF mismatch before updating the index: it silently hide the CRLF/LF warning. git add, git commit report the warning. git status should probably do the same. Can this problem be related to the rebase failure I've described in thread "git rebase fail with CRLF conversion" [1][2][3] ? 1. 2. <http://thread.gmane.org/gmane.comp.version-control.git/228613> 3. <http://marc.info/?l=git&m=137182211414404&w=2> Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Another core.safecrlf behavor with git diff/git status
Hi, I'm still trying to use .gitattributes "text" flag with CRLF line ending files under Linux. I'm surprised about the interaction between the index and the working directory, more specificaly about the interaction between git diff and git status: $ git init Initialized empty Git repository in /home/ydroneaud/tmp/.git/ $ echo "test text" > .gitattributes $ git add .gitattributes $ git commit -m ".gitattributes" [master (root-commit) 67c2a06] attrib 1 file changed, 1 insertion(+) create mode 100644 .gitattributes $ printf "One\r\nLine\r\n" > test $ git add test warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. $ git commit -m "test" [master 8b06aed] test warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. 1 file changed, 2 insertions(+) create mode 100644 test $ git diff # $ touch test $ git diff warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. $ git diff# <= twice warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. $ git status # On branch master nothing to commit, working directory clean $ git diff # - Why git diff does not always report the CRLF/LF mismatch ? - Why git status does not report about the CRLF/LF mismatch before updating the index: it silently hide the CRLF/LF warning. git add, git commit report the warning. git status should probably do the same. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git diff returns fatal error with core.safecrlf is set to true.
Hi, Le 21.06.2013 23:57, Junio C Hamano a écrit : Junio C Hamano writes: The helper may want to learn a way to be told to demote that error to a warning. Perhaps something like this? Thanks for the patch. I run my test again, eg. run git diff after a rebase failure (see my other mail about core.safecrlf), I'm able to run git diff a get a meaningful output: # git version 1.8.1.4 fatal: CRLF would be replaced by LF in test. # git version 1.8.3.1.741.g635527f.dirty (eg. next + your patch) warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. diff --git a/test b/test index b043836..63ba10f 100644 --- a/test +++ b/test @@ -1,4 +1,4 @@ -Hello World 1 -Hello World 2 -Hello World 3 +Hello World 1 +Hello World 2 +Hello World 3 Hello World 4 \ No newline at end of file It seems better. The removed lines have CRLF EOL while the added line have LF line ending characters. Tested-By: Yann Droneaud Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase fail with CRLF conversion
Le 21.06.2013 15:41, Yann Droneaud a écrit : In thoses two latter cases, running "git add" does not fail with a fatal error: it does nothing. I need to run "touch test" to make "git add" fail with error "fatal: CRLF would be replaced by LF in test. While searching on the Internet, I've found other people complaining of a similar error http://stackoverflow.com/questions/5074136/git-rebase-fails-your-local-changes-to-the-following-files-would-be-overwritte The workaround, "git config --global core.trustctime false", might suggest there's a race somewhere while rebasing. BTW, I forgot to describe my environnment: - GNU/Linux - Fedora 18 x86_64 - git version 1.8.1.4 - git version 1.8.3.1.448.gfb7dfaa I believe "git rebase" should not fail here, but more, it must not fail in a different fashion randomly. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0020-crlf: test rebase with text conversion and safecrlf
Le 21.06.2013 16:15, Yann Droneaud a écrit : This patch add two tests to reproduce the problems described in thread "git rebase fail with CRLF conversion" <http://thread.gmane.org/gmane.comp.version-control.git/228613> <http://marc.info/?l=git&m=137182211414404&w=2> - Add and commit a file with CRLF, - Add and commit a .gitattributes with text flag for the file, - Convert CRLF to LF in file, commit the change, - Rebase the whole on top of another parent The rebase currently failed. This scenario is repeated twice, first with core.safecrlf set to warn, a second time with core.safecrlf set to true. Note: those two tests might failed as described in message "git rebase fail with CRLF conversion" <http://thread.gmane.org/gmane.comp.version-control.git/228613> <http://marc.info/?l=git&m=137182211414404&w=2> I haven't found a testcase to reproduce the same exact failure at will. So this patch should probably not used asis until the two kind of errors can be reproduced. Additionnaly, It should also be tested on a CRLF system (Windows). git diff will also fail when core.safecrlf is set to true and the file is not already converted to LF. It might be a test on its own. Regards -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t0020-crlf: test rebase with text conversion and safecrlf
This patch add two tests to reproduce the problems described
in thread "git rebase fail with CRLF conversion"
<http://thread.gmane.org/gmane.comp.version-control.git/228613>
<http://marc.info/?l=git&m=137182211414404&w=2>
- Add and commit a file with CRLF,
- Add and commit a .gitattributes with text flag for the file,
- Convert CRLF to LF in file, commit the change,
- Rebase the whole on top of another parent
The rebase currently failed.
This scenario is repeated twice, first with core.safecrlf set to warn,
a second time with core.safecrlf set to true.
git diff will also fail when core.safecrlf is set to true
and the file is not already converted to LF.
Signed-off-by: Yann Droneaud
---
t/t0020-crlf.sh | 52
1 file changed, 52 insertions(+)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 1a8f44c..12147ba 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -506,4 +506,56 @@ test_expect_success 'New CRLF file gets LF in repo' '
test_cmp alllf alllf2
'
+test_expect_success 'Prepare rebase test' '
+ test_config core.autocrlf false &&
+ test_config core.safecrlf warn &&
+ test_config core.eol native &&
+ git branch rebase-initial &&
+ git checkout -b rebase-other rebase-initial &&
+ git commit --allow-empty -m "Another commit" &&
+ git checkout rebase-initial
+'
+
+# git rebase will failed to apply the "normalization" commit
+test_expect_success 'Rebase with core.safecrlf set to warn (default)' '
+ test_config core.autocrlf false &&
+ test_config core.safecrlf warn &&
+ test_config core.eol native &&
+ git checkout -b rebase-warn rebase-initial &&
+ for w in A couple of lines ; do echo $w ; done | append_cr
>rebase-warn.txt &&
+ git add rebase-warn.txt && git commit -m "Added raw text" &&
+ echo rebase-warn.txt text >> .gitattributes &&
+ git add .gitattributes && git commit -m "Added .gitattributes" &&
+ git rm --cached rebase-warn.txt && git reset --hard &&
+ git add rebase-warn.txt && git commit -m "Normalized" &&
+ git rebase rebase-other || {
+ git status && git diff &&
+ git add rebase-warn.txt && git rebase --continue ;
+ }
+'
+
+#
+# git rebase will failed to apply the "normalization" commit
+# additionnaly
+# git diff and git add will failed when core.safecrlf is set to true
+#
+test_expect_success 'Rebase with core.safecrlf set to true' '
+ test_config core.autocrlf false &&
+ test_config core.safecrlf true &&
+ test_config core.eol native &&
+ git checkout -b rebase-true rebase-initial &&
+ for w in Another couple of lines ; do echo $w ; done | append_cr
>rebase-true.txt &&
+ git add rebase-true.txt && git commit -m "Added raw text" &&
+ echo rebase-true.txt text >> .gitattributes &&
+ git add .gitattributes && git commit -m "Added .gitattributes" &&
+ git diff || git add rebase-true.txt ||
+ for w in Another couple of lines ; do echo $w ; done >rebase-true.txt &&
+ git add rebase-true.txt && git commit -m "Normalized" &&
+ git rebase rebase-other || {
+ git status && git diff || git add rebase-true.txt ||
+ for w in Another couple of lines ; do echo $w ; done
>rebase-true.txt &&
+ git add rebase-true.txt && git rebase --continue ;
+ }
+'
+
test_done
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase fail with CRLF conversion
Hi,
Le 21.06.2013 15:41, Yann Droneaud a écrit :
I believe "git rebase" should not fail here, but more, it must not
fail in a different fashion randomly.
Please find in reply to this email:
- a shell script to demonstrate the behavor
Please find a shell script to test git rebase with .gitattributes text
flag
set to enable End-Of-Line (EOL) conversion from CRLF to LF, with
core.safecrlf set to warn
and to true.
Regards.
--
Yann Droneaud
OPTEYA
--8<--
#! /bin/sh
set -e
LC_ALL=C
export LC_ALL
#GIT_AUTHOR_DATE=`date -R`
GIT_AUTHOR_DATE="2001-01-01 00:00:00.+00:00"
GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
export GIT_AUTHOR_DATE
export GIT_COMMITTER_DATE
# global settings
set +e
global_core_eol=`git config --global core.eol`
global_core_safecrlf=`git config --global core.safecrlf`
global_core_autocrlf=`git config --global core.autocrlf`
set -e
# archive
if test -d work; then
dir=`mktemp -d work.X`
rmdir $dir
mv work $dir
fi
mkdir work
echo "** Testing in work ***"
cd work
# prepare
git init
git commit --allow-empty -m "empty root commit"
# local settings, might be different from the global settings
set +e
local_core_eol=`git config core.eol`
local_core_safecrlf=`git config core.safecrlf`
local_core_autocrlf=`git config core.autocrlf`
set -e
echo "global core.eol = $global_core_eol"
echo "global core.safecrlf = $global_core_safecrlf"
echo "global core.autocrlf = $global_core_autocrlf"
echo "local core.eol= $local_core_eol"
echo "local core.safecrlf = $local_core_safecrlf"
echo "local core.autocrlf = $local_core_autocrlf"
# set default configuration
git config --local core.eol native
git config --local core.safecrl warn
git config --local core.autocrlf false
echo "current core.eol = `git config core.eol`"
echo "current core.safecrlf = `git config core.safecrlf`"
echo "current core.autocrlf = `git config core.autocrlf`"
CRLF="\r\n"
CR="\r"
LF="\n"
# TODO detect line ending on the current environment
if true ; then
EOL=$LF
else
EOL=$CRLF
fi
echo "Create work branches"
git branch import-raw master
git branch import-eol master
echo "Create a branch to be used as new root later"
git checkout import-eol
git commit --allow-empty -m "an empty commit"
file_type=
create_raw_file ()
{
# Want to test mixed EOL:
# printf "Hello World 1${CRLF}Hello World 2${CRLF}${CR}Hello World
3${CRLF}Hello World 4" > test
printf "Hello World 1${CRLF}Hello World 2${CRLF}Hello World
3${CRLF}Hello World 4" > test
file_type="`file test`"
echo "::: $file_type"
}
check_file ()
{
local t="`file test`"
if test "x$file_type" != "x$t" ; then
file_type="$t"
echo "::: $file_type"
fi
}
create_git_attributes ()
{
printf "test text${EOL}" > .gitattributes
}
#
# First test:
#
# import raw, add .gitattributes after, normalize, rebase
#
echo "= BEGIN: first test ="
git checkout import-raw
git reset --hard master
create_raw_file
git add test && check_file
git commit -m "Commit raw" && check_file
create_git_attributes && check_file
git add .gitattributes && check_file
git commit -m "Added git attributes" && check_file
echo "--- First kind of 'normalization'"
#
# trick from https://help.github.com/articles/dealing-with-line-endings
#
git rm --cached test
git reset --hard && check_file
git add test && check_file
git commit -m "Normalization"
check_file
git tag norm1
echo "--- Second kind of 'normalization'"
git reset --hard HEAD^
check_file
create_raw_file
rm test
git checkout test && check_file
git add test && check_file
git commit -m "Normalization"
check_file
git tag norm2
echo "--- Third kind of 'normalization'"
git reset --hard HEAD^
check_file
create_raw_file
dos2unix test && check_file
git add test && check_file
git commit -m "Normalization"
check_file
git tag norm3
echo "--- differences ? ---"
git diff norm1 norm2
git diff norm1 norm3
git diff norm2 norm1
git diff norm2 norm3
git diff norm3 norm1
git diff norm3 norm2
echo "--- rebase, should failed ---"
git rebase import-eol || {
echo "--- Expected failure to rebase on another branch ---"
check_file
git status
git diff -w --stat
git diff
# just adding the file again and continue ...
git add test && check_file
git rebase --continue || { echo "### failed to continue rebase" ;
exit
git rebase fail with CRLF conversion
Hi (again), Following my previous email "Tracking vendor release with Git" [1][2], and the advice from Git users/developers, I'm trying to use .gitattributes to handle CRLF/LF conversion. I'm following advices from: - "Dealing with line endings" https://help.github.com/articles/dealing-with-line-endings - "Tim's Blog, Mind the End of Your Line" http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ - "7.2 Customizing Git - Git Attributes" http://git-scm.com/book/ch7-2.html - "gitattributes(5) Manual Page" https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html While testing the behavor of Git regarding CRLF handling, I've found git rebase fail when trying to apply a commit that's going to fix/convert CRLF to LF. I'm using the following script: A file with CRLF end of line (EOL) "test" is added and commited, then a file .gitattributes is added and commited. The .gitattributes has a single line "test text" to ask git to do EOL conversion. After adding this .gitattributes file, Git start complaining about the line ending to file "test". The file is fixed and commited. Then this branch is rebased on top of another parent. And here come the failures: Most of the time git rebase failed with the following error: ... First, rewinding head to replay your work on top of it... Applying: Commit raw Applying: Added git attributes Applying: Normalization Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... error: Your local changes to the following files would be overwritten by merge: test Please, commit your changes or stash them before you can merge. Aborting Failed to merge in the changes. Patch failed at 0003 Normalization ... But sometime it failed with another error: with core.safecrlf = warn: ... First, rewinding head to replay your work on top of it... Applying: Commit raw Applying: Added git attributes warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. Applying: Normalization fatal: unrecognized input Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0003 Normalization ... with core.safecrlf = true: ... First, rewinding head to replay your work on top of it... Applying: Commit raw Applying: Added git attributes fatal: CRLF would be replaced by LF in test. Applying: Normalization fatal: unrecognized input Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0003 Normalization ... In thoses two latter cases, running "git add" does not fail with a fatal error: it does nothing. I need to run "touch test" to make "git add" fail with error "fatal: CRLF would be replaced by LF in test. I believe "git rebase" should not fail here, but more, it must not fail in a different fashion randomly. Please find in reply to this email: - a shell script to demonstrate the behavor - a patch to t0020-crlf.sh to add two rebase tests. 1. <1370970410-7935-1-git-send-email-ydrone...@opteya.com> 2. <http://thread.gmane.org/gmane.comp.version-control.git/227466> <http://marc.info/?l=git&m=137097069115462&w=2> Regards -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git diff returns fatal error with core.safecrlf is set to true.
Hi, Following my previous email "Tracking vendor release with Git" [1][2], and the advice from Git users/developers, I'm trying to use .gitattributes to handle CRLF/LF conversion. While testing the behavor of Git regarding CRLF handling, when core.safecrlf is set to true, I've found that "git diff" is returning "fatal: CRLF would be replaced by LF" without returning any kind of diff. This make me wonder if its the correct behavor for git diff to (only) fail: It should be fatal for git add / git commit ( / git cherry-pick / ... ?), but non fatal for git diff. According to the documentation git-config(5) [3]: "Git will verify if a command modifies a file in the work tree either directly or indirectly" I don't thing "git diff" is an operation that could modify a file. Regards. 1. <1370970410-7935-1-git-send-email-ydrone...@opteya.com> 2. <http://thread.gmane.org/gmane.comp.version-control.git/227466> <http://marc.info/?l=git&m=137097069115462&w=2> 3. https://www.kernel.org/pub/software/scm/git/docs/git-config.html -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tracking vendor release with Git
tion.
In some article[1], I've found an explanation of the lack of
"git merge -s theirs", quoting maintainer opinion[2] regarding it.
[1] <http://www.seanius.net/blog/2011/02/git-merge-s-theirs/>
[2] <http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89024>
I was able to use "git merge --strategy=recursive --strategy-option=theirs" aka.
"git merge -X theirs". So I'm only frustrated to see my workflow not being
considered. But happy to be able to do it with "uncommon" options.
Appended here a script to reproduce the workflow described previously:
#! /bin/sh
set -e
GIT_AUTHOR_DATE=`date -R`
GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
export GIT_AUTHOR_DATE
export GIT_COMMITTER_DATE
# cleanup
rm -rf .git main.c
# prepare
git init
git commit --allow-empty -m "empty root commit"
git branch downstream master
git branch upstream master
#
# import first upstream release: v1
git checkout upstream
cat > main.c < main.c < main.c < main.c <
/* version string */
#define VERSION "2"
int
main(void)
{
printf("version " VERSION "\n");
}
EOF
git add main.c
git commit -m "Fix 2"
# make the "fixed" release available
# merge the integration branch
git checkout downstream
git merge --no-edit --no-ff upstream-2-fix
git tag downstream-default-2
#
# new upstream release: v3
git checkout upstream
cat > main.c < main.c <
/* version string */
#define VERSION "3"
#define PACKAGE "foo"
int
main(void)
{
printf("version " VERSION "\n");
return 0;
}
EOF
git add main.c
git commit -m "Fix 3"
# make the "fixed" release available
# try to merge the integration branch
git checkout downstream
git merge --no-edit --no-ff upstream-3-fix || {
echo "Merge failed, \"manually\" resolve conflict ..."
cat > main.c <
/* version string */
#define VERSION "3"
#define PACKAGE "foo"
int
main(void)
{
printf("version " VERSION "\n");
return 0;
}
EOF
git add main.c
git commit --no-edit
}
git tag downstream-default-3
# now, try a different merge strategy
git checkout master
git branch -D downstream
git branch downstream master
git checkout downstream
git merge --no-edit --no-ff --strategy-option theirs upstream-1-fix
git tag downstream-theirs-1
git merge --no-edit --no-ff --strategy-option theirs upstream-2-fix
git tag downstream-theirs-2
git merge --no-edit --no-ff --strategy-option theirs upstream-3-fix
git tag downstream-theirs-3
git checkout master
# "default" and "theirs" should match
# but have a different commit message:
# no conflict reported for "theirs"
git diff downstream-default-3 downstream-theirs-3
# Regards !
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tracking vendor release with Git
-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: override merge.ff = false using --ff-only
Hi, Le 22.05.2013 15:21, Matt McClure a écrit : I naively tried to override merge.ff = false using --ff-only on the command line. I expected that it would override the configured default and perform a fast-forward merge. Instead, it said: $ git config -l | grep -F 'merge.ff' merge.ff=false $ git merge --ff-only foo fatal: You cannot combine --no-ff with --ff-only. On the other hand, I see that --ff works just fine in the same initial state. You might want to read the following messages from thread "git merge behavior" http://article.gmane.org/gmane.comp.version-control.git/218519 http://article.gmane.org/gmane.comp.version-control.git/218755 http://article.gmane.org/gmane.comp.version-control.git/218786 Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-tag(1): we tag HEAD by default
Hi,
Le 03.04.2013 16:27, Thomas Rast a écrit :
The | argument is actually not explained anywhere
(except implicitly in the description of an unannotated tag). Write
a
little explanation, in particular to cover the default.
+, ::
+ The object that the new tag will refer to, usually a commit.
+ Defaults to HEAD.
+
+
This puzzled me a lot, so I try various configuration:
- I was able to create an annotated tag on an annotated tag (this can
be recursively)
git tag -a -m "tagged a tag" test_tag_tag v1.8.2
git show test_tag_tag
- I was able to tag a file
git tag -a -m "tagged a file" test_tag_file `git ls-tree HEAD | awk
'{ print $3; exit; }'`
git show test_tag_file
git show -p test_tag_file
Is there any other kind of object that can be tagged ... and what is
the purpose of this ?
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] merge: a random object may not necssarily be a commit
Hi, Le lundi 01 avril 2013 à 12:57 -0700, Junio C Hamano a écrit : > The user could have said "git merge $(git rev-parse v1.0.0)"; we > shouldn't mark it as "Merge commit '1598fb...'" as the merge > name, even though such an invocation might be crazy. > > We could even read the "tag " header from the tag object and replace > the object name the user gave us, but let's not lose the information > by doing so, at least not yet. > > Signed-off-by: Junio C Hamano Thanks for the patch. I gave it a try and found the behavior rather good. Merging a tag object by its name or by its object-id are now using the same behavor: it is more consistent. Tested-by: Yann Droneaud PS: there's a typo in the commit title :) Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] Use test_config
Hi, Le 27.03.2013 16:05, Junio C Hamano a écrit : Yann Droneaud writes: Tested against master, 7b592fadf1e23b10b913e0771b9f711770597266 Is this because I suggested you to clean things up while you were touching in a vicinity of something that could use this clean-up? Yes, grep'ing shows others usage of the test_config pattern. I patched them all. If so, please first clean _that_ script in a patch, and then add the change you wanted to do in another patch, as a single two-patch series, without touching anything else that is not related to that change. The patch to t7600 is the one that needs to become two patches, one to clean up and the other to add tests for --no-ff. Actually the initial patch adding test for --no-ff-only is not part of this series. Patch against t7600 has a special note about a strange behavor found while testing test_config "anyware", that's why there's somes line added to the test and a note in the commit message. I was waiting for your opinion on this change in the test, but more, on the difference of behavior exhibited in the patched test "merge log message": git merge --no-log git show -s --pretty=format:%b HEAD vs git merge --no-ff --no-log git show -s --pretty=format:%b HEAD First produce an empty file, while the second produce an empty line. This was revealed by changing test "merge c0 with c1 (ff overrides no-ff) -git config branch.master.mergeoptions "--no-ff" && -test_config branch.master.mergeoptions "--no-ff" && I could split this patch in a first patch that add the behavor test to "merge log message" test, than I could rebase the patch series against. And later, submit my proposition for new tests in t7600 regarding --no-ff-only and tags. The rest, as a separate "only cleaning up, doing nothing else" series, are fine as a follow-up, but please make sure that they do not touch anything in-flight (one easy way to check is to see "git diff --name-only maint pu -- t/"). I would prefer to see "clean-up only" changes that introduce unnecessary conflicts with other real features and fixes held off until the dust settles. It's a good advice that fit perfectly in Documentation/SubmittingPatches. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] t7600: use test_config to set/unset git config variables
Instead of using construct such as:
test_when_finished "git config --unset "
git config
uses
test_config
The latter takes care of removing at the end of the test.
Tests are modified to assume default configuration at entry,
and to reset the modified configuration variables at the end.
Test 'merge log message' was relying on the presence of option `--no-ff`
in the configuration. With the option, git show -s --pretty=format:%b HEAD
produces an empty line and without the option, it produces an empty file.
The test is modified to check with and without `--no-ff` option.
Signed-off-by: Yann Droneaud
---
t/t7600-merge.sh | 60
1 file changed, 26 insertions(+), 34 deletions(-)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 5e19598..2f70433 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -56,7 +56,8 @@ create_merge_msgs () {
echo &&
git log --no-merges ^HEAD c2 c3
} >squash.1-5-9 &&
- echo >msg.nolog &&
+ : >msg.nologff &&
+ echo >msg.nolognoff &&
{
echo "* tag 'c3':" &&
echo " commit 3" &&
@@ -244,8 +245,7 @@ test_expect_success 'merges with --ff-only' '
test_expect_success 'merges with merge.ff=only' '
git reset --hard c1 &&
test_tick &&
- test_when_finished "git config --unset merge.ff" &&
- git config merge.ff only &&
+ test_config merge.ff "only" &&
test_must_fail git merge c2 &&
test_must_fail git merge c3 &&
test_must_fail git merge c2 c3 &&
@@ -336,7 +336,7 @@ test_debug 'git log --graph --decorate --oneline --all'
test_expect_success 'merge c1 with c2 (no-commit in config)' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--no-commit" &&
+ test_config branch.master.mergeoptions "--no-commit" &&
git merge c2 &&
verify_merge file result.1-5 &&
verify_head $c1 &&
@@ -346,12 +346,11 @@ test_expect_success 'merge c1 with c2 (no-commit in
config)' '
test_debug 'git log --graph --decorate --oneline --all'
test_expect_success 'merge c1 with c2 (log in config)' '
- git config branch.master.mergeoptions "" &&
git reset --hard c1 &&
git merge --log c2 &&
git show -s --pretty=tformat:%s%n%b >expect &&
- git config branch.master.mergeoptions --log &&
+ test_config branch.master.mergeoptions "--log" &&
git reset --hard c1 &&
git merge c2 &&
git show -s --pretty=tformat:%s%n%b >actual &&
@@ -360,17 +359,12 @@ test_expect_success 'merge c1 with c2 (log in config)' '
'
test_expect_success 'merge c1 with c2 (log in config gets overridden)' '
- test_when_finished "git config --remove-section branch.master" &&
- test_when_finished "git config --remove-section merge" &&
- test_might_fail git config --remove-section branch.master &&
- test_might_fail git config --remove-section merge &&
-
git reset --hard c1 &&
git merge c2 &&
git show -s --pretty=tformat:%s%n%b >expect &&
- git config branch.master.mergeoptions "--no-log" &&
- git config merge.log true &&
+ test_config branch.master.mergeoptions "--no-log" &&
+ test_config merge.log "true" &&
git reset --hard c1 &&
git merge c2 &&
git show -s --pretty=tformat:%s%n%b >actual &&
@@ -380,7 +374,7 @@ test_expect_success 'merge c1 with c2 (log in config gets
overridden)' '
test_expect_success 'merge c1 with c2 (squash in config)' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--squash" &&
+ test_config branch.master.mergeoptions "--squash" &&
git merge c2 &&
verify_merge file result.1-5 &&
verify_head $c1 &&
@@ -392,7 +386,7 @@ test_debug 'git log --graph --decorate --oneline --all'
test_expect_success 'override config option -n with --summary' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "-n" &&
+ test_config branch.master.mergeoptions "-n" &&
test_t
[PATCH 15/15] t7502: remove clear_config
Using test_config ensure the configuration variable are removed
at the end of the test, there's no need to remove variable
at the beginning of the test.
Signed-off-by: Yann Droneaud
---
t/t7502-commit.sh | 32 ++--
1 file changed, 6 insertions(+), 26 deletions(-)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 619d438..256137f 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -434,16 +434,6 @@ EOF
echo '## Custom template' >template
-clear_config () {
- (
- git config --unset-all "$1"
- case $? in
- 0|5)exit 0 ;;
- *) exit 1 ;;
- esac
- )
-}
-
try_commit () {
git reset --hard &&
echo >>negative &&
@@ -459,67 +449,57 @@ try_commit () {
try_commit_status_combo () {
test_expect_success 'commit' '
- clear_config commit.status &&
try_commit "" &&
test_i18ngrep "^# Changes to be committed:" .git/COMMIT_EDITMSG
'
test_expect_success 'commit' '
- clear_config commit.status &&
try_commit "" &&
test_i18ngrep "^# Changes to be committed:" .git/COMMIT_EDITMSG
'
test_expect_success 'commit --status' '
- clear_config commit.status &&
try_commit --status &&
test_i18ngrep "^# Changes to be committed:" .git/COMMIT_EDITMSG
'
test_expect_success 'commit --no-status' '
- clear_config commit.status &&
try_commit --no-status &&
test_i18ngrep ! "^# Changes to be committed:"
.git/COMMIT_EDITMSG
'
test_expect_success 'commit with commit.status = yes' '
- clear_config commit.status &&
- git config commit.status yes &&
+ test_config commit.status yes &&
try_commit "" &&
test_i18ngrep "^# Changes to be committed:" .git/COMMIT_EDITMSG
'
test_expect_success 'commit with commit.status = no' '
- clear_config commit.status &&
- git config commit.status no &&
+ test_config commit.status no &&
try_commit "" &&
test_i18ngrep ! "^# Changes to be committed:"
.git/COMMIT_EDITMSG
'
test_expect_success 'commit --status with commit.status = yes' '
- clear_config commit.status &&
- git config commit.status yes &&
+ test_config commit.status yes &&
try_commit --status &&
test_i18ngrep "^# Changes to be committed:" .git/COMMIT_EDITMSG
'
test_expect_success 'commit --no-status with commit.status = yes' '
- clear_config commit.status &&
- git config commit.status yes &&
+ test_config commit.status yes &&
try_commit --no-status &&
test_i18ngrep ! "^# Changes to be committed:"
.git/COMMIT_EDITMSG
'
test_expect_success 'commit --status with commit.status = no' '
- clear_config commit.status &&
- git config commit.status no &&
+ test_config commit.status no &&
try_commit --status &&
test_i18ngrep "^# Changes to be committed:" .git/COMMIT_EDITMSG
'
test_expect_success 'commit --no-status with commit.status = no' '
- clear_config commit.status &&
- git config commit.status no &&
+ test_config commit.status no &&
try_commit --no-status &&
test_i18ngrep ! "^# Changes to be committed:"
.git/COMMIT_EDITMSG
'
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] t5520: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t5520-pull.sh | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh index 35304b4..cb1a4c5 100755 --- a/t/t5520-pull.sh +++ b/t/t5520-pull.sh @@ -96,8 +96,7 @@ test_expect_success '--rebase' ' ' test_expect_success 'pull.rebase' ' git reset --hard before-rebase && - git config --bool pull.rebase true && - test_when_finished "git config --unset pull.rebase" && + test_config pull.rebase true && git pull . copy && test $(git rev-parse HEAD^) = $(git rev-parse copy) && test new = $(git show HEAD:file2) @@ -105,8 +104,7 @@ test_expect_success 'pull.rebase' ' test_expect_success 'branch.to-rebase.rebase' ' git reset --hard before-rebase && - git config --bool branch.to-rebase.rebase true && - test_when_finished "git config --unset branch.to-rebase.rebase" && + test_config branch.to-rebase.rebase true && git pull . copy && test $(git rev-parse HEAD^) = $(git rev-parse copy) && test new = $(git show HEAD:file2) @@ -114,10 +112,8 @@ test_expect_success 'branch.to-rebase.rebase' ' test_expect_success 'branch.to-rebase.rebase should override pull.rebase' ' git reset --hard before-rebase && - git config --bool pull.rebase true && - test_when_finished "git config --unset pull.rebase" && - git config --bool branch.to-rebase.rebase false && - test_when_finished "git config --unset branch.to-rebase.rebase" && + test_config pull.rebase true && + test_config branch.to-rebase.rebase false && git pull . copy && test $(git rev-parse HEAD^) != $(git rev-parse copy) && test new = $(git show HEAD:file2) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] t4034: use test_config/test_unconfig to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Additionally, instead of git config "" or git config --unset uses test_unconfig The latter doesn't failed if is not defined. Signed-off-by: Yann Droneaud --- t/t4034-diff-words.sh | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh index 40ab333..f2f55fc 100755 --- a/t/t4034-diff-words.sh +++ b/t/t4034-diff-words.sh @@ -230,7 +230,7 @@ test_expect_success '.gitattributes override config' ' ' test_expect_success 'setup: remove diff driver regex' ' - test_might_fail git config --unset diff.testdriver.wordRegex + test_unconfig diff.testdriver.wordRegex ' test_expect_success 'use configured regex' ' @@ -335,8 +335,7 @@ test_expect_success 'word-diff with diff.sbe' ' c EOF - test_when_finished "git config --unset diff.suppress-blank-empty" && - git config diff.suppress-blank-empty true && + test_config diff.suppress-blank-empty true && word_diff --word-diff=plain ' @@ -368,7 +367,7 @@ test_expect_success 'setup history with two files' ' test_expect_success 'wordRegex for the first file does not apply to the second' ' echo "*.tex diff=tex" >.gitattributes && - git config diff.tex.wordRegex "[a-z]+|." && + test_config diff.tex.wordRegex "[a-z]+|." && cat >expect <<-\EOF && diff --git a/a.tex b/a.tex --- a/a.tex -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/15] t7500: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t7500-commit.sh | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh index 1c908f4..436b7b6 100755 --- a/t/t7500-commit.sh +++ b/t/t7500-commit.sh @@ -36,8 +36,7 @@ test_expect_success 'nonexistent template file should return error' ' ' test_expect_success 'nonexistent template file in config should return error' ' - git config commit.template "$PWD"/notexist && - test_when_finished "git config --unset commit.template" && + test_config commit.template "$PWD"/notexist && ( GIT_EDITOR="echo hello >\"\$1\"" && export GIT_EDITOR && @@ -93,14 +92,13 @@ test_expect_success '-t option should be short for --template' ' test_expect_success 'config-specified template should commit' ' echo "new template" > "$TEMPLATE" && - git config commit.template "$TEMPLATE" && + test_config commit.template "$TEMPLATE" && echo "more content" >> foo && git add foo && ( test_set_editor "$TEST_DIRECTORY"/t7500/add-content && git commit ) && - git config --unset commit.template && commit_msg_is "new templatecommit message" ' -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] t7502: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t7502-commit.sh | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh index f9b44b7..619d438 100755 --- a/t/t7502-commit.sh +++ b/t/t7502-commit.sh @@ -171,10 +171,9 @@ test_expect_success 'verbose' ' test_expect_success 'verbose respects diff config' ' - git config color.diff always && + test_config color.diff always && git status -v >actual && - grep "\[1mdiff --git" actual && - git config --unset color.diff + grep "\[1mdiff --git" actual ' mesg_with_comment_and_newlines=' @@ -534,8 +533,7 @@ use_template="-t template" try_commit_status_combo test_expect_success 'commit --status with custom comment character' ' - test_when_finished "git config --unset core.commentchar" && - git config core.commentchar ";" && + test_config core.commentchar ";" && try_commit --status && test_i18ngrep "^; Changes to be committed:" .git/COMMIT_EDITMSG ' -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] t4304: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Tests are modified to assume correct (default) configuration at entry, and to reset the modified configuration variables at the end. Signed-off-by: Yann Droneaud --- t/t3404-rebase-interactive.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index 15dcbd4..a58406d 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -937,8 +937,7 @@ test_expect_success 'rebase --edit-todo can be used to modify todo' ' test_expect_success 'rebase -i respects core.commentchar' ' git reset --hard && git checkout E^0 && - git config core.commentchar "\\" && - test_when_finished "git config --unset core.commentchar" && + test_config core.commentchar "\\" && write_script remove-all-but-first.sh <<-\EOF && sed -e "2,\$s/^//" "$1" >"$1.tmp" && mv "$1.tmp" "$1" -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/15] t9500: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t9500-gitweb-standalone-no-errors.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh index 90bb605..6783c14 100755 --- a/t/t9500-gitweb-standalone-no-errors.sh +++ b/t/t9500-gitweb-standalone-no-errors.sh @@ -539,8 +539,7 @@ test_expect_success \ test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" && echo "ISO-8859-1" >> file && git add file && -git config i18n.commitencoding ISO-8859-1 && -test_when_finished "git config --unset i18n.commitencoding" && +test_config i18n.commitencoding ISO-8859-1 && git commit -F "$TEST_DIRECTORY"/t3900/ISO8859-1.txt && gitweb_run "p=.git;a=commit"' -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/15] t5541: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t5541-http-push.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh index 4b4b4a6..4086f02 100755 --- a/t/t5541-http-push.sh +++ b/t/t5541-http-push.sh @@ -181,8 +181,7 @@ test_expect_success 'push (chunked)' ' git checkout master && test_commit commit path3 && HEAD=$(git rev-parse --verify HEAD) && - git config http.postbuffer 4 && - test_when_finished "git config --unset http.postbuffer" && + test_config http.postbuffer 4 && git push -v -v origin $BRANCH 2>err && grep "POST git-receive-pack (chunked)" err && (cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git && -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] t7811: remove test_config implementation
test_config is provided by the test library,
a private version is not needed.
Signed-off-by: Yann Droneaud
---
t/t7811-grep-open.sh | 5 -
1 file changed, 5 deletions(-)
diff --git a/t/t7811-grep-open.sh b/t/t7811-grep-open.sh
index a895778..e1951a5 100755
--- a/t/t7811-grep-open.sh
+++ b/t/t7811-grep-open.sh
@@ -125,11 +125,6 @@ test_expect_success 'modified file' '
test_cmp empty out
'
-test_config() {
- git config "$1" "$2" &&
- test_when_finished "git config --unset $1"
-}
-
test_expect_success 'copes with color settings' '
rm -f actual &&
echo grep.h >expect &&
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/15] t7508: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t7508-status.sh | 46 -- 1 file changed, 16 insertions(+), 30 deletions(-) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index aecb4d1..e2ffdac 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -131,8 +131,7 @@ cat >expect <<\EOF EOF test_expect_success 'status (advice.statusHints false)' ' - test_when_finished "git config --unset advice.statusHints" && - git config advice.statusHints false && + test_config advice.statusHints false && git status >output && test_i18ncmp expect output @@ -332,8 +331,7 @@ test_expect_success 'status -uno' ' ' test_expect_success 'status (status.showUntrackedFiles no)' ' - git config status.showuntrackedfiles no - test_when_finished "git config --unset status.showuntrackedfiles" && + test_config status.showuntrackedfiles no && git status >output && test_i18ncmp expect output ' @@ -348,12 +346,11 @@ cat >expect <output && test_i18ncmp expect output ' -git config --unset advice.statusHints cat >expect << EOF M dir1/modified @@ -400,8 +397,7 @@ test_expect_success 'status -unormal' ' ' test_expect_success 'status (status.showUntrackedFiles normal)' ' - git config status.showuntrackedfiles normal - test_when_finished "git config --unset status.showuntrackedfiles" && + test_config status.showuntrackedfiles normal git status >output && test_i18ncmp expect output ' @@ -459,8 +455,7 @@ test_expect_success 'status -uall' ' ' test_expect_success 'status (status.showUntrackedFiles all)' ' - git config status.showuntrackedfiles all - test_when_finished "git config --unset status.showuntrackedfiles" && + test_config status.showuntrackedfiles all git status >output && test_i18ncmp expect output ' @@ -485,10 +480,9 @@ test_expect_success 'status -s -uall' ' test_cmp expect output ' test_expect_success 'status -s (status.showUntrackedFiles all)' ' - git config status.showuntrackedfiles all + test_config status.showuntrackedfiles all && git status -s >output && rm -rf dir3 && - git config --unset status.showuntrackedfiles && test_cmp expect output ' @@ -588,15 +582,13 @@ cat >expect <<\EOF EOF test_expect_success 'status with color.ui' ' - git config color.ui always && - test_when_finished "git config --unset color.ui" && + test_config color.ui always && git status | test_decode_color >output && test_i18ncmp expect output ' test_expect_success 'status with color.status' ' - git config color.status always && - test_when_finished "git config --unset color.status" && + test_config color.status always && git status | test_decode_color >output && test_i18ncmp expect output ' @@ -720,8 +712,7 @@ EOF test_expect_success 'status without relative paths' ' - git config status.relativePaths false && - test_when_finished "git config --unset status.relativePaths" && + test_config status.relativePaths false && (cd dir1 && git status) >output && test_i18ncmp expect output @@ -740,8 +731,7 @@ EOF test_expect_success 'status -s without relative paths' ' - git config status.relativePaths false && - test_when_finished "git config --unset status.relativePaths" && + test_config status.relativePaths false && (cd dir1 && git status -s) >output && test_cmp expect output @@ -1038,15 +1028,14 @@ test_expect_success '--ignore-submodules=untracked suppresses submodules with un ' test_expect_success '.gitmodules ignore=untracked suppresses submodules with untracked content' ' - git config diff.ignoreSubmodules dirty && + test_config diff.ignoreSubmodules dirty && git status >output && test_i18ncmp expect output && git config --add -f .gitmodules submodule.subname.ignore untracked && git config -
[PATCH 07/15] t4202: use test_config/test_unconfig to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Additionally, instead of git config "" or git config --unset uses test_unconfig The latter doesn't failed if is not defined. Tests are modified to assume correct (default) configuration at entry, and to reset the modified configuration variables at the end. Signed-off-by: Yann Droneaud --- t/t4202-log.sh | 28 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/t/t4202-log.sh b/t/t4202-log.sh index fa686b8..9243a97 100755 --- a/t/t4202-log.sh +++ b/t/t4202-log.sh @@ -419,8 +419,6 @@ test_expect_success 'log --graph with merge' ' ' test_expect_success 'log.decorate configuration' ' - test_might_fail git config --unset-all log.decorate && - git log --oneline >expect.none && git log --oneline --decorate >expect.short && git log --oneline --decorate=full >expect.full && @@ -429,8 +427,7 @@ test_expect_success 'log.decorate configuration' ' git log --oneline >actual && test_cmp expect.short actual && - git config --unset-all log.decorate && - git config log.decorate true && + test_config log.decorate true && git log --oneline >actual && test_cmp expect.short actual && git log --oneline --decorate=full >actual && @@ -438,8 +435,7 @@ test_expect_success 'log.decorate configuration' ' git log --oneline --decorate=no >actual && test_cmp expect.none actual && - git config --unset-all log.decorate && - git config log.decorate no && + test_config log.decorate no && git log --oneline >actual && test_cmp expect.none actual && git log --oneline --decorate >actual && @@ -447,8 +443,7 @@ test_expect_success 'log.decorate configuration' ' git log --oneline --decorate=full >actual && test_cmp expect.full actual && - git config --unset-all log.decorate && - git config log.decorate 1 && + test_config log.decorate 1 && git log --oneline >actual && test_cmp expect.short actual && git log --oneline --decorate=full >actual && @@ -456,8 +451,7 @@ test_expect_success 'log.decorate configuration' ' git log --oneline --decorate=no >actual && test_cmp expect.none actual && - git config --unset-all log.decorate && - git config log.decorate short && + test_config log.decorate short && git log --oneline >actual && test_cmp expect.short actual && git log --oneline --no-decorate >actual && @@ -465,8 +459,7 @@ test_expect_success 'log.decorate configuration' ' git log --oneline --decorate=full >actual && test_cmp expect.full actual && - git config --unset-all log.decorate && - git config log.decorate full && + test_config log.decorate full && git log --oneline >actual && test_cmp expect.full actual && git log --oneline --no-decorate >actual && @@ -474,16 +467,15 @@ test_expect_success 'log.decorate configuration' ' git log --oneline --decorate >actual && test_cmp expect.short actual - git config --unset-all log.decorate && + test_unconfig log.decorate && git log --pretty=raw >expect.raw && - git config log.decorate full && + test_config log.decorate full && git log --pretty=raw >actual && test_cmp expect.raw actual ' test_expect_success 'reflog is expected format' ' - test_might_fail git config --remove-section log && git log -g --abbrev-commit --pretty=oneline >expect && git reflog >actual && test_cmp expect actual @@ -496,10 +488,6 @@ test_expect_success 'whatchanged is expected format' ' ' test_expect_success 'log.abbrevCommit configuration' ' - test_when_finished "git config --unset log.abbrevCommit" && - - test_might_fail git config --unset log.abbrevCommit && - git log --abbrev-commit >expect.log.abbrev && git log --no-abbrev-commit >expect.log.full && git log --pretty=raw >expect.log.raw && @@ -508,7 +496,7 @@ test_expect_success 'log.abbrevCommit configuration' ' git whatchanged --abbrev-commit >expect.whatchanged.abbrev && git whatchanged --no-abbrev-commit >expect.whatchanged.full && - git config log.abbrevCommit true && + test_config log.abbrevCommit true && git log >actual && test_cmp expect.log.abbrev actual && -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] t3400: use test_config to set/unset git config variables
Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Signed-off-by: Yann Droneaud --- t/t3400-rebase.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index 1de0ebd..f6cc102 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -138,8 +138,7 @@ test_expect_success 'rebase a single mode change' ' ' test_expect_success 'rebase is not broken by diff.renames' ' - git config diff.renames copies && - test_when_finished "git config --unset diff.renames" && + test_config diff.renames copies && git checkout filemove && GIT_TRACE=1 git rebase force-3way ' -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/15] t7810: remove test_config implementation
test_config is provided by the test library,
a private version is not needed.
Signed-off-by: Yann Droneaud
---
t/t7810-grep.sh | 5 -
1 file changed, 5 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index f698001..500eb50 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -1084,11 +1084,6 @@ test_expect_success 'grep -E pattern with
grep.patternType=fixed' '
test_cmp expected actual
'
-test_config() {
- git config "$1" "$2" &&
- test_when_finished "git config --unset $1"
-}
-
cat >expected <:int main(int argc, const char **argv)
hello.c-{
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] t4018: remove test_config implementation
test_config is provided by the test library,
a private version is not needed.
Signed-off-by: Yann Droneaud
---
t/t4018-diff-funcname.sh | 5 -
1 file changed, 5 deletions(-)
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 082d3e8..38a092a 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -93,11 +93,6 @@ sed -e '
s/song;/song();/
' Beer-correct.perl
-test_config () {
- git config "$1" "$2" &&
- test_when_finished "git config --unset $1"
-}
-
test_expect_funcname () {
lang=${2-java}
test_expect_code 1 git diff --no-index -U1 \
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] Use test_config
Please find some patches to use test_config/test_unconfig Instead of using construct such as: test_when_finished "git config --unset " git config uses test_config The latter takes care of removing at the end of the test. Additionally, instead of git config "" or git config --unset uses test_unconfig The latter doesn't failed if is not defined. Patch "t7600: use test_config to set/unset git config variables" is more important than the other and must be carefully reviewed regarded to the --no-log --no-ff behavior. Others patches are fairly simple. Testsuite results are the same after the patches. Tested against master, 7b592fadf1e23b10b913e0771b9f711770597266 Yann Droneaud (15): t4018: remove test_config implementation t7810: remove test_config implementation t7811: remove test_config implementation t3400: use test_config to set/unset git config variables t4304: use test_config to set/unset git config variables t4034: use test_config/test_unconfig to set/unset git config variables t4202: use test_config/test_unconfig to set/unset git config variables t5520: use test_config to set/unset git config variables t5541: use test_config to set/unset git config variables t7500: use test_config to set/unset git config variables t7502: use test_config to set/unset git config variables t7508: use test_config to set/unset git config variables t7600: use test_config to set/unset git config variables t9500: use test_config to set/unset git config variables t7502: remove clear_config t/t3400-rebase.sh | 3 +- t/t3404-rebase-interactive.sh | 3 +- t/t4018-diff-funcname.sh | 5 --- t/t4034-diff-words.sh | 7 ++-- t/t4202-log.sh | 28 +--- t/t5520-pull.sh| 12 +++ t/t5541-http-push.sh | 3 +- t/t7500-commit.sh | 6 ++-- t/t7502-commit.sh | 40 +-- t/t7508-status.sh | 46 +- t/t7600-merge.sh | 60 +++--- t/t7810-grep.sh| 5 --- t/t7811-grep-open.sh | 5 --- t/t9500-gitweb-standalone-no-errors.sh | 3 +- 14 files changed, 72 insertions(+), 154 deletions(-) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t7600: merge tag shoud create a merge commit
Le 22.03.2013 15:48, Junio C Hamano a écrit : It's not in final shape: the line EDITOR=false test_must_fail git merge signed Because test_must_fail is a shell function, single-shot environment assignment like this should not be used. It's used throughout the test. The test 'merge --no-edit tag should skip editor' is using it. Before posting my half useful test, I used "EDITOR=false test_must_fail set" in --verbose mode to find if EDITOR was correctly defined passed test_must_fail, and it was. So it's still not clear why it's failing at failing. And it's making me angry. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t7600: test merge configuration override
Set the configuration variable 'merge.ff' to either 'only' or 'no' and check that this configuration can be overridden on command line. Additionally, test for currently not tested option '--no-ff-only' Signed-off-by: Yann Droneaud --- t/t7600-merge.sh | 26 ++ 1 file changed, 26 insertions(+) diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh index 5e19598..b524bdb 100755 --- a/t/t7600-merge.sh +++ b/t/t7600-merge.sh @@ -254,6 +254,32 @@ test_expect_success 'merges with merge.ff=only' ' verify_head $c3 ' +test_expect_success 'merges with merge.ff=only and --no-ff-only' ' + git reset --hard c1 && + test_tick && + test_when_finished "git config --unset merge.ff" && + git config merge.ff only && + test_must_fail git merge --no-ff c2 && + git merge --no-ff-only c2 && + + git reset --hard c1 && + git merge --no-ff-only --no-ff c2 +' + +test_expect_success 'merges with merge.ff=no and --ff' ' + git reset --hard c0 && + test_tick && + test_when_finished "git config --unset merge.ff" && + git config merge.ff no && + test_must_fail git merge --ff-only c1 && + git merge --ff c1 && + verify_head $c1 && + + git reset --hard c0 && + git merge --ff --ff-only c1 && + verify_head $c1 +' + test_expect_success 'merge c0 with c1 (no-commit)' ' git reset --hard c0 && git merge --no-commit c1 && -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git merge behavior
Hi, Le 21.03.2013 21:31, Max Nanasy a écrit : Yann Droneaud opteya.com> writes: 3) Merge options can't be overridden. If I modify .git/config to set a merge option, for example forcing fast-forward merge, this option cannot be overridden on command line: (git merge --no-ff-only --no-ff) should work. The --no-ff-only overrides the --ff-only configuration setting, and the --no-ff ensures that the merge is not a fast-forward. Thanks. I wasn't aware of the --no-ff-only option and thought --no-ff would be the opposite of --ff-only, or at least disable it given the order of the options. Please find a patch to document option --no-ff-only Documentation/merge-options.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 0bcbe0a..20a31cf 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -37,6 +37,10 @@ set to `no` at the beginning of them. current `HEAD` is already up-to-date or the merge can be resolved as a fast-forward. +--no-ff-only:: + Disable `--ff-only` behavior, eg. allows creation of merge commit. + This is the default behavior. + --log[=]:: --no-log:: In addition to branch names, populate the log message with -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: add a README file
Hi, Le jeudi 21 mars 2013 à 14:16 -0700, Junio C Hamano a écrit : > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines > index b1bfff6..7e4d571 100644 > --- a/Documentation/CodingGuidelines > +++ b/Documentation/CodingGuidelines > @@ -237,6 +237,9 @@ For Python scripts: > > Writing Documentation: > > + Most (if not all) of the documentation pages are written in AsciiDoc > + and processed into HTML output and manpages. > + > Every user-visible change should be reflected in the documentation. > The same general rule as for code applies -- imitate the existing > conventions. A few commented examples follow to provide reference > > Nice, I'm OK with this change. (But still thinking a README would be useful *too*). Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: add a README file
Le jeudi 21 mars 2013 à 10:39 -0700, Junio C Hamano a écrit : > Yann Droneaud writes: > > > There were no indication about how to write documentation > > in SubmittingPatches. > > I would agree that is probably the right place for it if we were to > add insns/hints. > But it will be difficult to find the place to put a note about how to write the documentation. Anyway, having a README at the Documentation/ level could also help to explain what to be found in this directory: - user-manual - howto - technical - RelNote - SubmittingPatches - CodingGuidelines - etc. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation: merging a tag is a special case
From: Junio C Hamano When asking Git to merge a tag (such as a signed tag or annotated tag), it will always create a merge commit even if fast-forward was possible. It's like having --no-ff present on the command line. It's a difference from the default behavior described in git-merge.txt. It should be documented as an exception of "FAST-FORWARD MERGE" section and "--ff" option description. Reviewed-by: Jonathan Nieder Reviewed-by: Yann Droneaud --- Documentation/git-merge.txt | 24 Documentation/merge-options.txt | 3 ++- 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index c852a26..42391f2 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -170,6 +170,30 @@ happens: If you tried a merge which resulted in complex conflicts and want to start over, you can recover with `git merge --abort`. +MERGING TAG +--- + +When merging an annotated (and possibly signed) tag, Git always +creates a merge commit even if a fast-forward merge is possible, and +the commit message template is prepared with the tag message. +Additionally, if the tag is signed, the signature check is reported +as a comment in the message template. See also linkgit:git-tag[1]. + +When you want to just integrate with the work leading to the commit +that happens to be tagged, e.g. synchronizing with an upstream +release point, you may not want to make an unnecessary merge commit. + +In such a case, you can "unwrap" the tag yourself before feeding it +to `git merge`, or pass `--ff-only` when you do not have any work on +your own. e.g. + +--- +git fetch origin +git merge v1.2.3^0 +git merge --ff-only v1.2.3 +--- + + HOW CONFLICTS ARE PRESENTED --- diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 0bcbe0a..34a8445 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -30,7 +30,8 @@ set to `no` at the beginning of them. --no-ff:: Create a merge commit even when the merge resolves as a - fast-forward. + fast-forward. This is the default behaviour when merging an + annotated (and possibly signed) tag. --ff-only:: Refuse to merge and exit with a non-zero status unless the -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: merging a tag is a special case
Hi, Just a little change I made on my own. The other part are definitely better than my version, so I propose to merge all the patches in the thread with you as author, putting Jonathan Nieder and myself as reviewers. Regards Documentation/git-merge.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index dd90feb..42391f2 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -176,8 +176,8 @@ MERGING TAG When merging an annotated (and possibly signed) tag, Git always creates a merge commit even if a fast-forward merge is possible, and the commit message template is prepared with the tag message. -Additionally, the signature check is reported as a comment -if the tag is signed. See also linkgit:git-tag[1]. +Additionally, if the tag is signed, the signature check is reported +as a comment in the message template. See also linkgit:git-tag[1]. When you want to just integrate with the work leading to the commit that happens to be tagged, e.g. synchronizing with an upstream -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: add a README file
Le 21.03.2013 16:31, Junio C Hamano a écrit : Yann Droneaud writes: The documentation is in AsciiDoc format: it should be written somewhere with links to AsciiDoc documentation so that it became easy to find how to write documentation for Git. Certainly this does not deserve a *new* file to hold it. That's the first one I look for. There were no indication about how to write documentation in SubmittingPatches. Later, I've found the only useful piece of advice regarding the documentation in howto/new-command.txt: " What every extension command needs -- You must have a man page, written in asciidoc (this is what Git help followed by your subcommand name will display). Be aware that there is a local asciidoc configuration and macros which you should use. It's often helpful to start by cloning an existing page and replacing the text content. " And I was grep'ing for ascii[ _-]doc throughout the sources ! Isn't this inferrable from the top-level INSTALL already? In short: No. You want me to look in the INSTALL file to search for the syntax to write documentation ? For someone who don't follow Git development, it's really not the file you're looking for. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: add a README file
The documentation is in AsciiDoc format: it should be written somewhere with links to AsciiDoc documentation so that it became easy to find how to write documentation for Git. Signed-off-by: Yann Droneaud --- Documentation/README | 13 + 1 file changed, 13 insertions(+) create mode 100644 Documentation/README diff --git a/Documentation/README b/Documentation/README new file mode 100644 index 000..c41734c --- /dev/null +++ b/Documentation/README @@ -0,0 +1,13 @@ +Documentation += + +Most of the Git documentation is in AsciiDoc format, +a lightweight markup text language. + +AsciiDoc formatted files can be translated to man pages, +HTML, DocBook or PDF documents. + +See: +- http://asciidoc.org/ +- https://git.wiki.kernel.org/index.php/AsciiDoc + -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git merge behavior
Hi, Le mercredi 20 mars 2013 à 19:04 +0100, Yann Droneaud a écrit : > > > 2) git merge VS git merge > > > > > > If is an object (not a lightweight/reference tag), git merge > > > ... > > > But, if you use the tag object-id instead of its name, for example using > > > git merge `git parse-rev `, > [EDIT] > > > signature is not checked. Git still create a merge commit, but doesn't > > > prepare a commit message with the tag message and the signature: > > > > > > It would be great to have Git using the tag message and check the > > > signature. > > > > Perhaps, but if you feed the $(git rev-parse v1.12.2) to merge, your > > subject will not be able to say "Merge tag 'v1.12.2'" in the first > > place, so I do not think you would want to encourage such usage in > > the first place. > > I think if someone want to merge the tag object-id instead of the tag, > the commit subject/message should probably not make a reference to the > tag. > > The only use case for such tag merging by commit-id would be to get > consistent behavior in case of tag deletion. The named tag could be > recreated to point to another point in time. So when looking at the > merge commit message and searching for the tag (by name) could be > misleading. > But but do not take those remarks as a feature request. I was just asking for clarification/comment on the behavior difference between merging tag/tag object-id. Regards -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git merge behavior
Hi, Le mardi 19 mars 2013 à 09:19 -0700, Junio C Hamano a écrit : > Yann Droneaud writes: > > > 1) there's no mention of the git merge behavior in git-merge.1 > Yes; we welcome documentation patches. > Sent. > > 2) git merge VS git merge > > > > If is an object (not a lightweight/reference tag), git merge > > ... > > But, if you use the tag object-id instead of its name, for example using > > git merge `git parse-rev `, [EDIT] > > signature is not checked. Git still create a merge commit, but doesn't > > prepare a commit message with the tag message and the signature: > > > > It would be great to have Git using the tag message and check the > > signature. > > Perhaps, but if you feed the $(git rev-parse v1.12.2) to merge, your > subject will not be able to say "Merge tag 'v1.12.2'" in the first > place, so I do not think you would want to encourage such usage in > the first place. I think if someone want to merge the tag object-id instead of the tag, the commit subject/message should probably not make a reference to the tag. The only use case for such tag merging by commit-id would be to get consistent behavior in case of tag deletion. The named tag could be recreated to point to another point in time. So when looking at the merge commit message and searching for the tag (by name) could be misleading. PS: and what about my third issue ? Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: merging a tag is a special case
When asking Git to merge a tag (such as a signed tag or annotated tag), it will always create a merge commit even if fast-forward was possible. It's like having --no-ff present on the command line. It's a difference from the default behavior described in git-merge.txt. It should be documented as an exception of "FAST-FORWARD MERGE" section and "--ff" option description. Signed-off-by: Yann Droneaud --- Documentation/git-merge.txt | 9 + Documentation/merge-options.txt | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index c852a26..84bc873 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -170,6 +170,15 @@ happens: If you tried a merge which resulted in complex conflicts and want to start over, you can recover with `git merge --abort`. +MERGING TAG +--- + +When merging a tag (annotated or signed), Git will create a merge commit +even if a fast-forward merge is possible (see above). +The commit message template will be created from the tag message. +Additionally, the signature check will be reported as a comment +if the tag was signed. See also linkgit:git-tag[1]. + HOW CONFLICTS ARE PRESENTED --- diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 0bcbe0a..70d1ec0 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -26,7 +26,7 @@ set to `no` at the beginning of them. --ff:: When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default - behavior. + behavior (except when merging a tag). --no-ff:: Create a merge commit even when the merge resolves as a -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git merge behavior
Hi, While trying to reproduce/understand the problems[1][2] I was facing when using Google's Git repo tool[3], I've found minor problems in Git: 1) there's no mention of the git merge behavior in git-merge.1 When asking Git to merge a tag (such as a signed tag or annotated tag), it will always create a merge commit even if fast-forward was possible. It's like having --no-ff present on the command line. It's a difference from the default behavior described in git-merge.1[4]. It should be documented as an exception of "FAST-FORWARD MERGE" section and "--ff" option description. 2) git merge VS git merge If is an object (not a lightweight/reference tag), git merge will by default create a merge commit with the tag message. Additionally, the signature check will be reported as comment, for example: Merge tag 'v1.12.2' into branch-v1.12.2 repo 1.12.2 # gpg: Signature made Fri Mar 1 18:36:42 2013 CET using DSA key ID 920F5C65 # gpg: Good signature from "Repo Maintainer " # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 8BB9 AD79 3E8E 6153 AF0F 9A44 1653 0D5E 920F 5C65 But, if you use the tag object-id instead of its name, for example using git merge `git show-ref `, the tag is not recognized and the signature is not checked. Git still create a merge commit, but doesn't prepare a commit message with the tag message and the signature: Merge commit 'ac22c7ae2e652f63366b65ee23122292d3564fff' into branch-ac22c7ae2e652f63366b65ee23122292d3564fff It would be great to have Git using the tag message and check the signature. 3) Merge options can't be overridden. If I modify .git/config to set a merge option, for example forcing fast-forward merge, this option cannot be overridden on command line: Example 1: $ cat .git/config: [branch "master"] mergeoptions = --ff-only $ git merge --no-ff fatal: You cannot combine --no-ff with --ff-only Example 2: $ cat .git/config: [merge] ff = only $ git merge --no-ff fatal: You cannot combine --no-ff with --ff-only Setting the merge options in config should overridden by command line. Regards. [1] issue 135: repo: repo sync should force fast-forward merge https://code.google.com/p/git-repo/issues/detail?id=135 [2] Issue 136: repo: repo sync should use the tag name instead of object identifier of the tag https://code.google.com/p/git-repo/issues/detail?id=136 [3] git-repo - repo - The multiple repository tool http://code.google.com/p/git-repo/ [4] git-merge(1) Manual Page https://www.kernel.org/pub/software/scm/git/docs/git-merge.html -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sha1: use char type for temporary work buffer
Le mercredi 12 septembre 2012 à 17:04 -0400, Jeff King a écrit :
> > > Wouldn't this break all of the code that is planning to index "W" by
> > > 32-bit words (see the definitions of setW in block-sha1/sha1.c)?
> > >
> > That's not the same "W" ... This part of the code is indeed unclear.
>
> Sorry, you're right, that's a different work array (though it has the
> identical issue, no?).
No, this one is really accessed as int. But would probably benefit being
declared as uint32_t.
> But the point still stands. Did you audit the
> block-sha1 code to make sure nobody is ever indexing the W array?
Yes. It was the first thing to do before changing its definition
(for alignment purpose especially).
> If you didn't, then your change is not safe. If you did, then you should
> really
> mention that in the commit message.
>
Sorry about this.
I thought having the test suite OK was enough to prove this.
> > > If that is indeed the problem, wouldn't the simplest fix be using
> > > uint32_t instead of "unsigned int"?
> >
> > It's another way to fix this oddity, but not simpler.
>
> It is simpler in the sense that it does not have any side effects (like
> changing how every user of the data structure needs to index it).
>
There's no other user than blk_SHA1_Update()
> > > Moreover, would that be sufficient to run on such a platform? At the
> > > very least, "H" above would want the same treatment. And I would not be
> > > surprised if some of the actual code in block-sha1/sha1.c needed
> > > updating, as well.
> >
> > ctx->H is actually used as an array of integer, so it would benefits of
> > being declared uint32_t for an ILP64 system. This fix would also be
> > required for blk_SHA1_Block() function.
>
> So...if we are not ready to run on an ILP system after this change, then
> what is the purpose?
>
Readility: in blk_SHA1_Block(), the ctx->W array is used a 64 bytes len
array, so, AFAIK, there's no point of having it defined as a 16 int len.
It's disturbing while reading the code.
This could allows us to change the memcpy() call further:
@@ -246,7 +246,7 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void
*data, unsigned long len)
unsigned int left = 64 - lenW;
if (len < left)
left = len;
- memcpy((char *)ctx->W + lenW, data, left);
+ memcpy(ctx->W + lenW, data, left);
lenW = (lenW + left) & 63;
if (lenW)
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sha1: use char type for temporary work buffer
Le mercredi 12 septembre 2012 à 14:38 -0400, Jeff King a écrit :
> On Wed, Sep 12, 2012 at 12:30:45PM +0200, Yann Droneaud wrote:
>
> > The SHA context is holding a temporary buffer for partial block.
> >
> > This block must 64 bytes long. It is currently described as
> > an array of 16 integers.
> >
> > Signed-off-by: Yann Droneaud
> > ---
> > block-sha1/sha1.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h
> > index b864df6..d29ff6a 100644
> > --- a/block-sha1/sha1.h
> > +++ b/block-sha1/sha1.h
> > @@ -9,7 +9,7 @@
> > typedef struct {
> > unsigned long long size;
> > unsigned int H[5];
> > - unsigned int W[16];
> > + unsigned char W[64];
> > } blk_SHA_CTX;
>
> Wouldn't this break all of the code that is planning to index "W" by
> 32-bit words (see the definitions of setW in block-sha1/sha1.c)?
>
That's not the same "W" ... This part of the code is indeed unclear.
> You do not describe an actual problem in the commit message, but reading
> between the lines it would be "system X would like to use block-sha1,
> but has an "unsigned int" that is not 32 bits". IOW, an ILP64 type of
> architecture. Do you have some specific platform in mind?
>
> If that is indeed the problem, wouldn't the simplest fix be using
> uint32_t instead of "unsigned int"?
>
It's another way to fix this oddity, but not simpler.
> Moreover, would that be sufficient to run on such a platform? At the
> very least, "H" above would want the same treatment. And I would not be
> surprised if some of the actual code in block-sha1/sha1.c needed
> updating, as well.
>
ctx->H is actually used as an array of integer, so it would benefits of
being declared uint32_t for an ILP64 system. This fix would also be
required for blk_SHA1_Block() function.
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] sha1: clean pointer arithmetic
Le mercredi 12 septembre 2012 à 11:37 -0700, Junio C Hamano a écrit : > Yann Droneaud writes: > > > One memcpy() argument is computed from a pointer added to an integer: > > eg. int + pointer. It's unusal. > > Let's write it in the correct order: pointer + offset. > > Meh. > > Both are correct. Aren't ctx->w[lenW] and lenW[ctx-w] both correct, > even? > "correct" in my commit log message should be read as "the way it's used by most C developer". It's again a cosmetic fix. -- Yann Droneaud -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sha1: use char type for temporary work buffer
Le mercredi 12 septembre 2012 à 11:42 -0700, Junio C Hamano a écrit : > Yann Droneaud writes: > > > The SHA context is holding a temporary buffer for partial block. > > > > This block must 64 bytes long. It is currently described as > > an array of 16 integers. > > > > Signed-off-by: Yann Droneaud > > --- > > As we do not work with 16-bit integers anyway, 16 integers occupy 64 > bytes anyway. > It's unclear why this array is declared as 'int' but used as 'char'. > What problem does this series fix? > The question I was hoping to not see asked :) This is mostly some cosmetic fixes to improve readability and portability. Regards -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] sha1: clean pointer arithmetic
One memcpy() argument is computed from a pointer added to an integer: eg. int + pointer. It's unusal. Let's write it in the correct order: pointer + offset. Signed-off-by: Yann Droneaud --- block-sha1/sha1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c index c1af112..a7c4470 100644 --- a/block-sha1/sha1.c +++ b/block-sha1/sha1.c @@ -246,7 +246,7 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data, unsigned long len) unsigned int left = 64 - lenW; if (len < left) left = len; - memcpy(lenW + (char *)ctx->W, data, left); + memcpy((char *)ctx->W + lenW, data, left); lenW = (lenW + left) & 63; if (lenW) return; -- 1.7.11.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] sha1: use char type for temporary work buffer
The SHA context is holding a temporary buffer for partial block.
This block must 64 bytes long. It is currently described as
an array of 16 integers.
Signed-off-by: Yann Droneaud
---
block-sha1/sha1.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h
index b864df6..d29ff6a 100644
--- a/block-sha1/sha1.h
+++ b/block-sha1/sha1.h
@@ -9,7 +9,7 @@
typedef struct {
unsigned long long size;
unsigned int H[5];
- unsigned int W[16];
+ unsigned char W[64];
} blk_SHA_CTX;
void blk_SHA1_Init(blk_SHA_CTX *ctx);
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] sha1: update pointer and remaining length after subfunction call
There's no need to update the pointer and remaining length before
leaving or calling the SHA1 sub function.
Additionnaly, the partial block code could be looking more like
the full block handling branch.
Signed-off-by: Yann Droneaud
---
block-sha1/sha1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index a8d4bf9..c1af112 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -248,11 +248,11 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data,
unsigned long len)
left = len;
memcpy(lenW + (char *)ctx->W, data, left);
lenW = (lenW + left) & 63;
- len -= left;
- data = ((const char *)data + left);
if (lenW)
return;
blk_SHA1_Block(ctx, ctx->W);
+ data = ((const char *)data + left);
+ len -= left;
}
while (len >= 64) {
blk_SHA1_Block(ctx, data);
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Janitor minor fixes on SHA1
While looking to use the git SHA1 code, I've found some small oddities. Please find little cosmetics fixes for them. The patches are against 'next' and can be merged in one single patch if needed. Yann Droneaud (3): sha1: update pointer and remaining length after subfunction call sha1: clean pointer arithmetic sha1: use char type for temporary work buffer block-sha1/sha1.c | 6 +++--- block-sha1/sha1.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) -- 1.7.11.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
