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

Re: [PATCH] Teach git-checkout-index to use file suffixes.

From
Junio C Hamano <junkio@cox.net>
Date
Mar 2, 2006, 07:59 UTC
Message-ID
<7vbqwp6zvg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<20060302065136.GA6377@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
Show 10 quoted lines
> Why let the user choose?  '/' shouldn't be permitted as that
> (possibly) would try to create a directory also named the same as
> the file (a bad thing).  Then its just two formats, depending on
> if you want all stages or just 1 stage:
>
> 	--stage=all --suffix=#1/#2/#3
>
> or
>
> 	--stage=1 --suffix=#1

I'll later agree with "why let the user choose" in this message, but for an entirely different reason.

I am not a great fan of extracting files from stages in the working tree to begin with. The git-unpack-file command tries carefully to avoid conflicts, and its use of temporary files is inherently, eh, temporary, and Porcelains know what names they get and know how to clean things up afterwards.

I am sympathetic to what you are trying to achieve here. Maybe your Porcelain would invoke a graphical 3-way merge program in a windowing environment, and the merge program displays the filename(s) your Porcelain fed it to the end user, without giving you a way to override it. In that context, it is not useful to the end user to show meaningless temporary filename, and having checkout-index to derive the temporary filename from real filename may look sensible.

However, --stage=all with --suffix would introduce name clashes between repeated conflicted merge runs, which requires Porcelain to be extra careful. Your last merge run might have involved three conflicting stages (leaving a.c~1, a.c~2, and a.c~3 in your working tree) and this time it may be "we removed it while they modified it" situation (needing to extract a.c~1, a.c~3 but not a.c~2). The Porcelain needs to make sure not to get confused by leftover a.c~2 file in the working tree from the previous run.

If what you are trying is to reduce the number of checkout-index calls by your Porcelain to extract conflicted stages, it _might_ make more sense to do something like this instead (I am thinking aloud, so take this with a big grain of salt -- it may not make sense at all):

    checkout-index --stage=all checks out higher-order stages in
    made-up temporary filenames, just like git-merge-one-file
    does using git-unpack-file one-by-one, with a single
    invocation.
    It reports the following to its standard output, one record
    per pathname in the index:
	tmp1 <SP> tmp2 <SP> tmp3 <TAB> pathname <RS>
    Here, tmp? is the temporary file names for each stage, or a
    dot for for a nonexistent stage.  pathname is c-quoted as
    usual for non -z output and RS is '\n' (under -z flag,
    pathname is a literal string and RS is NUL).  SP = space
    (ASCII 0x20), TAB = tab (ASCII 0x09).
    Example:
        ".tmp1323 . .tmp1232\tfoo/a.c\n"
    Notice the dot between the two temporary files -- stage2 is
    empty in this example.

Then your Porcelain could run --stage=all and read the output, and then moving the temporary files around whatever way pleases it. Since it needs to be careful about not overwriting the existing working tree files *and* not getting confused by existing garbage in the working tree anyway, I do not think it would make your life much easier to have checkout-index derive the temporary file names after the real working tree files.

BTW, using TAB to split metainformation and pathname and using SP to separate metainformation pieces are in line with the design other git tools use. With this, you can separate the LHS metainformation part and pathname using "cut", and you can have shell IFS to split the metainformation part apart after that. But that is a minor detail.

Previous: Shawn PearceNext: Shawn Pearce
Message 5 of 6 in “Teach git-checkout-index to use file suffixes.”
  1. Teach git-checkout-index to use file suffixes.Shawn Pearce, Mar 1, 2006
  2. Shawn PearceMar 1, 2006
  3. Mark WoodingMar 1, 2006
  4. Shawn PearceMar 2, 2006
  5. Junio C HamanoMar 2, 2006
  6. Shawn PearceMar 2, 2006

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.