Re: [BUG] Cannot push some grafted branches

2012-12-22 Thread Michael J Gruber
Junio C Hamano venit, vidit, dixit 21.12.2012 17:58:
 Michael J Gruber g...@drmicha.warpmail.net writes:
 
 While replace refs are much more general than grafts, it seems the two
 main uses are:

 - grafts (change the recorded parents for a commit)
 - svn cleanup (convert tagging commits into tag objects)

 The latter one being quite a special case already.

 The script below has helped me move from grafts to replace objects.
 While not being super clean, something like it may be fit for contrib.

 I think we ought to help John Doe get along with parents, while we can
 safely leave most more advanced operations to people who know how to
 edit a raw object file. Putting that facility into git-commit seems to
 be too encouraging, though - people would use replace when they should
 use amend or rebase-i. I'd prefer a special git-replace mode (be it
 --graft or --graft-commit) which does just what my script does. We
 could add things like --commit-tag later, a full blown
 object-factory seems like overkill.

 Michael

 ---%---

 #!/bin/sh

 die () {
  echo $@
  rm -f $commitfile
  exit 1
 }

 warn () {
  echo $@
 }

 test $# -gt 0 || die Usage: $0 commit [parent]*

 for commit
 do
  git rev-parse --verify -q $commit /dev/null || die Cannot parse
 $commit.
  test x$(git cat-file -t $commit) == xcommit || die $commit is no
 commit.
 
 s/==/=/ or you have to say #!/bin/bash on the first line, I think.
 Appears multiple times throughout this script.
 
 
 done

 commit=$1
 shift

 commitfile=$(mktemp)

 git cat-file commit $commit | while read a b
 do
  if test $a != parent
  then
  echo $a $b
 
 You are losing information on non-header lines by reading without
 -r in the above, and also multi-line headers (e.g. mergetag),
 aren't you?


Oh yes, it has bashisms and imperfections. It's not a submitted patch,
not even RFC. It's meant to show the git-replace mode that many users
could benefit from: works for commits only and replaces the parent list,
but takes any rev arguments as the new parents, rather than forcing the
user to specify a full sha1.

  fi
  if test $a == tree
  then
  for parent
  do
  echo parent $(git rev-parse $parent)
  done
  fi
 done $commitfile
 hash=$(git hash-object -t commit -w $commitfile) || die Cannot create
 commit object.
 git replace $commit $hash
 rm -f $commitfile
--
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: [BUG] Cannot push some grafted branches

2012-12-21 Thread Michael J Gruber
While replace refs are much more general than grafts, it seems the two
main uses are:

- grafts (change the recorded parents for a commit)
- svn cleanup (convert tagging commits into tag objects)

The latter one being quite a special case already.

The script below has helped me move from grafts to replace objects.
While not being super clean, something like it may be fit for contrib.

I think we ought to help John Doe get along with parents, while we can
safely leave most more advanced operations to people who know how to
edit a raw object file. Putting that facility into git-commit seems to
be too encouraging, though - people would use replace when they should
use amend or rebase-i. I'd prefer a special git-replace mode (be it
--graft or --graft-commit) which does just what my script does. We
could add things like --commit-tag later, a full blown
object-factory seems like overkill.

Michael

---%---

#!/bin/sh

die () {
echo $@
rm -f $commitfile
exit 1
}

warn () {
echo $@
}

test $# -gt 0 || die Usage: $0 commit [parent]*

for commit
do
git rev-parse --verify -q $commit /dev/null || die Cannot parse
$commit.
test x$(git cat-file -t $commit) == xcommit || die $commit is no
commit.
done

commit=$1
shift

commitfile=$(mktemp)

git cat-file commit $commit | while read a b
do
if test $a != parent
then
echo $a $b
fi
if test $a == tree
then
for parent
do
echo parent $(git rev-parse $parent)
done
fi
done $commitfile
hash=$(git hash-object -t commit -w $commitfile) || die Cannot create
commit object.
git replace $commit $hash
rm -f $commitfile
--
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: [BUG] Cannot push some grafted branches

2012-12-21 Thread Junio C Hamano
Michael J Gruber g...@drmicha.warpmail.net writes:

 While replace refs are much more general than grafts, it seems the two
 main uses are:

 - grafts (change the recorded parents for a commit)
 - svn cleanup (convert tagging commits into tag objects)

 The latter one being quite a special case already.

 The script below has helped me move from grafts to replace objects.
 While not being super clean, something like it may be fit for contrib.

 I think we ought to help John Doe get along with parents, while we can
 safely leave most more advanced operations to people who know how to
 edit a raw object file. Putting that facility into git-commit seems to
 be too encouraging, though - people would use replace when they should
 use amend or rebase-i. I'd prefer a special git-replace mode (be it
 --graft or --graft-commit) which does just what my script does. We
 could add things like --commit-tag later, a full blown
 object-factory seems like overkill.

 Michael

 ---%---

 #!/bin/sh

 die () {
   echo $@
   rm -f $commitfile
   exit 1
 }

 warn () {
   echo $@
 }

 test $# -gt 0 || die Usage: $0 commit [parent]*

 for commit
 do
   git rev-parse --verify -q $commit /dev/null || die Cannot parse
 $commit.
   test x$(git cat-file -t $commit) == xcommit || die $commit is no
 commit.

s/==/=/ or you have to say #!/bin/bash on the first line, I think.
Appears multiple times throughout this script.


 done

 commit=$1
 shift

 commitfile=$(mktemp)

 git cat-file commit $commit | while read a b
 do
   if test $a != parent
   then
   echo $a $b

You are losing information on non-header lines by reading without
-r in the above, and also multi-line headers (e.g. mergetag),
aren't you?

   fi
   if test $a == tree
   then
   for parent
   do
   echo parent $(git rev-parse $parent)
   done
   fi
 done $commitfile
 hash=$(git hash-object -t commit -w $commitfile) || die Cannot create
 commit object.
 git replace $commit $hash
 rm -f $commitfile
--
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: [BUG] Cannot push some grafted branches

2012-12-19 Thread Yann Dirson
On Tue, 18 Dec 2012 08:09:35 -0800
Junio C Hamano gits...@pobox.com wrote:

 Yann Dirson dir...@bertin.fr writes:
 
  On Mon, 17 Dec 2012 13:14:56 -0800
  Junio C Hamano gits...@pobox.com wrote:
 
  Andreas Schwab sch...@linux-m68k.org writes:
  
   Christian Couder christian.cou...@gmail.com writes:
  
   Yeah, at one point I wanted to have a command that created to craft a
   new commit based on an existing one.
  
   This isn't hard to do, you only have to resort to plumbing:
  
   $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed 
   s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
| git hash-object -t commit --stdin -w
   bb45cc6356eac6c7fa432965090045306dab7026
  
  Good.  I do not think an extra special-purpose command is welcome
  here.
 
  Well, I'm not sure this is intuitive enough to be useful to the average 
  user :)
 
 I do not understand why you even want to go in the harder route in
 the first place, only to complicate things?

Although the approach you propose is elegant, it still looks like one
could not leave the worktree untouched in the case of creating a merge replace,
which the just forge an arbitrary commit approach handles easily.

It seems the latter would also be more powerful, in that you can create new 
commits with an
arbitrary number of parents, even when merge-octopus would simply refuse to 
help;
and it is has no special case for creating merges.

 Is this not intuitive enough?

I would say it is a nice read that can help an advanced user to earn
some XP - but well, replace refs are also meant for somewhat advanced users :)

-- 
Yann Dirson - Bertin Technologies
--
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: [BUG] Cannot push some grafted branches

2012-12-19 Thread Jeff King
On Wed, Dec 19, 2012 at 08:13:21AM +0100, Johannes Sixt wrote:

 Am 12/18/2012 17:24, schrieb Jeff King:
  I am not really interested in pushing this forward myself, but I worked
  up this toy that somebody might find interesting (you can git replace
  HEAD~20 to get dumped in an editor). It should probably handle trees,
  and it would probably make sense to do per-object-type sanity checks
  (e.g., call verify_tag on tags).
 
 I know it's just a throw-away patch, but I would discourage to go this
 route without also adding all the sanity checks. Otherwise, it will have
 just created a porcelain command that can generate a commit object with
 any content you want!

I think I agree with you that it would not be worth doing without sanity
checks. I am not sure if your any content you want statement means
bad people can easily make bogus objects or it is too easy to make
arbitrary mistakes, putting your repo in a bogus state.

I would agree that the latter is compelling, but not the former.  You
can already easily generate a commit with any content you want via
hash-object -t commit, and I have frequently done this while testing
corner cases of fsck, how git behaves when given buggy data, etc. So to
me it is not about preventing intentional abuse, but about not promoting
a feature that makes it too easy to screw up.

-Peff
--
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: [BUG] Cannot push some grafted branches

2012-12-19 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes:

 I do not understand why you even want to go in the harder route in
 the first place, only to complicate things?

 All you want to do is to craft a commit object that records a
 specific tree shape, has a set of parents you want, and has the log
 information you want.  Once you have the commit, you can replace an
 unwanted commit with it.
[...]
 $ git checkout X^0 ;# detach
 $ git reset --soft A
 $ git commit -C X
[...]
 Is this not intuitive enough?

I still wouldn't recommend this approach in git-replace(1) for several
reasons:

* It does not generalize in any direction.  For each field you may want
  to change, you have to know a _specific_ way of getting just the
  commit you want.

* More to the point of replacing the parent lists, while the above might
  be expected of a slightly advanced git user, you get into deep magic
  the second you want to fake a merge commit with an arbitrary
  combination of parents.  (No, you don't need to tell me how.  I'm just
  saying that fooling with either MERGE_HEAD or read-tree is not for
  mere mortals.)

* The above potentially introduces clock skew into the repository, which
  can trigger bugs (like rev-list accidentally missing out on some side
  arm!) until we get around to implementing and using generation
  numbers.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [BUG] Cannot push some grafted branches

2012-12-19 Thread Junio C Hamano
Thomas Rast tr...@student.ethz.ch writes:

 I still wouldn't recommend this approach in git-replace(1) for several
 reasons:

 * It does not generalize in any direction.  For each field you may want
   to change, you have to know a _specific_ way of getting just the
   commit you want.

 * More to the point of replacing the parent lists, while the above might
   be expected of a slightly advanced git user, you get into deep magic
   the second you want to fake a merge commit with an arbitrary
   combination of parents.  (No, you don't need to tell me how.  I'm just
   saying that fooling with either MERGE_HEAD or read-tree is not for
   mere mortals.)

I do not buy either of the above.  When you are replacing one with
something else, you ought to know what that something else is and
how to create it.  Editing a text file with an editor to replace
40-hex object names with another is not a more intuitive way for end
users, either (in other words, you are seeing this from the point of
view of somebody who *knows* the internal representation of Git
objects too much).

 * The above potentially introduces clock skew into the repository, which
   can trigger bugs (like rev-list accidentally missing out on some side
   arm!) until we get around to implementing and using generation
   numbers.

That is an irrelevant point when comparing the go down to bare
metal replacing the object representation vs use the usual Git
tools the end users are already familiar with approaches.  You will
encounter the issue you are raising if you make a newer commit a
parent of an existing child with an older commit timestamp, no
matter how you do the grafting.
--
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: [BUG] Cannot push some grafted branches

2012-12-18 Thread Yann Dirson
On Mon, 17 Dec 2012 13:14:56 -0800
Junio C Hamano gits...@pobox.com wrote:

 Andreas Schwab sch...@linux-m68k.org writes:
 
  Christian Couder christian.cou...@gmail.com writes:
 
  Yeah, at one point I wanted to have a command that created to craft a
  new commit based on an existing one.
 
  This isn't hard to do, you only have to resort to plumbing:
 
  $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed 
  s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
   | git hash-object -t commit --stdin -w
  bb45cc6356eac6c7fa432965090045306dab7026
 
 Good.  I do not think an extra special-purpose command is welcome
 here.

Well, I'm not sure this is intuitive enough to be useful to the average user :)
Adding git-rev-parse calls for convenience, and calling git-replace, would make 
it
a more complete recipe, and we could suggest that as an alias in the collection 
that's
in the wiki (which is not even linked any more from git-scm.com btw), but imho 
that
would be hiding valuable information in a dark corner.

Anyway, in this form it will only replace a parent with another, whereas a full
graft replacement should allow to write a different number of new parents 
instead.
That is, instead of this simple sed, something like:

(NEWPARENTS='parent xxx\nparent yyy\nparent zzz\n; git cat-file commit master | 
perl -ne 'BEGIN { $state=0 }; if ($state eq 0) { if (/^parent/) { $state=1 } 
else { print } } elsif ($state eq 1) { if (/^author/) { print 
'$NEWPARENTS'; print; $state=2 } } else { print }')

Well, a short bash script should be more readable and possibly faster, but 
that's the
idea.  Such a script could be a candidate for contrib ?
-- 
Yann Dirson - Bertin Technologies
--
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: [BUG] Cannot push some grafted branches

2012-12-18 Thread Johannes Sixt
Am 12/18/2012 12:00, schrieb Yann Dirson:
 On Mon, 17 Dec 2012 13:14:56 -0800
 Junio C Hamano gits...@pobox.com wrote:
 
 Andreas Schwab sch...@linux-m68k.org writes:

 Christian Couder christian.cou...@gmail.com writes:

 Yeah, at one point I wanted to have a command that created to craft a
 new commit based on an existing one.

 This isn't hard to do, you only have to resort to plumbing:

 $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed 
 s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
  | git hash-object -t commit --stdin -w
 bb45cc6356eac6c7fa432965090045306dab7026

 Good.  I do not think an extra special-purpose command is welcome
 here.
 
 Well, I'm not sure this is intuitive enough to be useful to the average user 
 :)

When I played with git-replace in the past, I imagined that it could be

   git replace object --commit ...commit options...

that would do the trick.

We could implement it with a git-replace--commit helper script that
generates the replacement commit using the ...commit options... (to be
defined what this should be), and git-replace would just pick its output
(the SHA1 of the generated commit) as a substitute for the replacement
argument that would have to be given without the --commit option.

-- Hannes
--
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: [BUG] Cannot push some grafted branches

2012-12-18 Thread Thomas Rast
Johannes Sixt j.s...@viscovery.net writes:

 Am 12/18/2012 12:00, schrieb Yann Dirson:
 On Mon, 17 Dec 2012 13:14:56 -0800
 Junio C Hamano gits...@pobox.com wrote:
 
 Andreas Schwab sch...@linux-m68k.org writes:

 Christian Couder christian.cou...@gmail.com writes:

 Yeah, at one point I wanted to have a command that created to craft a
 new commit based on an existing one.

 This isn't hard to do, you only have to resort to plumbing:

 $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 |
 sed
 s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
 | git hash-object -t commit --stdin -w
 bb45cc6356eac6c7fa432965090045306dab7026

 Good.  I do not think an extra special-purpose command is welcome
 here.
 
 Well, I'm not sure this is intuitive enough to be useful to the average user 
 :)

 When I played with git-replace in the past, I imagined that it could be

git replace object --commit ...commit options...

 that would do the trick.

 We could implement it with a git-replace--commit helper script that
 generates the replacement commit using the ...commit options... (to be
 defined what this should be), and git-replace would just pick its output
 (the SHA1 of the generated commit) as a substitute for the replacement
 argument that would have to be given without the --commit option.

I wouldn't even want a script -- we'd end up inventing a complicated
command-line editor for what can simply be done by judicious use of an
actual text editor.  How about something like the following?


 Documentation/git-replace.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git i/Documentation/git-replace.txt w/Documentation/git-replace.txt
index 51131d0..2502118 100644
--- i/Documentation/git-replace.txt
+++ w/Documentation/git-replace.txt
@@ -61,6 +61,27 @@ OPTIONS
Typing git replace without arguments, also lists all replace
refs.
 
+
+EXAMPLE
+---
+
+Replacements (and before them, grafts) are often used to replace the
+parent list of a commit.  Since commits are stored in a human-readable
+format, you can in fact change any property using the following
+recipe:
+
+
+$ git cat-file commit original_commit tmp
+$ vi tmp
+
+In the editor, adjust the commit as needed.  For example, you can edit
+the parent lists by adding/removing lines starting with parent.
+When done, replace the original commit with the edited one:
+
+$ git replace original_commit $(git hash-object -w tmp)
+
+
+
 BUGS
 
 Comparing blobs or trees that have been replaced with those that


-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [BUG] Cannot push some grafted branches

2012-12-18 Thread Thomas Rast
Yann Dirson dir...@bertin.fr writes:

 +EXAMPLE
 +---
 +
 +Replacements (and before them, grafts) are often used to replace the
 +parent list of a commit.  Since commits are stored in a human-readable
 +format, you can in fact change any property using the following
 +recipe:
 +
 +
 +$ git cat-file commit original_commit tmp
 +$ vi tmp
 +
 +In the editor, adjust the commit as needed.  For example, you can edit
 +the parent lists by adding/removing lines starting with parent.
 +When done, replace the original commit with the edited one:
 +
 +$ git replace original_commit $(git hash-object -w tmp)

 You probably meant -t commit - a sign that it's not so trivial to forge ?

Mostly a sign that despite my testing efforts, I still fail at
cutpaste...

But yes, it absolutely needs -t commit.  Otherwise the commit would be
replaced by a blob, and confusion ensues.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [BUG] Cannot push some grafted branches

2012-12-18 Thread Jeff King
On Tue, Dec 18, 2012 at 02:41:57PM +0100, Yann Dirson wrote:

  I wouldn't even want a script -- we'd end up inventing a complicated
  command-line editor for what can simply be done by judicious use of an
  actual text editor.  How about something like the following?
 
 Well, while it does the job, it is still hardly as straightforward as the
 old vi .git/info/grafts, or as a single easily-remembered commandline.

I wouldn't discount coming up with something based around git commit
that might be easier to use for specific instances, but it does seem
like an obvious feature to git replace to encapsulate Thomas's edit
script, which is the most general form.

I am not really interested in pushing this forward myself, but I worked
up this toy that somebody might find interesting (you can git replace
HEAD~20 to get dumped in an editor). It should probably handle trees,
and it would probably make sense to do per-object-type sanity checks
(e.g., call verify_tag on tags).

diff --git a/builtin/replace.c b/builtin/replace.c
index 398ccd5..90979b6 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -81,6 +81,57 @@ static int delete_replace_ref(const char *name, const char 
*ref,
return 0;
 }
 
+static void edit_buffer(struct strbuf *out, const char *buf, unsigned long len)
+{
+   char tmpfile[PATH_MAX];
+   int fd;
+
+   fd = git_mkstemp(tmpfile, sizeof(tmpfile), replace.XX);
+   if (fd  0)
+   die_errno(unable to create tempfile);
+   if (write_in_full(fd, buf, len)  0)
+   die_errno(unable to write to tempfile);
+   if (launch_editor(tmpfile, out, NULL)  0)
+   die_errno(unable to run editor);
+
+   close(fd);
+   unlink_or_warn(tmpfile);
+}
+
+static void edit_object(unsigned char old[20], unsigned char new[20])
+{
+   enum object_type type;
+   unsigned long size;
+   char *old_buf;
+   struct strbuf new_buf = STRBUF_INIT;
+
+   old_buf = read_sha1_file_extended(old, type, size, 0);
+   if (!old_buf)
+   die(unable to read object '%s', sha1_to_hex(old));
+
+   switch (type) {
+   case OBJ_COMMIT:
+   case OBJ_TAG:
+   case OBJ_BLOB:
+   /* These are OK to edit literally. */
+   edit_buffer(new_buf, old_buf, size);
+   break;
+   case OBJ_TREE:
+   /*
+* XXX we'd probably want to massage this into ls-tree format,
+* and then read the result back via mktree.
+*/
+   die(editing tree objects is not yet supported);
+   default:
+   die(unknown object type for %s, sha1_to_hex(old));
+   }
+
+   if (write_sha1_file(new_buf.buf, new_buf.len, typename(type), new)  0)
+   die(unable to write replacement object);
+   free(old_buf);
+   strbuf_release(new_buf);
+}
+
 static int replace_object(const char *object_ref, const char *replace_ref,
  int force)
 {
@@ -90,7 +141,7 @@ static int replace_object(const char *object_ref, const char 
*replace_ref,
 
if (get_sha1(object_ref, object))
die(Failed to resolve '%s' as a valid ref., object_ref);
-   if (get_sha1(replace_ref, repl))
+   if (replace_ref  get_sha1(replace_ref, repl))
die(Failed to resolve '%s' as a valid ref., replace_ref);
 
if (snprintf(ref, sizeof(ref),
@@ -105,6 +156,9 @@ static int replace_object(const char *object_ref, const 
char *replace_ref,
else if (!force)
die(replace ref '%s' already exists, ref);
 
+   if (!replace_ref)
+   edit_object(object, repl);
+
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
die(%s: cannot lock the ref, ref);
@@ -144,7 +198,7 @@ int cmd_replace(int argc, const char **argv, const char 
*prefix)
 
/* Replace object */
if (!list  argc) {
-   if (argc != 2)
+   if (argc  1 || argc  2)
usage_msg_opt(bad number of arguments,
  git_replace_usage, options);
return replace_object(argv[0], argv[1], force);
--
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: [BUG] Cannot push some grafted branches

2012-12-18 Thread Johannes Sixt
Am 12/18/2012 17:24, schrieb Jeff King:
 I am not really interested in pushing this forward myself, but I worked
 up this toy that somebody might find interesting (you can git replace
 HEAD~20 to get dumped in an editor). It should probably handle trees,
 and it would probably make sense to do per-object-type sanity checks
 (e.g., call verify_tag on tags).

I know it's just a throw-away patch, but I would discourage to go this
route without also adding all the sanity checks. Otherwise, it will have
just created a porcelain command that can generate a commit object with
any content you want!

-- Hannes
--
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: [BUG] Cannot push some grafted branches

2012-12-17 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes:

 Yann Dirson dir...@bertin.fr writes:

   In this respect, they seem to be
 lacking a few features, when compared to replace refs, but they have 
 different
 uses, ...

 Not reallyl; grafts were old hack whose use is still supported with
 its original limitations; replace is meant to replace all uses of
 grafts while removing grafts' largest warts.

I suppose there's the additional issue that grafts are much easier to
use than replacements if you really only want to replace some parent
lists.  With replace you need to handcraft the replacement commits, and
git-replace(1) unhelpfully does not say this, much less gives an example
how to do it.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [BUG] Cannot push some grafted branches

2012-12-17 Thread Junio C Hamano
Yann Dirson dir...@bertin.fr writes:

 And we may still want the bug fixed, or would we just list it as a known bug ?
 At least it does not seem to occur with replace refs:

The replace was designed to fix known limitation of grafts,
which is _inherent_ to it; the graft information was designed _not_
to be shared across repositories.  The fix was done by by using a
different mechanism to allow propagating the information across
repositories.

So there is nothing further to fix, except that there is a documentation
bug you can fix if you didn't find it documented.

Thanks.


 git-test$ rm .git/info/grafts 
 git-test$ echo fake merge | git commit-tree master^{tree} -p master^ -p 
 maint
 b821b2aa00973a47936d7cd25c9a5978b1c839c6
 git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
 git-test$ git push origin maint
 ...
50b03b0..79211fe  maint - maint
--
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: [BUG] Cannot push some grafted branches

2012-12-17 Thread Yann Dirson
On Mon, 17 Dec 2012 00:56:06 -0800
Junio C Hamano gits...@pobox.com wrote:

 Yann Dirson dir...@bertin.fr writes:
 
  And we may still want the bug fixed, or would we just list it as a known 
  bug ?
  At least it does not seem to occur with replace refs:
 
 The replace was designed to fix known limitation of grafts,
 which is _inherent_ to it; the graft information was designed _not_
 to be shared across repositories.  The fix was done by by using a
 different mechanism to allow propagating the information across
 repositories.

I see.  But from what I observed (without looking at the source), it looks like
when determining which commits are to be pushed, the grafts file is not 
neutralized
as it should.

 So there is nothing further to fix, except that there is a documentation
 bug you can fix if you didn't find it documented.

Will do.

 Thanks.
 
 
  git-test$ rm .git/info/grafts 
  git-test$ echo fake merge | git commit-tree master^{tree} -p master^ -p 
  maint
  b821b2aa00973a47936d7cd25c9a5978b1c839c6
  git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
  git-test$ git push origin maint
  ...
 50b03b0..79211fe  maint - maint


-- 
Yann Dirson - Bertin Technologies
--
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: [BUG] Cannot push some grafted branches

2012-12-17 Thread Junio C Hamano
Andreas Schwab sch...@linux-m68k.org writes:

 Christian Couder christian.cou...@gmail.com writes:

 Yeah, at one point I wanted to have a command that created to craft a
 new commit based on an existing one.

 This isn't hard to do, you only have to resort to plumbing:

 $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed 
 s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
  | git hash-object -t commit --stdin -w
 bb45cc6356eac6c7fa432965090045306dab7026

Good.  I do not think an extra special-purpose command is welcome
here.
--
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: [BUG] Cannot push some grafted branches

2012-12-16 Thread Yann Dirson
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano gits...@pobox.com wrote:

 Yann Dirson dir...@bertin.fr writes:
 
    In this respect, they seem to be
  lacking a few features, when compared to replace refs, but they have 
  different
  uses, ...
 
 Not reallyl; grafts were old hack whose use is still supported with
 its original limitations; replace is meant to replace all uses of
 grafts while removing grafts' largest warts.

OK, I'll take this into account.

But this situation should probably be make more clear in the docs.  Currently,
gitrepository-layout.txt describes refs/replace/ (and shallow) by reference to 
grafts,
and those are not marked as discouraged-use or anything.

And we may still want the bug fixed, or would we just list it as a known bug ?
At least it does not seem to occur with replace refs:

git-test$ rm .git/info/grafts 
git-test$ echo fake merge | git commit-tree master^{tree} -p master^ -p maint
b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git push origin maint
...
   50b03b0..79211fe  maint - maint

-- 
Yann Dirson - Bertin Technologies
--
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: [BUG] Cannot push some grafted branches

2012-12-12 Thread Yann Dirson
On Tue, 11 Dec 2012 10:15:23 -0800
Junio C Hamano gits...@pobox.com wrote:

 Yann Dirson dir...@bertin.fr writes:
 
  There seems to be some bad interactions between git-push and grafts.
  The problem seems to occur when a commit that exists in the remote
  repo is subject to a graft in the local repo, and we try to push one
  of the fake parents.
 
 History tweaking by grafts is only visible inside your local
 repository and objects are not rewritten, and grafts are not
 transferred across repositories.  They were invented to be used as a
 stop-gap measure until you filter-branch the history before
 publishing (or if you do not publish, then you can keep using your
 local grafts).
 
 Isn't this well known?  Perhaps we would need to document it better.

I am well aware of that, and did not intend to push any grafted commit.
I am attempting to push a well-formed commit, which happens to be used as
a grafted commit's fake parent, and my interpretation is that git reacts
as if it was considering that the remote already had that commit, possibly
because it would not ignore grafts when deciding which commits are already
known to the remote.

 What you can do is to use replace instead and publish the replace
 refs, I think.  Object transfer will then follow the true parenthood
 connectivity and people who choose to use the same replacement as
 you do can fetch the replace ref from you (this will grab objects
 necessary to complete the alternative history) and install it.

I am only using grafts as a temporary and lightweight drafting area,
before setting the results in stone - although in my case it will be
with filter-branch rather than replace, but the idea is the same.  I just
got bitten when attempting to push a valid branch while the grafts were in
effect, when in fact they should have had no influence at all.

In fact, I even looked for a way to specify an alternate (or supplementary)
grafts file for this drafting work, so only well-controlled git invocations
would see them, whereas the others would just ignore them, and could not find
any - nor could I identify an existing way of disabling the use of grafts by
other means than moving it out of the way.  In this respect, they seem to be
lacking a few features, when compared to replace refs, but they have different
uses, and just using the latter as a drafting area is just not adequate.

I thought about adding support for a GIT_GRAFTS_FILE envvar, which would
default to $GITDIR/info/grafts, or maybe with a more general addition of a
GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that useful.

-- 
Yann Dirson - Bertin Technologies
--
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: [BUG] Cannot push some grafted branches

2012-12-12 Thread Yann Dirson
On Wed, 12 Dec 2012 09:44:32 +0100 Yann Dirson dir...@bertin.fr wrote:
 In fact, I even looked for a way to specify an alternate (or supplementary)
 grafts file for this drafting work, so only well-controlled git invocations
 would see them, whereas the others would just ignore them, and could not find
 any - nor could I identify an existing way of disabling the use of grafts by
 other means than moving it out of the way.  In this respect, they seem to be
 lacking a few features, when compared to replace refs, but they have 
 different
 uses, and just using the latter as a drafting area is just not adequate.
 
 I thought about adding support for a GIT_GRAFTS_FILE envvar, which would
 default to $GITDIR/info/grafts, or maybe with a more general addition of a
 GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that 
 useful.

My bad on this point: there *is* a GIT_GRAFT_FILE envvar, it is just 
undocumented.
In fact it is not the only one:

git.git$ for v in $(git grep define.*_ENVIRONMENT master -- cache.h | cut -d'' 
-f2|grep ^GIT_); do git grep -q $v master -- Documentation || echo missing 
$v; done
missing GIT_GRAFT_FILE
missing GIT_CONFIG_PARAMETERS


-- 
Yann Dirson - Bertin Technologies
--
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: [BUG] Cannot push some grafted branches

2012-12-12 Thread Junio C Hamano
Yann Dirson dir...@bertin.fr writes:

   In this respect, they seem to be
 lacking a few features, when compared to replace refs, but they have 
 different
 uses, ...

Not reallyl; grafts were old hack whose use is still supported with
its original limitations; replace is meant to replace all uses of
grafts while removing grafts' largest warts.

--
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: [BUG] Cannot push some grafted branches

2012-12-11 Thread Junio C Hamano
Yann Dirson dir...@bertin.fr writes:

 There seems to be some bad interactions between git-push and grafts.
 The problem seems to occur when a commit that exists in the remote
 repo is subject to a graft in the local repo, and we try to push one
 of the fake parents.

History tweaking by grafts is only visible inside your local
repository and objects are not rewritten, and grafts are not
transferred across repositories.  They were invented to be used as a
stop-gap measure until you filter-branch the history before
publishing (or if you do not publish, then you can keep using your
local grafts).

Isn't this well known?  Perhaps we would need to document it better.

What you can do is to use replace instead and publish the replace
refs, I think.  Object transfer will then follow the true parenthood
connectivity and people who choose to use the same replacement as
you do can fetch the replace ref from you (this will grab objects
necessary to complete the alternative history) and install it.


--
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