Re: [PATCH v5 07/14] trailer: add interpret-trailers command
On Fri, Feb 7, 2014 at 1:10 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> diff --git a/git.c b/git.c
>> index 3799514..1420b58 100644
>> --- a/git.c
>> +++ b/git.c
>> @@ -383,6 +383,7 @@ static void handle_internal_command(int argc, const char
>> **argv)
>> { "index-pack", cmd_index_pack, RUN_SETUP_GENTLY },
>> { "init", cmd_init_db },
>> { "init-db", cmd_init_db },
>> + { "interpret-trailers", cmd_interpret_trailers, RUN_SETUP },
>> { "log", cmd_log, RUN_SETUP },
>> { "ls-files", cmd_ls_files, RUN_SETUP },
>> { "ls-remote", cmd_ls_remote, RUN_SETUP_GENTLY },
>
> Does this even need to have a git repository? What is the RUN_SETUP
> for?
It needs to read git config files, but it could work without reading them too.
I will have another look at it.
Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Git Directory Diff for submodule
Hi, I think I have found a bug related to submodules and directory diff. See the details at hXXp://stackoverflow.com/q/21623155/337621. If you need any further details, just ask. Regards, Gábor Lipták -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
Thanks for your clear response. I can see where I went wrong now. On Thu, Feb 6, 2014 at 4:10 PM, David Kastrup wrote: > Vincent van Ravesteijn writes: > >> The commits that are in the log for master and which are not in the >> log for originssh/master are merged in at "6833fd4 (HEAD, master); >> Completed merge". >> >> As "git log" can only present the commits in a linear way, it shows >> the commits from the ancentry of both parents of HEAD in a reverse >> chronological order. This means that the commits from the two >> ancestries are mixed and commits that are shown after each other don't >> have to be parent and child. See the documentation of "git log" and >> the section "Commit Ordering": "By default, the commits are shown in >> reverse chronological order." > > git log --graph can help with getting a better picture. > > -- > David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
On Fri, Feb 07, 2014 at 09:43:46AM +, Francis Stephens wrote:
> Thanks for your clear response. I can see where I went wrong now.
Maybe something like this would help avoid confusion a bit in the
future? This toy patch puts a horizontal line as a break between two
commits if they are not related, so we can clearly see linear commit
segments.
--graph definitely helps, but it's too many threads for topic-based
development model like git.git that I avoid it most of the time.
-- 8< --
diff --git a/log-tree.c b/log-tree.c
index 08970bf..7841bf2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -795,6 +795,7 @@ static int log_tree_diff(struct rev_info *opt, struct
commit *commit, struct log
int log_tree_commit(struct rev_info *opt, struct commit *commit)
{
+ static struct commit_list *last_parents;
struct log_info log;
int shown;
@@ -805,6 +806,17 @@ int log_tree_commit(struct rev_info *opt, struct commit
*commit)
if (opt->line_level_traverse)
return line_log_print(opt, commit);
+ if (last_parents) {
+ struct commit_list *p = last_parents;
+ int got_parent = 0;
+ for (; p && !got_parent; p = p->next)
+ got_parent = !hashcmp(p->item->object.sha1,
+ commit->object.sha1);
+ if (!got_parent)
+
printf("__\n");
+ free_commit_list(last_parents);
+ last_parents = NULL;
+ }
shown = log_tree_diff(opt, commit, &log);
if (!shown && opt->loginfo && opt->always_show_header) {
log.parent = NULL;
@@ -813,5 +825,6 @@ int log_tree_commit(struct rev_info *opt, struct commit
*commit)
}
opt->loginfo = NULL;
maybe_flush_or_die(stdout, "stdout");
+ last_parents = copy_commit_list(commit->parents);
return shown;
}
-- 8< --
>
> On Thu, Feb 6, 2014 at 4:10 PM, David Kastrup wrote:
> > Vincent van Ravesteijn writes:
> >
> >> The commits that are in the log for master and which are not in the
> >> log for originssh/master are merged in at "6833fd4 (HEAD, master);
> >> Completed merge".
> >>
> >> As "git log" can only present the commits in a linear way, it shows
> >> the commits from the ancentry of both parents of HEAD in a reverse
> >> chronological order. This means that the commits from the two
> >> ancestries are mixed and commits that are shown after each other don't
> >> have to be parent and child. See the documentation of "git log" and
> >> the section "Commit Ordering": "By default, the commits are shown in
> >> reverse chronological order."
> >
> > git log --graph can help with getting a better picture.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
On 7 February 2014 18:26, Duy Nguyen wrote: > On Fri, Feb 07, 2014 at 09:43:46AM +, Francis Stephens wrote: >> Thanks for your clear response. I can see where I went wrong now. > > Maybe something like this would help avoid confusion a bit in the > future? This toy patch puts a horizontal line as a break between two > commits if they are not related, so we can clearly see linear commit > segments. FWIW, this would have saved a lot of head scratching at work over the years. I'd love to see this in place. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Avoid overflowing page body frame with large images
On Feb 6, 2014, at 10:31 PM, Andrew Keller wrote:
> When displaying a blob in gitweb, if it's an image, specify constraints for
> maximum display width and height to prevent the image from overflowing the
> frame of the enclosing page_body div.
>
> This change assumes that it is more desirable to see the whole image without
> scrolling (new behavior) than it is to see every pixel without zooming
> (previous behavior).
>
> Signed-off-by: Andrew B Keller
> ---
>
> I recently used Git to archive a set of scanned photos, and I used gitweb to
> provide access to them. Overall, everything worked well, but I found it
> undesirable that I had to zoom out in my browser on every photo to see the
> whole photo. In the spirit of making the default behavior the most likely
> correct behavior, this patch seems to be a good idea.
>
> However, I'm not an expert on the use cases of gitweb. In order for the
> maximum size constraints to take effect, the image would have to be at least
> the size of the web browser window (minus a handful of pixels), so the
> affected images are usually going to be pretty big. Are there any common use
> cases for displaying a large image without scaling (and hence, with
> scrolling)?
>
> Thanks,
> Andrew
>
>
> gitweb/gitweb.perl |2 +-
> gitweb/static/gitweb.css |5 +
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 3bc0f0b..2c6a77f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -7094,7 +7094,7 @@ sub git_blob {
> git_print_page_path($file_name, "blob", $hash_base);
> print "\n";
> if ($mimetype =~ m!^image/!) {
> - print qq! + print qq! type="!.esc_attr($mimetype).qq!"!;
> if ($file_name) {
> print qq! alt="!.esc_attr($file_name).qq!"
> title="!.esc_attr($file_name).qq!"!;
> }
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index 3b4d833..cd57c2f 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/gitweb.css
> @@ -32,6 +32,11 @@ img.avatar {
> vertical-align: middle;
> }
>
> +img.image_blob {
I wonder if simply "blob" is a better style name here. "image_blob" stands out
a bit amongst the existing code, and "blob" appears to be specific enough for
the needs.
> + max-height: 100%;
> + max-width: 100%;
> +}
> +
> a.list img.avatar {
> border-style: none;
> }
> --
> 1.7.7.1
- Andrew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 2/2] receive-pack: hint that the user can stop
Junio C Hamano pobox.com> writes: > Instead of adding a boolean --break-ok that is hidden, why not > adding an exposed boolean --daemonize, and let auto-gc run in the > background? With the recent "do not let more than one gc run at the > same time", that should give a lot more pleasant end user > experience, no? That sounds quite useful to me. Duy, are you up for generating such a patch? Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Avoid overflowing page body frame with large images
On Fri, Feb 7, 2014 at 4:31 AM, Andrew Keller wrote: > I recently used Git to archive a set of scanned photos, and I used gitweb to > provide access to them. Overall, everything worked well, but I found it > undesirable that I had to zoom out in my browser on every photo to see the > whole photo. In the spirit of making the default behavior the most likely > correct behavior, this patch seems to be a good idea. > > However, I'm not an expert on the use cases of gitweb. In order for the > maximum size constraints to take effect, the image would have to be at least > the size of the web browser window (minus a handful of pixels), so the > affected images are usually going to be pretty big. Are there any common use > cases for displaying a large image without scaling (and hence, with > scrolling)? > > Thanks, > Andrew > It sounds like your usecase is exactly what camlistore.org tries to achieve. Vincent -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
GET PAID DRIVING YOUR CAR BY ROCKSTAR ENERGY DRINK FOR ADVERTISEMENT
Hello Rockstar Energy Drink " seeks people, truck drivers and all car owners above 20 years old to getpaid driving their car for advertisement you only do advert for "Rockstar Energy Drink " plastered on there cars . The ads are typically vinyl also known as "auto wraps" that almost seem to be painted on the vehicle, and which will cover any portion of your car's exterior surface. You will be compensated with $400 as rental payment weekly for letting "Rockstar Energy Drink " use your car. Hiring Manager response to wonders...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 2/2] receive-pack: hint that the user can stop
On Fri, Feb 7, 2014 at 7:36 PM, chris wrote: > Junio C Hamano pobox.com> writes: >> Instead of adding a boolean --break-ok that is hidden, why not >> adding an exposed boolean --daemonize, and let auto-gc run in the >> background? With the recent "do not let more than one gc run at the >> same time", that should give a lot more pleasant end user >> experience, no? > > That sounds quite useful to me. Duy, are you up for generating such a patch? It would not be so hard for that patch. I'm still thinking whether it should be done if auto-gc is started on the client side too (sometimes it does, which is equally annoying).. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Avoid overflowing page body frame with large images
On Feb 7, 2014, at 7:35 AM, Vincent van Ravesteijn wrote: > On Fri, Feb 7, 2014 at 4:31 AM, Andrew Keller wrote: >> I recently used Git to archive a set of scanned photos, and I used gitweb to >> provide access to them. Overall, everything worked well, but I found it >> undesirable that I had to zoom out in my browser on every photo to see the >> whole photo. In the spirit of making the default behavior the most likely >> correct behavior, this patch seems to be a good idea. >> >> However, I'm not an expert on the use cases of gitweb. In order for the >> maximum size constraints to take effect, the image would have to be at least >> the size of the web browser window (minus a handful of pixels), so the >> affected images are usually going to be pretty big. Are there any common >> use cases for displaying a large image without scaling (and hence, with >> scrolling)? >> >> Thanks, >> Andrew >> > > It sounds like your usecase is exactly what camlistore.org tries to achieve. Yes. With that said, I don't think it's unreasonable for a software project to contain images larger than a browser window. And, when that happens, I'm pretty confident that the default behavior should be to scale the image down so the user can see the whole thing. - Andrew -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Avoid overflowing page body frame with large images
Andrew Keller wrote: > > With that said, I don't think it's unreasonable for a software project > to contain images larger than a browser window. And, when that happens, > I'm pretty confident that the default behavior should be to scale the > image down so the user can see the whole thing. Right. And if you want to see the unscaled version of the image you can view the blob_plain version instead of the (scaled html-wrapped) blob. Seems sensible in principle to me but I have not reviewed the code. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dearest Beloved One,Urgent Mail From Mr.Steven Mensah.
Dear One, How are you and your family, hope all is well ? As the world is defined as a global village, I don't want you to get this letter as a surprise but as an opportunity that will put smile on your face. With due respect I propose this business to you, to make it brief I want to transfer $3.5 Million US Dollars into your bank account. The fund belong to our deceased customer who died with his entire family in 2008 China Earthquake leaving nobody for the claim and as such I decided to contact you as a partner to enable us claim the fund. 50% of this fund will be for you and 50% for me. Hit reply on this e-mail to contact me only if you're interested in this business and for more details. I am assuring you that the transaction is 100% Risk Free. Above all a line of reply is highly appreciated in this regard as soon as possible if you are interested.Please Reply To This E-Mail: mensah.steve...@yahoo.com Thank you Sincerely, Mr.Steven Mensah. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 2/2] receive-pack: hint that the user can stop
Duy Nguyen gmail.com> writes: > On Fri, Feb 7, 2014 at 7:36 PM, chris hotmail.com> wrote: > > Junio C Hamano pobox.com> writes: > >> Instead of adding a boolean --break-ok that is hidden, why not > >> adding an exposed boolean --daemonize, and let auto-gc run in the > >> background? With the recent "do not let more than one gc run at the > >> same time", that should give a lot more pleasant end user > >> experience, no? > > > > That sounds quite useful to me. Duy, are you up for generating such a patch? > > It would not be so hard for that patch. I'm still thinking whether it > should be done if auto-gc is started on the client side too (sometimes > it does, which is equally annoying).. That could be nice, but I'd be less concerned about that, as the client has the ability to disable gc for itself. Still pushing it into the background, if considered acceptable behavior, seems reasonable. Perhaps two separate patches? Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] More preparatory work for multiparent tree-walker
Here I'm preparing tree-diff.c to be ready for the new tree-walker, so that the final change is tractable and looks good and non noisy. Some small speedups are gained along the way. The final bits are almost ready, but I don't want to release them in a hurry. Please apply and thanks, Kirill Kirill Smelkov (11): tree-diff: show_tree() is not needed tree-diff: consolidate code for emitting diffs and recursion in one place tree-diff: don't assume compare_tree_entry() returns -1,0,1 tree-diff: move all action-taking code out of compare_tree_entry() tree-diff: rename compare_tree_entry -> tree_entry_pathcmp tree-diff: show_path prototype is not needed anymore tree-diff: simplify tree_entry_pathcmp tree-diff: remove special-case diff-emitting code for empty-tree cases tree-diff: rework diff_tree interface to be sha1 based tree-diff: no need to call "full" diff_tree_sha1 from show_path() tree-diff: reuse base str(buf) memory on sub-tree recursion diff.h | 4 +- tree-diff.c | 270 2 files changed, 145 insertions(+), 129 deletions(-) -- 1.9.rc1.181.g641f458 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] tree-diff: don't assume compare_tree_entry() returns -1,0,1
It does, but we'll be reworking it in the next patch after it won't, and
besides it is better to stick to standard
strcmp/memcmp/base_name_compare/etc... convention, where comparison
function returns <0, =0, >0
Regarding performance, comparing for <0, =0, >0 should be a little bit
faster, than switch, because it is just 1 test-without-immediate
instruction and then up to 3 conditional branches, and in switch you
have up to 3 tests with immediate and up to 3 conditional branches.
No worry, that update_tree_entry(t2) is duplicated for =0 and >0 - it
will be good after we'll be adding support for multiparent walker and
will stay that way.
=0 case goes first, because it happens more often in real diffs - i.e.
paths are the same.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 0c8e3fc..c3fbfba 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -181,18 +181,24 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
update_tree_entry(t1);
continue;
}
- switch (compare_tree_entry(t1, t2, &base, opt)) {
- case -1:
+
+ cmp = compare_tree_entry(t1, t2, &base, opt);
+
+ /* t1 = t2 */
+ if (cmp == 0) {
update_tree_entry(t1);
- continue;
- case 0:
+ update_tree_entry(t2);
+ }
+
+ /* t1 < t2 */
+ else if (cmp < 0) {
update_tree_entry(t1);
- /* Fallthrough */
- case 1:
+ }
+
+ /* t1 > t2 */
+ else {
update_tree_entry(t2);
- continue;
}
- die("git diff-tree: internal error");
}
strbuf_release(&base);
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] tree-diff: show_path prototype is not needed anymore
We moved all action-taking code below show_path() in recent HEAD~~ (tree-diff: move all action-taking code out of compare_tree_entry). Signed-off-by: Kirill Smelkov --- tree-diff.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tree-diff.c b/tree-diff.c index df90bbe..604dc57 100644 --- a/tree-diff.c +++ b/tree-diff.c @@ -6,9 +6,6 @@ #include "diffcore.h" #include "tree.h" -static void show_path(struct strbuf *base, struct diff_options *opt, - struct tree_desc *t1, struct tree_desc *t2); - /* * Compare two tree entries, taking into account only path/S_ISDIR(mode), * but not their sha1's. -- 1.9.rc1.181.g641f458 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] tree-diff: no need to call "full" diff_tree_sha1 from show_path()
As described in previous commit, when recursing into sub-trees, we can
use lower-level tree walker, since its interface is now sha1 based.
The change is ok, because diff_tree_sha1() only invokes
__diff_tree_sha1(), and also, if base is empty, try_to_follow_renames().
But base is not empty here, as we have added a path and '/' before
recursing.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index dd6c760..e385ed4 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -116,8 +116,8 @@ static void show_path(struct strbuf *base, struct
diff_options *opt,
if (recurse) {
strbuf_addch(base, '/');
- diff_tree_sha1(t1 ? t1->entry.sha1 : NULL,
- t2 ? t2->entry.sha1 : NULL, base->buf, opt);
+ __diff_tree_sha1(t1 ? t1->entry.sha1 : NULL,
+t2 ? t2->entry.sha1 : NULL, base->buf, opt);
}
strbuf_setlen(base, old_baselen);
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] tree-diff: rework diff_tree interface to be sha1 based
In the next commit this will allow to reduce intermediate calls, when
recursing into subtrees - at that stage we know only subtree sha1, and
it is natural for tree walker to start from that phase. For now we do
diff_tree
show_path
diff_tree_sha1
diff_tree
...
and the change will allow to reduce it to
diff_tree
show_path
diff_tree
Also, it will allow to omit allocating strbuf for each subtree, and just
reuse the common strbuf via playing with its len.
The above-mentioned improvements go in the next 2 patches.
The downside is that try_to_follow_renames(), if active, we cause
re-reading of 2 initial trees, which was negligible based on my timings,
and which is outweighed cogently by the upsides.
NOTE To keep with the current interface and semantics, I needed to
rename the function. It will probably be renamed once more later, when
its semantic will change to just generate paths for a diff, instead of
producing it. So the current name is appropriate, but probably temporary.
Signed-off-by: Kirill Smelkov
---
diff.h | 4 ++--
tree-diff.c | 60
2 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/diff.h b/diff.h
index a24a767..4994d15 100644
--- a/diff.h
+++ b/diff.h
@@ -189,8 +189,8 @@ const char *diff_line_prefix(struct diff_options *);
extern const char mime_boundary_leader[];
-extern int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
-const char *base, struct diff_options *opt);
+extern int __diff_tree_sha1(const unsigned char *old, const unsigned char *new,
+ const char *base, struct diff_options *opt);
extern int diff_tree_sha1(const unsigned char *old, const unsigned char *new,
const char *base, struct diff_options *opt);
extern int diff_root_tree_sha1(const unsigned char *new, const char *base,
diff --git a/tree-diff.c b/tree-diff.c
index 7688402..dd6c760 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -139,12 +139,17 @@ static void skip_uninteresting(struct tree_desc *t,
struct strbuf *base,
}
}
-int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
- const char *base_str, struct diff_options *opt)
+int __diff_tree_sha1(const unsigned char *old, const unsigned char *new,
+const char *base_str, struct diff_options *opt)
{
+ struct tree_desc t1, t2;
+ void *t1tree, *t2tree;
struct strbuf base;
int baselen = strlen(base_str);
+ t1tree = fill_tree_descriptor(&t1, old);
+ t2tree = fill_tree_descriptor(&t2, new);
+
/* Enable recursion indefinitely */
opt->pathspec.recursive = DIFF_OPT_TST(opt, RECURSIVE);
@@ -157,39 +162,41 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
if (diff_can_quit_early(opt))
break;
if (opt->pathspec.nr) {
- skip_uninteresting(t1, &base, opt);
- skip_uninteresting(t2, &base, opt);
+ skip_uninteresting(&t1, &base, opt);
+ skip_uninteresting(&t2, &base, opt);
}
- if (!t1->size && !t2->size)
+ if (!t1.size && !t2.size)
break;
- cmp = tree_entry_pathcmp(t1, t2);
+ cmp = tree_entry_pathcmp(&t1, &t2);
/* t1 = t2 */
if (cmp == 0) {
if (DIFF_OPT_TST(opt, FIND_COPIES_HARDER) ||
- hashcmp(t1->entry.sha1, t2->entry.sha1) ||
- (t1->entry.mode != t2->entry.mode))
- show_path(&base, opt, t1, t2);
+ hashcmp(t1.entry.sha1, t2.entry.sha1) ||
+ (t1.entry.mode != t2.entry.mode))
+ show_path(&base, opt, &t1, &t2);
- update_tree_entry(t1);
- update_tree_entry(t2);
+ update_tree_entry(&t1);
+ update_tree_entry(&t2);
}
/* t1 < t2 */
else if (cmp < 0) {
- show_path(&base, opt, t1, /*t2=*/NULL);
- update_tree_entry(t1);
+ show_path(&base, opt, &t1, /*t2=*/NULL);
+ update_tree_entry(&t1);
}
/* t1 > t2 */
else {
- show_path(&base, opt, /*t1=*/NULL, t2);
- update_tree_entry(t2);
+ show_path(&base, opt, /*t1=*/NULL, &t2);
+ update_tree_entry(&t2);
}
}
strbuf_release(&base);
+ free(t2tree);
+ free(t1tree);
return 0;
}
@@ -204,7 +211,7 @@ static inline int diff_might_be_rena
[PATCH 11/11] tree-diff: reuse base str(buf) memory on sub-tree recursion
instead of allocating it all the time for every subtree in
__diff_tree_sha1, let's allocate it once in diff_tree_sha1, and then all
callee just use it in stacking style, without memory allocations.
This should be faster, and for me this change gives the following
slight speedups for `git log --raw --no-abbrev --no-renames`
navy.gitlinux.git v3.10..v3.11
before 0.547s 1.791s
after 0.541s 1.777s
speedup 1.1%0.8%
Signed-off-by: Kirill Smelkov
---
diff.h | 2 +-
tree-diff.c | 36 ++--
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/diff.h b/diff.h
index 4994d15..14016ce 100644
--- a/diff.h
+++ b/diff.h
@@ -190,7 +190,7 @@ const char *diff_line_prefix(struct diff_options *);
extern const char mime_boundary_leader[];
extern int __diff_tree_sha1(const unsigned char *old, const unsigned char *new,
- const char *base, struct diff_options *opt);
+ struct strbuf *base, struct diff_options *opt);
extern int diff_tree_sha1(const unsigned char *old, const unsigned char *new,
const char *base, struct diff_options *opt);
extern int diff_root_tree_sha1(const unsigned char *new, const char *base,
diff --git a/tree-diff.c b/tree-diff.c
index e385ed4..2adda04 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -117,7 +117,7 @@ static void show_path(struct strbuf *base, struct
diff_options *opt,
if (recurse) {
strbuf_addch(base, '/');
__diff_tree_sha1(t1 ? t1->entry.sha1 : NULL,
-t2 ? t2->entry.sha1 : NULL, base->buf, opt);
+t2 ? t2->entry.sha1 : NULL, base, opt);
}
strbuf_setlen(base, old_baselen);
@@ -140,12 +140,10 @@ static void skip_uninteresting(struct tree_desc *t,
struct strbuf *base,
}
int __diff_tree_sha1(const unsigned char *old, const unsigned char *new,
-const char *base_str, struct diff_options *opt)
+struct strbuf *base, struct diff_options *opt)
{
struct tree_desc t1, t2;
void *t1tree, *t2tree;
- struct strbuf base;
- int baselen = strlen(base_str);
t1tree = fill_tree_descriptor(&t1, old);
t2tree = fill_tree_descriptor(&t2, new);
@@ -153,17 +151,14 @@ int __diff_tree_sha1(const unsigned char *old, const
unsigned char *new,
/* Enable recursion indefinitely */
opt->pathspec.recursive = DIFF_OPT_TST(opt, RECURSIVE);
- strbuf_init(&base, PATH_MAX);
- strbuf_add(&base, base_str, baselen);
-
for (;;) {
int cmp;
if (diff_can_quit_early(opt))
break;
if (opt->pathspec.nr) {
- skip_uninteresting(&t1, &base, opt);
- skip_uninteresting(&t2, &base, opt);
+ skip_uninteresting(&t1, base, opt);
+ skip_uninteresting(&t2, base, opt);
}
if (!t1.size && !t2.size)
break;
@@ -175,7 +170,7 @@ int __diff_tree_sha1(const unsigned char *old, const
unsigned char *new,
if (DIFF_OPT_TST(opt, FIND_COPIES_HARDER) ||
hashcmp(t1.entry.sha1, t2.entry.sha1) ||
(t1.entry.mode != t2.entry.mode))
- show_path(&base, opt, &t1, &t2);
+ show_path(base, opt, &t1, &t2);
update_tree_entry(&t1);
update_tree_entry(&t2);
@@ -183,18 +178,17 @@ int __diff_tree_sha1(const unsigned char *old, const
unsigned char *new,
/* t1 < t2 */
else if (cmp < 0) {
- show_path(&base, opt, &t1, /*t2=*/NULL);
+ show_path(base, opt, &t1, /*t2=*/NULL);
update_tree_entry(&t1);
}
/* t1 > t2 */
else {
- show_path(&base, opt, /*t1=*/NULL, &t2);
+ show_path(base, opt, /*t1=*/NULL, &t2);
update_tree_entry(&t2);
}
}
- strbuf_release(&base);
free(t2tree);
free(t1tree);
return 0;
@@ -211,7 +205,7 @@ static inline int diff_might_be_rename(void)
!DIFF_FILE_VALID(diff_queued_diff.queue[0]->one);
}
-static void try_to_follow_renames(const unsigned char *old, const unsigned
char *new, const char *base, struct diff_options *opt)
+static void try_to_follow_renames(const unsigned char *old, const unsigned
char *new, struct strbuf *base, struct diff_options *opt)
{
struct diff_options diff_opts;
struct diff_queue_struct *q = &diff_queued_diff;
@@ -308,13 +302,19 @@ static void try_to_follow_renames(const unsigned char
*old, const unsigne
[PATCH 08/11] tree-diff: remove special-case diff-emitting code for empty-tree cases
via teaching tree_entry_pathcmp() how to compare empty tree descriptors:
While walking trees, we iterate their entries from lowest to highest in
sort order, so empty tree means all entries were already went over.
If we artificially assign +infinity value to such tree "entry", it will
go after all usual entries, and through the usual driver loop we will be
taking the same actions, which were hand-coded for special cases, i.e.
t1 empty, t2 non-empty
pathcmp(+∞, t2) -> +1
show_path(/*t1=*/NULL, t2); /* = t1 > t2 case in main loop */
t1 non-empty, t2-empty
pathcmp(t1, +∞) -> -1
show_path(t1, /*t2=*/NULL); /* = t1 < t2 case in main loop */
Right now we never go to when compared tree descriptors are infinity, as
this condition is checked in the loop beginning as finishing criteria,
but will do in the future, when there will be several parents iterated
simultaneously, and some pair of them would run to the end.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 330ca07..7688402 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -12,12 +12,19 @@
*
* NOTE files and directories *always* compare differently, even when having
* the same name - thanks to base_name_compare().
+ *
+ * NOTE empty (=invalid) descriptor(s) take part in comparison as +infty.
*/
static int tree_entry_pathcmp(struct tree_desc *t1, struct tree_desc *t2)
{
struct name_entry *e1, *e2;
int cmp;
+ if (!t1->size)
+ return t2->size ? +1 /* +∞ > c */ : 0 /* +∞ = +∞ */;
+ else if (!t2->size)
+ return -1; /* c < +∞ */
+
e1 = &t1->entry;
e2 = &t2->entry;
cmp = base_name_compare(e1->path, tree_entry_len(e1), e1->mode,
@@ -153,18 +160,8 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
skip_uninteresting(t1, &base, opt);
skip_uninteresting(t2, &base, opt);
}
- if (!t1->size) {
- if (!t2->size)
- break;
- show_path(&base, opt, /*t1=*/NULL, t2);
- update_tree_entry(t2);
- continue;
- }
- if (!t2->size) {
- show_path(&base, opt, t1, /*t2=*/NULL);
- update_tree_entry(t1);
- continue;
- }
+ if (!t1->size && !t2->size)
+ break;
cmp = tree_entry_pathcmp(t1, t2);
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] tree-diff: simplify tree_entry_pathcmp
Since 74aa4a18 (Finally switch over tree descriptors to contain a
pre-parsed entry) we can safely access all tree_desc->entry fields directly
instead of first "extracting" them through tree_entry_extract.
Use it. The code generated stays the same - only it now visually looks
cleaner.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 604dc57..330ca07 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -15,18 +15,13 @@
*/
static int tree_entry_pathcmp(struct tree_desc *t1, struct tree_desc *t2)
{
- unsigned mode1, mode2;
- const char *path1, *path2;
- const unsigned char *sha1, *sha2;
- int cmp, pathlen1, pathlen2;
+ struct name_entry *e1, *e2;
+ int cmp;
- sha1 = tree_entry_extract(t1, &path1, &mode1);
- sha2 = tree_entry_extract(t2, &path2, &mode2);
-
- pathlen1 = tree_entry_len(&t1->entry);
- pathlen2 = tree_entry_len(&t2->entry);
-
- cmp = base_name_compare(path1, pathlen1, mode1, path2, pathlen2, mode2);
+ e1 = &t1->entry;
+ e2 = &t2->entry;
+ cmp = base_name_compare(e1->path, tree_entry_len(e1), e1->mode,
+ e2->path, tree_entry_len(e2), e2->mode);
return cmp;
}
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] fetch-pack: fix deepen shallow over smart http with no-done cap
Nguyễn Thái Ngọc Duy writes: > diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh > index b0fa738..fb11073 100755 > --- a/t/t5537-fetch-shallow.sh > +++ b/t/t5537-fetch-shallow.sh > @@ -200,5 +200,29 @@ EOF > ) > ' > > +# This test is tricky. We need large enough "have"s that fetch-pack > +# will put pkt-flush in between. Then we need a "have" the the server > +# does not have, it'll send "ACK %s ready" > +test_expect_success 'add more commits' ' > + ( > + cd shallow && > + for i in $(seq 10); do > + git checkout --orphan unrelated$i && > + test_commit unrelated$i >/dev/null && > + git push -q "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" > refs/heads/unrelated$i:refs/heads/unrelated$i > + git push -q ../clone/.git refs/heads/unrelated$i:refs/heads/unrelated$i In addition to two problems Eric and Peff noticed, && chain is broken between these two pushes. I initially didn't notice it but it became obvious after reformatting to fix the indentation. Here is the difference between the posted series and what I queued after applying the changes suggested during the review. Thanks. Documentation/technical/pack-protocol.txt | 4 +-- Documentation/technical/protocol-capabilities.txt | 10 +++ t/t5537-fetch-shallow.sh | 34 +-- 3 files changed, 26 insertions(+), 22 deletions(-) diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index eb0b8a1..39c6410 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -338,8 +338,8 @@ during a prior round. This helps to ensure that at least one common ancestor is found before we give up entirely. Once the 'done' line is read from the client, the server will either -send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the -last SHA-1 determined to be common. The server only sends +send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object +name of the last commit determined to be common. The server only sends ACK after 'done' if there is at least one common base and multi_ack or multi_ack_detailed is enabled. The server always sends NAK after 'done' if there is no common base found. diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index cb2f5eb..e174343 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -77,15 +77,15 @@ section "Packfile Negotiation" for more information. no-done --- -This capability should be only used with smart HTTP protocol. If +This capability should only be used with the smart HTTP protocol. If multi_ack_detailed and no-done are both present, then the sender is free to immediately send a pack following its first "ACK obj-id ready" message. -Without no-done in smart HTTP protocol, the server session would end -and the client has to make another trip to send "done" and the server -can send the pack. no-done removes the last round and thus slightly -reduces latency. +Without no-done in the smart HTTP protocol, the server session would +end and the client has to make another trip to send "done" before +the server can send the pack. no-done removes the last round and +thus slightly reduces latency. thin-pack - diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh index fb11073..1413caf 100755 --- a/t/t5537-fetch-shallow.sh +++ b/t/t5537-fetch-shallow.sh @@ -201,26 +201,30 @@ EOF ' # This test is tricky. We need large enough "have"s that fetch-pack -# will put pkt-flush in between. Then we need a "have" the the server +# will put pkt-flush in between. Then we need a "have" the server # does not have, it'll send "ACK %s ready" test_expect_success 'add more commits' ' ( - cd shallow && - for i in $(seq 10); do - git checkout --orphan unrelated$i && - test_commit unrelated$i >/dev/null && - git push -q "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" refs/heads/unrelated$i:refs/heads/unrelated$i - git push -q ../clone/.git refs/heads/unrelated$i:refs/heads/unrelated$i - done && - git checkout master && - test_commit new && - git push "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" master + cd shallow && + for i in $(test_seq 10) + do + git checkout --orphan unrelated$i && + test_commit unrelated$i && + git push -q "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" \ + refs/heads/unrelated$i:refs/heads/unrelated$i && + git push -q ../clone/.git \ + refs/heads/unrelated$i:refs/heads/unrelated$i || + exit 1 + done && + git checkout master && + test_commit new && +
Re: [PATCH v5 07/14] trailer: add interpret-trailers command
Christian Couder writes:
> On Fri, Feb 7, 2014 at 1:10 AM, Junio C Hamano wrote:
>> Christian Couder writes:
>>
>>> diff --git a/git.c b/git.c
>>> index 3799514..1420b58 100644
>>> --- a/git.c
>>> +++ b/git.c
>>> @@ -383,6 +383,7 @@ static void handle_internal_command(int argc, const
>>> char **argv)
>>> { "index-pack", cmd_index_pack, RUN_SETUP_GENTLY },
>>> { "init", cmd_init_db },
>>> { "init-db", cmd_init_db },
>>> + { "interpret-trailers", cmd_interpret_trailers, RUN_SETUP },
>>> { "log", cmd_log, RUN_SETUP },
>>> { "ls-files", cmd_ls_files, RUN_SETUP },
>>> { "ls-remote", cmd_ls_remote, RUN_SETUP_GENTLY },
>>
>> Does this even need to have a git repository? What is the RUN_SETUP
>> for?
>
> It needs to read git config files, but it could work without reading them too.
> I will have another look at it.
Of course. At this point in the series while reviewing 7/14 there
was no config [*1*] and that was why I was scratching my head.
[Footnote]
*1* Flipping the series structure to a top-down fashion, having an
almost no-op command that fails all the new tests in the beginning
and then building the internal incrementally, might be a worthwhile
change, but it is *not* worth the effort to add the command without
RUN_SETUP at 7/14 and then change the same line to have RUN_SETUP
when you start to need it could be an option; I am *not* suggesting
that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] tree-diff: rename compare_tree_entry -> tree_entry_pathcmp
Since previous commit, this function does not compare entry hashes, and
mode are compared fully outside of it. So what it does is compare entry
names and DIR bit in modes. Reflect this in its name.
Add documentation stating the semantics, and move the note about
files/dirs comparison to it.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 54a3d23..df90bbe 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -9,7 +9,14 @@
static void show_path(struct strbuf *base, struct diff_options *opt,
struct tree_desc *t1, struct tree_desc *t2);
-static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2)
+/*
+ * Compare two tree entries, taking into account only path/S_ISDIR(mode),
+ * but not their sha1's.
+ *
+ * NOTE files and directories *always* compare differently, even when having
+ * the same name - thanks to base_name_compare().
+ */
+static int tree_entry_pathcmp(struct tree_desc *t1, struct tree_desc *t2)
{
unsigned mode1, mode2;
const char *path1, *path2;
@@ -22,10 +29,6 @@ static int compare_tree_entry(struct tree_desc *t1, struct
tree_desc *t2)
pathlen1 = tree_entry_len(&t1->entry);
pathlen2 = tree_entry_len(&t2->entry);
- /*
-* NOTE files and directories *always* compare differently,
-* even when having the same name.
-*/
cmp = base_name_compare(path1, pathlen1, mode1, path2, pathlen2, mode2);
return cmp;
}
@@ -171,7 +174,7 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
continue;
}
- cmp = compare_tree_entry(t1, t2);
+ cmp = tree_entry_pathcmp(t1, t2);
/* t1 = t2 */
if (cmp == 0) {
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/14] trailer: execute command from 'trailer..command'
Christian Couder writes: > Signed-off-by: Christian Couder "execute command from ..." is fine, but I wish there were more details before S-o-b line. Is is not worth explaining what happens to the output, and what the facility is used for in general? Is it to give a string used for the value part? "Key: Value" string? Is the command allowed to say "Put an entry with this string before the existing one, after the existing one, or replace the existing one"? Can it say "Upon inspection of the existing entry, it is no longer necessary to have it in the footer---remove it"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Fix the shallow deepen bug with no-done
Duy Nguyen wrote: > Don't take it the wrong way. I was just summarizing the last round. It > surprised me though that this went under my radar. Perhaps a bug > tracker is not a bad idea after all (if Jeff went missing, this bug > could fall under the crack) I'm happy to plug - http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=git;include=tags:upstream - http://packages.qa.debian.org/common/index.html (email subscription link: source package = git; under "Advanced" it's possible to subscribe to bug-tracking system emails and skip e.g. the automated build stuff) - https://www.debian.org/Bugs/Reporting (bug reporting interface - unfortunately the important part is buried under "Sending the bug report via e-mail") again. :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Fix the shallow deepen bug with no-done
Jonathan Nieder writes: > Duy Nguyen wrote: > >> Don't take it the wrong way. I was just summarizing the last round. It >> surprised me though that this went under my radar. Perhaps a bug >> tracker is not a bad idea after all (if Jeff went missing, this bug >> could fall under the crack) > > I'm happy to plug > - http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=git;include=tags:upstream > - http://packages.qa.debian.org/common/index.html (email subscription link: > source package = git; under "Advanced" it's possible to subscribe to > bug-tracking system emails and skip e.g. the automated build stuff) > - https://www.debian.org/Bugs/Reporting (bug reporting interface - > unfortunately the important part is buried under "Sending the bug > report via e-mail") > again. :) Then I'd add my bits ;-) http://git-blame.blogspot.com/p/leftover-bits.html Admittedly I haven't touched it for a while, as I usually update it during a lull, often in the pre-release -rc freeze period, but the list has been quite active during -rc this cycle. I probably should start dropping any new topics on the list and find leftover bits during this cycle. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] tree-diff: show_tree() is not needed
We don't need special code for showing added/removed subtree, because we
can do the same via diff_tree_sha1, just passing NULL for absent tree.
And compared to show_tree(), which was calling show_entry() for every
tree entry, that would lead to the same show_entry() callings:
show_tree(t):
for e in t.entries:
show_entry(e)
diff_tree_sha1(NULL, new): /* the same applies to (old, NULL) */
diff_tree(t1=NULL, t2)
...
if (!t1->size)
show_entry(t2)
...
and possible overhead is negligible, since after the patch, timing for
`git log --raw --no-abbrev --no-renames`
for navy.git and `linux.git v3.10..v3.11` is practically the same.
So let's say goodbye to show_tree() - it removes some code, but also,
and what is important, consolidates more code for showing/recursing into
trees into one place.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 35 +++
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index a8c2aec..2ad7788 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -55,25 +55,7 @@ static int compare_tree_entry(struct tree_desc *t1, struct
tree_desc *t2,
return 0;
}
-/* A whole sub-tree went away or appeared */
-static void show_tree(struct diff_options *opt, const char *prefix,
- struct tree_desc *desc, struct strbuf *base)
-{
- enum interesting match = entry_not_interesting;
- for (; desc->size; update_tree_entry(desc)) {
- if (match != all_entries_interesting) {
- match = tree_entry_interesting(&desc->entry, base, 0,
- &opt->pathspec);
- if (match == all_entries_not_interesting)
- break;
- if (match == entry_not_interesting)
- continue;
- }
- show_entry(opt, prefix, desc, base);
- }
-}
-
-/* A file entry went away or appeared */
+/* An entry went away or appeared */
static void show_entry(struct diff_options *opt, const char *prefix,
struct tree_desc *desc, struct strbuf *base)
{
@@ -85,23 +67,12 @@ static void show_entry(struct diff_options *opt, const char
*prefix,
strbuf_add(base, path, pathlen);
if (DIFF_OPT_TST(opt, RECURSIVE) && S_ISDIR(mode)) {
- enum object_type type;
- struct tree_desc inner;
- void *tree;
- unsigned long size;
-
- tree = read_sha1_file(sha1, &type, &size);
- if (!tree || type != OBJ_TREE)
- die("corrupt tree sha %s", sha1_to_hex(sha1));
-
if (DIFF_OPT_TST(opt, TREE_IN_RECURSIVE))
opt->add_remove(opt, *prefix, mode, sha1, 1, base->buf,
0);
strbuf_addch(base, '/');
-
- init_tree_desc(&inner, tree, size);
- show_tree(opt, prefix, &inner, base);
- free(tree);
+ diff_tree_sha1(*prefix == '-' ? sha1 : NULL,
+ *prefix == '+' ? sha1 : NULL, base->buf, opt);
} else
opt->add_remove(opt, prefix[0], mode, sha1, 1, base->buf, 0);
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] tree-diff: move all action-taking code out of compare_tree_entry()
- let it do only comparison.
This way the code is cleaner and more structured - cmp function only
compares, and the driver takes action based on comparison result.
There should be no change in performance, as effectively, we just move
if series from on place into another, and merge it to was-already-there
same switch/if, so the result is maybe a little bit faster.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index c3fbfba..54a3d23 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -9,8 +9,7 @@
static void show_path(struct strbuf *base, struct diff_options *opt,
struct tree_desc *t1, struct tree_desc *t2);
-static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2,
- struct strbuf *base, struct diff_options *opt)
+static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2)
{
unsigned mode1, mode2;
const char *path1, *path2;
@@ -28,19 +27,7 @@ static int compare_tree_entry(struct tree_desc *t1, struct
tree_desc *t2,
* even when having the same name.
*/
cmp = base_name_compare(path1, pathlen1, mode1, path2, pathlen2, mode2);
- if (cmp < 0) {
- show_path(base, opt, t1, /*t2=*/NULL);
- return -1;
- }
- if (cmp > 0) {
- show_path(base, opt, /*t1=*/NULL, t2);
- return 1;
- }
- if (!DIFF_OPT_TST(opt, FIND_COPIES_HARDER) && !hashcmp(sha1, sha2) &&
mode1 == mode2)
- return 0;
-
- show_path(base, opt, t1, t2);
- return 0;
+ return cmp;
}
@@ -163,6 +150,8 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
strbuf_add(&base, base_str, baselen);
for (;;) {
+ int cmp;
+
if (diff_can_quit_early(opt))
break;
if (opt->pathspec.nr) {
@@ -182,21 +171,28 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
continue;
}
- cmp = compare_tree_entry(t1, t2, &base, opt);
+ cmp = compare_tree_entry(t1, t2);
/* t1 = t2 */
if (cmp == 0) {
+ if (DIFF_OPT_TST(opt, FIND_COPIES_HARDER) ||
+ hashcmp(t1->entry.sha1, t2->entry.sha1) ||
+ (t1->entry.mode != t2->entry.mode))
+ show_path(&base, opt, t1, t2);
+
update_tree_entry(t1);
update_tree_entry(t2);
}
/* t1 < t2 */
else if (cmp < 0) {
+ show_path(&base, opt, t1, /*t2=*/NULL);
update_tree_entry(t1);
}
/* t1 > t2 */
else {
+ show_path(&base, opt, /*t1=*/NULL, t2);
update_tree_entry(t2);
}
}
--
1.9.rc1.181.g641f458
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] tree-diff: consolidate code for emitting diffs and recursion in one place
Currently both compare_tree_entry() and show_path() invoke opt diff
callbacks (opt->add_remove() and opt->change()), and also they both have
code which decides whether to recurse into sub-tree, and whether to emit
a tree as separate entry if DIFF_OPT_TREE_IN_RECURSIVE is set.
I.e. we have code duplication and logic scattered on two places.
Let's consolidate it - all diff emmiting code and recurion logic moves
to show_entry, which is now named as show_path, because it shows diff
for a path, based on up to two tree entries, with actual diff emitting
code being kept in new helper emit_diff() for clarity.
What we have as the result, is that compare_tree_entry is now free from
code with logic for diff generation, and also performance is not
affected as timings for
`git log --raw --no-abbrev --no-renames`
for navy.git and `linux.git v3.10..v3.11`, just like in previous patch,
stay the same.
Signed-off-by: Kirill Smelkov
---
tree-diff.c | 117
1 file changed, 86 insertions(+), 31 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 2ad7788..0c8e3fc 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -6,8 +6,8 @@
#include "diffcore.h"
#include "tree.h"
-static void show_entry(struct diff_options *opt, const char *prefix,
- struct tree_desc *desc, struct strbuf *base);
+static void show_path(struct strbuf *base, struct diff_options *opt,
+ struct tree_desc *t1, struct tree_desc *t2);
static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2,
struct strbuf *base, struct diff_options *opt)
@@ -16,7 +16,6 @@ static int compare_tree_entry(struct tree_desc *t1, struct
tree_desc *t2,
const char *path1, *path2;
const unsigned char *sha1, *sha2;
int cmp, pathlen1, pathlen2;
- int old_baselen = base->len;
sha1 = tree_entry_extract(t1, &path1, &mode1);
sha2 = tree_entry_extract(t2, &path2, &mode2);
@@ -30,51 +29,107 @@ static int compare_tree_entry(struct tree_desc *t1, struct
tree_desc *t2,
*/
cmp = base_name_compare(path1, pathlen1, mode1, path2, pathlen2, mode2);
if (cmp < 0) {
- show_entry(opt, "-", t1, base);
+ show_path(base, opt, t1, /*t2=*/NULL);
return -1;
}
if (cmp > 0) {
- show_entry(opt, "+", t2, base);
+ show_path(base, opt, /*t1=*/NULL, t2);
return 1;
}
if (!DIFF_OPT_TST(opt, FIND_COPIES_HARDER) && !hashcmp(sha1, sha2) &&
mode1 == mode2)
return 0;
- strbuf_add(base, path1, pathlen1);
- if (DIFF_OPT_TST(opt, RECURSIVE) && S_ISDIR(mode1)) {
- if (DIFF_OPT_TST(opt, TREE_IN_RECURSIVE)) {
- opt->change(opt, mode1, mode2,
- sha1, sha2, 1, 1, base->buf, 0, 0);
- }
- strbuf_addch(base, '/');
- diff_tree_sha1(sha1, sha2, base->buf, opt);
- } else {
- opt->change(opt, mode1, mode2, sha1, sha2, 1, 1, base->buf, 0,
0);
- }
- strbuf_setlen(base, old_baselen);
+ show_path(base, opt, t1, t2);
return 0;
}
-/* An entry went away or appeared */
-static void show_entry(struct diff_options *opt, const char *prefix,
- struct tree_desc *desc, struct strbuf *base)
+
+/* convert path, t1/t2 -> opt->diff_*() callbacks */
+static void emit_diff(struct diff_options *opt, struct strbuf *path,
+ struct tree_desc *t1, struct tree_desc *t2)
+{
+ unsigned int mode1 = t1 ? t1->entry.mode : 0;
+ unsigned int mode2 = t2 ? t2->entry.mode : 0;
+
+ if (mode1 && mode2) {
+ opt->change(opt, mode1, mode2, t1->entry.sha1, t2->entry.sha1,
+ 1, 1, path->buf, 0, 0);
+ }
+ else {
+ const unsigned char *sha1;
+ unsigned int mode;
+ int addremove;
+
+ if (mode2) {
+ addremove = '+';
+ sha1 = t2->entry.sha1;
+ mode = mode2;
+ }
+ else {
+ addremove = '-';
+ sha1 = t1->entry.sha1;
+ mode = mode1;
+ }
+
+ opt->add_remove(opt, addremove, mode, sha1, 1, path->buf, 0);
+ }
+}
+
+
+/* new path should be added to diff
+ *
+ * 3 cases on how/when it should be called and behaves:
+ *
+ * !t1, t2-> path added, parent lacks it
+ * t1, !t2-> path removed from parent
+ * t1, t2-> path modified
+ */
+static void show_path(struct strbuf *base, struct diff_options *opt,
+ struct tree_desc *t1, struct tree_desc *t2)
{
unsigned mode;
const char *path;
- const unsigned char *sha1 = tree_entry_extract(de
Re: [PATCH v5 07/14] trailer: add interpret-trailers command
Junio C Hamano writes: > ... RUN_SETUP at 7/14 and then change the same line to have RUN_SETUP > when you start to need it could be an option; I am *not* suggesting > that. Sorry, typo. s/could be an option;/;/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Git Directory Diff for submodule
Am 07.02.2014 10:15, schrieb Gábor Lipták: > I think I have found a bug related to submodules and directory diff. > See the details at hXXp://stackoverflow.com/q/21623155/337621. Let's inline the recipe one finds after decrypting this link: ~/Projects/MAINMODULE/platform/SUBMODULE [master]$ git difftool -tool=meld --dir-diff --cached fatal: Could not switch to '../../../../platform/': No such file or directory diff --raw --no-abbrev -z --cached: command returned error: 128 ~/Projects/MAINMODULE/platform/SUBMODULE [master]$ cd .. ~/Projects/MAINMODULE/platform [master]$ cd .. ~/Projects/MAINMODULE [master]$ git difftool -tool=meld --dir-diff --cached // NO PROBLEM, works. ~/Projects/MAINMODULE [master]$ git version git version 1.8.4 > If you need any further details, just ask. - Does this only happen when you use difftool? E.g. what does "git status" inside the submodule say? - What does "git config core.worktree" print when run in the submodule? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Feb 2014, #03; Fri, 7)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'master' has been tagged as v1.9.0-rc3. As a workaround
to make life easier for third-party tools, the upcoming major
release will be called "Git 1.9.0" (not "Git 1.9"). The first
maintenance release for it will be "Git 1.9.1", and the major
release after "Git 1.9.0" will either be "Git 2.0.0" or "Git
1.10.0".
The list ended up relatively active during the pre-release feature
freeze period in this cycle, and we still see new topics appearing
for the next cycle. I do not know if that is a good thing or not.
Let's spend some time to ensure that there is no brown paper bag
bugs remaining on the master front until the final, scheduled to
happen sometime late next week.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to "master"]
* aj/ada-diff-word-pattern (2014-02-05) 1 commit
(merged to 'next' on 2014-02-06 at 8062b22)
+ userdiff: update Ada patterns
* nd/tag-doc (2014-02-04) 1 commit
(merged to 'next' on 2014-02-06 at 9f02991)
+ git-tag.txt: for --contains is optional
* ow/manpages-typofix (2014-02-05) 1 commit
(merged to 'next' on 2014-02-06 at b482b8f)
+ Documentation: fix typos in man pages
--
[New Topics]
* jc/check-attr-honor-working-tree (2014-02-06) 2 commits
- check-attr: move to the top of working tree when in non-bare repository
- t0003: do not chdir the whole test process
"git check-attr" when (trying to) work on a repository with a
working tree did not work well when the working tree was specified
via --work-tree (and obviously with --git-dir).
The command also works in a bare repository but it reads from the
(possibly stale, irrelevant and/or nonexistent) index, which may
need to be fixed to read from HEAD, but that is a completely
separate issue. As a related tangentto this separate issue, we may
want to also fix "check-ignore", which refuses to work in a bare
repository, to also operate in a bare one.
* nd/http-fetch-shallow-fix (2014-02-07) 6 commits
- fetch-pack: fix deepen shallow over smart http with no-done cap
- protocol-capabilities.txt: document no-done
- protocol-capabilities.txt: refer multi_ack_detailed back to pack-protocol.txt
- pack-protocol.txt: clarify 'obj-id' in the last ACK after 'done'
- t5538: fix default http port
- test: rename http fetch and push test files
Attempting to deepen a shallow repository by fetching over smart
HTTP transport failed in the protocol exchange, when no-done
extension was used. The fetching side waited for the list of
shallow boundary commits after the sending end stopped talking to
it.
Will merge to 'next'.
--
[Stalled]
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
also its contents are a bit stale. It may be a good first step in
the right direction, but needs more work to at least get the
mark-up right before public consumption.
Will hold.
* jk/branch-at-publish-rebased (2014-01-17) 5 commits
- t1507 (rev-parse-upstream): fix typo in test title
- implement @{publish} shorthand
- branch_get: provide per-branch pushremote pointers
- branch_get: return early on error
- sha1_name: refactor upstream_mark
Give an easier access to the tracking branches from "other" side in
a triangular workflow by introducing B@{publish} that works in a
similar way to how B@{upstream} does.
Meant to be used as a basis for whatever Ram wants to build on.
Will hold.
* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits
- merge: drop unused arg from abort_commit method signature
- merge: make prepare_to_commit responsible for write_merge_state
- t7505: ensure cleanup after hook blocks merge
- t7505: add missing &&
Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
run during "git merge". The log message stresses too much on one
hook, prepare-commit-msg, but it would equally apply to other hooks
like post-merge, I think.
Waiting for a reroll.
* jl/submodule-recursive-checkout (2013-12-26) 5 commits
- Teach checkout to recursively checkout submodules
- submodule: teach unpack_trees() to update submodules
- submodule: teach unpack_trees() to repopulate submodules
- submodule: teach unpack_trees() to remove submodule contents
- submodule: prepare for recursive checkout of submodules
Expecting a reroll.
* jc/graph-post-root-gap (2013-12-30) 3 commits
- WIP: document what we want at the end
- graph: remove unused code a bit
- graph: stuff the current commit into gra
[ANNOUNCE] Git v1.9.0-rc3
A release candidate Git v1.9.0-rc3 is now available for testing at the usual places. Hopefully this will be the last one before the final, scheduled to happen sometime late next week. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: ed28a6dd2610f9f6052ce52f2eb6ab1db070a637 git-1.9.0.rc3.tar.gz 7512d3f0e2572face34416c2b9fda2385d490c82 git-htmldocs-1.9.0.rc3.tar.gz aac8cb1379f2d5e416db31a40ffb86deec902acc git-manpages-1.9.0.rc3.tar.gz The following public repositories all have a copy of the v1.9.0-rc3 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.9 Release Notes (draft) == Backward compatibility notes "git submodule foreach $cmd $args" used to treat "$cmd $args" the same way "ssh" did, concatenating them into a single string and letting the shell unquote. Careless users who forget to sufficiently quote $args gets their argument split at $IFS whitespaces by the shell, and got unexpected results due to this. Starting from this release, the command line is passed directly to the shell, if it has an argument. Read-only support for experimental loose-object format, in which users could optionally choose to write in their loose objects for a short while between v1.4.3 to v1.5.3 era, has been dropped. The meanings of "--tags" option to "git fetch" has changed; the command fetches tags _in addition to_ what are fetched by the same command line without the option. The way "git push $there $what" interprets $what part given on the command line, when it does not have a colon that explicitly tells us what ref at the $there repository is to be updated, has been enhanced. A handful of ancient commands that have long been deprecated are finally gone (repo-config, tar-tree, lost-found, and peek-remote). Backward compatibility notes (for Git 2.0) -- When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the "simple" semantics, which pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable "push.default" to change this. If you are an old-timer who is used to the "matching" semantics, you can set the variable to "matching" to keep the traditional behaviour. If you want to live in the future early, you can set it to "simple" today without waiting for Git 2.0. When "git add -u" (and "git add -A") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. The default prefix for "git svn" will change in Git 2.0. For a long time, "git svn" created its remote-tracking branches directly under refs/remotes, but it will place them under refs/remotes/origin/ unless it is told otherwise with its --prefix option. Updates since v1.8.5 Foreign interfaces, subsystems and ports. * The HTTP transport, when talking GSS-Negotiate, uses "100 Continue" response to avoid having to rewind and resend a large payload, which may not be always doable. * Various bugfixes to remote-bzr and remote-hg (in contrib/). * The build procedure is aware of MirBSD now. * Various "git p4", "git svn" and "gitk" updates. UI, Workflows & Features * Fetching from a shallowly-cloned
Re: [WIP/PATCH 1/9] submodule: prepare for recursive checkout of submodules
Am 04.02.2014 01:01, schrieb Jonathan Nieder:
> Jens Lehmann wrote:
>> --- /dev/null
>> +++ b/Documentation/recurse-submodules-update.txt
>> @@ -0,0 +1,8 @@
>> +--[no-]recurse-submodules::
>> +Using --recurse-submodules will update the work tree of all
>> +initialized submodules according to the commit recorded in the
>> +superproject if their update configuration is set to checkout'. If
>> +local modifications in a submodule would be overwritten the checkout
>> +will fail unless forced. Without this option or with
>> +--no-recurse-submodules is, the work trees of submodules will not be
>> +updated, only the hash recorded in the superproject will be updated.
>
> Tweaks:
>
> * Spelling out "--no-recurse-submodules, --recurse-submodules" (imitating
>e.g. --decorate in git-log(1))
>
> * Shortening, using imperative mood
>
> * Skipping description of safety check, since it matches how checkout
>works in general
>
> That would make
>
> --no-recurse-submodules::
> --recurse-submodules::
> Perform the checkout in submodules, too. This only affects
> submodules with update strategy `checkout` (which is the
> default update strategy; see `submodule..update` in
> link:gitmodules[5]).
> +
> The default behavior is to update submodule entries in the superproject
> index and to leave the inside of submodules alone. That behavior can
> also
> be requested explicitly with --no-recurse-submodules.
Much better, thanks!
> Ideas for further work:
>
> * The safety check probably deserves a new section where it could be
>described in detail alongside a description of the corresponding check
>for plain checkout. Then the description of the -f option could
>point to that section.
Good idea.
> * What happens when update = merge, rebase, or !command? I think
>skipping them for now like suggested above is fine, but:
>
>- It would be even better to error out when there are changes to carry
> over with update = merge or rebase
In the first round I'd rather do nothing (just like we do now) for merge
or rebase. These two should be tackled in a follow up series (especially
as I currently do not think everybody agrees on the desired behavior when
the branch config is set yet)
>- Better still to perform the rebase when update = rebase
>
>- I have no idea what update = merge should do for non-fast-forward
> moves
The same it does for checkout when we would overwrite local changes:
error out before doing anything and let the user sort things out?
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -16,6 +16,8 @@ static struct string_list config_name_for_path;
>> static struct string_list config_fetch_recurse_submodules_for_name;
>> static struct string_list config_ignore_for_name;
>> static int config_fetch_recurse_submodules = RECURSE_SUBMODULES_ON_DEMAND;
>> +static int config_update_recurse_submodules = RECURSE_SUBMODULES_OFF;
>> +static int option_update_recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
>
> Confusingly, config_update_recurse_submodules is set using the
> --recurse-submodules-default option, not configuration. There's
> precedent for that in fetch.recurseSubmodules handling, but perhaps
> a comment would help --- something like
>
> /*
>* When no --recurse-submodules option was passed, should git fetch
>* from submodules where submodule..fetchRecurseSubmodules
>* doesn't indicate what to do?
>*
>* Controlled by fetch.recurseSubmodules. The default is determined by
>* the --recurse-submodules-default option, which propagates
>* --recurse-submodules from the parent git process when recursing.
>*/
> static int config_fetch_recurse_submodules =
> RECURSE_SUBMODULES_ON_DEMAND;
>
> /*
>* When no --recurse-submodules option was passed, should git update
>* the index and worktree within submodules (and in turn their
>* submodules, etc)?
>*
>* Controlled by the --recurse-submodules-default option, which
>* propagates --recurse-submodules from the parent git process
>* when recursing.
>*/
> static int config_update_recurse_submodules = RECURSE_SUBMODULES_OFF;
Makes lots of sense.
> [...]
>> @@ -382,6 +384,48 @@ int parse_fetch_recurse_submodules_arg(const char *opt,
>> const char *arg)
>> }
>> }
>>
>> +int parse_update_recurse_submodules_arg(const char *opt, const char *arg)
>> +{
>> +switch (git_config_maybe_bool(opt, arg)) {
>> +case 1:
>> +return RECURSE_SUBMODULES_ON;
>> +case 0:
>> +return RECURSE_SUBMODULES_OFF;
>> +default:
>> +if (!strcmp(arg, "checkout"))
>> +return RECURSE_SUBMODULES_ON;
>
> Hm, is this arg == checkout case futureproofing for when
> --recurse-submodules learns to handle submodules
Re: [WIP/PATCH 1/9] submodule: prepare for recursive checkout of submodules
Am 03.02.2014 23:23, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> This commit adds the functions and files needed for configuration,
>
> Please just say "Add the functions and files needed for ...".
Roger that.
>> +++ b/Documentation/recurse-submodules-update.txt
>> @@ -0,0 +1,8 @@
>> +--[no-]recurse-submodules::
>> +Using --recurse-submodules will update the work tree of all
>> +initialized submodules according to the commit recorded in the
>> +superproject if their update configuration is set to checkout'. If
>
> That single quote does not seem to be closing any matching quote.
>
> The phrase "according to" feels a bit too fuzzy. Merging the commit
> to what is checked out is one possible implementation of "according to".
> Applying the diff between the commit and what is checked out to work
> tree is another. Resetting the work tree files to exactly match the
> commit would be yet another.
>
> I think "update the work trees to the commit" (i.e. lose the
> "according") would be the closest to what you are trying to say
> here.
>
>> +local modifications in a submodule would be overwritten the checkout
>> +will fail unless forced. Without this option or with
>> +--no-recurse-submodules is, the work trees of submodules will not be
>> +updated, only the hash recorded in the superproject will be updated.
>
> It is unclear what happens if their update configuration is set to
> something other than 'checkout'.
Jonathan already proposed a better description, will use that in the next
round.
>> diff --git a/submodule.c b/submodule.c
>> index 613857e..b3eb28d 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -382,6 +384,48 @@ int parse_fetch_recurse_submodules_arg(const char *opt,
>> const char *arg)
>> ...
>> +int option_parse_update_submodules(const struct option *opt,
>> + const char *arg, int unset)
>> +{
>> +if (unset) {
>> +*(int *)opt->value = RECURSE_SUBMODULES_OFF;
>> +} else {
>> +if (arg)
>> +*(int *)opt->value =
>> parse_update_recurse_submodules_arg(opt->long_name, arg);
>> +else
>> +*(int *)opt->value = RECURSE_SUBMODULES_ON;
>> +}
>
> You can easily unnest to lose {}
>
> if (unset)
> value = off;
> else if (arg)
> value = parse...;
> else
> value = on;
Yeah, that's better.
> Also I suspect that git_config_maybe_bool() natively knows how to
> handle arg==NULL, so
>
> if (unset)
> value = off;
> else
> value = parse...;
>
> is sufficient?
Will try.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 2/9] Teach reset the --[no-]recurse-submodules option
Am 03.02.2014 23:40, schrieb Junio C Hamano: > Jens Lehmann writes: > >> This new option will allow the user to not only reset the work tree of >> the superproject but to also update the work tree of all initialized >> submodules (so they match the SHA-1 recorded in the superproject) when >> used together with --hard or --merge. But this commit only adds the > > I agree that --soft and --mixed should not do anything. I am not > sure why --keep should not do anything to submodule working trees > when asked to recurse, though. Correct, I missed that option. I think it should update submodules too. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitweb: Added syntax highlight support for golang
Golang is quickly becoming one of the major programming languages.
This change switches on golang syntax highlight support by default
in gitweb rather than asking the users to do it using config files.
Signed-off-by: Pavan Kumar Sunkara
---
gitweb/gitweb.perl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bf7fd67..aa6fcfd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -273,7 +273,7 @@ our %highlight_basename = (
our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
- (map { $_ => $_ } qw(py rb java css js tex bib xml awk bat ini spec tcl
sql)),
+ (map { $_ => $_ } qw(py rb java go css js tex bib xml awk bat ini spec
tcl sql)),
# alternate extensions, see /etc/highlight/filetypes.conf
(map { $_ => 'c' } qw(c h)),
(map { $_ => 'sh' } qw(sh bash zsh ksh)),
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 3/9] Teach checkout the --[no-]recurse-submodules option
Am 03.02.2014 23:56, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> +set_config_update_recurse_submodules(
>> +
>> parse_update_recurse_submodules_arg("--recurse-submodules-default",
>> +recurse_submodules_default),
>> +recurse_submodules);
>
> I think I saw these exact lines in another patch. Perhaps the whole
> thing can become a helper function that lets the caller avoid typing
> the whole long strings that needs a strange/unfortunate line break?
Right, that'd be better.
>> diff --git a/t/t2013-checkout-submodule.sh b/t/t2013-checkout-submodule.sh
>> index 06b18f8..bc3e1ca 100755
>> --- a/t/t2013-checkout-submodule.sh
>> +++ b/t/t2013-checkout-submodule.sh
>> @@ -4,17 +4,57 @@ test_description='checkout can handle submodules'
>>
>> . ./test-lib.sh
>>
>> +submodule_creation_must_succeed() {
>
> Style: SP before (), i.e.
>
> submodule_creation_must_succeed () {
>
>> +# checkout base ($1)
>> +git checkout -f --recurse-submodules $1 &&
>> +git diff-files --quiet &&
>> +git diff-index --quiet --cached $1 &&
>
> Please make it a habit to quote a parameter that is intended not to
> be split at $IFS (e.g. write these as "$1" not as $1). Otherwise
> the reader has to wonder if this can be called with a "foo bar" and
> the expects it to be split into two.
>
>> +# checkout target ($2)
>> +if test -d submodule; then
>
> Style: no semicolons in standard control structure, i.e.
>
> if test -d submodule
> then
>
>> +echo change>>submodule/first.t &&
>
> Style: SP before but not after redirection operator, i.e.
>
> echo foo >>bar
>
>> +submodule_removal_must_succeed() {
>
> Likewise.
>
>> +# checkout base ($1)
>> +git checkout -f --recurse-submodules $1 &&
>
> Likewise.
>
>> +echo first > file &&
>
> Likewise.
>
>> +test_expect_success '"checkout --recurse-submodules" replaces submodule
>> with files' '
>> +git checkout -f base &&
>> +git checkout -b replace_submodule_with_dir &&
>> +git update-index --force-remove submodule &&
>> +rm -rf submodule/.git .gitmodules &&
>> +git add .gitmodules submodule/* &&
>> +git commit -m "submodule replaced" &&
>> +git checkout -f base &&
>> +git submodule update -f &&
>> +git checkout --recurse-submodules replace_submodule_with_dir &&
>> +test -d submodule &&
>> +! test -e submodule/.git &&
>> +test -f submodule/first.t &&
>> +test -f submodule/second.t
>> +'
>
> H. Is it sufficient for these files to just exist, or do we
> want to make sure they have expected contents?
Thanks, will consider all you remarks above in the ongoing work for
testing framework which should replace these tests.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
Am 04.02.2014 00:01, schrieb Junio C Hamano: > Jens Lehmann writes: > >> This new option will allow the user to not only update the work tree of >> the superproject according to the merge result but to also update the >> work tree of all initialized submodules (so they match the SHA-1 recorded >> in the superproject). But this commit only adds the option without any >> functionality, that will be added to unpack_trees() in subsequent commits. > > When the two branches of the superproject being merged wants to put > a submodule project to commit A and B, that conflict needs to be > resolved, but if they agree that the submodule project should be at > C (which is different from what the current superproject HEAD has > for the submodule in its gitlink), then we want a checkout of that > commit to happen in that submodule. Makes sense. > > After resolving such a conflict between A and B, who is responsible > to adjust the working tree state of the submodule involved, by the > way? "git merge --continue" does not exist and its moral equivalent > to conclude such an interrupted merge is "git commit". Should it > learn to do "recurse-submodule", or should the user run a separate > "checkout --recurse-submodule"? I think the user needs to sort things out, just like she has to do when a file has a merge conflict. But unfortunately we cannot use conflict markers here, so I'd propose the following: * When merge proposes a merge resolution (which it does today by telling the user "Found a possible merge resolution for the submodule ... [use] git update-index --cacheinfo 16 ...") that commit should be checked out in the submodule but not staged. Then the user can simply add and commit. * If the merge resolution is not obvious to merge, it leaves the submodule in an unmerged state, the local commit still being checked out. The user has to manually do the merge in the submodule and commits that in the superproject. Does that make sense? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 7/9] submodule: teach unpack_trees() to remove submodule contents
Am 03.02.2014 21:10, schrieb W. Trevor King: > On Mon, Feb 03, 2014 at 08:52:49PM +0100, Jens Lehmann wrote: >> Implement the functionality needed to enable work tree manipulating >> commands to that a deleted submodule should not only affect the index >> (leaving all the files of the submodule in the work tree) but also to >> remove the work tree of the superproject (including any untracked >> files). >> >> That will only work properly when the submodule uses a gitfile instead of >> a .git directory and no untracked files are present. Otherwise the removal >> will fail with a warning (which is just what happened until now). > > I'm having trouble parsing this one. How about: > > Add a depopulate_submodule helper which removes the submodule > working directory without touching the index. This will only work > properly when the submodule uses a gitfile… Thanks, that's better. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 9/9] submodule: teach unpack_trees() to update submodules
Am 03.02.2014 21:19, schrieb W. Trevor King: > On Mon, Feb 03, 2014 at 08:54:17PM +0100, Jens Lehmann wrote: >> Implement the functionality needed to enable work tree manipulating >> commands so that an changed submodule does not only affect the index but >> it also updates the work tree of any initialized submodule according to >> the SHA-1 recorded in the superproject. > > How about: > > …so that *a* changed submodule ** updates the index and work tree of > any initialized submodule according to the SHA-1 recorded in the > superproject. Before this commit it updated neither; users had to > run 'submodule update' to propagate gitlink updates into the > submodule. > > I'm pretty sure that's accurate anyway ;). And I like it better ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 9/9] submodule: teach unpack_trees() to update submodules
Am 04.02.2014 01:11, schrieb Duy Nguyen:
> On Tue, Feb 4, 2014 at 2:54 AM, Jens Lehmann wrote:
>> Implement the functionality needed to enable work tree manipulating
>> commands so that an changed submodule does not only affect the index but
>> it also updates the work tree of any initialized submodule according to
>> the SHA-1 recorded in the superproject.
>>
>> Signed-off-by: Jens Lehmann
>> ---
>> entry.c| 15 --
>> submodule.c| 86
>> ++
>> submodule.h| 3 ++
>> unpack-trees.c | 69 --
>> unpack-trees.h | 1 +
>> 5 files changed, 157 insertions(+), 17 deletions(-)
>>
>> diff --git a/entry.c b/entry.c
>> index d1bf6ec..61a2767 100644
>> --- a/entry.c
>> +++ b/entry.c
>> @@ -265,7 +265,7 @@ int checkout_entry(struct cache_entry *ce,
>>
>> if (!check_path(path, len, &st, state->base_dir_len)) {
>> unsigned changed = ce_match_stat(ce, &st,
>> CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE);
>> - if (!changed)
>> + if (!changed && (!S_ISDIR(st.st_mode) ||
>> !S_ISGITLINK(ce->ce_mode)))
>> return 0;
>
> Should we report something when ce is a gitlink, but path is not a
> directory, instead of siliently exit?
Good point.
>> diff --git a/submodule.c b/submodule.c
>> index 3907034..83e7595 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -520,6 +520,42 @@ int depopulate_submodule(const char *path)
>> return 0;
>> }
>>
>> +int update_submodule(const char *path, const unsigned char sha1[20], int
>> force)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + struct child_process cp;
>> + const char *hex_sha1 = sha1_to_hex(sha1);
>> + const char *argv[] = {
>> + "checkout",
>> + force ? "-fq" : "-q",
>
> respect "state->quiet" in checkout_entry() as well?
See below.
>> + hex_sha1,
>> + NULL,
>> + };
>> + const char *git_dir;
>> +
>> + strbuf_addf(&buf, "%s/.git", path);
>> + git_dir = read_gitfile(buf.buf);
>> + if (!git_dir)
>> + git_dir = buf.buf;
>> + if (!is_directory(git_dir)) {
>> + strbuf_release(&buf);
>> + /* The submodule is not populated, so we can't check it out
>> */
>> + return 0;
>> + }
>> + strbuf_release(&buf);
>> +
>> + memset(&cp, 0, sizeof(cp));
>> + cp.argv = argv;
>> + cp.env = local_repo_env;
>> + cp.git_cmd = 1;
>> + cp.no_stdin = 1;
>> + cp.dir = path; /* GIT_WORK_TREE doesn't work for git checkout */
>
> And if we do respect --quiet and it's not specified, paths printed by
> this process is relative to "dir", not to user cwd. Could be
> confusing.
That's the reason I'm currently always passing -q to checkout. While
checkout would have to learn a "--prefix=" option to be able to print
the path relative to the superproject, some (most?) users don't want
to see this detailed information from inside the submodule. After all
git status and diff currently also only show a condensed view of the
submodule state and don't print any detailed information about files
inside the submodule. We might want to add means to enable that later,
and then we'd have to conditionally provide --quiet (and --prefix)
here.
>> + if (run_command(&cp))
>> + return error("Could not checkout submodule %s", path);
>> +
>> + return 0;
>> +}
>> +
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Added syntax highlight support for golang
The highlight project which is being used by gitweb supports this. I
checked it before submitting the patch.
Thanks
On Sat, Feb 8, 2014 at 3:24 AM, Junio C Hamano wrote:
> Pavan Kumar Sunkara writes:
>
>> Golang is quickly becoming one of the major programming languages.
>>
>> This change switches on golang syntax highlight support by default
>> in gitweb rather than asking the users to do it using config files.
>
> Looks trivially harmless ;-)
>
> I haven't touched this part of our system, but the patch makes me
> wonder if there is a way for us to _ask_ the installed 'highlight'
> binary what languages it knows about. This hash is used only in
> guess_file_syntax sub, and it may not be unreasonable to populate it
> lazily there, or at least generate this part by parsing output from
> 'highlight -p' at build-install time.
>
>> Signed-off-by: Pavan Kumar Sunkara
>> ---
>> gitweb/gitweb.perl |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index bf7fd67..aa6fcfd 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -273,7 +273,7 @@ our %highlight_basename = (
>> our %highlight_ext = (
>> # main extensions, defining name of syntax;
>> # see files in /usr/share/highlight/langDefs/ directory
>> - (map { $_ => $_ } qw(py rb java css js tex bib xml awk bat ini spec
>> tcl sql)),
>> + (map { $_ => $_ } qw(py rb java go css js tex bib xml awk bat ini spec
>> tcl sql)),
>> # alternate extensions, see /etc/highlight/filetypes.conf
>> (map { $_ => 'c' } qw(c h)),
>> (map { $_ => 'sh' } qw(sh bash zsh ksh)),
--
- Pavan Kumar Sunkara
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Added syntax highlight support for golang
Pavan Kumar Sunkara writes:
> Golang is quickly becoming one of the major programming languages.
>
> This change switches on golang syntax highlight support by default
> in gitweb rather than asking the users to do it using config files.
Looks trivially harmless ;-)
I haven't touched this part of our system, but the patch makes me
wonder if there is a way for us to _ask_ the installed 'highlight'
binary what languages it knows about. This hash is used only in
guess_file_syntax sub, and it may not be unreasonable to populate it
lazily there, or at least generate this part by parsing output from
'highlight -p' at build-install time.
> Signed-off-by: Pavan Kumar Sunkara
> ---
> gitweb/gitweb.perl |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index bf7fd67..aa6fcfd 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -273,7 +273,7 @@ our %highlight_basename = (
> our %highlight_ext = (
> # main extensions, defining name of syntax;
> # see files in /usr/share/highlight/langDefs/ directory
> - (map { $_ => $_ } qw(py rb java css js tex bib xml awk bat ini spec tcl
> sql)),
> + (map { $_ => $_ } qw(py rb java go css js tex bib xml awk bat ini spec
> tcl sql)),
> # alternate extensions, see /etc/highlight/filetypes.conf
> (map { $_ => 'c' } qw(c h)),
> (map { $_ => 'sh' } qw(sh bash zsh ksh)),
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Added syntax highlight support for golang
Sorry. I misunderstood your message. Yes, I guess lazy loading the supported file extensions would be better. But not all highlighters support `-p` option. So, I think its better to leave it to the user. Thanks -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
Jens Lehmann writes: > I think the user needs to sort things out, just like she has to do > when a file has a merge conflict. But unfortunately we cannot use > conflict markers here, so I'd propose the following: > > * When merge proposes a merge resolution (which it does today by > telling the user "Found a possible merge resolution for the > submodule ... [use] git update-index --cacheinfo 16 ...") > that commit should be checked out in the submodule but not > staged. Then the user can simply add and commit. > > * If the merge resolution is not obvious to merge, it leaves the > submodule in an unmerged state, the local commit still being > checked out. The user has to manually do the merge in the > submodule and commits that in the superproject. > > Does that make sense? The latter one does not worry me too much. For the former, "add and commit" at the top-level makes perfect sense, and the "commit should be checked out in the submodule" is a necessary step to sanity-check and prepare for that "add and commit" step, but what does "checked out in the submodule" exactly mean? Do we detach the HEAD at the commit? Do we advance the tip of the branch of the submodule to that commit? Do we know/require/care if such a move always fast-forwards? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
On Fri, Feb 07, 2014 at 02:00:23PM -0800, Junio C Hamano wrote: > Jens Lehmann writes: > > I think the user needs to sort things out, just like she has to do > > when a file has a merge conflict. But unfortunately we cannot use > > conflict markers here, so I'd propose the following: > > > > * When merge proposes a merge resolution (which it does today by > > telling the user "Found a possible merge resolution for the > > submodule ... [use] git update-index --cacheinfo 16 ...") > > that commit should be checked out in the submodule but not > > staged. Then the user can simply add and commit. > > … > … > > For the former, "add and commit" at the top-level makes perfect > sense, … This still works if the merge issue is in a grandchild submodule, but it's going to be a bit tedious if the user has to add-and-commit at each level from the troublesome sub-sub-…-module on up to the top-level superproject. I can't think of a cleaner solution though. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] gitweb: Added syntax highlight support for golang
Pavan Kumar Sunkara writes: > Sorry. I misunderstood your message. Yes, I guess lazy loading the > supported file extensions would be better. But not all highlighters > support `-p` option. So, I think its better to leave it to the user. Yes, those highlighters that do not support `-p` may have to rely on the hard-coded list %highlight_ext. But with the same line of reasoning, not all versions of highligher supports 'go' language, so it's better to leave that to the user, no? The version of 'highlight' you may have may know about 'go', and somebody else's 'highlight' may not yet. A hard-coded list that appears in %highlight_ext will be correct for only one of you while the other between you two needs to customize it to his system. Note that I was not talking about removing the configurability. Even with lazy loading and/or auto-genearting at build-install time when 'highlight -p' is available, the users still want to be able to customize, and supporting that is fine. But for those whose 'highlight' does support '-p', it will help to lazily discover the list of supported languages and/or enumarate them at build-install time. They do not have to keep adding new language (or removing it from the list we give as the upstream) to adjust it to their system. In any case, the comment was not about this patch from you, but about the future direction for the code it touches in general. In other words, it did not mean "because it does not update the mechanism to lazily discover the list of languages, and instead added yet another language to the existing one, it is not an acceptable solution to start supporting 'go'". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Added syntax highlight support for golang
Yeah. I agree with you. I am currently looking into allowing users to customize the parameters given to their highlighter. I will try to look into this. Thanks On Sat, Feb 8, 2014 at 4:31 AM, Junio C Hamano wrote: > Pavan Kumar Sunkara writes: > >> Sorry. I misunderstood your message. Yes, I guess lazy loading the >> supported file extensions would be better. But not all highlighters >> support `-p` option. So, I think its better to leave it to the user. > > Yes, those highlighters that do not support `-p` may have to rely on > the hard-coded list %highlight_ext. > > But with the same line of reasoning, not all versions of highligher > supports 'go' language, so it's better to leave that to the user, > no? The version of 'highlight' you may have may know about 'go', > and somebody else's 'highlight' may not yet. A hard-coded list that > appears in %highlight_ext will be correct for only one of you while > the other between you two needs to customize it to his system. > > Note that I was not talking about removing the configurability. > Even with lazy loading and/or auto-genearting at build-install time > when 'highlight -p' is available, the users still want to be able to > customize, and supporting that is fine. > > But for those whose 'highlight' does support '-p', it will help to > lazily discover the list of supported languages and/or enumarate > them at build-install time. They do not have to keep adding new > language (or removing it from the list we give as the upstream) to > adjust it to their system. > > In any case, the comment was not about this patch from you, but > about the future direction for the code it touches in general. In > other words, it did not mean "because it does not update the > mechanism to lazily discover the list of languages, and instead > added yet another language to the existing one, it is not an > acceptable solution to start supporting 'go'". -- - Pavan Kumar Sunkara -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] fetch-pack: fix deepen shallow over smart http with no-done cap
On Fri, Feb 07, 2014 at 10:01:08AM -0800, Junio C Hamano wrote: > Here is the difference between the posted series and what I queued > after applying the changes suggested during the review. > > Thanks. I was going to send a reroll after the received comments. Could you put this on top of 6/6, just to make sure future changes in t5537 (maybe more or less commits created..) does not change the test behavior? It fixes the test name too. I originally thought, ok let's create commits in one test and do fetch in another. But it ended up in the same test and I forgot to update test name. -- 8< -- diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh index 1413caf..b300383 100755 --- a/t/t5537-fetch-shallow.sh +++ b/t/t5537-fetch-shallow.sh @@ -203,7 +203,7 @@ EOF # This test is tricky. We need large enough "have"s that fetch-pack # will put pkt-flush in between. Then we need a "have" the server # does not have, it'll send "ACK %s ready" -test_expect_success 'add more commits' ' +test_expect_success 'no shallow lines after receiving ACK ready' ' ( cd shallow && for i in $(test_seq 10) @@ -224,7 +224,9 @@ test_expect_success 'add more commits' ' cd clone && git checkout --orphan newnew && test_commit new-too && - git fetch --depth=2 + GIT_TRACE_PACKET="$TRASH_DIRECTORY/trace" git fetch --depth=2 && + grep "fetch-pack< ACK .* ready" ../trace && + ! grep "fetch-pack> done" ../trace ) ' -- 8< -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] t5538: fix default http port
On Thu, Feb 06, 2014 at 02:35:33PM -0500, Jeff King wrote:
> On Thu, Feb 06, 2014 at 10:10:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
> > Originally I had t5537 use port 5536 and 5538 use port 5537(!). Then
> > Jeff found my fault so I changed port in t5537 from 5536 to 5537 in
> > 3b32a7c (t5537: fix incorrect expectation in test case 10 -
> > 2014-01-08). Which makes it worse because now both t5537 and t5538
> > both use the same port. Fix it.
> [...]
Thinking on this more, I wonder if we should just do something like
this:
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index bfdff2a..c82b4ee 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -64,7 +64,9 @@ case $(uname) in
esac
LIB_HTTPD_PATH=${LIB_HTTPD_PATH-"$DEFAULT_HTTPD_PATH"}
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'8111'}
+if test -z "$LIB_HTTPD_PORT"; then
+ LIB_HTTPD_PORT=${this_test#t}
+fi
TEST_PATH="$TEST_DIRECTORY"/lib-httpd
HTTPD_ROOT_PATH="$PWD"/httpd
and drop the manual LIB_HTTPD_PORT setting in each of the test scripts.
That would prevent this type of error in the future, and people can
still override if they want to.
Any test scripts that are not numbered would need to set it, but we
should not have any of those (and if we did, the failure mode would be
OK, as Apache would barf on the bogus port number).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 8/9] rebase: add the --gpg-sign option
On Mon, Feb 03, 2014 at 01:42:06PM -0800, Junio C Hamano wrote:
> > + --gpg-sign)
> > + gpg_sign_opt=-S
> > + ;;
> > + --gpg-sign=*)
> > + # Try to quote only the argument, as this will appear in
> > human-readable
> > + # output as well as being passed to commands.
> > + gpg_sign_opt="-S$(git rev-parse --sq-quote "${1#--gpg-sign=}" |
> > + sed 's/^ //')"
>
> Isn't an invocation of sed excessive?
>
> gpg_sign_opt=$(git rev-parse --sq-quote "${1#--gpg-sign=}") &&
> gpg_sign_opt=-S${gpg_sign_opt# }
>
> if you really need to strip the leading SP, which I do not think is
> a necessary thing to do. It is sufficient to remove the SP before
> the variable substitution in the human-readable messages, e.g.
I'm not sure that command line parsing of "-S 'foo '"
will work exactly as expected due to the fact that -S doesn't always
take an argument. Your suggestion to use # seems fine, though.
I'm a little embarrassed to admit that in my fifteen years of Unix
experience, I've never learned the variable modifiers for shell, so it
didn't occur to me to use them in this case. Guess it's time to learn
them now.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
[GIT PULL] l10n updates for 1.9.0 round 2
2014-02-08 Junio C Hamano : > A release candidate Git v1.9.0-rc3 is now available for testing > at the usual places. Hopefully this will be the last one before the > final, scheduled to happen sometime late next week. > The following changes since commit be961c292f1d36097afa1690df68cf90f655c855: Git 1.9-rc2 (2014-01-31 14:16:06 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 98b2761d5efaf559d67e7ed5694f3a2bddf3e868: l10n: zh_CN.po: Disambiguation for rebase (2014-02-06 23:15:33 +0800) Jean-Noel Avila (1): l10n: fr: 1.9rc2 2211t Jiang Xin (5): l10n: git.pot: v1.9 round 2 (1 new) Merge branch 'master' of git://github.com/vnwildman/git Merge branch 'master' of git://github.com/nafmo/git-l10n-sv l10n: zh_CN.po: translate 1 new message (2211t0f0u) l10n: zh_CN.po: Disambiguation for rebase Peter Krefting (1): l10n: Update Swedish translation (2211t0f0u) Tran Ngoc Quan (1): l10n: vi.po (2211t): Updated one new string po/fr.po| 58 po/git.pot | 29 -- po/sv.po| 31 --- po/vi.po| 123 ++-- po/zh_CN.po | 63 +-- 5 files changed, 165 insertions(+), 139 deletions(-) -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git best strategy for two version development
Hello, I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses this library, version_B uses my own code to replace it. For strategic reasons I want to keep it this way for the time being. Both versions have the same documentation, the same data files, and 99% of the source code is the same (a few makefile changes, two additional files in version_B and some minor changes: a diff -r has only 170 lines). The question is what is the best strategy to manage a situation like this with git? Shall I maintain two different repositories? I don't think so... Apparently the best solution would be to maintain two long term branches, say mater_A and master_B, and merge all later developments in both branches, keeping the initial difference... Specifically: 1) do some new work in branch master_A, commit, etc. 2) checkout master_B and merge the new work in master_B, without merging the initial diff between the two versions. What is the better way to do that? I suppose this is a fairly common situation, for example, some standalone code distributed with two different GUI toolkits. I could carefully choose which commits should be merged in both branches (the changes in standalone code) and which should not (the changes in GUI code), but that is error-prone and seems to miss the whole point of using a managment system... How shall I handle this? Thanks for your help! Regards, Carlos Pereira, http://www.gamgi.org/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git best strategy for two version development
On Sat, Feb 08, 2014 at 02:06:41AM +, Carlos Pereira wrote: > Hello, > > I am a git and CVS newbie, I bought and red most of the excellent > Pro Git book by Scott Chacon, but I still have a doubt. I have a > package that I distribute in two versions differing only in one > library: version_A uses this library, version_B uses my own code to > replace it. For strategic reasons I want to keep it this way for the > time being. Both versions have the same documentation, the same data > files, and 99% of the source code is the same (a few makefile > changes, two additional files in version_B and some minor changes: a > diff -r has only 170 lines). The question is what is the best > strategy to manage a situation like this with git? > > Shall I maintain two different repositories? I don't think so... > > Apparently the best solution would be to maintain two long term > branches, say mater_A and master_B, and merge all later developments > in both branches, keeping the initial difference... Specifically: > > 1) do some new work in branch master_A, commit, etc. > 2) checkout master_B and merge the new work in master_B, without > merging the initial diff between the two versions. > > What is the better way to do that? That's pretty much the way to do it. If you check in master-A, then create the master-B branch off of that, copying in the code from B and checking it in, then when you merge from master-A to master-B, git will basically do the right thing. Changes you make on master-A that are specific to that version will probably conflict, but they should be easy to fix up. I basically do this for a consulting project for a client: there's generic code in master, and a special branch for the client. Since most changes don't touch the modified code, conflicts are infrequent, and I can fix them up when they occur. I also do it for my dotfiles, which vary slightly between home and work. You could also make the changes to master-B as a set of commits on top of master-A, and always rebase master-B on master-A, but this isn't a good solution if other people are going to be using your code. It has the benefits of keeping the history free of frequent merges, which may or may not be important to you; it doesn't really bother me very much. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH] diff: Document --staged over --cached
Since recent documentation uses terms like 'staged' and 'staging area', --staged is more in line with other documentation and to be pfeferred over --cached. Signed-off-by: Soren Brinkmann --- Documentation/git-diff.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 33fbd8c56f91..12d5b62e71f9 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git diff' [options] [] [--] [...] -'git diff' [options] --cached [] [--] [...] +'git diff' [options] --staged [] [--] [...] 'git diff' [options] [--] [...] 'git diff' [options] 'git diff' [options] [--no-index] [--] @@ -38,7 +38,7 @@ two blob objects, or changes between two files on disk. or when running the command outside a working tree controlled by Git. -'git diff' [--options] --cached [] [--] [...]:: +'git diff' [--options] --staged [] [--] [...]:: This form is to view the changes you staged for the next commit relative to the named . Typically you @@ -46,7 +46,7 @@ two blob objects, or changes between two files on disk. do not give , it defaults to HEAD. If HEAD does not exist (e.g. unborned branches) and is not given, it shows all staged changes. - --staged is a synonym of --cached. + --cached is a synonym of --staged. 'git diff' [--options] [--] [...]:: -- 1.8.5.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] daemon: move daemonize() to libgit.a
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 1 +
daemon.c | 30 --
setup.c | 24
3 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/cache.h b/cache.h
index dc040fb..264b6f1 100644
--- a/cache.h
+++ b/cache.h
@@ -434,6 +434,7 @@ extern int set_git_dir_init(const char *git_dir, const char
*real_git_dir, int);
extern int init_db(const char *template_dir, unsigned int flags);
extern void sanitize_stdfds(void);
+extern int daemonize(void);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/daemon.c b/daemon.c
index 503e039..eba1255 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1056,11 +1056,6 @@ static void drop_privileges(struct credentials *cred)
/* nothing */
}
-static void daemonize(void)
-{
- die("--detach not supported on this platform");
-}
-
static struct credentials *prepare_credentials(const char *user_name,
const char *group_name)
{
@@ -1102,24 +1097,6 @@ static struct credentials *prepare_credentials(const
char *user_name,
return &c;
}
-
-static void daemonize(void)
-{
- switch (fork()) {
- case 0:
- break;
- case -1:
- die_errno("fork failed");
- default:
- exit(0);
- }
- if (setsid() == -1)
- die_errno("setsid failed");
- close(0);
- close(1);
- close(2);
- sanitize_stdfds();
-}
#endif
static void store_pid(const char *path)
@@ -1333,9 +1310,10 @@ int main(int argc, char **argv)
if (inetd_mode || serve_mode)
return execute();
- if (detach)
- daemonize();
- else
+ if (detach) {
+ if (daemonize())
+ die("--detach not supported on this platform");
+ } else
sanitize_stdfds();
if (pid_file)
diff --git a/setup.c b/setup.c
index 6c3f85f..b09a412 100644
--- a/setup.c
+++ b/setup.c
@@ -787,3 +787,27 @@ void sanitize_stdfds(void)
if (fd > 2)
close(fd);
}
+
+int daemonize(void)
+{
+#ifdef NO_POSIX_GOODIES
+ errno = -ENOSYS;
+ return -1;
+#else
+ switch (fork()) {
+ case 0:
+ break;
+ case -1:
+ die_errno("fork failed");
+ default:
+ exit(0);
+ }
+ if (setsid() == -1)
+ die_errno("setsid failed");
+ close(0);
+ close(1);
+ close(2);
+ sanitize_stdfds();
+ return 0;
+#endif
+}
--
1.8.5.2.240.g8478abd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] gc: config option for running --auto in background
`gc --auto` takes time and can block the user temporarily (but not any
less annoyingly). Make it run in background on systems that support
it. The only thing lost with running in background is printouts. But
gc output is not really interesting. You can keep it in foreground by
changing gc.autodetach.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 4
builtin/gc.c | 23 ++-
t/t5400-send-pack.sh | 1 +
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f4d793..4781773 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1167,6 +1167,10 @@ gc.autopacklimit::
--auto` consolidates them into one larger pack. The
default value is 50. Setting this to 0 disables it.
+gc.autodetach::
+ Make `git gc --auto` return immediately andrun in background
+ if the system supports it. Default is true.
+
gc.packrefs::
Running `git pack-refs` in a repository renders it
unclonable by Git versions prior to 1.5.1.2 over dumb
diff --git a/builtin/gc.c b/builtin/gc.c
index c19545d..ed5cc3c 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -29,6 +29,7 @@ static int pack_refs = 1;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
+static int detach_auto = 1;
static const char *prune_expire = "2.weeks.ago";
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
@@ -73,6 +74,10 @@ static int gc_config(const char *var, const char *value,
void *cb)
gc_auto_pack_limit = git_config_int(var, value);
return 0;
}
+ if (!strcmp(var, "gc.autodetach")) {
+ detach_auto = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp(var, "gc.pruneexpire")) {
if (value && strcmp(value, "now")) {
unsigned long now = approxidate("now");
@@ -301,11 +306,19 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
*/
if (!need_to_gc())
return 0;
- if (!quiet)
- fprintf(stderr,
- _("Auto packing the repository for
optimum performance. You may also\n"
- "run \"git gc\" manually. See "
- "\"git help gc\" for more
information.\n"));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _("Auto packing the repository
in background for optimum performance.\n"));
+ else
+ fprintf(stderr, _("Auto packing the repository
for optimum performance.\n"));
+ fprintf(stderr, _("See \"git help gc\" for manual
housekeeping.\n"));
+ }
+ if (detach_auto)
+ /*
+* failure to daemonize is ok, we'll continue
+* in foreground
+*/
+ daemonize();
} else
add_repack_all_option();
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 129fc88..0736bcb 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -164,6 +164,7 @@ test_expect_success 'receive-pack runs auto-gc in remote
repo' '
# Set the child to auto-pack if more than one pack exists
cd child &&
git config gc.autopacklimit 1 &&
+ git config gc.autodetach false &&
git branch test_auto_gc &&
# And create a file that follows the temporary object naming
# convention for the auto-gc to remove
--
1.8.5.2.240.g8478abd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug tracker (again)
(Dropped some CC as this becomes a different topic) On Sat, Feb 8, 2014 at 2:20 AM, Jonathan Nieder wrote: > Duy Nguyen wrote: > >> Don't take it the wrong way. I was just summarizing the last round. It >> surprised me though that this went under my radar. Perhaps a bug >> tracker is not a bad idea after all (if Jeff went missing, this bug >> could fall under the crack) > > I'm happy to plug > - http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=git;include=tags:upstream > - http://packages.qa.debian.org/common/index.html (email subscription link: > source package = git; under "Advanced" it's possible to subscribe to > bug-tracking system emails and skip e.g. the automated build stuff) > - https://www.debian.org/Bugs/Reporting (bug reporting interface - > unfortunately the important part is buried under "Sending the bug > report via e-mail") > again. :) So I wonder if we use debian bug tracker for git upstream. I haven't used debian tracker much (or debian for that matter). It's probably best just ask instead of searching and guessing. I suppose if debian people (mostly debian git maintainer?) are not opposed to us using their tracker for upstream bugs, then it's just a matter of associating a mail thread with a bug number for tracking. That could be probably be done via email, then reply all to the thread in question with a bug email address. After that all email discussions are also tracked via this bug email. Anybody can help track bugs. Say if 3 weekdays are over and nobody said a thing about something that looks a lot like bug, then it should be tracked (problems that can be quickly fixed do not need tracking). Hmm? -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] t5538: fix default http port
On Sat, Feb 8, 2014 at 6:47 AM, Jeff King wrote:
> Thinking on this more, I wonder if we should just do something like
> this:
>
> diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
> index bfdff2a..c82b4ee 100644
> --- a/t/lib-httpd.sh
> +++ b/t/lib-httpd.sh
> @@ -64,7 +64,9 @@ case $(uname) in
> esac
>
> LIB_HTTPD_PATH=${LIB_HTTPD_PATH-"$DEFAULT_HTTPD_PATH"}
> -LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'8111'}
> +if test -z "$LIB_HTTPD_PORT"; then
> + LIB_HTTPD_PORT=${this_test#t}
> +fi
>
> TEST_PATH="$TEST_DIRECTORY"/lib-httpd
> HTTPD_ROOT_PATH="$PWD"/httpd
>
> and drop the manual LIB_HTTPD_PORT setting in each of the test scripts.
> That would prevent this type of error in the future, and people can
> still override if they want to.
>
> Any test scripts that are not numbered would need to set it, but we
> should not have any of those (and if we did, the failure mode would be
> OK, as Apache would barf on the bogus port number).
Yes! Next stop, attempt to start httpd at start_httpd regardless of
GIT_TEST_HTTPD. If successful, test_set_prereq HTTPD or something that
the following tests can use. If GIT_TEST_HTTPD is set and start_httpd
fails, error out, not set prereq.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
