All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann Dirson <dirson@bertin.fr>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
	Junio C Hamano <gitster@pobox.com>,
	Andreas Schwab <schwab@linux-m68k.org>,
	Christian Couder <christian.couder@gmail.com>,
	Thomas Rast <trast@student.ethz.ch>,
	git list <git@vger.kernel.org>
Subject: Re: [BUG] Cannot push some grafted branches
Date: Tue, 18 Dec 2012 14:41:57 +0100	[thread overview]
Message-ID: <20121218144157.00ccd915@chalon.bertin.fr> (raw)
In-Reply-To: <871uentthz.fsf@pctrast.inf.ethz.ch>

On Tue, 18 Dec 2012 13:49:44 +0100
Thomas Rast <trast@inf.ethz.ch> wrote:

> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
> > Am 12/18/2012 12:00, schrieb Yann Dirson:
> >> On Mon, 17 Dec 2012 13:14:56 -0800
> >> Junio C Hamano <gitster@pobox.com> wrote:
> >> 
> >>> Andreas Schwab <schwab@linux-m68k.org> writes:
> >>>
> >>>> Christian Couder <christian.couder@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?

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 was again thinking the only commandline stuff that does not exist currently in
git-commit is specifying parents.  One possiblity would be to add such an
option to git-commit, together with a --replace flag that would cause the
new commit to attached a replace ref (not completely unlike --append, in that
we're doing some non-default action instead of just adding the changes to a
new commit).

But well, I don't think we would want to add to git-commit the ability of playing
with something else than what's in the index/worktree.  Abstracting the commit
commandline to make it reusable by a git-replace--commit and possibly other tools
that may want to rw-manipulate arbitrary commits could make sense ?


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

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

> +------------------------------------------------
> +
> +
>  BUGS
>  ----
>  Comparing blobs or trees that have been replaced with those that
> 
> 


-- 
Yann Dirson - Bertin Technologies

  reply	other threads:[~2012-12-18 13:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 14:39 [BUG] Cannot push some grafted branches Yann Dirson
2012-12-11 18:15 ` Junio C Hamano
2012-12-12  8:44   ` Yann Dirson
2012-12-12 10:54     ` Yann Dirson
2012-12-12 19:57     ` Junio C Hamano
2012-12-17  7:52       ` Yann Dirson
2012-12-17  8:56         ` Junio C Hamano
2012-12-17 10:30           ` Yann Dirson
2012-12-17  8:43       ` Thomas Rast
2012-12-17 10:40         ` Yann Dirson
2012-12-17 13:43           ` Christian Couder
2012-12-17 14:02             ` Yann Dirson
2012-12-17 20:03             ` Andreas Schwab
2012-12-17 21:14               ` Junio C Hamano
2012-12-18 11:00                 ` Yann Dirson
2012-12-18 12:03                   ` Johannes Sixt
2012-12-18 12:49                     ` Thomas Rast
2012-12-18 13:41                       ` Yann Dirson [this message]
2012-12-18 14:31                         ` Thomas Rast
2012-12-18 16:24                         ` Jeff King
2012-12-19  7:13                           ` Johannes Sixt
2012-12-19 13:06                             ` Jeff King
2012-12-18 16:09                   ` Junio C Hamano
2012-12-19  8:29                     ` Yann Dirson
2012-12-19 13:12                     ` Thomas Rast
2012-12-19 20:07                       ` Junio C Hamano
2012-12-21 12:47                         ` Michael J Gruber
2012-12-21 16:58                           ` Junio C Hamano
2012-12-22 16:38                             ` Michael J Gruber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121218144157.00ccd915@chalon.bertin.fr \
    --to=dirson@bertin.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=schwab@linux-m68k.org \
    --cc=trast@inf.ethz.ch \
    --cc=trast@student.ethz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.