* [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Johannes Schindelin @ 2007-12-19 13:40 UTC (permalink / raw)
To: Dana How; +Cc: Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com>
When you are in a deeply-nested directory structure, and just want
to reference a blob in a past revision, it can be pretty slow to
type out "HEAD~29:/bla/blub/.../that-file".
This patch makes "HEAD~29:./that-file" substitute the current prefix
for "./". If there is not working directory, the prefix is empty.
Note that this patch does not handle "../", and neither do I plan to.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 18 Dec 2007, Dana How wrote:
> On Dec 18, 2007 5:16 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Tue, 18 Dec 2007, Dana How wrote:
> >
> > > The cases we are talking about are all subtrees of the
> > > working tree. There is a useful cwd suffix.
> >
> > No.
> >
> > The cases we're talking of are *not* subtrees of the working
> > tree.
> >
> > The SHA1 of a commit may well be a totally disjoint tree. Try
> > it in the git repository with something like
>
> Agreed, but note you wrote *may*.
Okay, this is a proposed patch. It leaves the existing
"HEAD:<path>" handling alone, and only touches "HEAD:./<path>",
which would have been invalid anyway (except if you hacked your
objects database to include a tree named ".").
Note: this patch is not meant for application directly. It should
be split into get_current_prefix() as one patch, and the
sha1_name.c stuff as the second. (Not only to boost my ohloh
statistics, but because they are logically two separate things.)
Note, too: this is a quick and little-bit-dirty patch, not well
tested. Particularly, I was unable to trigger the "No <path> in
<rev>" error path, so I am not confident that this handling is
correct.
Note also: in contrast to Alex' approach, this will not only work
for git-show, but for all callers of get_sha1().
cache.h | 1 +
setup.c | 16 +++++++++++++---
sha1_name.c | 17 ++++++++++++++---
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index 39331c2..83a2c31 100644
--- a/cache.h
+++ b/cache.h
@@ -225,6 +225,7 @@ extern char *get_index_file(void);
extern char *get_graft_file(void);
extern int set_git_dir(const char *path);
extern const char *get_git_work_tree(void);
+extern const char *get_current_prefix(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/setup.c b/setup.c
index b59dbe7..fb9b680 100644
--- a/setup.c
+++ b/setup.c
@@ -3,6 +3,12 @@
static int inside_git_dir = -1;
static int inside_work_tree = -1;
+static const char *current_prefix;
+
+const char *get_current_prefix()
+{
+ return current_prefix;
+}
const char *prefix_path(const char *prefix, int len, const char *path)
{
@@ -267,6 +273,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
/* config may override worktree */
if (check_repository_format_gently(nongit_ok))
return NULL;
+ current_prefix = retval;
return retval;
}
if (check_repository_format_gently(nongit_ok))
@@ -279,7 +286,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (chdir(work_tree_env) < 0)
die ("Could not chdir to %s", work_tree_env);
strcat(buffer, "/");
- return retval;
+ current_prefix = retval;
+ return current_prefix;
}
if (nongit_ok) {
*nongit_ok = 1;
@@ -339,7 +347,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
offset++;
cwd[len++] = '/';
cwd[len] = 0;
- return cwd + offset;
+ current_prefix = cwd + offset;
+ return current_prefix;
}
int git_config_perm(const char *var, const char *value)
@@ -396,7 +405,8 @@ const char *setup_git_directory(void)
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
- return rel && *rel ? strcat(rel, "/") : NULL;
+ current_prefix = rel && *rel ? strcat(rel, "/") : NULL;
+ return current_prefix;
}
return retval;
diff --git a/sha1_name.c b/sha1_name.c
index 13e1164..6f61d26 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -712,9 +712,20 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ if (!get_sha1_1(name, cp-name, tree_sha1)) {
+ const char *prefix;
+ if (!prefixcmp(cp + 1, "./") &&
+ (prefix = get_current_prefix())) {
+ unsigned char subtree_sha1[20];
+ if (get_tree_entry(tree_sha1, prefix,
+ subtree_sha1, mode))
+ return error("No '%s' in '%.*s'",
+ prefix, cp-name, name);
+ memcpy(tree_sha1, subtree_sha1, 20);
+ cp += 2;
+ }
+ return get_tree_entry(tree_sha1, cp+1, sha1, mode);
+ }
}
return ret;
}
--
1.5.4.rc0.72.g536e9
^ permalink raw reply related
* Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
From: Haavard Skinnemoen @ 2007-12-19 14:07 UTC (permalink / raw)
To: git
Cc: Chip Coldwell, linux, kernel, linux-kernel, linux-arm-kernel,
Bohmer, Andrew Victor
In-Reply-To: <20071219124008.4945e592@dhcp-252-066.norway.atmel.com>
On Wed, 19 Dec 2007 12:40:08 +0100
Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:
> Btw, the funny thing is that, looking at my shell history, I think I
> actually did the right thing when committing your patches:
>
> git commit -s --author 'Remy Bohmer <linux@bohmer.net>'
> git commit -s --author 'Chip Coldwell <coldwell@frank.harvard.edu>'
>
> But for some reason only your names stuck, not your e-mail addresses...
It just happened again. Seems like if git-rebase hits a conflict, and I
just do "git-rebase --continue" after resolving it (and updating the
index), the original author's name is used, but not his e-mail address.
Looks like a bug in git-rebase...?
Haavard
^ permalink raw reply
* Re: bug with .gitattributes diff and embedded NUL
From: Eric Blake @ 2007-12-19 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve6vw5kg.fsf@gitster.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Junio C Hamano on 12/18/2007 11:40 PM:
> Eric Blake <ebb9@byu.net> writes:
>
>> Looking closer at .dotest/0001, the diff is indeed invalid, containing the
>> single line
>
> That dataflow loses NUL. Fixing
> rebase not to reuse the e-mailed patch dataflow is on my to-do list, but
> has been slipping.
>
> I think you can use "rebase -m" to work this issue around.
Indeed, after learning about git-rebase -m and git-mergetool, adding the
merge option alongside the diff option for the file in question, and
teaching emacs that it should use emerge-diff-options "-a" so that it can
handle embedded NUL, I was finally able to use git-mergetool to do a sane
merge of the differences in the mostly-text file. Thanks!
But it raised some additional issues:
Is there a way to specify custom merge tools, rather than the current
hard-coded list valid for merge.tool? For example, what if I prefer
emacs' ediff driver over its emerge driver?
Using merge.tool of emerge leaves junk around when the merge is aborted.
Before I edited emacs' emerge-diff-options, the subsidiary diff3 was
failing because it treated the file to merge as binary even though git was
trying to treat it as text. As a result, emerge left behind all of its
command-line argument files (file.{BASE,LOCAL,REMOTE}.pid), and git did
not clean any of them up.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHaShk84KuGfSFAYARAkDtAJ0XhhhbeJZJS6td3/aeOlxd7iuoawCgiVY6
3s+aMxRO1vjKf/EqncKW2jE=
=GrcF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Charles Bailey @ 2007-12-19 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Linus Torvalds, git
In-Reply-To: <7v3au2joo2.fsf_-_@gitster.siamese.dyndns.org>
On Sun, Dec 16, 2007 at 01:49:17PM -0800, Junio C Hamano wrote:
>
> Kind'a embarrassing that both of us cannot get this right without so
> many rounds, isn't it?
>
> -- >8 --
> Subject: [PATCH] Re-re-re-fix common tail optimization
>
> We need to be extra careful recovering the removed common section, so
> that we do not break context nor the changed incomplete line (i.e. the
> last line that does not end with LF).
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just to add to the woe on this one, this test breaks on MacOS X due to
the pattern length limitations of the default sed on that platform.
Interested in a patch?
Charles.
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Jeff King @ 2007-12-19 14:27 UTC (permalink / raw)
To: Charles Bailey; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20071219141845.GA2146@hashpling.org>
On Wed, Dec 19, 2007 at 02:18:45PM +0000, Charles Bailey wrote:
> Just to add to the woe on this one, this test breaks on MacOS X due to
> the pattern length limitations of the default sed on that platform.
>
> Interested in a patch?
Somebody beat you to it. :) Can you confirm that the fix in
<1198007158-27576-1-git-send-email-win@wincent.com>
works for you?
-Peff
^ permalink raw reply
* Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-19 14:32 UTC (permalink / raw)
To: git
I'm struggling to come up with a minimal test case that confirms this,
but I seem to be hitting a bug in the pretty string formatter when
trying to print bodies of commits that don't have bodies.
For example, on a private repository, I'm trying to print the subject
& body of a commit. This particular commit doesn't actually have a
body, so I'm expecting to see this output :
=================
commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
Try to flush log files before terminating the app
=================
However, when I actually run the command, I get gibberish in place of %b :
=================
$ git rev-list -1- --pretty=format:"%s%n%b"
18d2480ab689b483ef1ebbdb3f7420904049ba0b
commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
Try to flush log files before terminating the app
tree 57bc7cf30a10aee96251852125cf30fd2c81d7aa
parent 04c833865828538315fcdf6e187da077869ce444
author Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
committer Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
Check that ThreadWorker's work method actually returns a value with
method signatures
=================
So here you can see that the full details of a different commit is
appearing in place of the requested commit's (empty) body. Rerunning
the rev-list produces the same output - the same string appears in
place of %b every time, but it's different for each commit. Often you
only get a small fragment of another commit's message, rather than the
full commit as seen above.
When I use --pretty=full, it works fine.
This appears in quite a few places in my repository's history.
Repacking the repo semi-fixes it - I still get junk bodies, but not
quite so many.
It doesn't always happen when a commit message body is empty, but I've
never seen it happen where the message body has something in.
This happens with both git 1.5.3.7 and 1.5.4.rc0.1162.g3bfea, though
the output is slightly different - the former has a number of
<unknown> markers in it. This is on OS X 10.5.1
Any suggestions?
Cheers,
Jon
^ permalink raw reply
* Re: [PATCH] Use pathexpand to preparse the relative pathnames in blob references
From: Jeff King @ 2007-12-19 14:37 UTC (permalink / raw)
To: Alex Riesen
Cc: Jakub Narebski, git, Junio C Hamano, Johannes Schindelin,
Linus Torvalds
In-Reply-To: <20071218205253.GF2875@steel.home>
On Tue, Dec 18, 2007 at 09:52:53PM +0100, Alex Riesen wrote:
> This, OTOH, is a bit intrusive and changes the current behaviour a bit
> too far. git-show cannot use the absolute pathnames in blob locators
> at all now, which I consider bad. An obvious way to use rev:/path is
> blocked by Johannes' get_sha1_oneline. It would have worked, though.
IMO, this is backwards. The default should be absolute naming (after
all, you have already rooted it at a tree by saying HEAD:), and you
should treat '.' as a short-hand for "my current prefix". IOW, this
works as before:
cd t && git show HEAD:t/test-lib.sh
but this would now work:
cd t && git show HEAD:./test-lib.sh
and of course supporting '..' could be added, as well.
This works under the assumption that you don't have tree entries of '.'
or '..'; I don't think the data structure enforces any such assumption,
but I doubt you could easily create such a tree without hacking the git
tools (and you would have to be insane to do so anyway).
-Peff
PS I didn't just think of this...I'm pretty sure this discussion came up
sometime in the past year and somebody more clever than I thought of it.
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Charles Bailey @ 2007-12-19 14:37 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20071219142715.GB14187@coredump.intra.peff.net>
On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
> On Wed, Dec 19, 2007 at 02:18:45PM +0000, Charles Bailey wrote:
>
> > Just to add to the woe on this one, this test breaks on MacOS X due to
> > the pattern length limitations of the default sed on that platform.
> >
> > Interested in a patch?
>
> Somebody beat you to it. :) Can you confirm that the fix in
>
> <1198007158-27576-1-git-send-email-win@wincent.com>
>
> works for you?
>
> -Peff
Ooh, the excitement, I've never had the opportunity to "git am"
before.
Yes, I can confirm. It works for me.
For reference I had the following, which is fewer lines but not
inherently better in any other way.
Charles.
diff --git a/t/t4024-diff-optimize-common.sh b/t/t4024-diff-optimize-common.sh
index 20fe87b..ffb2c8f 100755
--- a/t/t4024-diff-optimize-common.sh
+++ b/t/t4024-diff-optimize-common.sh
@@ -7,8 +7,9 @@ test_description='common tail optimization'
z=zzzzzzzz ;# 8
z="$z$z$z$z$z$z$z$z" ;# 64
z="$z$z$z$z$z$z$z$z" ;# 512
-z="$z$z$z$z" ;# 2048
-z2047=$(expr "$z" : '.\(.*\)') ; #2047
+z="$z$z" ;# 1024
+z1023=$(expr "$z" : '.\(.*\)') ; #1023
+z2047=$z$z1023
test_expect_success setup '
@@ -35,8 +36,8 @@ diff --git a/file-a b/file-a
--- a/file-a
+++ b/file-a
@@ -1 +1 @@
--aZ
-+AZ
+-aZZz
++AZZz
diff --git a/file-b b/file-b
--- a/file-b
+++ b/file-b
@@ -47,9 +48,9 @@ diff --git a/file-c b/file-c
--- a/file-c
+++ b/file-c
@@ -1 +1 @@
--cZ
+-cZZz
\ No newline at end of file
-+CZ
++CZZz
\ No newline at end of file
diff --git a/file-d b/file-d
--- a/file-d
@@ -61,7 +62,7 @@ EOF
test_expect_success 'diff -U0' '
- git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
+ git diff -U0 | sed -e "/^index/d" -e "s/$z1023/Z/g" >actual &&
diff -u expect actual
'
--
1.5.3.7.11.ga3d7
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 14:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071218052115.GA13422@diana.vm.bytemark.co.uk>
On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> git://repo.or.cz/stgit/kha.git safe
[...]
> Ask git about unmerged files
This patch wrongly assumes that there is a stage 2 entry in the index.
Test t1202-push-undo.sh fails because a file is added, differently, in
both master and patch but it doesn't exist in ancestor (no stage 2).
Using stage 3 doesn't fix it either because a patch might remove a
file.
I fixed it by using a set to get the unique names.
--
Catalin
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Jeff King @ 2007-12-19 15:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dana How, Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0712191334460.23902@racer.site>
On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote:
> When you are in a deeply-nested directory structure, and just want
> to reference a blob in a past revision, it can be pretty slow to
> type out "HEAD~29:/bla/blub/.../that-file".
>
> This patch makes "HEAD~29:./that-file" substitute the current prefix
> for "./". If there is not working directory, the prefix is empty.
>
> Note that this patch does not handle "../", and neither do I plan to.
I think this is definitely the right approach. Here's a (possibly
insane) alternative. Revert the change in get_sha1_with_mode and detect
"./" in get_tree_entry:
diff --git a/tree-walk.c b/tree-walk.c
index 8d4b673..fc54354 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -191,6 +191,7 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch
unsigned long size;
struct tree_desc t;
unsigned char root[20];
+ const char *prefix;
tree = read_object_with_reference(tree_sha1, tree_type, &size, root);
if (!tree)
@@ -202,7 +203,11 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch
}
init_tree_desc(&t, tree, size);
- retval = find_tree_entry(&t, name, sha1, mode);
+ if (!prefixcmp(name, "./") && (prefix = get_current_prefix()))
+ retval = find_tree_entry(&t, mkpath("%s%s", prefix, name + 2),
+ sha1, mode);
+ else
+ retval = find_tree_entry(&t, name, sha1, mode);
free(tree);
return retval;
}
This means that the directory '.' becomes a token replacement for "my
current path" in tree paths. So if you are in "foo/bar", and you are
looking at a distance commit where the same content was in
"baz/foo/bar", you can do:
git show distant:baz/./file
This is probably insane because:
- this is a fairly unlikely use case
- get_tree_entry gets called in a lot of places, and I have no idea if
there will be some crazy fallouts.
So it is probably not worth pursuing, but maybe somebody else can think
of a good use.
-Peff
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 15:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712180809l4d2d01b8j32ab2a410885cc5e@mail.gmail.com>
On 18/12/2007, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > Fix "stg resolved" to work with new conflict representation
>
> For some reason, the interactive resolving keeps invoking the merger.
> I'll have a look.
I found the problem. git.ls_files() now returns all three stages if
there was a conflict and the file list got longer. I added a set to
remove the duplicates.
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 15:39 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0712190659p6c4cb557jae5b21aa68de029d@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>> git://repo.or.cz/stgit/kha.git safe
> [...]
>> Ask git about unmerged files
>
> This patch wrongly assumes that there is a stage 2 entry in the index.
> Test t1202-push-undo.sh fails because a file is added, differently, in
> both master and patch but it doesn't exist in ancestor (no stage 2).
> Using stage 3 doesn't fix it either because a patch might remove a
> file.
>
> I fixed it by using a set to get the unique names.
That sounds reasonable.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] clone: fix options '-o' and '--origin' to be recognised again
From: Jeff King @ 2007-12-19 15:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marco Roeland, git, Pierre Habouzit, Kristian Høgsberg
In-Reply-To: <20071219091515.GA20707@fiberbit.xs4all.nl>
On Wed, Dec 19, 2007 at 10:15:15AM +0100, Marco Roeland wrote:
> This is a regression in 'next', introduced on Nov 4th by commit 94362599
> "Migrate git-clone to use git-rev-parse --parseopt". Added Kristian as
> he works on the builtin version; perhaps nice for a test case (!).
Here is a test case that catches this regression. It can perhaps be
expanded by Kristian to test other options, but is probably worth adding
now as a basic sanity check.
I put the test in 5702. There seems to be a '5600' clone test, as well,
which perhaps should be in the 57?? series.
-- >8 --
test "git clone -o"
This tests a recently fixed regression in which "git clone
-o" didn't work at all.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t5702-clone-options.sh | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100755 t/t5702-clone-options.sh
diff --git a/t/t5702-clone-options.sh b/t/t5702-clone-options.sh
new file mode 100755
index 0000000..328e4d9
--- /dev/null
+++ b/t/t5702-clone-options.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+test_description='basic clone options'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one)
+
+'
+
+test_expect_success 'clone -o' '
+
+ git clone -o foo parent clone-o &&
+ (cd clone-o && git rev-parse --verify refs/remotes/foo/master)
+
+'
+
+test_done
--
1.5.4.rc0.1162.gaa83ae
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Jakub Narebski @ 2007-12-19 16:23 UTC (permalink / raw)
To: Karl Hasselström
Cc: Catalin Marinas, David Kågedal, git, Theodore Ts'o
In-Reply-To: <20071219114021.GB5565@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:
>> On Wed, 19 Dec 2007, Karl Hasselström wrote:
>>> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
>>>
>>>> I also would like to have this command kept (and shown in 'stg
>>>> help'!). Contrary to 'git add' it can check and add to index /
>>>> update index only for files with conflict; we have -r
>>>> (ancestor|current|patched) to choose one side, and we could add
>>>> --check to check if there are no conflict markers with files
>>>> (useful with -a/--all).
>>>
>>> This too sounds like stuff that could profitably be added to "git
>>> add". Except for the ancestor/current/patched words, it is not
>>> specific to patch stacks, so the implementation should be in git
>>> and not in stg.
>>
>> No it cannot, at least the '-r (ancestor|current|patched)' part for
>> resetting file to given version, even if we change the wording to
>> ancestor, ours and theirs. The git-add command is about adding
>> contents, which updates index, which almost as a intended
>> side-effect clears merge state, i.e. stages; and not about resetting
>> to stage.
>
> git checkout-index --stage=1|2|3 <filename>
>
> does what you want. But "git cat-file" knows this handy syntax for
> getting at particular index stages:
>
> :stage:<filename>
I always forget which stage is which. It would be nice if
git-checkout-index implemented human-friendly names, just like
git-diff-files has --base, --ours, --theirs, i.e. if it would be
possible to write
git checkout-index --stage=base|ours|theirs <filename>
and perhaps even
:base|ours|theirs:<filename>.
(but there is a problem with files containing ':'...).
> It would be very convenient to be able to do
>
> git checkout :stage:<filename>
>
> but it doesn't seem to work currently. Does anyone know the "best" way
> of manually checking out a particular index stage in git?
It's a pity it doesn't work. Or if not this, then perhaps
git checkout --stage=ours -- <filename>
>> Besides with "stg resolved" you can update index _only_ for files
>> which were in the conflict, also for -a/--all, and not all the files
>> not only those which were in the conflict like "git add -u" does.
>
> This sounds like a straightforward addition to "git add".
>
>> "stg resolved --check" could happily ignore things that only look
>> like conflict markers, but must have been intended, because they are
>> in files not in conflict.
>
> git knows about conflicting files too.
>
>> Unless you are talking about adding "resolve"/"resolved" command to
>> git-core, as a porcelain wrapper around git-update-index, like "git
>> add"...
>
> Yes, that's what I want. You and others like what "stg resolved" does,
> but I don't want it in StGit because it's a generic git enhancement
> that has nothing to with patch stacks. People who don't use StGit
> would presumably like it as well.
You mean adding another option to git-add, similar to '-u' option, but
updating only the files which were (are) in merge conflict;
'-c'/'-r'/'-s' perhaps? This would be replacement for
"stg resolved --all", wouldn't it (and with filename replacement for
"stg resolved <filename>", of course)?
P.S. Sidenote: it would be nice if git-mergetool was updated to
understand StGIT style interactive 2-way and 3-way merge configuration,
and not offer only limited choice of pre-defined interactive merge tools
(although pre-defined are nice, too).
--
Jakub Narebski
Poland
^ permalink raw reply
* git-svn and migration
From: Nigel Magnay @ 2007-12-19 16:50 UTC (permalink / raw)
To: git
In-Reply-To: <320075ff0712190849u2c40cc46pf01fa2a75f557482@mail.gmail.com>
Hi there!
I've been playing around with git for a while, read the guides to
git-svn and have been successfully using it on my own to track an
upstream svn repository.
Eventually, I'd like us all to switch to git, throw out the svn
server, and replace it with a git repository that can be pushed to,
where commits that pass tests get merged into the master.
But - that's not going to happen overnight. The most likely next steps
are going to be something like migrating a couple of other developers
onto git to test the water, but in the interim most people will still
be on svn.
Has anyone got any tips as I'm sure it's a path trodden before? I've
seen examples of keeping a read-only svn, but that's not really what
I'm after. I'm considering whether to have a central git repo
regularly pull from svn so that it's up to date, and having us
possibly push to svn (or git if it's not merged to trunk) as an
interim step..
Nigel
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 17:02 UTC (permalink / raw)
To: Jakub Narebski
Cc: Karl Hasselström, David Kågedal, git, Theodore Ts'o
In-Reply-To: <200712191723.29591.jnareb@gmail.com>
On 19/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> Karl Hasselström wrote:
> > On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:
> >> On Wed, 19 Dec 2007, Karl Hasselström wrote:
> >>> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> >>>
> >>>> I also would like to have this command kept (and shown in 'stg
> >>>> help'!). Contrary to 'git add' it can check and add to index /
> >>>> update index only for files with conflict; we have -r
> >>>> (ancestor|current|patched) to choose one side, and we could add
> >>>> --check to check if there are no conflict markers with files
> >>>> (useful with -a/--all).
> >>>
> >>> This too sounds like stuff that could profitably be added to "git
> >>> add". Except for the ancestor/current/patched words, it is not
> >>> specific to patch stacks, so the implementation should be in git
> >>> and not in stg.
> >>
> >> No it cannot, at least the '-r (ancestor|current|patched)' part for
> >> resetting file to given version, even if we change the wording to
> >> ancestor, ours and theirs. The git-add command is about adding
> >> contents, which updates index, which almost as a intended
> >> side-effect clears merge state, i.e. stages; and not about resetting
> >> to stage.
> >
> > git checkout-index --stage=1|2|3 <filename>
> >
> > does what you want. But "git cat-file" knows this handy syntax for
> > getting at particular index stages:
> >
> > :stage:<filename>
>
> I always forget which stage is which. It would be nice if
> git-checkout-index implemented human-friendly names, just like
> git-diff-files has --base, --ours, --theirs, i.e. if it would be
> possible to write
>
> git checkout-index --stage=base|ours|theirs <filename>
This gets even more confusing with StGIT. For plain git, after a git
merge or pull conflict, 'theirs' is stage 3. With StGIT, we first
advance the base of the stack and merge the patches onto it, in which
case the 'patched' (which I would normally call 'ours' rather than
'theirs') is 3.
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 17:14 UTC (permalink / raw)
To: Jakub Narebski, Catalin Marinas
Cc: Theodore Ts'o, git, Karl Hasselström
In-Reply-To: <b0943d9e0712190902r2000c1ebob2303b32d1b948b8@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
>> I always forget which stage is which. It would be nice if
>> git-checkout-index implemented human-friendly names, just like
>> git-diff-files has --base, --ours, --theirs, i.e. if it would be
>> possible to write
>>
>> git checkout-index --stage=base|ours|theirs <filename>
>
> This gets even more confusing with StGIT. For plain git, after a git
> merge or pull conflict, 'theirs' is stage 3. With StGIT, we first
> advance the base of the stack and merge the patches onto it, in which
> case the 'patched' (which I would normally call 'ours' rather than
> 'theirs') is 3.
True. And the same problem obviously exists for "git rebase".
--
David Kågedal
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 17:14 UTC (permalink / raw)
To: Jakub Narebski
Cc: Catalin Marinas, David Kågedal, git, Theodore Ts'o
In-Reply-To: <200712191723.29591.jnareb@gmail.com>
On 2007-12-19 17:23:27 +0100, Jakub Narebski wrote:
> Karl Hasselström wrote:
>
> > git checkout-index --stage=1|2|3 <filename>
> >
> > does what you want. But "git cat-file" knows this handy syntax for
> > getting at particular index stages:
> >
> > :stage:<filename>
>
> I always forget which stage is which. It would be nice if
> git-checkout-index implemented human-friendly names, just like
> git-diff-files has --base, --ours, --theirs, i.e. if it would be
> possible to write
>
> git checkout-index --stage=base|ours|theirs <filename>
>
> and perhaps even
>
> :base|ours|theirs:<filename>.
>
> (but there is a problem with files containing ':'...).
<ref>:<path> is already accepted, so I don't think this would be much
worse.
And yes, I agree that the base/ours/theirs aliases are nice, and
should be accepted by at least the porcelain commands.
> > Yes, that's what I want. You and others like what "stg resolved"
> > does, but I don't want it in StGit because it's a generic git
> > enhancement that has nothing to with patch stacks. People who
> > don't use StGit would presumably like it as well.
>
> You mean adding another option to git-add, similar to '-u' option,
> but updating only the files which were (are) in merge conflict;
> '-c'/'-r'/'-s' perhaps?
Yes. That _is_ the operation you want, isn't it?
> This would be replacement for "stg resolved --all", wouldn't it (and
> with filename replacement for "stg resolved <filename>", of course)?
Yes. Though with a filename argument, you wouldn't need the new flag.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-19 17:21 UTC (permalink / raw)
To: Jakub Narebski
Cc: Linus Torvalds, Johannes Schindelin, Alex Riesen, git, danahow
In-Reply-To: <200712191223.42446.jnareb@gmail.com>
On Dec 19, 2007 3:23 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 19 Dec 2007, Dana How wrote:
> > I'd like to move some stuff currently in a p4 repository into git.
> > The directory structure within the repo is 13 levels deep;
> > I didn't design it nor can I change it.
> >
> > ... The
> > basic commit:file syntax doesn't accept relative paths. I am not
> > specifically hung up on the commit:./path syntax; I just want some
> > notation that will get those 13 directories from $cwd instead of
> > making me type them again.
>
> I think new feature like this should be postponed after 1.5.4 is out;
> we are now in feature freeze (only bugfixes are accepted).
OK. This is all the conversation that resulted from Alex's RFC.
> That said, does git-showrel solution proposed by Johannes Schindelin
> in
> Message-ID: <Pine.LNX.4.64.0712182250040.23902@racer.site>
> http://permalink.gmane.org/gmane.comp.version-control.git/68840
> work for you?
>
> Below version of git-showrel script which uses proposed 'commit:./relpath'
> syntax (it could be improved, of course):
>
> cat > git-showrel <<\EOF
> #!/bin/sh
>
> rel=$(git rev-parse --show-prefix 2>/dev/null)
> git show $(echo "$@" | sed -e "s!:./!:${rel}!")
>
> EOF
It's definitely true I could use this for now. In the long run
(meaning after the feature freeze) I don't view this as adequate
for 2 reasons:
(1) I would like a consistent interpretation of commit:path
wherever it is accepted; and
(2) If a novice types bad arguments to git-showrel , they
are probably going to be very confused by its error messages
which are a response to a munged version of their command line.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Dana How @ 2007-12-19 17:40 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Linus Torvalds, Alex Riesen, Jakub Narebski,
git, danahow
In-Reply-To: <20071219150510.GB13942@coredump.intra.peff.net>
On Dec 19, 2007 7:05 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote:
> > When you are in a deeply-nested directory structure, and just want
> > to reference a blob in a past revision, it can be pretty slow to
> > type out "HEAD~29:/bla/blub/.../that-file".
> >
> > This patch makes "HEAD~29:./that-file" substitute the current prefix
> > for "./". If there is not working directory, the prefix is empty.
>
> I think this is definitely the right approach. Here's a (possibly
> insane) alternative. Revert the change in get_sha1_with_mode and detect
> "./" in get_tree_entry:
>
> [..]
>
> This means that the directory '.' becomes a token replacement for "my
> current path" in tree paths. So if you are in "foo/bar", and you are
> looking at a distance commit where the same content was in
> "baz/foo/bar", you can do:
>
> git show distant:baz/./file
>
> This is probably insane because:
> - this is a fairly unlikely use case
> - get_tree_entry gets called in a lot of places, and I have no idea if
> there will be some crazy fallouts.
>
> So it is probably not worth pursuing, but maybe somebody else can think
> of a good use.
For me, I was only interested in the recognition of ./ at the beginning
of a path just after : (causing a cwd suffix to be inserted there).
If there were additional /./ or /../ patterns in the result, I think it
would be more useful (e.g. for script writers who forgot to run
their file arguments thru something like "readlink -f") for them
to be squashed out (e.g. in Perl:
s#/(\./)+#/#g;
s#/([^/]*[^./][^/]*/\.\./)+#/#g;
). But this is something that could be added later if desired to
the interpretation of all paths, and so seems like a different issue.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [PATCH] make 'git describe --all --contains' work
From: Nicolas Pitre @ 2007-12-19 17:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-describe.c b/builtin-describe.c
index 6eeb9b5..7a148a2 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -267,12 +267,14 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
if (contains) {
const char **args = xmalloc((4 + argc) * sizeof(char*));
- args[0] = "name-rev";
- args[1] = "--name-only";
- args[2] = "--tags";
- memcpy(args + 3, argv, argc * sizeof(char*));
- args[3 + argc] = NULL;
- return cmd_name_rev(3 + argc, args, prefix);
+ int i = 0;
+ args[i++] = "name-rev";
+ args[i++] = "--name-only";
+ if (!all)
+ args[i++] = "--tags";
+ memcpy(args + i, argv, argc * sizeof(char*));
+ args[i + argc] = NULL;
+ return cmd_name_rev(i + argc, args, prefix);
}
if (argc == 0) {
^ permalink raw reply related
* Re: git-svn and migration
From: Steven Walter @ 2007-12-19 17:54 UTC (permalink / raw)
To: Nigel Magnay; +Cc: git
In-Reply-To: <320075ff0712190850r35263bcfv1d8f84e699208e15@mail.gmail.com>
On Wed, Dec 19, 2007 at 04:50:30PM +0000, Nigel Magnay wrote:
> Has anyone got any tips as I'm sure it's a path trodden before? I've
> seen examples of keeping a read-only svn, but that's not really what
> I'm after. I'm considering whether to have a central git repo
> regularly pull from svn so that it's up to date, and having us
> possibly push to svn (or git if it's not merged to trunk) as an
> interim step..
Using a central git repo that is kept uptodate with svn is the approach
I've used. git-svn isn't especially keen on this mode of operation,
however. After every fetch, you have to reset refs/remotes/trunk to
origin/master, which it turn puts .git/svn out of date (you can blow it
away and run "git svn fetch" to regenerate it).
I wrote a script that automates most of this stuff (including doing
incremental additions to git-svn's revdb/revmap). If there's interest,
I can see about cleaning it up for general consumption.
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Alex Riesen @ 2007-12-19 18:09 UTC (permalink / raw)
To: Dana How
Cc: Jeff King, Johannes Schindelin, Linus Torvalds, Jakub Narebski,
git
In-Reply-To: <56b7f5510712190940g2a377f4tfe3ca897561ed446@mail.gmail.com>
Dana How, Wed, Dec 19, 2007 18:40:04 +0100:
> If there were additional /./ or /../ patterns in the result, I think it
> would be more useful (e.g. for script writers who forgot to run
> their file arguments thru something like "readlink -f") for them
> to be squashed out (e.g. in Perl:
> s#/(\./)+#/#g;
> s#/([^/]*[^./][^/]*/\.\./)+#/#g;
> ). But this is something that could be added later if desired to
> the interpretation of all paths, and so seems like a different issue.
This is what the pathexpand in pathexpand-patch does.
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: René Scharfe @ 2007-12-19 18:28 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com>
Jonathan del Strother schrieb:
> I'm struggling to come up with a minimal test case that confirms this,
> but I seem to be hitting a bug in the pretty string formatter when
> trying to print bodies of commits that don't have bodies.
>
> For example, on a private repository, I'm trying to print the subject
> & body of a commit. This particular commit doesn't actually have a
> body, so I'm expecting to see this output :
>
> =================
> commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> Try to flush log files before terminating the app
>
> =================
>
> However, when I actually run the command, I get gibberish in place of %b :
> =================
> $ git rev-list -1- --pretty=format:"%s%n%b"
> 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> Try to flush log files before terminating the app
> tree 57bc7cf30a10aee96251852125cf30fd2c81d7aa
> parent 04c833865828538315fcdf6e187da077869ce444
> author Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
> committer Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
>
> Check that ThreadWorker's work method actually returns a value with
> method signatures
> =================
>
> So here you can see that the full details of a different commit is
> appearing in place of the requested commit's (empty) body. Rerunning
> the rev-list produces the same output - the same string appears in
> place of %b every time, but it's different for each commit. Often you
> only get a small fragment of another commit's message, rather than the
> full commit as seen above.
>
> When I use --pretty=full, it works fine.
>
> This appears in quite a few places in my repository's history.
> Repacking the repo semi-fixes it - I still get junk bodies, but not
> quite so many.
>
> It doesn't always happen when a commit message body is empty, but I've
> never seen it happen where the message body has something in.
>
> This happens with both git 1.5.3.7 and 1.5.4.rc0.1162.g3bfea, though
> the output is slightly different - the former has a number of
> <unknown> markers in it. This is on OS X 10.5.1
That's strange. Could you check if this happens with e52a5de, too?
That's the commit that introduced --pretty=format. If it doesn't, could
you then please try to bisect the bug?
How many '<unknown>' markers are there in the output of version 1.5.3.7
(and e52a5de)? One per %b? Are they the only output or are they
combined with parts of unrelated commits, too?
Thanks,
René
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Alex Riesen @ 2007-12-19 18:44 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com>
Jonathan del Strother, Wed, Dec 19, 2007 15:32:20 +0100:
> I'm struggling to come up with a minimal test case that confirms this,
> but I seem to be hitting a bug in the pretty string formatter when
> trying to print bodies of commits that don't have bodies.
I tried
$ git init
$ git rev-list --pretty=format:"%s%n%b" \
$(echo -n "Test" |git commit-tree $(git write-tree))
but it works. It is possible that the commit in question is created
with an older commit-tree code. Could you try
git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
(or any other problematic commit) and post its output here?
Or is the repo publised somewhere?
^ 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