* Re: shallow clone not very shallow due to tags
From: Nguyen Thai Ngoc Duy @ 2011-08-15 14:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJuyZMj+qwFr_=stbQtGh2SCCpjfsBxm+2wbfJK=i_VTdw@mail.gmail.com>
On Mon, Aug 15, 2011 at 6:58 AM, Shawn Pearce <spearce@spearce.org> wrote:
> Uhm. That is not a very shallow clone. The clone copied 20234 objects
> at 9.15 MiB... so its ~20 MiB lighter than a full clone. But nearly
> all of the tags exist, because the clone client is declaring want
> lines for them, making the server generate up to 1 commit back from
> the wanted tag. I know shallow support is the feature nobody wants to
> think about, but this just seems broken to me. Clients performing a
> shallow clone shouldn't be asking for tags... but they should be using
> the include-tag protocol option so that if they do happen to receive a
> tagged commit, the tag object will also be sent.
The same would apply if the repo in question has many branches. Should
we fetch only master (or a user-specified set of refs) in shallow
clone?
--
Duy
^ permalink raw reply
* Re: [PATCH v3 2/2] Move git-dir for submodules
From: Marc Branchaud @ 2011-08-15 14:30 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: git, jens.lehmann, hvoigt, gitster
In-Reply-To: <1313178913-25617-3-git-send-email-iveqy@iveqy.com>
On 11-08-12 03:55 PM, Fredrik Gustafsson wrote:
>
> This patch will not affect already cloned submodules at all.
My question is perhaps a bit beyond the scope of this series...
Is there going to be a way to migrate submodules to the new layout? If the
eventual goal is to be able to delete & restore submodule working
directories, it would be nice if that could work with submodules cloned by an
older git.
M.
^ permalink raw reply
* Core dump on commit
From: Marko Vukovic @ 2011-08-15 14:30 UTC (permalink / raw)
To: git
I get this error after running "git commit"
error: Object 42504431bac2e2054483c1bbc35f1b535f8d11bb is a tag, not a commit
Segmentation fault (core dumped)
"git cat-file -p 42504431bac2e2054483c1bbc35f1b535f8d11bb" gives this:
object 1b9a97613307b5c7bbc189a0e41506cb1534740a
type commit
tag v1.0
tagger marko <marko@bib> Sun Aug 14 20:42:12 2011 -0400
The first release
I had created a tag yesterday which I deleted since with "git tag -d" command.
Curiously, I could not find file
".git/objects/42/504431bac2e2054483c1bbc35f1b535f8d11bb" which I expected based
on my very limited understanding of the Git internals. So, where does "git
cat-file" pick up that information from? But more importantly, how do I fix this
problem?
^ permalink raw reply
* Re: Core dump on commit
From: Michael Witten @ 2011-08-15 14:41 UTC (permalink / raw)
To: Marko Vukovic; +Cc: git
In-Reply-To: <loom.20110815T162144-798@post.gmane.org>
On Mon, Aug 15, 2011 at 14:30, Marko Vukovic <amasniko@yahoo.com> wrote:
> error: Object 42504431bac2e2054483c1bbc35f1b535f8d11bb is a tag, not a commit
> Segmentation fault (core dumped)
You found a SHA-1 hash collision!? :-P (but really :-/)
^ permalink raw reply
* Re: Core dump on commit
From: Marko Vukovic @ 2011-08-15 15:02 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1BvbNnmqyXmcfUCeJGEcqHR4UkfZhkx1CFJiPLSfnk0CQA@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> You found a SHA-1 hash collision!? :-P (but really :-/)
>
Do I go out and buy a lottery ticket now?
But seriously, how do I get out of this mess now?
^ permalink raw reply
* Re: Core dump on commit
From: Nguyen Thai Ngoc Duy @ 2011-08-15 15:12 UTC (permalink / raw)
To: Marko Vukovic; +Cc: git
In-Reply-To: <loom.20110815T162144-798@post.gmane.org>
On Mon, Aug 15, 2011 at 9:30 PM, Marko Vukovic <amasniko@yahoo.com> wrote:
> I get this error after running "git commit"
>
> error: Object 42504431bac2e2054483c1bbc35f1b535f8d11bb is a tag, not a commit
> Segmentation fault (core dumped)
Can you get the stack trace? Does HEAD point to
42504431bac2e2054483c1bbc35f1b535f8d11bb (iow what does "git rev-parse
HEAD" say).
> "git cat-file -p 42504431bac2e2054483c1bbc35f1b535f8d11bb" gives this:
>
> object 1b9a97613307b5c7bbc189a0e41506cb1534740a
> type commit
> tag v1.0
> tagger marko <marko@bib> Sun Aug 14 20:42:12 2011 -0400
>
> The first release
If HEAD does point to 42504431, I think you can do "git reset
1b9a976133" to reset the HEAD back to a commit object (as oppose to a
tag)
But please backup the repository somewhere, I'm still not sure how you
get into this situation. The repo may help.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 2/2] Move git-dir for submodules
From: Fredrik Gustafsson @ 2011-08-15 15:14 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Fredrik Gustafsson, git, jens.lehmann, hvoigt, gitster
In-Reply-To: <4E492D7B.50508@xiplink.com>
On Mon, Aug 15, 2011 at 10:30:19AM -0400, Marc Branchaud wrote:
> On 11-08-12 03:55 PM, Fredrik Gustafsson wrote:
> >
> > This patch will not affect already cloned submodules at all.
>
> My question is perhaps a bit beyond the scope of this series...
>
> Is there going to be a way to migrate submodules to the new layout? If the
> eventual goal is to be able to delete & restore submodule working
> directories, it would be nice if that could work with submodules cloned by an
> older git.
>
That's not planned as far as I know. However, a new clone will do that,
(and of course it's quite easy to do it manually).
When git supports to delete and restore submodules that will not be done
if there isn't a .git-FILE in the submodule.
--
Med vänliga hälsningar
Fredrik
^ permalink raw reply
* Re: Bug report: git log --[num|short]stat sometimes counts lines wrong
From: Carlos Martín Nieto @ 2011-08-15 15:26 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git
In-Reply-To: <91324E9A-3134-455D-B7CA-ABBDA88FC7B7@inf.fu-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
On Mon, 2011-08-15 at 10:24 +0200, Alexander Pepper wrote:
> Am 12.08.2011 um 17:21 schrieb Alexander Pepper:
> > Hi there.
> > This is my first contribution to git (if you count a bug report as a contribution) and I'm not really familiar where to report bugs. In the irc channel #git at freenode somebody pointed me to this mailing list.
> >
> > First of: I'm running git version 1.7.6 on OS X 10.6.8.
> >
> > Let me describe what I observed.
> > repository: https://github.com/voldemort/voldemort.git
> > The command "git log --numstat c21ad764ea1bae7f7bd83b5e2cb015dcbc44d586" shows for the commit c21ad764 and file '.../readonly/mr/HadoopStoreBuilderReducer.java' 25 lines added and 22 lines removed. But the patch of HadoopStoreBuilderReducer.java that I get with "git show c21ad764ea1bae7f7bd83b5e2cb015dcbc44d586 -- contrib/hadoop-store-builder/src/java/voldemort/store/readonly/mr/HadoopStoreBuilderReducer.java" adds 30 lines and removes 27.
> >
> > Why does "git log --numstat" drops 5 added lines and 5 removed lines? This also holds true for "git log --stat" and "git log --shortstat".
> >
> > Is this a bug or am I missing an option to git log or git show?
> >
> > More commits where I observed this problem on the same repository:
> > 7e00fb6d2cf131dfed59c180f2171952808cc336 src/java/voldemort/client/rebalance/MigratePartitions.java
> > 78ad6f2a6ea327dbae2110f4530a5bd07e5deaac src/java/voldemort/client/rebalance/MigratePartitions.java (same commit on another branch)
> > 7871933f0f0f056e2eeac03a01db1e9cf81f8bda src/java/voldemort/client/protocol/admin/AdminClient.java
> > 2d6f68b09c3bdc23dcf3ae1f91c9285fbd668820 src/java/voldemort/store/readonly/ExternalSorter.java
> > 6fcacee866307ec34eb32b268e2c2b885a949319 build.xml
> >
> > Greetings from Berlin
> > Alex
>
> Hello again.
>
> I also observed this behavior with git version 1.7.4.1 on Gentoo.
>
> Any ideas how to fix this?
I've just checked and `git show --stat` does give different numbers from
`git show | diffstat`. Git ignores (or can ignore) empty lines in
several contexts, have you checked to see if there are 5 empty lines
added and removed?
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Core dump on commit
From: Nguyen Thai Ngoc Duy @ 2011-08-15 15:26 UTC (permalink / raw)
To: Marko Vukovic; +Cc: git
In-Reply-To: <loom.20110815T162144-798@post.gmane.org>
On Mon, Aug 15, 2011 at 9:30 PM, Marko Vukovic <amasniko@yahoo.com> wrote:
> I get this error after running "git commit"
>
> error: Object 42504431bac2e2054483c1bbc35f1b535f8d11bb is a tag, not a commit
> Segmentation fault (core dumped)
If I put a tag to HEAD, I could reproduce this. Let's assume that "git
cat-file -t HEAD" in your repo returns "tag", how did you create the
last commits? Did you modify a ref manually? What git version did you
use?
--
Duy
^ permalink raw reply
* Re: Bug report: git log --[num|short]stat sometimes counts lines wrong
From: Alexander Pepper @ 2011-08-15 15:33 UTC (permalink / raw)
To: git
In-Reply-To: <1313422005.26123.2.camel@bee.lab.cmartin.tk>
Am 15.08.2011 um 17:26 schrieb Carlos Martín Nieto:
> On Mon, 2011-08-15 at 10:24 +0200, Alexander Pepper wrote:
>> Am 12.08.2011 um 17:21 schrieb Alexander Pepper:
>>> Hi there.
>>> This is my first contribution to git (if you count a bug report as a contribution) and I'm not really familiar where to report bugs. In the irc channel #git at freenode somebody pointed me to this mailing list.
>>>
>>> First of: I'm running git version 1.7.6 on OS X 10.6.8.
>>>
>>> Let me describe what I observed.
>>> repository: https://github.com/voldemort/voldemort.git
>>> The command "git log --numstat c21ad764ea1bae7f7bd83b5e2cb015dcbc44d586" shows for the commit c21ad764 and file '.../readonly/mr/HadoopStoreBuilderReducer.java' 25 lines added and 22 lines removed. But the patch of HadoopStoreBuilderReducer.java that I get with "git show c21ad764ea1bae7f7bd83b5e2cb015dcbc44d586 -- contrib/hadoop-store-builder/src/java/voldemort/store/readonly/mr/HadoopStoreBuilderReducer.java" adds 30 lines and removes 27.
>>>
>>> Why does "git log --numstat" drops 5 added lines and 5 removed lines? This also holds true for "git log --stat" and "git log --shortstat".
>>>
>>> Is this a bug or am I missing an option to git log or git show?
>>>
>>> More commits where I observed this problem on the same repository:
>>> 7e00fb6d2cf131dfed59c180f2171952808cc336 src/java/voldemort/client/rebalance/MigratePartitions.java
>>> 78ad6f2a6ea327dbae2110f4530a5bd07e5deaac src/java/voldemort/client/rebalance/MigratePartitions.java (same commit on another branch)
>>> 7871933f0f0f056e2eeac03a01db1e9cf81f8bda src/java/voldemort/client/protocol/admin/AdminClient.java
>>> 2d6f68b09c3bdc23dcf3ae1f91c9285fbd668820 src/java/voldemort/store/readonly/ExternalSorter.java
>>> 6fcacee866307ec34eb32b268e2c2b885a949319 build.xml
>>>
>>> Greetings from Berlin
>>> Alex
>>
>> Hello again.
>>
>> I also observed this behavior with git version 1.7.4.1 on Gentoo.
>>
>> Any ideas how to fix this?
>
> I've just checked and `git show --stat` does give different numbers from
> `git show | diffstat`. Git ignores (or can ignore) empty lines in
> several contexts, have you checked to see if there are 5 empty lines
> added and removed?
>
> Cheers,
> cmn
Hi Charlos.
At least with "git show c21ad764 -- contrib/hadoop-store-builder/src/java/voldemort/store/readonly/mr/HadoopStoreBuilderReducer.java" there are 6 removed lines and 5 added empty lines.
If `git show --stat` ignores empty lines compared to `git show | diffstat`, is there a way or an option to enable, to tell `git show --stat` to also count empty lines?
Greetings from Berlin
Alex
^ permalink raw reply
* [PATCH] commit: check return value of lookup_commit()
From: Nguyễn Thái Ngọc Duy @ 2011-08-15 15:38 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
If lookup_commit() returns NULL, there's usually serious error and the
command aborts anyway. However it's still nicer to have a message
telling us where it aborts, rather than segmentation fault.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I suppose die() also cleans up $GIT_DIR/index.lock while sigsegv does not.
builtin/commit.c | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 2088b6b..bfb7a5a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1387,6 +1387,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char commit_sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
+ struct commit *commit;
struct stat statbuf;
int allow_fast_forward = 1;
struct wt_status s;
@@ -1423,7 +1424,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = "commit (initial)";
} else if (amend) {
struct commit_list *c;
- struct commit *commit;
if (!reflog_msg)
reflog_msg = "commit (amend)";
@@ -1439,7 +1439,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!reflog_msg)
reflog_msg = "commit (merge)";
- pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
+ commit = lookup_commit(head_sha1);
+ if (!commit)
+ die(_("could not parse HEAD commit"));
+ pptr = &commit_list_insert(commit, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1448,7 +1451,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
if (get_sha1_hex(m.buf, sha1) < 0)
die(_("Corrupt MERGE_HEAD file (%s)"), m.buf);
- pptr = &commit_list_insert(lookup_commit(sha1), pptr)->next;
+ commit = lookup_commit(sha1);
+ if (!commit)
+ die(_("could not parse commit %s"), sha1_to_hex(sha1));
+ pptr = &commit_list_insert(commit, pptr)->next;
}
fclose(fp);
strbuf_release(&m);
@@ -1465,7 +1471,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = (whence == FROM_CHERRY_PICK)
? "commit (cherry-pick)"
: "commit";
- pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
+ commit = lookup_commit(head_sha1);
+ if (!commit)
+ die(_("could not parse HEAD commit"));
+ pptr = &commit_list_insert(commit, pptr)->next;
}
/* Finally, get the commit message */
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: Core dump on commit
From: Marko Vukovic @ 2011-08-15 15:48 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8AL5D938HA-sQkFkn_d9xuT2Vw8BKfD-h+V=iEkNrS1eA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> Can you get the stack trace? Does HEAD point to
Please find the stack trace at the end of the message (I did not want to insert
it in the middle)
> 42504431bac2e2054483c1bbc35f1b535f8d11bb (iow what does "git rev-parse
> HEAD" say).
>
> If HEAD does point to 42504431, I think you can do "git reset
> 1b9a976133" to reset the HEAD back to a commit object (as oppose to a
> tag)
>
It does print the same hash.
Pardon my ignorance, but what does "git reset" do? I have got some uncommitted
changes in the staging area. What will happen to them?
The stack trace:
[New Thread 10518]
[Thread debugging using libthread_db enabled]
Core was generated by `git commit'.
Program terminated with signal 11, Segmentation fault.
#0 sha1_to_hex (sha1=0x4 <Address 0x4 out of bounds>) at hex.c:60
60 hex.c: No such file or directory.
in hex.c
Thread 1 (Thread 0x7f290c8e3720 (LWP 10518)):
#0 sha1_to_hex (sha1=0x4 <Address 0x4 out of bounds>) at hex.c:60
val = <value optimized out>
bufno = 3
hexbuffer = {'\000' <repeats 49 times>,
"42504431bac2e2054483c1bbc35f1b535f8d11bb\000\000\000\000\000\000\000\000\000",
"583438f1bd3bf58f3defb0cb6adbf32b26a2ce43\000\000\000\000\000\000\000\000\000",
'\000' <repeats 49 times>}
hex = "0123456789abcdef"
buffer = 0x75f936 ""
#1 0x0000000000471fe3 in commit_tree (msg=0x9d5920 "Weekend and holiday
fees\n", tree=<value optimized out>, parents=0x9d5900, ret=0x7fff55c683f0
"\022", author=0x989f10 "Marko Vukovic <marko@bib.(none)> 1313422327 -0400") at
commit.c:855
next = 0x0
result = <value optimized out>
encoding_is_utf8 = 1
buffer = {alloc = 8193, len = 46, buf = 0x9d8950 "tree
583438f1bd3bf58f3defb0cb6adbf32b26a2ce43\n"}
#2 0x000000000041c223 in cmd_commit (argc=<value optimized out>, argv=<value
optimized out>, prefix=0x0) at builtin/commit.c:1394
sb = {alloc = 12313, len = 25, buf = 0x9d5920 "Weekend and holiday fees\
n"}
author_ident = {alloc = 50, len = 49, buf = 0x989f10 "Marko Vukovic
<marko@bib.(none)> 1313422327 -0400"}
index_file = 0x7fff55c67330 ""
reflog_msg = 0x4e6e0f "commit"
nl = <value optimized out>
p = <value optimized out>
commit_sha1 =
"\022\000\000\000\000\000\000\000\022\000\000\000\000\000\000\000[\000\000"
ref_lock = <value optimized out>
parents = 0x9d5900
pptr = <value optimized out>
statbuf = {st_dev = 0, st_ino = 2, st_nlink = 0, st_mode = 0, st_uid =
0, st_gid = 1439068784, __pad0 = 32767, st_rdev = 64, st_size = 0, st_blksize =
0, st_blocks = 0, st_atim = {tv_sec = 206158430210, tv_nsec = 472446402651},
st_mtim = {tv_sec = 532575944823, tv_nsec = 140734632456832}, st_ctim = {tv_sec
= 140734632456815, tv_nsec = 140734632457008}, __unused = {4096, 5116818,
233337090496}}
s = {is_initial = 0, branch = 0x9754c0 "refs/heads/release-1", reference
= 0x4e3c11 "HEAD", pathspec = 0x0, verbose = 0, amend = 0, in_merge = 0, nowarn
= 1, use_color = 0, relative_paths = 1, submodule_summary = 0,
show_ignored_files = 0, show_untracked_files = SHOW_NORMAL_UNTRACKED_FILES,
ignore_submodule_arg = 0x0, color_palette = {'\000' <repeats 39 times>,
"\033[32m", '\000' <repeats 34 times>, "\033[31m", '\000' <repeats 34 times>,
"\033[31m", '\000' <repeats 34 times>, "\033[31m", '\000' <repeats 34 times>,
"\033[31m", '\000' <repeats 34 times>, "\033[32m", '\000' <repeats 34 times>,
"\033[31m", '\000' <repeats 34 times>, "NIL", '\000' <repeats 36 times>},
commitable = 1, workdir_dirty = 1, index_file = 0x975480 ".git/index", fp =
0x988630, prefix = 0x0, change = {items = 0x98ae60, nr = 10, alloc = 32,
strdup_strings = 1}, untracked = {items = 0x9cd490, nr = 14, alloc = 32,
strdup_strings = 1}, ignored = {items = 0x0, nr = 0, alloc = 0, strdup_strings =
1}}
#3 0x000000000040462c in run_builtin (argc=1, argv=0x7fff55c686a0) at git.c:290
status = <value optimized out>
help = <value optimized out>
st = {st_dev = 7094065766045672051, st_ino = 7308620263551823465,
st_nlink = 7074996046893509935, st_mode = 28265, st_uid = 0, st_gid = 9916512,
__pad0 = 0, st_rdev = 233333546946, st_size = 140734632462224, st_blksize = 1,
st_blocks = 4294967296, st_atim = {tv_sec = 150, tv_nsec = 9916512}, st_mtim =
{tv_sec = 140734632461552, tv_nsec = 140734632471472}, st_ctim = {tv_sec =
4210352, tv_nsec = 140734632461648}, __unused = {0, 0, 4992233}}
prefix = <value optimized out>
#4 handle_internal_command (argc=1, argv=0x7fff55c686a0) at git.c:448
p = <value optimized out>
cmd = <value optimized out>
commands = {{cmd = 0x4f481b "add", fn = 0x4051d0 <cmd_add>, option = 9},
{cmd = 0x4e1145 "stage", fn = 0x4051d0 <cmd_add>, option = 9}, {cmd = 0x4e114b
"annotate", fn = 0x405bf0 <cmd_annotate>, option = 1}, {cmd = 0x4e1949 "apply",
fn = 0x40c9e0 <cmd_apply>, option = 2}, {cmd = 0x4e3426 "archive", fn = 0x40d6d0
<cmd_archive>, option = 0}, {cmd = 0x4e1154 "bisect--helper", fn = 0x40d940
<cmd_bisect__helper>, option = 9}, {cmd = 0x4e1163 "blame", fn = 0x410210
<cmd_blame>, option = 1}, {cmd = 0x4f49e0 "branch", fn = 0x412a00 <cmd_branch>,
option = 1}, {cmd = 0x4e6363 "bundle", fn = 0x413b30 <cmd_bundle>, option = 2},
{cmd = 0x4e1169 "cat-file", fn = 0x413e30 <cmd_cat_file>, option = 1}, {cmd =
0x4e649d "checkout", fn = 0x4168e0 <cmd_checkout>, option = 9}, {cmd = 0x4e1172
"checkout-index", fn = 0x4150c0 <cmd_checkout_index>, option = 9}, {cmd =
0x4e1181 "check-ref-format", fn = 0x414b20 <cmd_check_ref_format>, option = 0},
{cmd = 0x4e1192 "check-attr", fn = 0x4147b0 <cmd_check_attr>, option = 1}, {cmd
= 0x4e119d "cherry", fn = 0x4360c0 <cmd_cherry>, option = 1}, {cmd = 0x50432a
"cherry-pick", fn = 0x45a1a0 <cmd_cherry_pick>, option = 9}, {cmd = 0x4e11a4
"clone", fn = 0x418d30 <cmd_clone>, option = 0}, {cmd = 0x4e11aa "clean", fn =
0x417fa0 <cmd_clean>, option = 9}, {cmd = 0x4e6e0f "commit", fn = 0x41b2b0
<cmd_commit>, option = 9}, {cmd = 0x4e11b0 "commit-tree", fn = 0x419f80
<cmd_commit_tree>, option = 1}, {cmd = 0x4e1392 "config", fn = 0x41e010
<cmd_config>, option = 2}, {cmd = 0x4e11bc "count-objects", fn = 0x41e740
<cmd_count_objects>, option = 1}, {cmd = 0x4e11ca "describe", fn = 0x41f8f0
<cmd_describe>, option = 1}, {cmd = 0x4fd07d "diff", fn = 0x420910 <cmd_diff>,
option = 0}, {cmd = 0x4e11d3 "diff-files", fn = 0x41fe80 <cmd_diff_files>,
option = 9}, {cmd = 0x4e11de "diff-index", fn = 0x4200d0 <cmd_diff_index>,
option = 1}, {cmd = 0x4e11e9 "diff-tree", fn = 0x420270 <cmd_diff_tree>, option
= 1}, {cmd = 0x506d5a "fast-export", fn = 0x421d20 <cmd_fast_export>, option =
1}, {cmd = 0x4e63e3 "fetch", fn = 0x426a70 <cmd_fetch>, option = 1}, {cmd =
0x4e11f3 "fetch-pack", fn = 0x4245e0 <cmd_fetch_pack>, option = 1}, {cmd =
0x4e11fe "fmt-merge-msg", fn = 0x427a20 <cmd_fmt_merge_msg>, option = 1}, {cmd =
0x4e120c "for-each-ref", fn = 0x4296b0 <cmd_for_each_ref>, option = 1}, {cmd =
0x4e1219 "format-patch", fn = 0x434930 <cmd_format_patch>, option = 1}, {cmd =
0x4fe34e "fsck", fn = 0x42a910 <cmd_fsck>, option = 1}, {cmd = 0x4e1226
"fsck-objects", fn = 0x42a910 <cmd_fsck>, option = 1}, {cmd = 0x4ebe68 "gc", fn
= 0x42b490 <cmd_gc>, option = 1}, {cmd = 0x4e1233 "get-tar-commit-id", fn =
0x460a10 <cmd_get_tar_commit_id>, option = 0}, {cmd = 0x4ec25b "grep", fn =
0x42cbe0 <cmd_grep>, option = 2}, {cmd = 0x4e1245 "hash-object", fn = 0x42e540
<cmd_hash_object>, option = 0}, {cmd = 0x4e0f80 "help", fn = 0x42f210
<cmd_help>, option = 0}, {cmd = 0x4e1251 "index-pack", fn = 0x4307c0
<cmd_index_pack>, option = 2}, {cmd = 0x4e6527 "init", fn = 0x432920
<cmd_init_db>, option = 0}, {cmd = 0x4e125c "init-db", fn = 0x432920
<cmd_init_db>, option = 0}, {cmd = 0x503888 "log", fn = 0x434850 <cmd_log>,
option = 1}, {cmd = 0x4e1264 "ls-files", fn = 0x436bc0 <cmd_ls_files>, option =
1}, {cmd = 0x4e126d "ls-tree", fn = 0x438560 <cmd_ls_tree>, option = 1}, {cmd =
0x4e1275 "ls-remote", fn = 0x437e20 <cmd_ls_remote>, option = 2}, {cmd =
0x4e127f "mailinfo", fn = 0x439fb0 <cmd_mailinfo>, option = 0}, {cmd = 0x4e1288
"mailsplit", fn = 0x43b4d0 <cmd_mailsplit>, option = 0}, {cmd = 0x4f01d7
"merge", fn = 0x43d170 <cmd_merge>, option = 9}, {cmd = 0x4e1292 "merge-base",
fn = 0x43ece0 <cmd_merge_base>, option = 1}, {cmd = 0x4e129d "merge-file", fn =
0x43f060 <cmd_merge_file>, option = 2}, {cmd = 0x4e12a8 "merge-index", fn =
0x43f820 <cmd_merge_index>, option = 1}, {cmd = 0x4e12b4 "merge-ours", fn =
0x43fa50 <cmd_merge_ours>, option = 1}, {cmd = 0x4e12bf "merge-recursive", fn =
0x43fb20 <cmd_merge_recursive>, option = 9}, {cmd = 0x4e12cf
"merge-recursive-ours", fn = 0x43fb20 <cmd_merge_recursive>, option = 9}, {cmd =
0x4e12e4 "merge-recursive-theirs", fn = 0x43fb20 <cmd_merge_recursive>, option =
9}, {cmd = 0x4e12fb "merge-subtree", fn = 0x43fb20 <cmd_merge_recursive>, option
= 9}, {cmd = 0x4e1309 "merge-tree", fn = 0x440340 <cmd_merge_tree>, option = 1},
{cmd = 0x4e1314 "mktag", fn = 0x440710 <cmd_mktag>, option = 1}, {cmd = 0x4e131a
"mktree", fn = 0x440c70 <cmd_mktree>, option = 1}, {cmd = 0x4e1321 "mv", fn =
0x441450 <cmd_mv>, option = 9}, {cmd = 0x4e1324 "name-rev", fn = 0x4421c0
<cmd_name_rev>, option = 1}, {cmd = 0x4f108c "notes", fn = 0x443880 <cmd_notes>,
option = 1}, {cmd = 0x4fad16 "pack-objects", fn = 0x448240 <cmd_pack_objects>,
option = 1}, {cmd = 0x4e132d "pack-redundant", fn = 0x449b70
<cmd_pack_redundant>, option = 1}, {cmd = 0x4e133c "patch-id", fn = 0x44b100
<cmd_patch_id>, option = 0}, {cmd = 0x4e1345 "peek-remote", fn = 0x437e20
<cmd_ls_remote>, option = 2}, {cmd = 0x4e1351 "pickaxe", fn = 0x410210
<cmd_blame>, option = 1}, {cmd = 0x4f4757 "prune", fn = 0x44b750 <cmd_prune>,
option = 1}, {cmd = 0x4e1359 "prune-packed", fn = 0x44b520 <cmd_prune_packed>,
option = 1}, {cmd = 0x506773 "push", fn = 0x44bdd0 <cmd_push>, option = 1}, {cmd
= 0x4e1366 "read-tree", fn = 0x44c8d0 <cmd_read_tree>, option = 1}, {cmd =
0x4f6fcf "receive-pack", fn = 0x44da50 <cmd_receive_pack>, option = 0}, {cmd =
0x4e4514 "reflog", fn = 0x4503f0 <cmd_reflog>, option = 1}, {cmd = 0x4f4614
"remote", fn = 0x4519a0 <cmd_remote>, option = 1}, {cmd = 0x4e1370 "remote-ext",
fn = 0x454c20 <cmd_remote_ext>, option = 0}, {cmd = 0x4e137b "remote-fd", fn =
0x454dd0 <cmd_remote_fd>, option = 0}, {cmd = 0x4e1385 "replace", fn = 0x4551f0
<cmd_replace>, option = 1}, {cmd = 0x4e138d "repo-config", fn = 0x41e010
<cmd_config>, option = 2}, {cmd = 0x4e1399 "rerere", fn = 0x455540 <cmd_rerere>,
option = 1}, {cmd = 0x4e5743 "reset", fn = 0x455ff0 <cmd_reset>, option = 1},
{cmd = 0x4eaa47 "rev-list", fn = 0x456f30 <cmd_rev_list>, option = 1}, {cmd =
0x4e13a0 "rev-parse", fn = 0x457930 <cmd_rev_parse>, option = 0}, {cmd =
0x4e13aa "revert", fn = 0x45a150 <cmd_revert>, option = 9}, {cmd = 0x4e13b1
"rm", fn = 0x45a1b0 <cmd_rm>, option = 1}, {cmd = 0x4e13b4 "send-pack", fn =
0x45b3d0 <cmd_send_pack>, option = 1}, {cmd = 0x4e13be "shortlog", fn = 0x45c640
<cmd_shortlog>, option = 6}, {cmd = 0x4e13c7 "show-branch", fn = 0x45d2f0
<cmd_show_branch>, option = 1}, {cmd = 0x4e13d3 "show", fn = 0x434390
<cmd_show>, option = 1}, {cmd = 0x4f6f44 "status", fn = 0x41b000 <cmd_status>,
option = 9}, {cmd = 0x4e13d8 "stripspace", fn = 0x45f170 <cmd_stripspace>,
option = 0}, {cmd = 0x4e13e3 "symbolic-ref", fn = 0x45f260 <cmd_symbolic_ref>,
option = 1}, {cmd = 0x50640d "tag", fn = 0x45f9a0 <cmd_tag>, option = 1}, {cmd =
0x4e13f0 "tar-tree", fn = 0x460880 <cmd_tar_tree>, option = 0}, {cmd = 0x4e13f9
"unpack-file", fn = 0x460af0 <cmd_unpack_file>, option = 1}, {cmd = 0x4e1405
"unpack-objects", fn = 0x461510 <cmd_unpack_objects>, option = 1}, {cmd =
0x4e1414 "update-index", fn = 0x463550 <cmd_update_index>, option = 1}, {cmd =
0x4e1421 "update-ref", fn = 0x464150 <cmd_update_ref>, option = 1}, {cmd =
0x4e142c "update-server-info", fn = 0x4643e0 <cmd_update_server_info>, option =
1}, {cmd = 0x4e341f "upload-archive", fn = 0x4647e0 <cmd_upload_archive>, option
= 0}, {cmd = 0x4e143f "var", fn = 0x464ac0 <cmd_var>, option = 2}, {cmd =
0x4e1443 "verify-tag", fn = 0x4653b0 <cmd_verify_tag>, option = 1}, {cmd =
0x50005d "version", fn = 0x48ebd0 <cmd_version>, option = 0}, {cmd = 0x4e144e
"whatchanged", fn = 0x434280 <cmd_whatchanged>, option = 1}, {cmd = 0x4f9c35
"write-tree", fn = 0x4655c0 <cmd_write_tree>, option = 1}, {cmd = 0x4e145a
"verify-pack", fn = 0x465090 <cmd_verify_pack>, option = 0}, {cmd = 0x4e1466
"show-ref", fn = 0x45ed70 <cmd_show_ref>, option = 1}, {cmd = 0x4e146f
"pack-refs", fn = 0x44ac80 <cmd_pack_refs>, option = 1}}
i = <value optimized out>
#5 0x0000000000404848 in run_argv (argc=1, argv=0x7fff55c686a0) at git.c:492
done_alias = 0
#6 main (argc=1, argv=0x7fff55c686a0) at git.c:565
done_help = 0
was_alias = 0
cmd = 0x7fff55c6a2dc "commit"
From To Syms Read Shared Object Library
0x0000003cb5c01e70 0x0000003cb5c0e678 Yes /lib64/libz.so.1
0x0000003654805630 0x00000036548108b8 Yes (*) /lib64/libpthread.so.0
0x0000003653c1eba0 0x0000003653d45f5c Yes (*) /lib64/libc.so.6
0x0000003653800b20 0x0000003653818c46 Yes (*) /lib64/ld-linux-x86-64.so.2
0x00007f290c6d9120 0x00007f290c6e0448 Yes (*) /lib64/libnss_files.so.2
(*): Shared library is missing debugging information.
$1 = 0x0
No symbol "__glib_assert_msg" in current context.
rax 0x75f936 7731510
rbx 0x9d5900 10311936
rcx 0x4fb256 5222998
rdx 0x0 0
rsi 0x2e 46
rdi 0x4 4
rbp 0x0 0x0
rsp 0x7fff55c66e88 0x7fff55c66e88
r8 0x1 1
r9 0x28 40
r10 0x3261363262323366 3630242364661052262
r11 0x2001 8193
r12 0x9d5920 10311968
r13 0x7fff55c683f0 140734632461296
r14 0x7fff55c66ea0 140734632455840
r15 0x989f10 10002192
rip 0x48ec78 0x48ec78 <sha1_to_hex+40>
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
Dump of assembler code for function sha1_to_hex:
0x000000000048ec50 <+0>: mov 0x2d0d12(%rip),%eax # 0x75f968
0x000000000048ec56 <+6>: xor %edx,%edx
0x000000000048ec58 <+8>: add $0x1,%eax
0x000000000048ec5b <+11>: mov %eax,0x2d0d07(%rip) # 0x75f968
0x000000000048ec61 <+17>: and $0x3,%eax
0x000000000048ec64 <+20>: lea (%rax,%rax,4),%rax
0x000000000048ec68 <+24>: lea (%rax,%rax,4),%rax
0x000000000048ec6c <+28>: lea 0x75f8a0(%rax,%rax,1),%rax
0x000000000048ec74 <+36>: nopl 0x0(%rax)
=> 0x000000000048ec78 <+40>: movzbl (%rdi),%ecx
0x000000000048ec7b <+43>: add $0x1,%rdi
0x000000000048ec7f <+47>: mov %ecx,%esi
0x000000000048ec81 <+49>: and $0xf,%ecx
0x000000000048ec84 <+52>: shr $0x4,%esi
0x000000000048ec87 <+55>: movzbl 0x4fec80(%rcx),%ecx
0x000000000048ec8e <+62>: mov %esi,%esi
0x000000000048ec90 <+64>: movzbl 0x4fec80(%rsi),%esi
0x000000000048ec97 <+71>: mov %cl,0x1(%rax,%rdx,1)
0x000000000048ec9b <+75>: mov %sil,(%rax,%rdx,1)
0x000000000048ec9f <+79>: add $0x2,%rdx
0x000000000048eca3 <+83>: cmp $0x28,%rdx
0x000000000048eca7 <+87>: jne 0x48ec78 <sha1_to_hex+40>
0x000000000048eca9 <+89>: movb $0x0,0x28(%rax)
0x000000000048ecad <+93>: retq
End of assembler dump.
^ permalink raw reply
* Re: Core dump on commit
From: Marko Vukovic @ 2011-08-15 15:55 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8CKFeSXy-QV=qdgtax92TdWCfem9rC-FYzptjd1JA1+AA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> If I put a tag to HEAD, I could reproduce this. Let's assume that "git
> cat-file -t HEAD" in your repo returns "tag", how did you create the
> last commits? Did you modify a ref manually? What git version did you
> use?
Sorry, I do not understand what you mean by "modifying a ref manually". I
created the last commit and the tag with the Eclipse plugin "eGit". Later when I
could not create more commits, I deleted the tag from the command line and also
tried to commit from the command line which gave me the core dump.
I have got git.x86_64 package 1.7.4.4-1.fc14 installed on my computer.
^ permalink raw reply
* Re: Core dump on commit
From: Nguyen Thai Ngoc Duy @ 2011-08-15 16:03 UTC (permalink / raw)
To: Marko Vukovic; +Cc: git
In-Reply-To: <loom.20110815T172423-956@post.gmane.org>
On Mon, Aug 15, 2011 at 10:48 PM, Marko Vukovic <amasniko@yahoo.com> wrote:
> Pardon my ignorance, but what does "git reset" do? I have got some uncommitted
> changes in the staging area. What will happen to them?
I should have written "git reset --soft 1b9a976133", which resets HEAD
ref back to (assuming) good commit. See [1] for more information. I
think for some reason, eGit put a tag object to HEAD, while it should
be a commit object. By resetting it back to the commit that the tag
points to, you may be able to commit again.
No history would be lost. Also if you use --soft, index should be
untouched. As always, back up your repository (copy the whole
directory, including .git) before doing anything.
[1] http://www.kernel.org/pub/software/scm/git/docs/git-reset.html
--
Duy
^ permalink raw reply
* Re: Core dump on commit
From: Marko Vukovic @ 2011-08-15 16:09 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8BBvgJauL4a9MxWAXGN-_qiAKprt15hizyBp0O9knwKrg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> I should have written "git reset --soft 1b9a976133", which resets HEAD
> ref back to (assuming) good commit. See [1] for more information. I
> think for some reason, eGit put a tag object to HEAD, while it should
> be a commit object. By resetting it back to the commit that the tag
> points to, you may be able to commit again.
>
> No history would be lost. Also if you use --soft, index should be
> untouched. As always, back up your repository (copy the whole
> directory, including .git) before doing anything.
>
> [1] http://www.kernel.org/pub/software/scm/git/docs/git-reset.html
Thank you very much, I was able to commit after the reset.
I shall remember never to use eGit for tagging in the future!
^ permalink raw reply
* Re: Core dump on commit
From: Carlos Martín Nieto @ 2011-08-15 16:11 UTC (permalink / raw)
To: Marko Vukovic; +Cc: git
In-Reply-To: <loom.20110815T180732-236@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Mon, 2011-08-15 at 16:09 +0000, Marko Vukovic wrote:
> Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
> > I should have written "git reset --soft 1b9a976133", which resets HEAD
> > ref back to (assuming) good commit. See [1] for more information. I
> > think for some reason, eGit put a tag object to HEAD, while it should
> > be a commit object. By resetting it back to the commit that the tag
> > points to, you may be able to commit again.
> >
> > No history would be lost. Also if you use --soft, index should be
> > untouched. As always, back up your repository (copy the whole
> > directory, including .git) before doing anything.
> >
> > [1] http://www.kernel.org/pub/software/scm/git/docs/git-reset.html
>
> Thank you very much, I was able to commit after the reset.
>
> I shall remember never to use eGit for tagging in the future!
A (probably) more useful way to deal with it would be to report a bug to
EGIT so they know about it and can fix it.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: shallow clone not very shallow due to tags
From: Shawn Pearce @ 2011-08-15 17:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8DF49PJtv41vZEOX0fLg4U1+m6JEW28+iYD6jJxGctEzg@mail.gmail.com>
On Mon, Aug 15, 2011 at 07:03, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Mon, Aug 15, 2011 at 6:58 AM, Shawn Pearce <spearce@spearce.org> wrote:
>> Uhm. That is not a very shallow clone. The clone copied 20234 objects
>> at 9.15 MiB... so its ~20 MiB lighter than a full clone. But nearly
>> all of the tags exist, because the clone client is declaring want
>> lines for them, making the server generate up to 1 commit back from
>> the wanted tag. I know shallow support is the feature nobody wants to
>> think about, but this just seems broken to me. Clients performing a
>> shallow clone shouldn't be asking for tags... but they should be using
>> the include-tag protocol option so that if they do happen to receive a
>> tagged commit, the tag object will also be sent.
>
> The same would apply if the repo in question has many branches. Should
> we fetch only master (or a user-specified set of refs) in shallow
> clone?
Yes, I think a user who is making a shallow clone should only get the
HEAD branch to the depth specified, nothing else. If they want
additional branches, they should either pass them on the command line
to a new flag for clone, or modify their fetch configuration
after-the-fact and fetch those separately.
>From what I can gather from some users I have talked to, the primary
usage of shallow clone is to try and (sort of) quickly grab a branch,
make a change, and post that change to the maintainers for review and
acceptance. E.g. correcting a spelling typo. Relatively simple changes
that can be built on a specific branch, and don't really require all
of the history.
And if a repository does have more than one branch, but is shallow
cloned at say depth of 1, the user probably doesn't get the merge
bases between them, so the value of the other branches is greatly
reduced. You can't make a merge between these, and a new developer
getting involved in the project cannot see how the branches relate to
each other. So there isn't a lot of value in sucking down those
additional branches during clone.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] commit: check return value of lookup_commit()
From: Junio C Hamano @ 2011-08-15 17:46 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313422716-26432-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> If lookup_commit() returns NULL, there's usually serious error and the
> command aborts anyway. However it's still nicer to have a message
> telling us where it aborts, rather than segmentation fault.
The change itself looks good to me but a point and a half to think about:
- In this if/elseif/.../else cascade, everybody except for the
"initial_commit" case needs to make sure that head_sha1 points at a
valid commit and get an commit object. Hoisting the scope of the
variable "commit" one level in your patch is good, but it would make it
easier to read and the future code modification much less error prone
if (1) you called lookup_commit() and checked for errors before
entering this if/elseif/... cascade, and (2) you renamed this variable
to "head_commit".
- Whether we like it or not, many people have a broken reimplementations
of git that can put a non-commit in HEAD, and they won't be fixed
overnight. Instead of erroring out, would it be nicer of us if we just
warned, unwrapped the tag and used the tagged commit instead?
^ permalink raw reply
* Re: [PATCH 7/7] sequencer: Remove sequencer state after final commit
From: Junio C Hamano @ 2011-08-15 18:55 UTC (permalink / raw)
To: Jonathan Nieder, Ramkumar Ramachandra
Cc: Git List, Christian Couder, Daniel Barkalow, Jeff King
In-Reply-To: <7vippzlj7a.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I believe it is meant to support command sequences such as these:
>>
>> 1.
>> git cherry-pick foo; # has conflicts
>> ... resolve conflicts and "git add" the resolved files ...
>> git commit
>> git cherry-pick bar
>
> Why does a single commit "cherry-pick foo" leave any sequencer state that
> may interfere with the latter to begin with? Isn't that already a bug?
>
>> 2.
>> git cherry-pick foo bar; # has conflicts applying "bar"
>> ... resolve ...
>> git commit
>> git cherry-pick baz
>>
>> Those were intuitive things to do before the sequencer existed, and if
>> I understand correctly, d3f4628e was intended to support people and
>> scripts (such as the test suite) that have these commands wired into
>> their fingers.
>
> Given that the latter was broken when "foo" stopped with conficts (it lost
> "bar" altogether anyway), I am not worried about it, and I do not care
> much about anybody who had wired such multi-pick into scripts or fingers,
> either.
>
> IOW, I do not necessarily agree with your "those were intuitive"
> assertion.
After sleeping on this, here are my random thoughts on this topic.
- The sequencing flow the current "rebase -i" implements when resuming a
controlled stop (i.e. "edit" or "reword"), even as the last step of the
insn sheet, feels like the right thing. The actual tweaking of the
commit done by "commit --amend" is oblivious to the sequencing state,
and resuming is controlled by "rebase --continue".
- The case to resume an unexpected stop (i.e. "pick" that causes conflict
or "rebase" without "-i") also feels right. The user fixes up and marks
things as "done" with "add/rm", and tell the stopped command that it can
now continue with "rebase --continue". The same comment applies for
"am".
- Even before we started talking about the sequencer, the workflow to deal
with conflicted "revert" or "cherry-pick" was awkward. From the end
user's point of view, the operation the end user wanted to perform was
"revert" (or "cherry-pick"), but we tell the user to fix things up, mark
them as "done" with "add/rm", and commit the result themselves. We could
have made the UI more consistent by introducing "revert --continue".
- In a sense, the last point got worse by a recent change to make
"commit" notice CHERRY_PICK_HEAD. This was modeled the workflow to
conclude a conflicted "merge", that noticed "MERGE_HEAD" etc., but from
the UI point of view, I think it was a mistake. Back when "merge" was
the only command that needs post-clean-up by the user, saying "when
merge stops due to conflict, you conclude it with commit, but
everything else you conclude (or continue) with --continue" was
reasonable, but now we have to say "after conflicted merge, revert and
cherry-pick, you conclude it with commit; use --continue for everything
else".
So I think that questions that affect us longer term are:
- Does it make sense to keep this two quite different ways to resume an
interrupted operation? Some saying "The operation you started was Foo
but you need to conclude it with 'commit'", others saying "When Bar
stops in the middle, you say 'Bar --continue'"?
- If so, which camp should the sequencer-based commands fall into?
- If not, shouldn't we be unifying the user experience to one of them,
with backward compatibility escape hatches?
I think what d3f4628e tried to do may make sense _if_ we want to make
"commit" the way to conclude or continue sequencer-based commands. If we
really wanted to go that route, however, it would make it easier if
"commit" were the _only_ way to deal with all the "stopped because the
user needs to resolve conflicts or because the user told us to pause"
situations. For example, when "rebase -i" stops (either due to an "edit"
or a conflicted "pick"), after the user tweaks the tree and says "git
commit [--amend]" to reword, "rebase --continue" after that shouldn't be
necessary. If we are making "commit" aware of the sequencer status, it
should already know that the next thing after that invocation of "commit"
is to resume the sequencing.
But I do not think that is the direction we would want to go for two
reasons. There is a (complicated) workflow to split an commit during
"rebase -i" that does _not_ want an auto-resume by a commit. Also not
all conflicted/stopped state can be concluded with "commit" (think:
"rebase/am --skip").
I personally am leaning towards teaching "--continue" to "merge" and
"cherry-pick", while keeping only existing awareness of these two commands
in "commit" as historical mistakes (look for 'unlink(git_path("[A-Z_]*"))'
in builtin/commit.c). That would mean that in the long run, new users need
to learn only one thing: when "git Foo" stops because it needs help from
you resolving conflicts, after you help it by editing the files in your
working tree and making that with add/rm, you say "git Foo --continue" to
signal that you are done helping it.
And we do not have to worry about making "commit" only half-aware of
sequencer states.
^ permalink raw reply
* Re: [PATCH 1/2] xdiff-interface: allow consume function to quit early by returning non-zero
From: Junio C Hamano @ 2011-08-15 19:41 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313376083-24713-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
What is this for? No explanation?
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 0e2c169..c5684b4 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -56,7 +56,7 @@ int parse_hunk_header(char *line, int len,
> return -!!memcmp(cp, " @@", 3);
> }
>
> -static void consume_one(void *priv_, char *s, unsigned long size)
> +static int consume_one(void *priv_, char *s, unsigned long size)
> {
> struct xdiff_emit_state *priv = priv_;
> char *ep;
> @@ -64,10 +64,12 @@ static void consume_one(void *priv_, char *s, unsigned long size)
> unsigned long this_size;
> ep = memchr(s, '\n', size);
> this_size = (ep == NULL) ? size : (ep - s + 1);
> - priv->consume(priv->consume_callback_data, s, this_size);
> + if (priv->consume(priv->consume_callback_data, s, this_size))
> + return -1;
> size -= this_size;
> s += this_size;
> }
> + return 0;
> }
Returning a negative value implies that this is an error condition. Should
all "non-zero" returns from ->consume necessarily be considered error?
The same comment applies to the new "return -1" in the rest of the patch.
^ permalink raw reply
* [PATCH v2] git svn : hook before 'git svn dcommit'
From: Frédéric Heitzmann @ 2011-08-15 20:04 UTC (permalink / raw)
To: gitster; +Cc: git, Frédéric Heitzmann
The 'pre-svn-dcommit' hook is called before 'git svn dcommit', which aborts
if return value is not zero. The only parameter given to the hook is the
reference given to 'git svn dcommit'. If no paramter was used, hook gets HEAD
as its only parameter.
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
---
I resend the same patch previously sent July 9th.
Apparently it did not graduated upstream, and I do not know why.
Please someone tell me if something needs to be improved.
Documentation/git-svn.txt | 14 +++++++++++++-
git-svn.perl | 21 +++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 713e523..ec87ed3 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -700,6 +700,18 @@ section because they affect the 'git-svn-id:' metadata line, except
for rewriteRoot and rewriteUUID which can be used together.
+HOOKS
+-----
+
+The 'pre-svn-dcommit' hook is called by 'git svn dcommit' and can be used to
+prevent some diff to be committed to a SVN repository. It may typically be
+used to filter some intermediate patches, which were committed into git but
+must not find their way to the SVN repository.
+
+It takes a single parameter, the reference given to 'git svn dcommit'. If the
+hook exists with a non zero-status, 'git svn dcommit' will abort.
+
+
BASIC EXAMPLES
--------------
@@ -901,7 +913,7 @@ reset) branches-maxRev and/or tags-maxRev as appropriate.
SEE ALSO
--------
-linkgit:git-rebase[1]
+linkgit:git-rebase[1], linkgit:githooks[5]
GIT
---
diff --git a/git-svn.perl b/git-svn.perl
index 89f83fd..a537858 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -396,6 +396,25 @@ sub init_subdir {
$_repository = Git->repository(Repository => $ENV{GIT_DIR});
}
+sub pre_svn_dcommit_hook {
+ my $head = shift;
+
+ my $hook = "$ENV{GIT_DIR}/hooks/pre-svn-dcommit";
+ return 0 if ! -e $hook || ! -x $hook;
+
+ system($hook, $head);
+ if ($? == -1) {
+ print "[pre_svn_dcommit_hook] failed to execute $hook: $!\n";
+ return 1;
+ } elsif ($? & 127) {
+ printf "[pre_svn_dcommit_hook] child died with signal %d, %s coredump\n",
+ ($? & 127), ($? & 128) ? 'with' : 'without';
+ return 1;
+ } else {
+ return $? >> 8;
+ }
+}
+
sub cmd_clone {
my ($url, $path) = @_;
if (!defined $path &&
@@ -505,6 +524,8 @@ sub cmd_dcommit {
. "or stash them with `git stash'.\n";
$head ||= 'HEAD';
+ return if pre_svn_dcommit_hook($head);
+
my $old_head;
if ($head ne 'HEAD') {
$old_head = eval {
--
1.7.6.133.gd3b55a
^ permalink raw reply related
* Re: [PATCH 0/2] Add an update=none option for 'loose' submodules
From: Junio C Hamano @ 2011-08-15 20:37 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
In-Reply-To: <20110811195955.GA21185@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> On Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote:
>> Heiko Voigt <hvoigt@hvoigt.net> writes:
>>
>> > If a submodule is used to seperate some bigger parts of a project into
>> > an optional directory it is helpful to not clone/update them by default.
>>
>> Sorry if I am slow, but I do not get this.
>>
>> I thought unless you say "submodule init" once, a submodule you are not
>> interested in should not be cloned nor updated at all. If that is not the
>> case, isn't it a bug to be fixed without a new configuration variable that
>> fixes it only when it is set?
>
> What I usually do is say "submodule init" without any extra option once.
> That will register all submodules from .gitmodules in the config. Now
> when I say "submodule update" all submodules would be cloned. In the
> case of recursive submodules actually
>
> git submodule update --init --recursive
>
> is the only command which can get you really everything in one go.
>
> Do you think the "submodule init" behavior is wrong? If so I think its a
> bit late to change this since people using submodules (me included)
> already have got used to it.
>
> With this config variable all submodules will still be registered to
> .git/config on "submodule init" but "submodule update" will skip those
> submodules.
Ok, that sort-of makes sense, but we have been using "do we have the
submodule registered in the .git/config of the superproject?" to decide
"does the user interested in having a checkout of the submodule?" (I think
in the ancient days it was "do we have .git in that submodule directory?"
that decided it, but we dropped that because it won't work when switching
branches that has and does not have the submodule in superproject).
It is somewhat worrying that some parts of the system may still be using
that old criteria "do we have it in .git/config of the superproject?" to
decide if the user is interested in the submodule. If so they need to be
updated to take this new semantics "do we have it in .git/config without
its submodule.$name.update set to none" into account. We would probably
need to have a paragraph in the release notes to warn about the semantics
change (which I tend to agree with you that it is a good one).
>> > We have been talking about loose submodules for some time:
>>
>> Also before introducing a new terminology "loose submodule", please define
>> it somewhere. It feels confusing to me that a normal submodule, which
>> shouldn't be auto-cloned nor auto-updated without "submodule init", needs
>> to be called by a name other than simply a "submodule" but with an
>> adjuctive "loose submodule".
>
> Thats why I avoided talking about it in the docs. For the commit message
> I thought it would be kind of intuitive but I can update the commit
> message so that it becomes more clear.
That sounds like a good thing to do.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] git svn : hook before 'git svn dcommit'
From: Junio C Hamano @ 2011-08-15 21:14 UTC (permalink / raw)
To: Frédéric Heitzmann; +Cc: git, Eric Wong
In-Reply-To: <1313438699-9926-1-git-send-email-frederic.heitzmann@gmail.com>
Frédéric Heitzmann <frederic.heitzmann@gmail.com> writes:
> The 'pre-svn-dcommit' hook is called before 'git svn dcommit', which aborts
> if return value is not zero. The only parameter given to the hook is the
> reference given to 'git svn dcommit'. If no paramter was used, hook gets HEAD
> as its only parameter.
It appears that this is in the same spirit as the pre-commit hook used in
"git commit", so it may not hurt but I do not know if having a separate
hook is the optimal approach to achieve what it wants to do.
I notice that git-svn users have been happily using the subsystem without
need for any hook (not just pre-commit). Does "git svn" need an equivalent
of pre-commit hook? If so, does it need equivalents to other hooks as
well? I am not suggesting you to add support for a boatload of other hooks
in this patch---I am trying to see if this is really a necessary change to
begin with.
Eric, do you want this one?
> diff --git a/git-svn.perl b/git-svn.perl
> index 89f83fd..a537858 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -396,6 +396,25 @@ sub init_subdir {
> $_repository = Git->repository(Repository => $ENV{GIT_DIR});
> }
>
> +sub pre_svn_dcommit_hook {
> + my $head = shift;
> +
> + my $hook = "$ENV{GIT_DIR}/hooks/pre-svn-dcommit";
> + return 0 if ! -e $hook || ! -x $hook;
Why force two stat(), instead of just "if ! -x $hook"? Doesn't it respond
to a non-existing $hook with "there is nothing executable there" just fine?
> + system($hook, $head);
> + if ($? == -1) {
> + print "[pre_svn_dcommit_hook] failed to execute $hook: $!\n";
> + return 1;
> + } elsif ($? & 127) {
> + printf "[pre_svn_dcommit_hook] child died with signal %d, %s coredump\n",
> + ($? & 127), ($? & 128) ? 'with' : 'without';
> + return 1;
> + } else {
> + return $? >> 8;
> + }
> +}
Should these messages go to the standard output?
> sub cmd_clone {
> my ($url, $path) = @_;
> if (!defined $path &&
> @@ -505,6 +524,8 @@ sub cmd_dcommit {
> . "or stash them with `git stash'.\n";
> $head ||= 'HEAD';
>
> + return if pre_svn_dcommit_hook($head);
> +
> my $old_head;
> if ($head ne 'HEAD') {
> $old_head = eval {
^ permalink raw reply
* [PATCH v4 1/2] rev-parse: add option --resolve-git-dir <path>
From: Fredrik Gustafsson @ 2011-08-15 21:17 UTC (permalink / raw)
To: git; +Cc: gitster, jens.lehmann, hvoigt, iveqy
In-Reply-To: <1313443067-2642-1-git-send-email-iveqy@iveqy.com>
Check if <path> is a valid git-dir or a valid git-file that points
to a valid git-dir.
We want tests to be independent from the fact that a git-dir may
be a git-file. Thus we changed tests to use this feature.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Documentation/git-rev-parse.txt | 4 ++
builtin/rev-parse.c | 8 +++
cache.h | 1 +
setup.c | 7 +++
t/t7400-submodule-basic.sh | 4 +-
t/t7403-submodule-sync.sh | 5 +-
t/t7407-submodule-foreach.sh | 103 ++++++++++++++++++++-------------------
7 files changed, 78 insertions(+), 54 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 42c9676..8023dc0 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -180,6 +180,10 @@ print a message to stderr and exit with nonzero status.
<args>...::
Flags and parameters to be parsed.
+--resolve-git-dir <path>::
+ Check if <path> is a valid git-dir or a git-file pointing to a valid
+ git-dir. If <path> is a valid git-dir the resolved path to git-dir will
+ be printed.
include::revisions.txt[]
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 4c19f84..98d1cbe 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -468,6 +468,14 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
return 0;
}
+ if (argc > 2 && !strcmp(argv[1], "--resolve-git-dir")) {
+ const char *gitdir = resolve_gitdir(argv[2]);
+ if (!gitdir)
+ die("not a gitdir '%s'", argv[2]);
+ puts(gitdir);
+ return 0;
+ }
+
if (argc > 1 && !strcmp("-h", argv[1]))
usage(builtin_rev_parse_usage);
diff --git a/cache.h b/cache.h
index 9e12d55..550f632 100644
--- a/cache.h
+++ b/cache.h
@@ -436,6 +436,7 @@ 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 *read_gitfile_gently(const char *path);
+extern const char *resolve_gitdir(const char *suspect);
extern void set_git_work_tree(const char *tree);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/setup.c b/setup.c
index 5ea5502..efad002 100644
--- a/setup.c
+++ b/setup.c
@@ -808,3 +808,10 @@ const char *setup_git_directory(void)
{
return setup_git_directory_gently(NULL);
}
+
+const char *resolve_gitdir(const char *suspect)
+{
+ if (is_git_directory(suspect))
+ return suspect;
+ return read_gitfile_gently(suspect);
+}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 14dc927..270a7d5 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -360,10 +360,10 @@ test_expect_success 'update --init' '
git submodule update init > update.out &&
cat update.out &&
test_i18ngrep "not initialized" update.out &&
- ! test -d init/.git &&
+ test_must_fail git rev-parse --resolve-git-dir init/.git &&
git submodule update --init init &&
- test -d init/.git
+ git rev-parse --resolve-git-dir init/.git
'
test_expect_success 'do not add files from a submodule' '
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 95ffe34..3620215 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t7403-submodule-sync.sh
@@ -56,8 +56,9 @@ test_expect_success '"git submodule sync" should update submodule URLs' '
git pull --no-recurse-submodules &&
git submodule sync
) &&
- test -d "$(git config -f super-clone/submodule/.git/config \
- remote.origin.url)" &&
+ test -d "$(cd super-clone/submodule &&
+ git config remote.origin.url
+ )" &&
(cd super-clone/submodule &&
git checkout master &&
git pull
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index be745fb..9b69fe2 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -118,19 +118,19 @@ test_expect_success 'use "submodule foreach" to checkout 2nd level submodule' '
git clone super clone2 &&
(
cd clone2 &&
- test ! -d sub1/.git &&
- test ! -d sub2/.git &&
- test ! -d sub3/.git &&
- test ! -d nested1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
+ test_must_fail git rev-parse --resolve-git-dir nested1/.git &&
git submodule update --init &&
- test -d sub1/.git &&
- test -d sub2/.git &&
- test -d sub3/.git &&
- test -d nested1/.git &&
- test ! -d nested1/nested2/.git &&
+ git rev-parse --resolve-git-dir sub1/.git &&
+ git rev-parse --resolve-git-dir sub2/.git &&
+ git rev-parse --resolve-git-dir sub3/.git &&
+ git rev-parse --resolve-git-dir nested1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir nested1/nested2/.git &&
git submodule foreach "git submodule update --init" &&
- test -d nested1/nested2/.git &&
- test ! -d nested1/nested2/nested3/.git
+ git rev-parse --resolve-git-dir nested1/nested1/nested2/.git
+ test_must_fail git rev-parse --resolve-git-dir nested1/nested2/nested3/.git
)
'
@@ -138,8 +138,8 @@ test_expect_success 'use "foreach --recursive" to checkout all submodules' '
(
cd clone2 &&
git submodule foreach --recursive "git submodule update --init" &&
- test -d nested1/nested2/nested3/.git &&
- test -d nested1/nested2/nested3/submodule/.git
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
)
'
@@ -183,18 +183,18 @@ test_expect_success 'use "update --recursive" to checkout all submodules' '
git clone super clone3 &&
(
cd clone3 &&
- test ! -d sub1/.git &&
- test ! -d sub2/.git &&
- test ! -d sub3/.git &&
- test ! -d nested1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
+ test_must_fail git rev-parse --resolve-git-dir nested1/.git &&
git submodule update --init --recursive &&
- test -d sub1/.git &&
- test -d sub2/.git &&
- test -d sub3/.git &&
- test -d nested1/.git &&
- test -d nested1/nested2/.git &&
- test -d nested1/nested2/nested3/.git &&
- test -d nested1/nested2/nested3/submodule/.git
+ git rev-parse --resolve-git-dir sub1/.git &&
+ git rev-parse --resolve-git-dir sub2/.git &&
+ git rev-parse --resolve-git-dir sub3/.git &&
+ git rev-parse --resolve-git-dir nested1/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
)
'
@@ -247,14 +247,17 @@ test_expect_success 'ensure "status --cached --recursive" preserves the --cached
test_expect_success 'use "git clone --recursive" to checkout all submodules' '
git clone --recursive super clone4 &&
- test -d clone4/.git &&
- test -d clone4/sub1/.git &&
- test -d clone4/sub2/.git &&
- test -d clone4/sub3/.git &&
- test -d clone4/nested1/.git &&
- test -d clone4/nested1/nested2/.git &&
- test -d clone4/nested1/nested2/nested3/.git &&
- test -d clone4/nested1/nested2/nested3/submodule/.git
+ (
+ cd clone4 &&
+ git rev-parse --resolve-git-dir .git &&
+ git rev-parse --resolve-git-dir sub1/.git &&
+ git rev-parse --resolve-git-dir sub2/.git &&
+ git rev-parse --resolve-git-dir sub3/.git &&
+ git rev-parse --resolve-git-dir nested1/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
+ )
'
test_expect_success 'test "update --recursive" with a flag with spaces' '
@@ -262,14 +265,14 @@ test_expect_success 'test "update --recursive" with a flag with spaces' '
git clone super clone5 &&
(
cd clone5 &&
- test ! -d nested1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir d nested1/.git &&
git submodule update --init --recursive --reference="$(dirname "$PWD")/common objects" &&
- test -d nested1/.git &&
- test -d nested1/nested2/.git &&
- test -d nested1/nested2/nested3/.git &&
- test -f nested1/.git/objects/info/alternates &&
- test -f nested1/nested2/.git/objects/info/alternates &&
- test -f nested1/nested2/nested3/.git/objects/info/alternates
+ git rev-parse --resolve-git-dir nested1/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
+ test -f .git/modules/nested1/objects/info/alternates &&
+ test -f .git/modules/nested1/modules/nested2/objects/info/alternates &&
+ test -f .git/modules/nested1/modules/nested2/modules/nested3/objects/info/alternates
)
'
@@ -277,18 +280,18 @@ test_expect_success 'use "update --recursive nested1" to checkout all submodules
git clone super clone6 &&
(
cd clone6 &&
- test ! -d sub1/.git &&
- test ! -d sub2/.git &&
- test ! -d sub3/.git &&
- test ! -d nested1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
+ test_must_fail git rev-parse --resolve-git-dir nested1/.git &&
git submodule update --init --recursive -- nested1 &&
- test ! -d sub1/.git &&
- test ! -d sub2/.git &&
- test ! -d sub3/.git &&
- test -d nested1/.git &&
- test -d nested1/nested2/.git &&
- test -d nested1/nested2/nested3/.git &&
- test -d nested1/nested2/nested3/submodule/.git
+ test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
+ test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
+ git rev-parse --resolve-git-dir nested1/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
)
'
--
1.7.6.398.gb3f84
^ permalink raw reply related
* [PATCH v4 2/2] Move git-dir for submodules
From: Fredrik Gustafsson @ 2011-08-15 21:17 UTC (permalink / raw)
To: git; +Cc: gitster, jens.lehmann, hvoigt, iveqy
In-Reply-To: <1313443067-2642-1-git-send-email-iveqy@iveqy.com>
Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of
the superproject. This is a step towards being able to delete submodule
directories without loosing the information from their .git directory
as that is now stored outside the submodules work tree.
This is done relying on the already existent .git-file functionality.
When adding or updating a submodule whose git directory is found under
$GIT_DIR/modules/[name_of_submodule], don't clone it again but simply
point the .git-file to it and remove the now stale index file from it.
The index will be recreated by the following checkout.
This patch will not affect already cloned submodules at all.
Tests that rely on .git being a directory have been fixed.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
---
git-submodule.sh | 49 ++++++++++++++++--
t/t7406-submodule-update.sh | 107 ++++++++++++++++++++++++++++++++++++++++
t/t7408-submodule-reference.sh | 4 +-
3 files changed, 153 insertions(+), 7 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index bc1d3fa..ace6c1d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -122,14 +122,53 @@ module_clone()
path=$1
url=$2
reference="$3"
+ gitdir=
+ gitdir_base=
+ name=$(module_name "$path")
+ if test -z "$name"
+ then
+ name="$path"
+ fi
+ base_path=$(dirname "$path")
+
+ gitdir=$(git rev-parse --git-dir)
+ gitdir_base="$gitdir/modules/$base_path"
+ gitdir="$gitdir/modules/$path"
+
+ case $gitdir in
+ /*)
+ a="$(cd_to_toplevel && pwd)/"
+ b=$gitdir
+ while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
+ do
+ a=${a#*/} b=${b#*/};
+ done
+
+ rel="$a$name"
+ rel=`echo $rel | sed -e 's|[^/]*|..|g'`
+ rel_gitdir="$rel/$b"
+ ;;
+ *)
+ rel=`echo $name | sed -e 's|[^/]*|..|g'`
+ rel_gitdir="$rel/$gitdir"
+ ;;
+ esac
- if test -n "$reference"
+ if test -d "$gitdir"
then
- git-clone "$reference" -n "$url" "$path"
+ mkdir -p "$path"
+ echo "gitdir: $rel_gitdir" >"$path/.git"
+ rm -f "$gitdir/index"
else
- git-clone -n "$url" "$path"
- fi ||
- die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
+ mkdir -p "$gitdir_base"
+ if test -n "$reference"
+ then
+ git-clone "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
+ else
+ git-clone -n "$url" "$path" --separate-git-dir "$gitdir"
+ fi ||
+ die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
+ fi
}
#
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index c679f36..1ae6b4e 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -408,6 +408,7 @@ test_expect_success 'submodule update exit immediately in case of merge conflict
test_cmp expect actual
)
'
+
test_expect_success 'submodule update exit immediately after recursive rebase error' '
(cd super &&
git checkout master &&
@@ -442,4 +443,110 @@ test_expect_success 'submodule update exit immediately after recursive rebase er
test_cmp expect actual
)
'
+
+test_expect_success 'add different submodules to the same path' '
+ (cd super &&
+ git submodule add ../submodule s1 &&
+ test_must_fail git submodule add ../merging s1
+ )
+'
+
+test_expect_success 'submodule add places git-dir in superprojects git-dir' '
+ (cd super &&
+ mkdir deeper &&
+ git submodule add ../submodule deeper/submodule &&
+ (cd deeper/submodule &&
+ git log > ../../expected
+ ) &&
+ (cd .git/modules/deeper/submodule &&
+ git log > ../../../../actual
+ ) &&
+ test_cmp actual expected
+ )
+'
+
+test_expect_success 'submodule update places git-dir in superprojects git-dir' '
+ (cd super &&
+ git commit -m "added submodule"
+ ) &&
+ git clone super super2 &&
+ (cd super2 &&
+ git submodule init deeper/submodule &&
+ git submodule update &&
+ (cd deeper/submodule &&
+ git log > ../../expected
+ ) &&
+ (cd .git/modules/deeper/submodule &&
+ git log > ../../../../actual
+ ) &&
+ test_cmp actual expected
+ )
+'
+
+test_expect_success 'submodule add places git-dir in superprojects git-dir recursive' '
+ (cd super2 &&
+ (cd deeper/submodule &&
+ git submodule add ../submodule subsubmodule &&
+ (cd subsubmodule &&
+ git log > ../../../expected
+ ) &&
+ git commit -m "added subsubmodule" &&
+ git push
+ ) &&
+ (cd .git/modules/deeper/submodule/modules/subsubmodule &&
+ git log > ../../../../../actual
+ ) &&
+ git add deeper/submodule &&
+ git commit -m "update submodule" &&
+ git push &&
+ test_cmp actual expected
+ )
+'
+
+test_expect_success 'submodule update places git-dir in superprojects git-dir recursive' '
+ mkdir super_update_r &&
+ (cd super_update_r &&
+ git init --bare
+ ) &&
+ mkdir subsuper_update_r &&
+ (cd subsuper_update_r &&
+ git init --bare
+ ) &&
+ mkdir subsubsuper_update_r &&
+ (cd subsubsuper_update_r &&
+ git init --bare
+ ) &&
+ git clone subsubsuper_update_r subsubsuper_update_r2 &&
+ (cd subsubsuper_update_r2 &&
+ test_commit "update_subsubsuper" file &&
+ git push origin master
+ ) &&
+ git clone subsuper_update_r subsuper_update_r2 &&
+ (cd subsuper_update_r2 &&
+ test_commit "update_subsuper" file &&
+ git submodule add ../subsubsuper_update_r subsubmodule &&
+ git commit -am "subsubmodule" &&
+ git push origin master
+ ) &&
+ git clone super_update_r super_update_r2 &&
+ (cd super_update_r2 &&
+ test_commit "update_super" file &&
+ git submodule add ../subsuper_update_r submodule &&
+ git commit -am "submodule" &&
+ git push origin master
+ ) &&
+ rm -rf super_update_r2 &&
+ git clone super_update_r super_update_r2 &&
+ (cd super_update_r2 &&
+ git submodule update --init --recursive &&
+ (cd submodule/subsubmodule &&
+ git log > ../../expected
+ ) &&
+ (cd .git/modules/submodule/modules/subsubmodule
+ git log > ../../../../../actual
+ )
+ test_cmp actual expected
+ )
+'
+
test_done
diff --git a/t/t7408-submodule-reference.sh b/t/t7408-submodule-reference.sh
index cc16d3f..ab37c36 100755
--- a/t/t7408-submodule-reference.sh
+++ b/t/t7408-submodule-reference.sh
@@ -43,7 +43,7 @@ git commit -m B-super-added'
cd "$base_dir"
test_expect_success 'after add: existence of info/alternates' \
-'test `wc -l <super/sub/.git/objects/info/alternates` = 1'
+'test `wc -l <super/.git/modules/sub/objects/info/alternates` = 1'
cd "$base_dir"
@@ -66,7 +66,7 @@ test_expect_success 'update with reference' \
cd "$base_dir"
test_expect_success 'after update: existence of info/alternates' \
-'test `wc -l <super-clone/sub/.git/objects/info/alternates` = 1'
+'test `wc -l <super-clone/.git/modules/sub/objects/info/alternates` = 1'
cd "$base_dir"
--
1.7.6.398.gb3f84
^ permalink raw reply related
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