From: Shawn Pearce <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Teach git-checkout-index to use file suffixes.
Date: Thu, 2 Mar 2006 12:10:09 -0500 [thread overview]
Message-ID: <20060302171009.GD18929@spearce.org> (raw)
In-Reply-To: <7vbqwp6zvg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> 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.
Clearly. pg was trying to delete all of those files before doing its
merge work but failed because of the --ignored bug in git-ls-files;
but this is now fixed. Still a possibility for confusion does exist.
But in at least one case my Porcelain is Eclipse and a Cygwin
prompt. In this case I want to view and edit everything in Eclipse.
Having all of the files in the same directory just makes it easier
to view. Random temporary names in the same directory as the tracked
file would be OK except if I had multiple conflicts in the same
directory, in which case I need some easy way to tell them apart.
At which point we're starting to derive off the tracked file name
and might as well always use well-known names.
> 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>
[...]
That's not a bad idea. The only thing I don't like about that
is that git-checkout-index won't build the directory tree for me;
the Porcelain must still be responsible for doing that before it
can rename the temporary files (if available) into the correct
subdirectory.
My plan with git-checkout-index though was originally to just have
it fail if the file already exists, unless -f is given. So if
a left-over foo.c#2 was still on disk and git-checkout-index was
going to write to that name it would fail.
I see a lot of benefit from the checkout to temporary file names
and let the Porcelian rename (if it desires).
So I'm going to ask you to withdraw the --suffix patch from pu.
I'll write up a new patch using the ideas you suggest above and
submit that instead.
--
Shawn.
prev parent reply other threads:[~2006-03-02 17:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-01 4:41 [PATCH] Teach git-checkout-index to use file suffixes Shawn Pearce
2006-03-01 15:06 ` Shawn Pearce
2006-03-01 15:56 ` Mark Wooding
2006-03-02 6:51 ` Shawn Pearce
2006-03-02 7:59 ` Junio C Hamano
2006-03-02 17:10 ` Shawn Pearce [this message]
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=20060302171009.GD18929@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).