* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-19 15:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git
In-Reply-To: <alpine.LFD.2.00.0908181711350.6044@xanadu.home>
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Jakub Narebski wrote:
>
>> You can probably get number and size taken by delta and non-delta (base)
>> objects in the packfile somehow. Neither "git verify-pack -v <packfile>"
>> nor contrib/stats/packinfo.pl did help me arrive at this data.
>
> Documentation for verify-pack says:
>
> |When specifying the -v option the format used is:
> |
> | SHA1 type size size-in-pack-file offset-in-packfile
> |
> |for objects that are not deltified in the pack, and
> |
> | SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
> |
> |for objects that are deltified.
>
> So a simple script should be able to give you the answer.
Thanks.
There are 114937 objects in this packfile, including 56249 objects
used as base (can be deltified or not). git-verify-pack -v shows
that all objects have total size-in-packfile of 33 MB (which agrees
with packfile size of 33 MB), with 17 MB size-in-packfile taken by
deltaified objects, and 16 MB taken by base objects.
git verify-pack -v |
grep -v "^chain" |
grep -v "objects/pack/pack-" > verify-pack.out
sum=0; bsum=0; dsum=0;
while read sha1 type size packsize off depth base; do
echo "$sha1" >> verify-pack.sha1.out
sum=$(( $sum + $packsize ))
if [ -n "$base" ]; then
echo "$sha1" >> verify-pack.delta.out
dsum=$(( $dsum + $packsize ))
else
echo "$sha1" >> verify-pack.base.out
bsum=$(( $bsum + $packsize ))
fi
done < verify-pack.out
echo "sum=$sum; bsum=$bsum; dsum=$dsum"
>>>> (BTW what happens if this pack is larger than file size limit for
>>>> given filesystem?).
[...]
>> If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
>> FAT is often used on SSD, on USB drive. Although if you have 2 GB
>> packfile, you are doing something wrong, or UGFWIINI (Using Git For
>> What It Is Not Intended).
>
> Hopefully you're not performing a 'git clone' off of a FAT filesystem.
> For physical transport you may repack with the appropriate switches.
Not off a FAT filesystem, but into a FAT filesystem.
[...]
>>> I think it is better to "prime" the repository with the content of the
>>> top commit in the most straight forward manner using git-archive which
>>> has the potential to be fully restartable at any point with little
>>> complexity on the server side.
>>
>> But didn't it make fully restartable 2.5 MB part out of 37 MB packfile?
>
> The front of the pack is the critical point. If you get enough to
> create the top commit then further transfers can be done incrementally
> with only the deltas between each commits.
How? You have some objects that can be used as base; how to tell
git-daemon that we have them (but not theirs prerequisites), and how
to generate incrementals?
>> A question about pack protocol negotiation. If clients presents some
>> objects as "have", server can and does assume that client has all
>> prerequisites for such objects, e.g. for tree objects that it has
>> all objects for files and directories inside tree; for commit it means
>> all ancestors and all objects in snapshot (have top tree, and its
>> prerequisites). Do I understand this correctly?
>
> That works only for commits.
Hmmmm... how do you intent for "prefetch top objects restartable-y first"
to work, then?
>> BTW. because of compression it might be more difficult to resume
>> archive creation in the middle, I think...
>
> Why so? the tar+gzip format is streamable.
gzip format uses sliding window in compression. "cat a b | gzip"
is different from "cat <(gzip a) <(gzip b)".
But that doesn't matter. If we are interrupted in the middle, we can
uncompress what we have to check how far did we get, and tell server
to send the rest; this way server wouldn't have to even generate
(but not send) what we get as partial transfer.
P.S. What do you think about 'bundle' capability extension mentioned
in a side sub-thread?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Erik Faye-Lund @ 2009-08-19 14:51 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes Schindelin, Marius Storm-Olsen, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <4A8BFD75.8000706@storm-olsen.com>
On Wed, Aug 19, 2009 at 3:26 PM, Marius
Storm-Olsen<marius@storm-olsen.com> wrote:
> They would still require the rest of the msysgit environment to be able to
> use the result. Not until we have zero scripts left as git commands can we
> ditch the msysgit environment. So yes, even for msvc-built git is msysgit
> required. Its just not build with MinGW.
...perhaps support for msvc for a subset of git-core (without all
shell scripts, that is) is just the incentive some windows-developers
need to start developing c-versions of the lacking functionality? A
pure C git-core would IMO be the ideal case. Utilities could still be
scripted on top of this through bindings given that the developer have
perl installed, no?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: D Sundstrom @ 2009-08-19 14:40 UTC (permalink / raw)
To: git
In-Reply-To: <20090819102036.GC28920@sigill.intra.peff.net>
Thanks to all that responded.
It might help to frame things from Aunt Tillie's point of view.
Her workflow consists of editing office documents (word, powerblower, etc)
in collaboration with her peers. They email these back and forth and
come up with whatever ad-hoc "version control" they think of at the
moment, such as file names, dates, verbal communication, etc.
I'm technical product manager and I need to coordinate reviews of
these documents as well as my release process. I also face audits
and accreditation from my customers.
We previously chose and implemented GIT for our scm system based
on a number of considerations. Primarily we have distributed teams and
also there is a review and sign-off process before code is "blessed" into
our official repository. For this, GIT fits well.
I'm going to put all the project artifacts into this repository, including
the aforementioned office documents. They just get versioned as binary
blobs, which is fine for this application. I just need to know which one
is current and maintain prior versions.
Aunt Tillie may someday appreciate our scm enough to install a client
on her machine and learn how to use it. But that is a big jump from
the simple workflow she has today. My thought is that I might get her
to upload this document to a SMB/CIFS or webdav file share, or use
a simple webapp, but that is about it for now.
My thought is to just have a process that watches for these files and
commits them as they arrive. I wouldn't do any filename magic, I would
just train Aunt Tillie to use the same name every time. If two people
step on each other's work, they tend learn from the experience and
coordinate amongst themselves the next time. There are only a
few people touching any given document.
A wiki doesn't seem appropriate because we are dealing with office
documents rather than "wiki-like" content. This is more of a
document management system, albeit a very simple one.
The Aunt Tillies are all on windows (XP or later). The development
team is all over the map, windows, osx, linux.
-David
On Wed, Aug 19, 2009 at 5:20 AM, Jeff King<peff@peff.net> wrote:
> On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:
>
>> Then you have a bunch of people who do not want to care about learning
>> proper version control.
>>
>> This is what I would do: write a very simple .cgi (I'd use Perl for that),
>> which has a file upload button, takes the name as commit message (or maybe
>> adds a field where you can type in a commit message, but that might be
>> asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes
>> ($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and
>> committer information according to IP (and refuse if the IP is not in the
>> internal mapping) and commit.
>>
>> The whole script would probably not be larger than 50 lines, and require
>> Git to be installed on the server.
>>
>> The bigger problem is that your Aunt Tillies most likely would not love
>> gitweb, so you need a fancier interface.
>
> Actually, I think there is a technical problem here. You get Aunt
> Tillie's v3, but you don't necessarily know what it is based on. So if
> some other Aunt Tillie has submitted a v3 in the meantime, what do you
> do with her file? Commit on top? Try to guess where her v2 was, branch
> from there, and merge?
>
> If you commit on top, then you are potentially erasing the other
> person's work. If you do a merge, you are likely to get conflicts
> (especially because Aunt Tillie likes to use horrible binary formats)
> that _somebody_ will have to resolve.
>
> I guess you can throw each Tillie on their own branch and then let
> somebody clueful do the merging, but then you do not really have people
> working together.
>
> I think this is a fundamental issue. Most version control systems (and
> especially distributed ones) are about doing concurrent work and
> merging, and merging requires a bit of a clue. The Aunt Tillies of the
> world really need a locking system to manage concurrency.
>
> -Peff
>
^ permalink raw reply
* Re: [msysGit] Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-19 13:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908191455140.5594@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Johannes Schindelin said the following on 19.08.2009 14:56:
> On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
>> Ok, but you would still have to rely on GNU Make in this setup,
>> and it would have to generate the common_cmds.h before you can
>> even compile with the MSVC IDE.
>
> But then I could bundle it up and give it to a Visual Studio user
> and they do not need msysGit.
>
> But maybe we should require them to have msysGit? After all, if
> the package is too small, no Windows developer will take it
> seriously, right? ;-)
They would still require the rest of the msysgit environment to be
able to use the result. Not until we have zero scripts left as git
commands can we ditch the msysgit environment. So yes, even for
msvc-built git is msysgit required. Its just not build with MinGW.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Jakub Narebski @ 2009-08-19 13:20 UTC (permalink / raw)
To: Jeff King; +Cc: Rob (gmail), git
In-Reply-To: <20090819124820.GC20381@coredump.intra.peff.net>
On Wed, 19 August 2009, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 19, 2009 at 02:18:07PM +0200, Jakub Narebski wrote:
>
> > More complicated solution, used by gitweb, requires Perl, not checked
> > that it works correctly, doesn't work with ancient repositories with
> > symlink HEAD.
> >
> > $ perl -e '
> > use File::Find qw(find);
> > my @list = ();
> > find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
> > wanted => sub {
> > return if (m!^[/.]$!);
> > return unless (-d $_);
> > push @list, $_ if -e "$_/HEAD"
> > }});
> > print join("\n", @list)."\n";
> > '
>
> That doesn't seem very accurate. It will find 'HEAD' in "logs/" of
> repositories with reflogs enabled, and "refs/remotes/*/" of cloned
> repositories, giving you a lot of false positives.
To be more exact it is simplified solution used by git; in this case
_oversimplified_, as gitweb doesn't have problems with 'HEAD' in
remote-tracking branches.
On the other hand gitweb currently does not detect submodules or
submodule-like repositories, i.e. repositories inside working directory
of other repository. So this could be improved...
>
> If you want accuracy, you can ask git rev-parse to verify whether a
> directory is a git repo; it actually uses a few different heuristics to
> check. For example:
>
> find . -type d |
> while read dir; do
> if GIT_DIR=$dir git rev-parse --git-dir >/dev/null 2>&1; then
Or "git --git-dir=$dir rev-parse 2> /dev/null"
> echo $dir
> fi
> done
>
> but it is a bit slower, as you invoke rev-parse for every directory, and
> it actually does some verification of the contents of HEAD (so it is
> probably a bad idea for something like gitweb, which cares about
> performance).
>
> If you want to do a cheap and fast check, searching for 'HEAD', 'refs',
> and 'objects' in the same directory is a reasonable heuristic.
If one follow preferred git conventions for naming non-bare repositories,
and one doesn't have anything funny,
$ find . -name "*.git" -type d
should be sufficient.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH JGIT] Ensure created test repositories use canonical paths
From: Jonas Fonseca @ 2009-08-19 13:18 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Fixes breakage in the RepositoryCacheTest when running tests using:
mvn -f ./jgit-maven/jgit/pom.xml test
which in turn will lead to test repositories using paths, such as:
/path/to/jgit/./jgit-maven/jgit/trash/trash1250647279819.186/.git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index b1adde9..d1aef78 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -217,7 +217,7 @@ public void setUp() throws Exception {
final String name = getClass().getName() + "." + getName();
recursiveDelete(trashParent, true, name, false); // Cleanup old failed stuff
trash = new File(trashParent,"trash"+System.currentTimeMillis()+"."+(testcount++));
- trash_git = new File(trash, ".git");
+ trash_git = new File(trash, ".git").getCanonicalFile();
if (shutdownhook == null) {
shutdownhook = new Thread() {
@Override
@@ -307,7 +307,7 @@ protected Repository createNewEmptyRepo() throws IOException {
protected Repository createNewEmptyRepo(boolean bare) throws IOException {
final File newTestRepo = new File(trashParent, "new"
+ System.currentTimeMillis() + "." + (testcount++)
- + (bare ? "" : "/") + ".git");
+ + (bare ? "" : "/") + ".git").getCanonicalFile();
assertFalse(newTestRepo.exists());
final Repository newRepo = new Repository(newTestRepo);
newRepo.create();
--
1.6.4.rc3.195.g2b05f
^ permalink raw reply related
* Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-19 13:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Frank Li, Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <4A8BDA2A.9030105@viscovery.net>
Hi,
On Wed, 19 Aug 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Wed, 19 Aug 2009, Frank Li wrote:
> >> I have push my change to tgit
> >> git://repo.or.cz/tgit.git
> >> branch vcpatch2
> >>
> >> How do I know if patch has been applied main line?
> >
> > I applied them to 4msysgit.git's devel. Note that I had a strange
> > merge conflict in pager.c: you replaced and #ifndef __MINGW32__ with
> > an #ifndef WIN32, but I don't have that #ifndef at all.
>
> 4msysgit has my "Windows: Better support PAGER settings with spaces in
> the path", which removes the #ifndefs, Frank's version doesn't have it.
> Therefore, you should not rebase Frank's patches on top of 4msysgit's
> master or devel before they are merged into git.git.
Well, I wanted to give them a little bit more visibility by putting them
into 4msysgit.git, as I think the best way to get Microsoft Visual C++
support into git.git _is_ via 4msysgit.git.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Joshua Jensen @ 2009-08-19 13:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Marius Storm-Olsen, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908190910270.5594@intel-tinevez-2-302>
----- Original Message -----
From: Johannes Schindelin
Date: 8/19/2009 1:16 AM
> Using a Makefile from within Visual Studio is just not the intended way to
> do things, so you will hit the limitations sooner or later.
>
I use Visual Studio makefile projects daily and have for years. In my
case, an additional script takes the Jam build scripts and creates the
.vcproj files with the proper file lists and project source folders.
These Makefile .vcproj files have full support for Intellisense,
debugging, and nearly everything else. The only thing a Makefile
project doesn't seem to expose is single file compilation.
Josh
^ permalink raw reply
* Re: [msysGit] Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-19 12:56 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <4A8BDAF6.5060805@gmail.com>
Hi,
On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 19.08.2009 10:29:
> > Hi,
> >
> > On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
> >
> > > The full IDE support is secondary, first because you *can* use the
> > > IDE already, and second because it'll be harder to whip something up
> > > which guarantees that the vcproj support stays in-sync at all times
> > > and won't lag behind.
> >
> > I think the point of Frank's patches is to make Visual Studio users
> > comfortable with Git. You cannot ask those to use a build process or
> > an IDE they are not used to.
> >
> > > Of course, if someone has a huge itch to restructure the current
> > > Makefile; factoring out the files into a file which can simply be
> > > included in the current Makefile, and easily parsed by a script, or
> > > included by CMake, then that can be done in parallel and possible
> > > added to git mainline before the MSVC support patches from Frank.
> >
> > I still think it would be possible to use a combination of a Makefile
> > rule and GNU make features to spit out a list of targets and their
> > dependet .h and .c files.
>
> Ok, but you would still have to rely on GNU Make in this setup, and it
> would have to generate the common_cmds.h before you can even compile
> with the MSVC IDE.
But then I could bundle it up and give it to a Visual Studio user and they
do not need msysGit.
But maybe we should require them to have msysGit? After all, if the
package is too small, no Windows developer will take it seriously, right?
;-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH JGIT] Make Repository.stripWorkDir more robust
From: Jonas Fonseca @ 2009-08-19 12:50 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: awhawks, git
In-Reply-To: <200908122147.52530.robin.rosenberg.lists@dewire.com>
Repository.stripWorkDir was assuming too much about its File arguments,
namely that the given file was always a decendant of the workdir.
Futhermore, it did not "normalize" paths of relative files, but simpy
relied on the path returned by File.getPath().
The new behavior is to fall-back to using File.getAbsolutePath() if the
path returned by File.getPath() cannot be normalized. Test the new
behavior against mix of relative and absolute paths given as arguments.
Fixes problem with string out of bound exception when the path of the
given file is shorter than the workdir, usually meaning it is not a
decendant of the workdir.
Reported-by: Adam W. Hawks <awhawks@writeme.com>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
On Wed, Aug 12, 2009 at 15:47, Robin Rosenberg<robin.rosenberg.lists@dewire.com> wrote:
> Why not convert both paths? A trickier issue is that getAbsolutePath is very slow when
> the path is not absolute. I don't think we will always need to normalize in order to
> fix this. A few unit tests to show the cases solved would help.
Something like this? I am myself interested in fixing the string out of bound
exception, which makes this method unusable for me.
.../tst/org/spearce/jgit/lib/T0003_Basic.java | 25 ++++++++++++++++
.../src/org/spearce/jgit/lib/Repository.java | 31 ++++++++++++++-----
2 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
index 3660b45..c2b1b91 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
@@ -545,6 +545,31 @@ public void test029_mapObject() throws IOException {
assertEquals(Commit.class, db.mapObject(ObjectId.fromString("540a36d136cf413e4b064c2b0e0a4db60f77feab"), null).getClass());
assertEquals(Tree.class, db.mapObject(ObjectId.fromString("aabf2ffaec9b497f0950352b3e582d73035c2035"), null).getClass());
assertEquals(Tag.class, db.mapObject(ObjectId.fromString("17768080a2318cd89bba4c8b87834401e2095703"), null).getClass());
+ }
+
+ public void test30_stripWorkDir() {
+ File relCwd = new File(".");
+ File absCwd = relCwd.getAbsoluteFile();
+ File absBase = new File(new File(absCwd, "repo"), "workdir");
+ File relBase = new File(new File(relCwd, "repo"), "workdir");
+ assertEquals(absBase.getAbsolutePath(), relBase.getAbsolutePath());
+
+ File relBaseFile = new File(new File(relBase, "other"), "module.c");
+ File absBaseFile = new File(new File(absBase, "other"), "module.c");
+ assertEquals("other/module.c", Repository.stripWorkDir(relBase, relBaseFile));
+ assertEquals("other/module.c", Repository.stripWorkDir(relBase, absBaseFile));
+ assertEquals("other/module.c", Repository.stripWorkDir(absBase, relBaseFile));
+ assertEquals("other/module.c", Repository.stripWorkDir(absBase, absBaseFile));
+
+ File relNonFile = new File(new File(relCwd, "not-repo"), ".gitignore");
+ File absNonFile = new File(new File(absCwd, "not-repo"), ".gitignore");
+ assertEquals("", Repository.stripWorkDir(relBase, relNonFile));
+ assertEquals("", Repository.stripWorkDir(absBase, absNonFile));
+
+ assertEquals("", Repository.stripWorkDir(db.getWorkDir(), db.getWorkDir()));
+
+ File file = new File(new File(db.getWorkDir(), "subdir"), "File.java");
+ assertEquals("subdir/File.java", Repository.stripWorkDir(db.getWorkDir(), file));
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index d6be9bf..46b7804 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -729,7 +729,7 @@ else if (item.equals("")) {
}
}
if (time != null)
- throw new RevisionSyntaxException("reflogs not yet supported by revision parser yet", revstr);
+ throw new RevisionSyntaxException("reflogs not yet supported by revision parser", revstr);
i = m - 1;
break;
default:
@@ -1029,15 +1029,30 @@ public static boolean isValidRefName(final String refName) {
}
/**
- * Strip work dir and return normalized repository path
+ * Strip work dir and return normalized repository path.
*
- * @param wd Work dir
- * @param f File whose path shall be stripped of its workdir
- * @return normalized repository relative path
+ * @param workDir Work dir
+ * @param file File whose path shall be stripped of its workdir
+ * @return normalized repository relative path or the empty
+ * string if the file is not relative to the work directory.
*/
- public static String stripWorkDir(File wd, File f) {
- String relName = f.getPath().substring(wd.getPath().length() + 1);
- relName = relName.replace(File.separatorChar, '/');
+ public static String stripWorkDir(File workDir, File file) {
+ final String filePath = file.getPath();
+ final String workDirPath = workDir.getPath();
+
+ if (filePath.length() <= workDirPath.length() ||
+ filePath.charAt(workDirPath.length()) != File.separatorChar ||
+ !filePath.startsWith(workDirPath)) {
+ File absWd = workDir.isAbsolute() ? workDir : workDir.getAbsoluteFile();
+ File absFile = file.isAbsolute() ? file : file.getAbsoluteFile();
+ if (absWd == workDir && absFile == file)
+ return "";
+ return stripWorkDir(absWd, absFile);
+ }
+
+ String relName = filePath.substring(workDirPath.length() + 1);
+ if (File.separatorChar != '/')
+ relName = relName.replace(File.separatorChar, '/');
return relName;
}
--
1.6.4.rc3.195.g2b05f
^ permalink raw reply related
* Re: New to Git / Questions about single user / multiple projects
From: Jeff King @ 2009-08-19 12:49 UTC (permalink / raw)
To: Rob (gmail); +Cc: Jakub Narebski, git
In-Reply-To: <a2db4dd50908190528o7f16b65are1acc89c900f7014@mail.gmail.com>
On Wed, Aug 19, 2009 at 08:28:04AM -0400, Rob (gmail) wrote:
> That seems like the best solution.
> How do I delete my initial repository that I created and obviously
> messed up ?
If you have nothing of value in the whole directory, just "rm -rf repo".
If you want to keep the working tree but delete all of the git bits,
just "rm -rf .git".
-Peff
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Jeff King @ 2009-08-19 12:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Rob (gmail), git
In-Reply-To: <200908191418.08838.jnareb@gmail.com>
On Wed, Aug 19, 2009 at 02:18:07PM +0200, Jakub Narebski wrote:
> More complicated solution, used by gitweb, requires Perl, not checked
> that it works correctly, doesn't work with ancient repositories with
> symlink HEAD.
>
> $ perl -e '
> use File::Find qw(find);
> my @list = ();
> find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
> wanted => sub {
> return if (m!^[/.]$!);
> return unless (-d $_);
> push @list, $_ if -e "$_/HEAD"
> }});
> print join("\n", @list)."\n";
> '
That doesn't seem very accurate. It will find 'HEAD' in "logs/" of
repositories with reflogs enabled, and "refs/remotes/*/" of cloned
repositories, giving you a lot of false positives.
If you want accuracy, you can ask git rev-parse to verify whether a
directory is a git repo; it actually uses a few different heuristics to
check. For example:
find . -type d |
while read dir; do
if GIT_DIR=$dir git rev-parse --git-dir >/dev/null 2>&1; then
echo $dir
fi
done
but it is a bit slower, as you invoke rev-parse for every directory, and
it actually does some verification of the contents of HEAD (so it is
probably a bad idea for something like gitweb, which cares about
performance).
If you want to do a cheap and fast check, searching for 'HEAD', 'refs',
and 'objects' in the same directory is a reasonable heuristic.
-Peff
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Rob (gmail) @ 2009-08-19 12:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200908191418.08838.jnareb@gmail.com>
On Wed, Aug 19, 2009 at 8:18 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> Please do not toppost, and when responding cull the quoted part,
> so only those parts that are relevant to your reply are remaining.
Sorry, n00b mistake.
> BTW. you can
> use different identities for different projects by setting it
> in .git/config, i.e. in per-repository configuration file.
That seems like the best solution.
How do I delete my initial repository that I created and obviously messed up ?
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Jakub Narebski @ 2009-08-19 12:18 UTC (permalink / raw)
To: Rob (gmail); +Cc: git
In-Reply-To: <a2db4dd50908190400x1cbb1506sa38c60e31587f49d@mail.gmail.com>
Please do not toppost, and when responding cull the quoted part,
so only those parts that are relevant to your reply are remaining.
On Wed, 19 Aug 2009, Rob wrote:
> Thanks all for all the answers :)
>
> One last question based on the multiple projects issue:
> Is there a command that lists all your projects ?
>
> My initial thought is that there probably isn't, as there is no
> relation between the project except the userID ?
No, there no git commands for listing all your projects. BTW. you can
use different identities for different projects by setting it
in .git/config, i.e. in per-repository configuration file.
Simple solution, which finds only non-bare repositories, and which
can find false positives:
$ find ~ -name ".git" -type d -print
More complicated solution, used by gitweb, requires Perl, not checked
that it works correctly, doesn't work with ancient repositories with
symlink HEAD.
$ perl -e '
use File::Find qw(find);
my @list = ();
find({follow_fast => 1, follow_skip => 2, dangling_symlinks => 0,
wanted => sub {
return if (m!^[/.]$!);
return unless (-d $_);
push @list, $_ if -e "$_/HEAD"
}});
print join("\n", @list)."\n";
'
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: New to Git / Questions about single user / multiple projects
From: Rob (gmail) @ 2009-08-19 11:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ab1wnsie.fsf@localhost.localdomain>
Thanks all for all the answers :)
One last question based on the multiple projects issue:
Is there a command that lists all your projects ?
My initial thought is that there probably isn't, as there is no
relation between the project except the userID ?
Thanks again,
Rob.
On Wed, Aug 19, 2009 at 3:59 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> "Rob (gmail)" <robvanb@gmail.com> writes:
>
>> I'm new to git and have some (I think) basic questions that I have
>> not been able to find answers to in the documentation. It's very
>> possible that these are the result of my lack in understanding git /
>> version control, so feel free to point me to documentation that
>> might contain the answers.
>
> Documentation you might want to read:
>
> * "Git User's Manual", distributed with Git (installed at least on
> Linux at $sharedir/doc/git-$version/user-manual.html), also at
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
>
> * "The Git Community Book", available at
> http://book.git-scm.com/
>
> * "Pro Git. Professional version control", available at
> http://progit.org/book/
>
>> Q1:
>> Can I create a single repository (project?) for all my code, knowing
>> that there are multiple small, unrelated projects. Or should I create
>> a new repository for each project ?
>
> You should create a new repository for each project. In git each
> commit is about state of whole repository.
>
>
> If you have single unrelated files, you might want to consider using
> Zit tool (see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools for
> details), but beware that it is in early stages of development.
>
> (Although if you choose one big repository, you can split it later
> with some effort using git-filter-branch (or git-split somewhere in
> mailing list archives) if you didn't publish your repositories).
>
>> Q2:
>> After initalizing my repository, and comitting the 1st batch of code:
>> When further working on the code, will the command "git add ." add all
>> changed and new files ? Or do I specifically need to list the new
>> files ?
>
> "git add ." would add _all_ new not ignored files, and would stage all
> changed files. But you would have to be sure that all files you don't
> want to be comitted, like generated files (*.o, *.log,...) and backup
> files of your editor (*~ or *.bak), are ignored using .gitignore
> (usually for generated files) and .git/info/excludes or
> core.excludesFile (usually for specific patterns like backup files).
>
>> Q3: Can I run 'git add x' in any subdirectory, or do I need to issue
>> if from the root of the project ?
>
> Most git commands take subdirectory they are in into consideration
> when acting. "git add <filename>" in subdirectory works as expected.
>
> Note that some commands need to have '.' as filename / pattern to be
> limited to current subdirectory / act on current directory.
>
>> --
>> When in trouble or in doubt, run in circles, scream and shout
>
> :-)
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
--
When in trouble or in doubt, run in circles, scream and shout
^ permalink raw reply
* Re: [msysGit] Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-19 10:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johan 't Hart,
Junio C Hamano, msysgit, git, lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908190951020.5594@intel-tinevez-2-302>
Johannes Schindelin said the following on 19.08.2009 10:29:
> Hi,
>
> On Wed, 19 Aug 2009, Marius Storm-Olsen wrote:
>
>> The full IDE support is secondary, first because you *can* use the IDE
>> already, and second because it'll be harder to whip something up which
>> guarantees that the vcproj support stays in-sync at all times and won't
>> lag behind.
>
> I think the point of Frank's patches is to make Visual Studio users
> comfortable with Git. You cannot ask those to use a build process or an
> IDE they are not used to.
>
>> Of course, if someone has a huge itch to restructure the current
>> Makefile; factoring out the files into a file which can simply be
>> included in the current Makefile, and easily parsed by a script, or
>> included by CMake, then that can be done in parallel and possible added
>> to git mainline before the MSVC support patches from Frank.
>
> I still think it would be possible to use a combination of a
> Makefile rule and GNU make features to spit out a list of targets and
> their dependet .h and .c files.
Ok, but you would still have to rely on GNU Make in this setup, and it
would have to generate the common_cmds.h before you can even compile
with the MSVC IDE.
--
.marius
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Sixt @ 2009-08-19 10:55 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Frank Li, Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908191158310.5594@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> On Wed, 19 Aug 2009, Frank Li wrote:
>> I have push my change to tgit
>> git://repo.or.cz/tgit.git
>> branch vcpatch2
>>
>> How do I know if patch has been applied main line?
>
> I applied them to 4msysgit.git's devel. Note that I had a strange merge
> conflict in pager.c: you replaced and #ifndef __MINGW32__ with an #ifndef
> WIN32, but I don't have that #ifndef at all.
4msysgit has my "Windows: Better support PAGER settings with spaces in the
path", which removes the #ifndefs, Frank's version doesn't have it.
Therefore, you should not rebase Frank's patches on top of 4msysgit's
master or devel before they are merged into git.git.
-- Hannes
^ permalink raw reply
* Re: Simple commit mechanism for non-technical users
From: Jeff King @ 2009-08-19 10:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: D Sundstrom, git
In-Reply-To: <alpine.DEB.1.00.0908190940430.5594@intel-tinevez-2-302>
On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:
> Then you have a bunch of people who do not want to care about learning
> proper version control.
>
> This is what I would do: write a very simple .cgi (I'd use Perl for that),
> which has a file upload button, takes the name as commit message (or maybe
> adds a field where you can type in a commit message, but that might be
> asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes
> ($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and
> committer information according to IP (and refuse if the IP is not in the
> internal mapping) and commit.
>
> The whole script would probably not be larger than 50 lines, and require
> Git to be installed on the server.
>
> The bigger problem is that your Aunt Tillies most likely would not love
> gitweb, so you need a fancier interface.
Actually, I think there is a technical problem here. You get Aunt
Tillie's v3, but you don't necessarily know what it is based on. So if
some other Aunt Tillie has submitted a v3 in the meantime, what do you
do with her file? Commit on top? Try to guess where her v2 was, branch
from there, and merge?
If you commit on top, then you are potentially erasing the other
person's work. If you do a merge, you are likely to get conflicts
(especially because Aunt Tillie likes to use horrible binary formats)
that _somebody_ will have to resolve.
I guess you can throw each Tillie on their own branch and then let
somebody clueful do the merging, but then you do not really have people
working together.
I think this is a fundamental issue. Most version control systems (and
especially distributed ones) are about doing concurrent work and
merging, and merging requires a bit of a clue. The Aunt Tillies of the
world really need a locking system to manage concurrency.
-Peff
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-19 10:15 UTC (permalink / raw)
To: Frank Li; +Cc: Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <1976ea660908180911m7469ac20w48a28b90262d25f6@mail.gmail.com>
On Wed, 19 Aug 2009, Frank Li wrote:
> > Okay, I will wait for Frank's updates (just fetched tgit.git and it still
> > contains the old branch), merge the early part and add the compiler flags.
> >
> Today, I just update 5 patch according review feedback.
> Do I need send it again?
>
> I have push my change to tgit
> git://repo.or.cz/tgit.git
> branch vcpatch2
>
> How do I know if patch has been applied main line?
I applied them to 4msysgit.git's devel. Note that I had a strange merge
conflict in pager.c: you replaced and #ifndef __MINGW32__ with an #ifndef
WIN32, but I don't have that #ifndef at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
From: Jeff King @ 2009-08-19 10:11 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, git, Sverre Rabbelier, Nanako Shiraishi,
Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <200908191140.22235.trast@student.ethz.ch>
On Wed, Aug 19, 2009 at 11:40:20AM +0200, Thomas Rast wrote:
> > I took a look at this today.
> Heh, now *my* procrastination is paying off :-)
Curses, I fell into your trap!
> I think that is the correct way to go about it from the user's POV.
> He would be confused if the patch applied to WT/index were different
> (because of a later merge) from the hunks he chose in the -p loop.
>
> However, there's the issue of merge conflicts. Some options I can
> think of are
>
> 1) refuse to work in the face of merge problems
I had assumed we would do (1), just to keep things simple. Otherwise
stash becomes a multi-invocation command (with a --continue feature),
which really has a lot of complexity and corner cases.
> 2) stash requires a clean WT, so we can move the user's index out of
> the way and use temporary index + WT to let the user resolve the
> conflicts
>
> 3) require both clean WT and index so we can simply use the repo to
> resolve
Actually, we currently require that the index and WT match, so
these two are equivalent. But I think they add a lot of complexity
because of the continuation.
> (The first one isn't quite as restrictive as it sounds; the user can
> always apply on top of a clean HEAD, fix conflicts and re-stash, thus
> doing a "stash rebase".)
Which is really a nice way of dodging the continuation bullet, since the
results after each step are well-defined in terms of currently existing
steps. That is, the user could "git stash apply" and never invoke "git
stash apply -p" if munging the conflicts led to the result they wanted.
OTOH, it may have been simpler for them to edit the stash beforehand to
avoid the conflicts.
Hmm. Maybe we are really talking about two different commands:
1. edit the hunks that will be applied to the working tree from the
stash (apply -p)
2. edit the _stash itself_, taking or leaving hunks to create a new
stash
What was in my patch was basically (2), but then always followed by
applying. By splitting them, you can use whichever makes sense for your
situation.
> > 1. For --index mode, it actually invokes add--interactive twice. It
> > would be nice to do both passes at the same time, but I don't think
> > it is possible with the current add--interactive infrastructure.
>
> Note that the 'git stash -p' in next always stashes the index whole,
> so the "easy" way might simply be to also unstash the index whole (if
> requested).
That might be worthwhile. It is less flexible, but I really wonder if
people actually keep stash randomly different changes in their index and
worktree and want to pick through them individually. I guess we could
also add a --patch-index for people who really wanted it.
-Peff
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-19 9:58 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <4A8AEAF5.6070205@gmail.com>
Hi,
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 18.08.2009 16:11:
>
> > On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> >
> > > diff --git a/Makefile b/Makefile
> > > +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
> ...
> > > +else
> > > ifneq (,$(findstring MINGW,$(uname_S)))
> > > pathsep = ;
> > > NO_PREAD = YesPlease
> >
> > This means that gcc is never used when Visual C++ is available? Hmm.
>
> Yes it does :)
As you know, I do not own a Windows computer. On the Windows computer I
am allowed to use sometimes to test Git and my day-time project, the
Express edition was installed, but it was never registered, so it is not
usable, and I would not want to use it anyway.
So this change would break my setup.
> I was actually going to replace it with a USE_MSVC variable check
> instead though, so you'd rather do 'make USE_MSVC=1'
That's much nicer, especially since you can put that into config.mak.
> > > diff --git a/compat/msvc.h b/compat/msvc.h
> > > index 6071565..a9d5f7f 100644
> > > --- a/compat/msvc.h
> > > +++ b/compat/msvc.h
> > > @@ -10,50 +10,120 @@
> > >
> > > /*Configuration*/
> > >
> > > +#ifndef NO_PREAD
> > > #define NO_PREAD
> > > +#endif
> >
> > Why? You now have the stuff in two places. If you want to keep them
> > in compat/msvc.h to be able to generate .vcproj files, I'd rather not
> > have them duplicated in the Makefile.
>
> The changes to the msvc.h where added just keep Frank's vcproj project
> working. I would have just nuked all that stuff in the msvc.h since the
> Makefile would just provide it for me anyways..
So maybe you and Frank (and Pau) hash out what you want?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] stash: reject stash name starting with a dash.
From: Jeff King @ 2009-08-19 9:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <vpq8whg1ebi.fsf@bauges.imag.fr>
On Wed, Aug 19, 2009 at 08:57:05AM +0200, Matthieu Moy wrote:
> >> +test_expect_success 'stash --invalid-option' '
> >> + echo bar5 > file &&
> >> + echo bar6 > file2 &&
> >> + git add file2 &&
> >> + ! git stash --invalid-option &&
> >> + test bar5,bar6 = $(cat file),$(cat file2) &&
> >> + git stash -- -message-starting-with-dash &&
> >> + test bar,bar2 = $(cat file),$(cat file2)
> >> +'
> >
> > Should this actually be "git stash save --invalid-option", since it is
> > really testing the actual save option parsing, and not the behavior to
> > automatically push options to "git stash save"?
>
> It could be, but the most annoying DWIM would be the "implicit save"
> case, so that's the one I'm testing. One could test both, but that'd
> probably be a bit overkill.
But if your proposal to accept any "-*' is not accepted, then it is not
testing your added code at all, is it? Even without the rest of the
patch, the test would pass.
-Peff
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-19 9:53 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Nicolas Pitre, Tomasz Kontusz, git
In-Reply-To: <2e24e5b90908182142n16201ed4ua41408878664e353@mail.gmail.com>
On Wed, Aug 19, 2009, Sitaram Chamarty wrote:
> On Wed, Aug 19, 2009 at 12:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> > There is another way which we can go to implement resumable clone.
> > Let's git first try to clone whole repository (single pack; BTW what
> > happens if this pack is larger than file size limit for given
> > filesystem?). If it fails, client ask first for first half of of
> > repository (half as in bisect, but it is server that has to calculate
> > it). If it downloads, it will ask server for the rest of repository.
> > If it fails, it would reduce size in half again, and ask about 1/4 of
> > repository in packfile first.
>
> How about an extension where the user can *ask* for a clone of a
> particular HEAD to be sent to him as a git bundle? Or particular
> revisions (say once a week) were kept as a single file git-bundle,
> made available over HTTP -- easily restartable with byte-range -- and
> anyone who has bandwidth problems first gets that, then changes the
> origin remote URL and does a "pull" to get uptodate?
>
> I've done this manually a few times when sneakernet bandwidth was
> better than the normal kind, heh, but it seems to me the lowest impact
> solution.
>
> Yes you'd need some extra space on the server, but you keep only one
> bundle, and maybe replace it every week by cron. Should work fine
> right now, as is, with a wee bit of manual work by the user, and a
> quick cron entry on the server
This is a good idea, i think, and it can be implemented with various
amount of effort and changes to git, and various amount of seamless
integration.
1. Simplest solution: social (homepage). Not integrated at all.
On projects homepage, the one where there is described where project
repository is and how to get it, you add a link to most recent bundle
(perhaps in addition to most recent snapshot). This bundle would be
served as a static file via HTTP (and perhaps also FTP) by (any) web
server that supports resuming (range requests). Or you can make
server generate bundles on demand, only when they are first requested.
Most recent might mean latest tagged release, or it might mean daily
snapshot^W bundle.
This solution could be integrated into gitweb, either by generic
'latest bundle' link in project's README.html (or in site's
GITWEB_HOMETEXT, default indextext.html), or by having gitweb
generate those links (and perhaps bundles as well) by itself.
2. Seamless solution: 'bundle' or 'bundles' capability. Requires
changes to both server and client.
If server supports (advertises) 'bundle' capability, it can serve
list of bundles (as HTTP / FTP / rsync URLs) either at client request,
or after (or before) list of refs if client requests 'bundle'
capability.
If client has support for 'bundles' capability, it terminates
connection to sshd or git-daemon, and does ordinary resumable HTTP
fetch using libcurl. After bundle is downloaded fully, it clones
from bundle, and does git-fetch with the same server as before,
which would then have less to transfer. Client has also to handle
situation where bundle download is interrupted, and do not do cleanup,
allowing for "git clone --continue".
3. Seamless solution: GitTorrent or its simplification: git mirror-sync.
I think that GitTorrent (see http://git.or.cz/gitwiki/SoC2009Ideas)
or even its simplification git-mirror-sync would include restartable
cloning. It is even among its intended features. Also this would
help to download faster via mirrors which can have faster and better
network connection.
But this would be most work.
You can implement solution 1. even now...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Continue git clone after interruption
From: Johannes Schindelin @ 2009-08-19 9:52 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nicolas Pitre, Jakub Narebski, Tomasz Kontusz, git
In-Reply-To: <fcaeb9bf0908190125u3e1bcaaap27e72a5784f4f9db@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1065 bytes --]
Hi,
On Wed, 19 Aug 2009, Nguyen Thai Ngoc Duy wrote:
> On Wed, Aug 19, 2009 at 2:35 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > But here comes an idea: together with Nguy要's sparse series, it is
>
> FWIW, you can write "Nguyen" instead. It might save you one copy/paste
> (I take it you don't have a Vietnamese IM ;-)
FWIW I originally wrote Nguyễn (not that Chinese(?) character)... I look
it up everytime I want to write your name by searching my address book for
"pclouds". ;-)
> > conceivable that we support a shallow & narrow clone via the
> > upload-pack protocol (also making mithro happy). The problem with
> > narrow clones was not the pack generation side, that is done by a
> > rev-list that can be limited to certain paths. The problem was that
> > we end up with missing tree objects. However, if we can make a sparse
> > checkout, we can avoid the problem.
>
> But then git-fsck, git-archive... will die?
Oh, but they should be made aware of the narrow clone, just like for
shallow clones.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
From: Thomas Rast @ 2009-08-19 9:40 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Sverre Rabbelier, Nanako Shiraishi,
Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <20090818164826.GA27377@coredump.intra.peff.net>
Jeff King wrote:
>
> I took a look at this today.
Heh, now *my* procrastination is paying off :-)
> Hmm. I was about to write "so we need some clever way of integrating the
> interactive hunk selection with a 3-way merge". But I just had a
> thought: we should do it in the reverse order. We do the three-way merge
> into a temporary index, and then ask the user to apply the result of
> _that_ tree into the working tree. Or maybe I am missing something else
> obvious and you can enlighten me.
I think that is the correct way to go about it from the user's POV.
He would be confused if the patch applied to WT/index were different
(because of a later merge) from the hunks he chose in the -p loop.
However, there's the issue of merge conflicts. Some options I can
think of are
1) refuse to work in the face of merge problems
2) stash requires a clean WT, so we can move the user's index out of
the way and use temporary index + WT to let the user resolve the
conflicts
3) require both clean WT and index so we can simply use the repo to
resolve
(The first one isn't quite as restrictive as it sounds; the user can
always apply on top of a clean HEAD, fix conflicts and re-stash, thus
doing a "stash rebase".)
> 1. For --index mode, it actually invokes add--interactive twice. It
> would be nice to do both passes at the same time, but I don't think
> it is possible with the current add--interactive infrastructure.
Note that the 'git stash -p' in next always stashes the index whole,
so the "easy" way might simply be to also unstash the index whole (if
requested).
The changes will usually still be available in the worktree
application, because the 3-way merge is between base and HEAD on one
side and base and worktree-stash on the other side.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox