Re: [PATCH v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Philip Oakley philipoak...@iee.org Sent: Saturday, August 31, 2013 11:16 PM From: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 736b48c..a2bd2ee 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -21,10 +21,12 @@ replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. Is this trying to allude to the fact that merge commits may be exchanged with non-merge commits? I strongly believe that this ability to exchange merge and non-merge commits should be stated _explicitly_ to counteract the false beliefs that are listed out on the internet. It's probably better stated in a separate patch for that explicit purpose to avoid mixed messages within this commit. Not sure how this method of preparing a comment patch will pan out.. ---8 From a0c0e765cfd969c9c8a6ff3a2cb6b2f1391d2e7d Mon Sep 17 00:00:00 2001 From: Philip Oakley philipoak...@iee.org Date: Thu, 5 Sep 2013 22:54:04 +0100 Subject: [PATCH] Doc: 'replace' merge and non-merge commits Signed-off-by: Philip Oakley philipoak...@iee.org --- This is supplemental to Christian Couder's 'replace' patch series (2013-09-03 69dada4 (Christian Couder): t6050-replace: use some long option names). It adds the clarification that merge and non-merge commits are replaceable. Merges are often treated as special case objects so tell users that they are not special here. --- Documentation/git-replace.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 414000e..f373ab4 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -26,6 +26,7 @@ This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. There is no other restriction on the replaced and replacement objects. +Merge commits can be replaced by non-merge commits and vice versa. Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and -- 1.8.1.msysgit.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: [PATCH v3 07/11] Documentation/replace: tell that -f option bypasses the type check
Philip Oakley philipoak...@iee.org writes: From: Philip Oakley philipoak...@iee.org Sent: Saturday, August 31, 2013 11:16 PM From: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 736b48c..a2bd2ee 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -21,10 +21,12 @@ replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. Is this trying to allude to the fact that merge commits may be exchanged with non-merge commits? I strongly believe that this ability to exchange merge and non-merge commits should be stated _explicitly_ to counteract the false beliefs that are listed out on the internet. It's probably better stated in a separate patch for that explicit purpose to avoid mixed messages within this commit. Not sure how this method of preparing a comment patch will pan out.. ---8 Make it --- 8 --- perhaps to balance out the perforation on both sides. From a0c0e765cfd969c9c8a6ff3a2cb6b2f1391d2e7d Mon Sep 17 00:00:00 2001 Not needed nor wanted. From: Philip Oakley philipoak...@iee.org Not needed but does not hurt. Date: Thu, 5 Sep 2013 22:54:04 +0100 Is OK but redundant given that your message has a timestamp when we saw your patch for the first time anyway. Subject: [PATCH] Doc: 'replace' merge and non-merge commits Signed-off-by: Philip Oakley philipoak...@iee.org --- This is supplemental to Christian Couder's 'replace' patch series (2013-09-03 69dada4 (Christian Couder): t6050-replace: use some long option names). It adds the clarification that merge and non-merge commits are replaceable. Merges are often treated as special case objects so tell users that they are not special here. I think the last paragraph deserves to be in the proposed commit log message proper. It explains why it is a good idea to have the added line in the documentation very well. --- Documentation/git-replace.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 414000e..f373ab4 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -26,6 +26,7 @@ This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. There is no other restriction on the replaced and replacement objects. +Merge commits can be replaced by non-merge commits and vice versa. Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
On Mon, Sep 2, 2013 at 11:50 PM, Philip Oakley philipoak...@iee.org wrote:
From: Christian Couder chrisc...@tuxfamily.org
You mean something like the following:
$ cat ./graft2replace.sh
#!/bin/bash
while read orig parents
do
printf %s git cat-file commit $orig
printf %s | perl -n -e 'print unless /^parent /'
insn=''
for commit in $parents; do insn=$insn print \parent
$commit\\n\;; done
printf %s | perl -n -e 'print; if (/^tree /) { $insn }'
printf %s\n new_commit.txt
printf %s\n 'REPL=$(git hash-object -t commit -w new_commit.txt)'
Does `hash-object` do the inverese of `cat-file commit`?
I didn't find the hash-object(1) man page very informative on that matter
and a (very) quick look at its code made me think it was just hashing the
raw contents which wouldn't be what what was wanted.
I agree with Jonathan's suggest to add an EXAMPLE section in
hash-object(1) manpage and maybe a new gitobject(5) manpage too.
You can also find a few examples of how git hash-object can be used in
t/t6050-replace.sh:
For example:
R=$(git cat-file commit $HASH2 | sed -e s/A U/O/ | git
hash-object -t commit --stdin -w)
git cat-file commit $R | grep author O Thor
git update-ref refs/replace/$HASH2 $R
printf %s\n git replace $orig \$REPL
done
This generates shell instructions from a graft file. Then you only need to
execute the generated shell instructions.
For example:
$ cat graft_file.txt
5bf34fff3186254d7254583675d10ddf98df989b
79fe155489351e8af829a3106e7150397c57d863
dcfbab6bea3df3166503f3084cec2679f10f9e80
fb5657082148297b61fbca7e64d51c1e7870309a
$ cat graft_file.txt | ./graft2replace.sh
git cat-file commit 5bf34fff3186254d7254583675d10ddf98df989b | perl -n -e
'print unless /^parent /' | perl -n -e 'print; if (/^tree /) { print
parent 79fe155489351e8af829a3106e7150397c57d863\n; print parent
dcfbab6bea3df3166503f3084cec2679f10f9e80\n; }' new_commit.txt
REPL=$(git hash-object -t commit -w new_commit.txt)
git replace 5bf34fff3186254d7254583675d10ddf98df989b $REPL
git cat-file commit fb5657082148297b61fbca7e64d51c1e7870309a | perl -n -e
'print unless /^parent /' | perl -n -e 'print; if (/^tree /) { }'
new_commit.txt
REPL=$(git hash-object -t commit -w new_commit.txt)
git replace fb5657082148297b61fbca7e64d51c1e7870309a $REPL
Note that I haven't really tested it.
Also note that it is obviously broken if you have commits with a
commit message that has lines starting with 'parent ' or 'tree '.
I think we could call it 'git-graft', being the help function/script that
converts raw grafts to proper object replacements ;-)
I will have a look at improving it, testing it and sending a patch to
put it in contrib/.
Thanks,
Christian.
--
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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Christian Couder chrisc...@tuxfamily.org
From: Philip Oakley philipoak...@iee.org
From: Christian Couder chrisc...@tuxfamily.org
Maybe we can show that in an example. But I think the patch is quite
clear as it is and should be enough.
If we really want to correct some false beliefs, the best would be
to
state the truth where those false beliefs are stated.
I've added a sub-comment to the original SO post that started this
thread (my post $gmane/231598 - SO/a/18027030/717355), but given the
guy's blog has comments going back to 2009 I suspect its a bit of a
http://xkcd.com/386/ task, hence my desire that it's explicitly
mentioned in the 'replace' documentation. In addition, if the guy
doesn't correct his post I'll mark it down in a couple of days to
make
it plain to other readers it's in error.
The creation of a (merge?) commit that's equivalent to a graft line
isn't something that jumps out (to me) as an easy couple lines of
bash
script.
A 'graft2replace' script (or 'git-graft' command) which takes an
existing graft file (or command line list) and creates the
replacement
objects and then does the replace, all while still in a dirty tree
would be the holy grail for properly deprecating grafts (which are
sooo easy to create)
You mean something like the following:
$ cat ./graft2replace.sh
#!/bin/bash
while read orig parents
do
printf %s git cat-file commit $orig
printf %s | perl -n -e 'print unless /^parent /'
insn=''
for commit in $parents; do insn=$insn print \parent
$commit\\n\;; done
printf %s | perl -n -e 'print; if (/^tree /) { $insn }'
printf %s\n new_commit.txt
printf %s\n 'REPL=$(git hash-object -t commit -w
new_commit.txt)'
Does `hash-object` do the inverese of `cat-file commit`?
I didn't find the hash-object(1) man page very informative on that
matter and a (very) quick look at its code made me think it was just
hashing the raw contents which wouldn't be what what was wanted.
printf %s\n git replace $orig \$REPL
done
This generates shell instructions from a graft file. Then you only
need to execute the generated shell instructions.
For example:
$ cat graft_file.txt
5bf34fff3186254d7254583675d10ddf98df989b
79fe155489351e8af829a3106e7150397c57d863
dcfbab6bea3df3166503f3084cec2679f10f9e80
fb5657082148297b61fbca7e64d51c1e7870309a
$ cat graft_file.txt | ./graft2replace.sh
git cat-file commit 5bf34fff3186254d7254583675d10ddf98df989b |
perl -n -e 'print unless /^parent /' | perl -n -e 'print; if (/^tree
/) { print parent 79fe155489351e8af829a3106e7150397c57d863\n; print
parent dcfbab6bea3df3166503f3084cec2679f10f9e80\n; }'
new_commit.txt
REPL=$(git hash-object -t commit -w new_commit.txt)
git replace 5bf34fff3186254d7254583675d10ddf98df989b $REPL
git cat-file commit fb5657082148297b61fbca7e64d51c1e7870309a |
perl -n -e 'print unless /^parent /' | perl -n -e 'print; if (/^tree
/) { }' new_commit.txt
REPL=$(git hash-object -t commit -w new_commit.txt)
git replace fb5657082148297b61fbca7e64d51c1e7870309a $REPL
Note that I haven't really tested it.
Best,
Christian.
--
I think we could call it 'git-graft', being the help function/script
that converts raw grafts to proper object replacements ;-)
Philip
--
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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
Hi, Philip Oakley wrote: Does `hash-object` do the inverese of `cat-file commit`? I didn't find the hash-object(1) man page very informative on that matter Hm. The manpage says: Computes the object ID value for an object with specified type with the contents of the named file [...], and optionally writes the resulting object into the object database. And then: -w Actually write the object into the object database. Any ideas for making this clearer? Thanks, Jonathan -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Jonathan Nieder jrnie...@gmail.com Hi, Philip Oakley wrote: Does `hash-object` do the inverese of `cat-file commit`? I didn't find the hash-object(1) man page very informative on that matter Hm. The manpage says: Computes the object ID value for an object with specified type with the contents of the named file [...], and optionally writes the resulting object into the object database. And then: -w Actually write the object into the object database. Any ideas for making this clearer? The problem is the file format, in the sense that the earlier `git cat-file commit $orig` has a human readable output which is a description of the commit header, rather than the specific binary content. I couldn't tell if the command would cope with such a human readable file. In Christian's quick untested script he'd matched the two commands as opposites, which doesn't appear to be the case, and I'm somewhat ignorant of what hash-object is doing - I'd expect that it simply hashed the already constructed data, but my ignorance starts showing at this point ;-) regards Philip -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
Philip Oakley wrote: The problem is the file format, in the sense that the earlier `git cat-file commit $orig` has a human readable output which is a description of the commit header, rather than the specific binary content. Ah. That's the actual raw commit object format, though. The manpage for git-cat-file(1) says: SYNOPSIS git cat-file (-t | -s | -e | -p | type | --textconv ) object git cat-file (--batch | --batch-check) list-of-objects DESCRIPTION In its first form, the command provides the content or the type of an object in the repository. [...] OUTPUT ... If type is specified, the raw (though uncompressed) contents of the object will be returned. I agree that this isn't as clear as it should be. I see a few problems: (1) The synopsis treats git cat-file -t/-s/-e/-p object, git cat-file --textconv tree:path, and git cat-file type object as the same form of the command. It would be easier to explain these as three different forms. (2) There is no EXAMPLES section and no examples. (3) There is no pointer to the git object formats. A pointer to a new gitobject(5) manpage would presumably make everything clearer. https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#examining-the-data might be a good source of text to start from for solving (1), since it explains the command a little better. Thanks, Jonathan -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Jonathan Nieder jrnie...@gmail.com Philip Oakley wrote: The problem is the file format, in the sense that the earlier `git cat-file commit $orig` has a human readable output which is a description of the commit header, rather than the specific binary content. Ah. That's the actual raw commit object format, though. Aha.. Sudden realisation that the cat-file _is_ the 'raw' format and that the sha1's etc are shown in ascii hex, rather than being in a compact binary format (same for 'unix' dates etc.) So the 'human readable' output is exactly the 'type_name' field followed by a single space (SP) followed by the sha1 in ascii hex (i.e. tree/parent), or appropriate data in the well defined format (for author/committer) SP 'email' SP date. etc. It was the Human readable == Machine readable that I'd missed. The manpage for git-cat-file(1) says: SYNOPSIS git cat-file (-t | -s | -e | -p | type | --textconv ) object git cat-file (--batch | --batch-check) list-of-objects DESCRIPTION In its first form, the command provides the content or the type of an object in the repository. [...] OUTPUT ... If type is specified, the raw (though uncompressed) contents of the object will be returned. I agree that this isn't as clear as it should be. I see a few problems: (1) The synopsis treats git cat-file -t/-s/-e/-p object, git cat-file --textconv tree:path, and git cat-file type object as the same form of the command. It would be easier to explain these as three different forms. (2) There is no EXAMPLES section and no examples. (3) There is no pointer to the git object formats. A pointer to a new gitobject(5) manpage would presumably make everything clearer. https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#examining-the-data might be a good source of text to start from for solving (1), since it explains the command a little better. A quick run of the example git cat-file commit HEAD, seen in the context of your email helped me appreciate the situation. Thanks, Jonathan Philip -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Philip Oakley philipoak...@iee.org From: Christian Couder chrisc...@tuxfamily.org The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. Is this trying to allude to the fact that merge commits may be exchanged with non-merge commits? I strongly believe that this ability to exchange merge and non-merge commits should be stated _explicitly_ to counteract the false beliefs that are listed out on the internet. Maybe we can show that in an example. But I think the patch is quite clear as it is and should be enough. If we really want to correct some false beliefs, the best would be to state the truth where those false beliefs are stated. It's probably better stated in a separate patch for that explicit purpose to avoid mixed messages within this commit. If people agree, I will add a another patch with an example in an EXAMPLE section. Thanks, Christian. -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Christian Couder chrisc...@tuxfamily.org From: Philip Oakley philipoak...@iee.org From: Christian Couder chrisc...@tuxfamily.org The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. Is this trying to allude to the fact that merge commits may be exchanged with non-merge commits? I strongly believe that this ability to exchange merge and non-merge commits should be stated _explicitly_ to counteract the false beliefs that are listed out on the internet. Maybe we can show that in an example. But I think the patch is quite clear as it is and should be enough. If we really want to correct some false beliefs, the best would be to state the truth where those false beliefs are stated. I've added a sub-comment to the original SO post that started this thread (my post $gmane/231598 - SO/a/18027030/717355), but given the guy's blog has comments going back to 2009 I suspect its a bit of a http://xkcd.com/386/ task, hence my desire that it's explicitly mentioned in the 'replace' documentation. In addition, if the guy doesn't correct his post I'll mark it down in a couple of days to make it plain to other readers it's in error. The creation of a (merge?) commit that's equivalent to a graft line isn't something that jumps out (to me) as an easy couple lines of bash script. A 'graft2replace' script (or 'git-graft' command) which takes an existing graft file (or command line list) and creates the replacement objects and then does the replace, all while still in a dirty tree would be the holy grail for properly deprecating grafts (which are sooo easy to create) It's probably better stated in a separate patch for that explicit purpose to avoid mixed messages within this commit. If people agree, I will add a another patch with an example in an EXAMPLE section. Thanks, Christian. Thanks for your work on this. Philip -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 736b48c..a2bd2ee 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -21,10 +21,12 @@ replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. + Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck). -- 1.8.4.rc1.31.g530f5ce.dirty -- 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 v3 07/11] Documentation/replace: tell that -f option bypasses the type check
From: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 736b48c..a2bd2ee 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -21,10 +21,12 @@ replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. The replaced object and the replacement object must be of the same type. -There is no other restriction on them. +This restriction can be bypassed using `-f`. Unless `-f` is given, the 'replace' reference must not yet exist. +There is no other restriction on the replaced and replacement objects. Is this trying to allude to the fact that merge commits may be exchanged with non-merge commits? I strongly believe that this ability to exchange merge and non-merge commits should be stated _explicitly_ to counteract the false beliefs that are listed out on the internet. It's probably better stated in a separate patch for that explicit purpose to avoid mixed messages within this commit. + Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck). -- -- 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
