git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUG] Cannot push some grafted branches

From
YDYann Dirson <dirson@bertin.fr>
Date
Dec 17, 2012, 14:02 UTC
Message-ID
<20121217150230.545a3938@chalon.bertin.fr>
In-Reply-To
<CAP8UFD2pkotNy=t5wTxDH-pMivQsTz-kw2y8Y7rWY42YKabp7g@mail.gmail.com>

On Mon, 17 Dec 2012 14:43:59 +0100 Christian Couder <christian.couder@gmail.com> wrote:

Show 33 quoted lines
> Hi Yann,
> 
> On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson <dirson@bertin.fr> wrote:
> > On Mon, 17 Dec 2012 09:43:53 +0100
> > Thomas Rast <trast@student.ethz.ch> wrote:
> >
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>
> >>
> >> 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.
> >>
> >
> > Right, replace refs can surely be made easier to use.  The requirement to craft a
> > new commit manually is a major step back in ease of use.
> 
> Yeah, at one point I wanted to have a command that created to craft a
> new commit based on an existing one.
> Perhaps it could be useful when using filter-branch or perhaps it
> could reuse some filter-branch code.
> 
> > Maybe something like "git replace -p <orig-commit> <parent>..." to just provide a simple
> > API to the exact graft functionnality would be good.  But it would be commit-specific, whereas
> > replace refs are indeed more generic, and, one could want to rewrite any other part of the commit,
> > so we could prefer a more general mechanism.
> 
> Yeah I wondered at one point if something like the following would do:
> 
> git replace --parent <parent1> --parent <parent2> --author <author>
> --commiter <commiter> ... <orig-commit>

Yes, modification flags, that would only be allowed when the objects are commits, and would cause creation of a replace commit that's <orig-commit> plus modifications. We could then reuse the relevant options from git-commit, and add the missing --parent.

But wouldn't it stretch git-replace too much, to add commit-specific behaviour there ?
Show 8 quoted lines
> > Something that could be useful in this respect, would be an --amend like option to git-commit, like
> > "git commit --replace".  But unfortunately it does not allow to change parents, and it has the
> > drawback of requiring that HEAD points to the commit to be replaced.
> >
> > So maybe, if there are no other idea, a simple "git graft" command that would wrap "git replace",
> > would fill the gap.
> 
> It would not be straightforward to call it "graft" if it uses git replace.

Well, "git replace" would just be the "implementation detail". The idea would be to keep the concept of a "graft", and just change its implementation. If we care (and we surely do not, it's just a thought experiment ;), we could even provide, for pre-replace gits, a "git graft" implementation that would manipulate info/grafts, together with a docpatch saying that direct manipulation of info/grafts is deprecated.

-- 
Yann Dirson - Bertin Technologies
Previous: Christian CouderNext: Andreas Schwab
Message 12 of 29 in “[BUG] Cannot push some grafted branches”
  1. Yann DirsonDec 11, 2012
  2. Junio C HamanoDec 11, 2012
  3. Yann DirsonDec 12, 2012
  4. Yann DirsonDec 12, 2012
  5. Junio C HamanoDec 12, 2012
  6. Yann DirsonDec 17, 2012
  7. Junio C HamanoDec 17, 2012
  8. Yann DirsonDec 17, 2012
  9. Thomas RastDec 17, 2012
  10. Yann DirsonDec 17, 2012
  11. Christian CouderDec 17, 2012
  12. Yann DirsonDec 17, 2012
  13. Andreas SchwabDec 17, 2012
  14. Junio C HamanoDec 17, 2012
  15. Yann DirsonDec 18, 2012
  16. Johannes SixtDec 18, 2012
  17. Thomas RastDec 18, 2012
  18. Yann DirsonDec 18, 2012
  19. Thomas RastDec 18, 2012
  20. Jeff KingDec 18, 2012
  21. Johannes SixtDec 19, 2012
  22. Jeff KingDec 19, 2012
  23. Junio C HamanoDec 18, 2012
  24. Yann DirsonDec 19, 2012
  25. Thomas RastDec 19, 2012
  26. Junio C HamanoDec 19, 2012
  27. Michael J GruberDec 21, 2012
  28. Junio C HamanoDec 21, 2012
  29. Michael J GruberDec 22, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.