Re: [PATCH] rev-list docs: clarify --topo-order description
On Mon, Aug 13, 2012 at 4:05 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>>> diff --git a/Documentation/rev-list-options.txt
>>> b/Documentation/rev-list-options.txt
>>> index 6a4b635..dc501ee 100644
>>> --- a/Documentation/rev-list-options.txt
>>> +++ b/Documentation/rev-list-options.txt
>>> @@ -579,15 +579,32 @@ Commit Ordering
>>> By default, the commits are shown in reverse chronological order.
>>
>> It seems likely that those reading the above sentence will continue on
>> to read about --topo-order, but still, do you think the "descendant
>> commits are shown before parents" part belong here instead?
>
> I do not think so. When you are not limited (i.e. limit_list() is
> not called), you could do something like "git rev-list 4 5" in a
> history like this:
>
> --1---5---2---3---4
>
> and get end up getting "5 4 3 2 1", and "2" certainly doesn't get
> shown before "5" does.
Oh, interesting. I had no idea, although that does make sense. Thanks.
Still, the "Even without this option" strongly suggests to me that
what follows ("descendant commits are shown before parents") applies
to the "By default" case. Would it be correct to say something like
"By default, the commits are shown in reverse chronological order.
When commit limiting is in effect, descendant commits are shown before
parents."? I'm not sure the "commit limiting" section in the man page
involves the same options as "limit_list" (I rather think they don't),
but I don't know if there's a better term to use in the documentation
either.
--
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 4/4] fetch-pack: mention server version with verbose output
Jeff King writes:
> + if ((agent_feature = server_feature_value("agent", &agent_len))) {
> agent_supported = 1;
> + if (args.verbose && agent_len) {
> + fprintf(stderr, "Server version is %.*s\n",
> + agent_len, agent_feature);
> + }
> + }
OK. The one I queued in 'pu' said "Server version not disclosed"
when length was 0, but I think I like this one better.
Also I like the the update to the parsing code in the previous
patch. It makes the logic clearer.
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: OSLC connectivity to GIT in Java
I tried with Lyo, which provides, ADAPters to communicate with GIT, On running one sample, i got an error. Kindly let me know if this is a right approach too? http://www.eclipse.org/forums/index.php/m/901670/#msg_901670 -- View this message in context: http://git.661346.n2.nabble.com/OSLC-connectivity-to-GIT-in-Java-tp7564860p7564908.html Sent from the git mailing list archive at Nabble.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: OSLC connectivity to GIT in Java
Hi Martin, Thanks for the feedback, do you have any Links using which I can get the below scenario, as a matter of fact I am new to the below protocol and am taking baby steps for the same. Mit freundlichen Grüßen / Best Regards, Rahul Chandrashekar Robert Bosch Engineering and Business Solutions Limited Engineering Methods and Tools (RBEI\EMT2) 123, Industrial Layout, Hosur Road, Koramangala, Bangalore - 560 095 INDIA www.bosch.com Tel. +91 80 6657 1661 VoIp. +49(711)811-3615170 Mobile +91 9886944213 rahul.chandrashe...@in.bosch.com -Original Message- From: Martin Langhoff [mailto:martin.langh...@gmail.com] Sent: Tuesday, 14. August 2012 1:15 AM To: Rahul Chandrashekar (RBEI/EMT2) Cc: git@vger.kernel.org Subject: Re: OSLC connectivity to GIT in Java On Mon, Aug 13, 2012 at 8:12 AM, rahul.chandrashekar wrote: > I am interested to connect to a GIT SCM through OSLC. It seems to me a very strange request. There is a very well implemented, fit-for-purpose "git protocol". OSLC, after some googling, is a REST-style definition over HTTP. We already have a git-over-http protocol, not very efficient but opens a window of opportunity to those behind unreasonable firewalls. Perhaps it is a starting point for you. hth, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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 4/4] fetch-pack: mention server version with verbose output
On Mon, Aug 13, 2012 at 09:59:27PM -0400, Jeff King wrote:
> So if we want to avoid the allocation, then this is how I would do it:
> by returning the feature's _value_ and not the whole key. Since we know
> that the beginning part must obviously match what we fed it anyway, it
> is not that interesting.
>
> -- >8 --
> Subject: [PATCH] parse_feature_request: make it easier to see feature values
And here is the rebased 4/4 on top of that.
At this point, I think this part of the topic has received more than
enough attention. Please feel free to apply these patches, your patches,
or even just drop it altogether (and when somebody has a more compelling
reason to actually parse such a value, they can resurrect the
infrastructure patch).
-- >8 --
Subject: [PATCH] fetch-pack: mention server version with verbose output
Fetch-pack's verbose mode is more of a debugging mode (and
in fact takes two "-v" arguments to trigger via the
porcelain layer). Let's mention the server version as
another possible item of interest.
Signed-off-by: Jeff King
---
builtin/fetch-pack.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index bc7a0f9..3b2b5a4 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -787,6 +787,8 @@ static struct ref *do_fetch_pack(int fd[2],
{
struct ref *ref = copy_ref_list(orig_ref);
unsigned char sha1[20];
+ const char *agent_feature;
+ int agent_len;
sort_ref_list(&ref, ref_compare_name);
@@ -823,8 +825,14 @@ static struct ref *do_fetch_pack(int fd[2],
fprintf(stderr, "Server supports ofs-delta\n");
} else
prefer_ofs_delta = 0;
- if (server_supports("agent"))
+
+ if ((agent_feature = server_feature_value("agent", &agent_len))) {
agent_supported = 1;
+ if (args.verbose && agent_len) {
+ fprintf(stderr, "Server version is %.*s\n",
+ agent_len, agent_feature);
+ }
+ }
if (everything_local(&ref, nr_match, match)) {
packet_flush(fd[1]);
--
1.7.12.rc2.11.gf0a1e27
--
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 4/4] fetch-pack: mention server version with verbose output
On Mon, Aug 13, 2012 at 05:11:10PM -0400, Jeff King wrote:
> On Mon, Aug 13, 2012 at 02:09:32PM -0700, Junio C Hamano wrote:
>
> > >> +if ((agent_feature = server_feature("agent", &agent_len)) !=
> > >> NULL &&
> > >> +5 < agent_len && agent_feature[5] == '=') {
> > >> agent_supported = 1;
> > >> +if (args.verbose) {
> > >> +fprintf(stderr, "Server version is %.*s\n",
> > >> +agent_len - 6, agent_feature + 6);
> > >> +}
> > >> +}
> > >
> > > Yeah, this is exactly the kind of ugliness I was trying to avoid with my
> > > allocating wrapper. Still, there is only one call site, so I do not care
> > > overly much (and I as I've already said, I'm lukewarm on the final two
> > > patches, anyway).
> >
> > Actually, the above is vastly superiour compared to the allocating
> > kind. Be honest and think about it. If the caller wants to
> > allocate, it could, and it does not even have to count. If the
> > caller does not want to allocate, it does not have to pay the price.
>
> My point is that the run-time allocation price is quite small, but the
> readability cost of that ugly conditional with the magic "5" is
> non-trivial. But they are apples and oranges, so it is hard to compare
> their amounts directly.
So if we want to avoid the allocation, then this is how I would do it:
by returning the feature's _value_ and not the whole key. Since we know
that the beginning part must obviously match what we fed it anyway, it
is not that interesting.
-- >8 --
Subject: [PATCH] parse_feature_request: make it easier to see feature values
We already take care to parse key/value capabilities like
"foo=bar", but the code does not provide a good way of
actually finding out what is on the right-hand side of the
"=".
A server using "parse_feature_request" could accomplish this
with some extra parsing. You must skip past the "key"
portion manually, check for "=" versus NUL or space, and
then find the length by searching for the next space (or
NUL). But clients can't even do that, since the
"server_supports" interface does not even return the
pointer.
Instead, let's have our parser share more information by
providing a pointer to the value and its length. The
"parse_feature_value" function returns a pointer to the
feature's value portion, along with the length of the value.
If the feature is missing, NULL is returned. If it does not
have an "=", then a zero-length value is returned.
Similarly, "server_feature_value" behaves in the same way,
but always checks the static server_feature_list variable.
We can then implement "server_supports" in terms of
"server_feature_value". We cannot implement the original
"parse_feature_request" in terms of our new function,
because it returned a pointer to the beginning of the
feature. However, no callers actually cared about the value
of the returned pointer, so we can simplify it to a boolean
just as we do for "server_supports".
Signed-off-by: Jeff King
---
cache.h | 4 +++-
connect.c | 45 -
2 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/cache.h b/cache.h
index 67f28b4..95daa69 100644
--- a/cache.h
+++ b/cache.h
@@ -1038,7 +1038,9 @@ struct extra_have_objects {
};
extern struct ref **get_remote_heads(int in, struct ref **list, unsigned int
flags, struct extra_have_objects *);
extern int server_supports(const char *feature);
-extern const char *parse_feature_request(const char *features, const char
*feature);
+extern int parse_feature_request(const char *features, const char *feature);
+extern const char *server_feature_value(const char *feature, int *len_ret);
+extern const char *parse_feature_value(const char *feature_list, const char
*feature, int *len_ret);
extern struct packed_git *parse_pack_index(unsigned char *sha1, const char
*idx_path);
diff --git a/connect.c b/connect.c
index 55a85ad..49e56ba 100644
--- a/connect.c
+++ b/connect.c
@@ -115,12 +115,7 @@ struct ref **get_remote_heads(int in, struct ref **list,
return list;
}
-int server_supports(const char *feature)
-{
- return !!parse_feature_request(server_capabilities, feature);
-}
-
-const char *parse_feature_request(const char *feature_list, const char
*feature)
+const char *parse_feature_value(const char *feature_list, const char *feature,
int *lenp)
{
int len;
@@ -132,14 +127,46 @@ const char *parse_feature_request(const char
*feature_list, const char *feature)
const char *found = strstr(feature_list, feature);
if (!found)
return NULL;
- if ((feature_list == found || isspace(found[-1])) &&
- (!found[len] || isspace(found[len]) || found[len] == '='))
- return found;
+ if (feature_list == found || isspace(found[-1])) {
+ const char *value
Re: [PATCH/RFC] index-pack: produce pack index version 3
On Tue, Aug 14, 2012 at 7:46 AM, Shawn Pearce wrote: > Colby is nearly done prototyping the bitmap reachability > implementation in JGit and will release the code under the BSD license > there soon. I can't promise when yet because Colby will soon be > heading out for some (much deserved) vacation time, and doesn't want > to publish something until he is ready to stand behind the code. So it > might not show up until mid-September. But I think its worth giving > him a few weeks to finish getting the code ready, vs. rushing > something in that someone else thinks might help. We have waited more > than 6 years or whatever to improve packing. Colby's experiments are > showing massive improvements (40s enumeration cut to 100ms) with low > disk usage increase (<10%) and no pack file format changes. Its OK to > wait 4 more weeks. Thanks. I did not know it's being worked on (your last email did not indicate that, I think). I just wanted to try out and see how it might work. And sure I can wait :) -- 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/RFC] index-pack: produce pack index version 3
Let me start by echoing Junio's remark... "lacks sufficient justification". You don't give enough evidence to support even why it is worth looking at this commit, let alone why it should be included and cause a format change in the idx file format. At some point you start to hand-wave about how it may benefit my bitmap reachability index idea, but you don't seem to fully understand that idea. And some of what you do here sounds like it actively hurts doing the bitmap reachability project. So again this doesn't really help. Colby is nearly done prototyping the bitmap reachability implementation in JGit and will release the code under the BSD license there soon. I can't promise when yet because Colby will soon be heading out for some (much deserved) vacation time, and doesn't want to publish something until he is ready to stand behind the code. So it might not show up until mid-September. But I think its worth giving him a few weeks to finish getting the code ready, vs. rushing something in that someone else thinks might help. We have waited more than 6 years or whatever to improve packing. Colby's experiments are showing massive improvements (40s enumeration cut to 100ms) with low disk usage increase (<10%) and no pack file format changes. Its OK to wait 4 more weeks. On Mon, Aug 13, 2012 at 12:40 AM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> On Mon, Aug 13, 2012 at 2:49 AM, Junio C Hamano wrote: >>> For example, the reachability bitmap would want to say something >>> like "Traversing from commit A, these objects in this pack are >>> reachable." The bitmap for one commit A would logically consist of >>> N bits for a packfile that stores N objects (the resulting bitmap >>> needs to be compressed before going to disk, perhaps with RLE or >>> something). With the single "sorted by SHA-1" table, we can use the >>> index in that single table to enumerate all reachable objects of any >>> type in one go. With four separate tables, on the other hand, we >>> would need four bitmaps per commit. >> >> No we still need one per commit. The n-th bit is in the order of the >> object in the pack, not the index. How sha-1 is sorted does not >> matter. Yes, for RLE encoding to work well it is important that the bits are assigned using pack offset ordering, not SHA-1 ordering. The object at bit 0 is the object at offset 12 in the pack file, not the object that has the lowest SHA-1. The RLE encoding is relying on the packer to store objects closely reachable by time near each other in the pack file. Which the packer already does because we have roughly proven though the years that this ordering works sufficiently well enough for nobody to propose another ordering. :-) > Then what is the problem of using that same "N" that counts the > object using the order of the objects in the pack as a short-hand to > the object name instead, if your objective is to avoid having to > repeat the full 20-byte object name in your secondary tables? That > does not call for any split in the list of SHA-1s, no? Exactly. There is no need to store a second copy of the SHA-1s anywhere. We can discover information about object identified by bit N by creating the reverse pack index in memory. The N-th entry in the reverse index will tell us the Y-th position in the normal idx file, which gives us the SHA-1. So SHA-1 can be obtained from a bitmap in constant time, once the reverse index is built. The reverse index build costs O(N log N) time, but its already required by the packer to do efficient reuse of packed objects. We already pay this O(N log N) penalty. So its currently free to us. The bitmap approach Colby and I are collaborating on also contains 4 RLE bitmaps indicating what type each object is. Its needed so the packer can avoid looking up type data in the base pack file, while also avoiding parsing of trees where the mode information normally provides the type hint. We could instead get this by splitting the SHA-1 table into 4 tables as this patch proposes, but it doesn't help. Type information can be obtained fast enough from these 4 RLE bitmaps, without muddying the read code path with needing to know what table to search, or needing to search 4 tables rather than 1 table. >>> Either way is _possible_, but I think the former is simpler, and the >>> latter makes it harder to introduce new types of objects in the >>> future, which I do not think we have examined possible use cases >>> well enough to make that decision to say "four types is enough >>> forever". >> >> New types can be put in one of those four tables, depending on its >> purpose. No. A new type should get a new table. We should never cram a new type into an existing type table just because it sounds like a good idea. Its not. We are unlikely to add a new type anytime soon. If we do its going to take more work than just worrying about where it fits into an idx file. But it shouldn't be combined into a bucket with an existing type. >> The reason
Re: send-email and in-reply-to = n
Stephen Boyd writes: > Can we throw up a big warning or just outright fail if someone types > 'n' or 'y' and hits enter for the in-reply-to question in > git-send-email? I saw a git-send-email sent patch with an In-Reply-To > header containing n on lkml today and it makes threading in my mail > client get confused. Yeah, I think it is a good idea to minimally sanity check the answer to in-reply-to (and possibly other fields); perhaps "does it have @ and dot" would be a good enough heuristics. Please make it so ;-) -- 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
send-email and in-reply-to = n
Can we throw up a big warning or just outright fail if someone types 'n' or 'y' and hits enter for the in-reply-to question in git-send-email? I saw a git-send-email sent patch with an In-Reply-To header containing n on lkml today and it makes threading in my mail client get confused. https://lkml.org/lkml/headers/2012/8/13/503 -- 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] rev-list docs: clarify --topo-order description
Martin von Zweigbergk writes: >> diff --git a/Documentation/rev-list-options.txt >> b/Documentation/rev-list-options.txt >> index 6a4b635..dc501ee 100644 >> --- a/Documentation/rev-list-options.txt >> +++ b/Documentation/rev-list-options.txt >> @@ -579,15 +579,32 @@ Commit Ordering >> By default, the commits are shown in reverse chronological order. > > It seems likely that those reading the above sentence will continue on > to read about --topo-order, but still, do you think the "descendant > commits are shown before parents" part belong here instead? I do not think so. When you are not limited (i.e. limit_list() is not called), you could do something like "git rev-list 4 5" in a history like this: --1---5---2---3---4 and get end up getting "5 4 3 2 1", and "2" certainly doesn't get shown before "5" does. In your series where cherry-pick runs prepare_revision_walk() and makes the outcome sort in reverse, the list has to be limited, so the above is a non-issue, but in the context of this document, we cannot assume 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
Re: [PATCH] rev-list docs: clarify --topo-order description
On Mon, Aug 13, 2012 at 3:21 PM, Junio C Hamano wrote: > * Let's do this before I forget...; came up in discussion $gmane/203370 Thanks! That definitely confused me (and I suppose I stupidly didn't test with a proper range). > > Documentation/rev-list-options.txt | 29 +++-- > 1 file changed, 23 insertions(+), 6 deletions(-) > > diff --git a/Documentation/rev-list-options.txt > b/Documentation/rev-list-options.txt > index 6a4b635..dc501ee 100644 > --- a/Documentation/rev-list-options.txt > +++ b/Documentation/rev-list-options.txt > @@ -579,15 +579,32 @@ Commit Ordering > By default, the commits are shown in reverse chronological order. It seems likely that those reading the above sentence will continue on to read about --topo-order, but still, do you think the "descendant commits are shown before parents" part belong here instead? > --topo-order:: > - > - This option makes them appear in topological order (i.e. > - descendant commits are shown before their parents). > + This option makes them appear in topological order. Even > + without this option, descendant commits are shown before > + their parents, but this tries to avoid showing commits on > + multiple lines of history intermixed. > > --date-order:: > > - This option is similar to '--topo-order' in the sense that no > - parent comes before all of its children, but otherwise things > - are still ordered in the commit timestamp order. > + Show no parents before all of its children, but otherwise > + show commits in the commit timestamp order. > ++ > +For example, in a commit history like this: > ++ > + > + > +---1247 > + \ \ > +3568--- > + > + > ++ > +where the numbers denote the order of commit timestamps, `git > +rev-list` and friends with `--date-order` show the commits in the > +timestamp order: 8 7 6 5 4 3 2 1. > ++ > +With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 > +3 1), to avoid commits from two branches mixed together. It would help at least me to also know what the output would be without either of --date-order or --topo-order. (Does the default order have a name, by the way?) -- 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] rev-list docs: clarify --topo-order description
We said "--date-order" still does not violate the topology, but it was still not clear enough. Reword the description for both "--date-order" and "--topo-order", and add an illustration to it. Signed-off-by: Junio C Hamano --- * Let's do this before I forget...; came up in discussion $gmane/203370 Documentation/rev-list-options.txt | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 6a4b635..dc501ee 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -579,15 +579,32 @@ Commit Ordering By default, the commits are shown in reverse chronological order. --topo-order:: - - This option makes them appear in topological order (i.e. - descendant commits are shown before their parents). + This option makes them appear in topological order. Even + without this option, descendant commits are shown before + their parents, but this tries to avoid showing commits on + multiple lines of history intermixed. --date-order:: - This option is similar to '--topo-order' in the sense that no - parent comes before all of its children, but otherwise things - are still ordered in the commit timestamp order. + Show no parents before all of its children, but otherwise + show commits in the commit timestamp order. ++ +For example, in a commit history like this: ++ + + +---1247 + \ \ +3568--- + + ++ +where the numbers denote the order of commit timestamps, `git +rev-list` and friends with `--date-order` show the commits in the +timestamp order: 8 7 6 5 4 3 2 1. ++ +With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 +3 1), to avoid commits from two branches mixed together. --reverse:: -- 1.7.12.rc2.85.g1de7134 -- 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/4] Re: cherry-pick and 'log --no-walk' and ordering
On Mon, Aug 13, 2012 at 2:31 PM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> Makes sense. The shortlog example is a good example of sorting that >> completely reorders the commit graph sometimes even making sense for >> ranges. Thanks! > > By the way, does this topic relate to the long stalled "rebase" > topic from you, and if so how? Yes, but only through the first patch in the series. Unless I'm mistaken, I would can get a list of revisions to rebase using git-patch-id, but to convert that into a instruction list with running git-log on each commit, I planned to use 'git rev-list --format=... --no-walk=unsorted --stdin', which of course doesn't exist before patch 1/4. The rest of the current series is a little fuzzy to me, especially the confusion about reversing or not. Feel free to split out patch 1 into a separate topic if you like, or however you would handle 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
Re: [PATCH 4/4] cherry-pick/revert: default to topological sorting
Junio C Hamano writes: > y...@google.com writes: > >> From: Martin von Zweigbergk >> >> When 'git cherry-pick' and 'git revert' are used with ranges such as >> 'git cherry-pick A..B', the order of the commits to pick are >> determined by the default date-based sorting. If a commit has a commit >> date before the commit date of its parent, it will therfore be applied >> before its parent. > > Is that what --topo-order really means? And it turns out that the documentation is crappy. Perhaps something like this, but an illustration may not hurt. Documentation/rev-list-options.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index d9b2b5b..c147117 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -579,9 +579,10 @@ Commit Ordering By default, the commits are shown in reverse chronological order. --topo-order:: - - This option makes them appear in topological order (i.e. - descendant commits are shown before their parents). + This option makes them appear in topological order. Even + without this option, descendant commits are shown before + their parents, but this tries to avoid showing commits on + multiple lines of history intermixed. --date-order:: -- 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/4] Re: cherry-pick and 'log --no-walk' and ordering
Martin von Zweigbergk writes: > Makes sense. The shortlog example is a good example of sorting that > completely reorders the commit graph sometimes even making sense for > ranges. Thanks! By the way, does this topic relate to the long stalled "rebase" topic from you, and if so how? -- 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 4/4] fetch-pack: mention server version with verbose output
On Mon, Aug 13, 2012 at 02:09:32PM -0700, Junio C Hamano wrote:
> >> + if ((agent_feature = server_feature("agent", &agent_len)) != NULL &&
> >> + 5 < agent_len && agent_feature[5] == '=') {
> >>agent_supported = 1;
> >> + if (args.verbose) {
> >> + fprintf(stderr, "Server version is %.*s\n",
> >> + agent_len - 6, agent_feature + 6);
> >> + }
> >> + }
> >
> > Yeah, this is exactly the kind of ugliness I was trying to avoid with my
> > allocating wrapper. Still, there is only one call site, so I do not care
> > overly much (and I as I've already said, I'm lukewarm on the final two
> > patches, anyway).
>
> Actually, the above is vastly superiour compared to the allocating
> kind. Be honest and think about it. If the caller wants to
> allocate, it could, and it does not even have to count. If the
> caller does not want to allocate, it does not have to pay the price.
My point is that the run-time allocation price is quite small, but the
readability cost of that ugly conditional with the magic "5" is
non-trivial. But they are apples and oranges, so it is hard to compare
their amounts directly.
-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 4/4] fetch-pack: mention server version with verbose output
Jeff King writes:
> On Mon, Aug 13, 2012 at 12:07:35PM -0700, Junio C Hamano wrote:
>
>> * And this is your 4 adjusted for the previous one, releaving the
>>caller from having to figure out where the capability string
>>ends.
>> [...]
>> @@ -829,8 +831,15 @@ static struct ref *do_fetch_pack(int fd[2],
>> fprintf(stderr, "Server supports ofs-delta\n");
>> } else
>> prefer_ofs_delta = 0;
>> -if (server_supports("agent"))
>> +
>> +if ((agent_feature = server_feature("agent", &agent_len)) != NULL &&
>> +5 < agent_len && agent_feature[5] == '=') {
>> agent_supported = 1;
>> +if (args.verbose) {
>> +fprintf(stderr, "Server version is %.*s\n",
>> +agent_len - 6, agent_feature + 6);
>> +}
>> +}
>
> Yeah, this is exactly the kind of ugliness I was trying to avoid with my
> allocating wrapper. Still, there is only one call site, so I do not care
> overly much (and I as I've already said, I'm lukewarm on the final two
> patches, anyway).
Actually, the above is vastly superiour compared to the allocating
kind. Be honest and think about it. If the caller wants to
allocate, it could, and it does not even have to count. If the
caller does not want to allocate, it does not have to pay the price.
--
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 4/4] fetch-pack: mention server version with verbose output
On Mon, Aug 13, 2012 at 02:07:22PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Of course, a server can also say "agent=git/none-of-your-business"; this > > is just a syntactic question. > > You do not even have to advertise it in the first place, no? If you want the client to respond with theirs, you do. -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 4/4] fetch-pack: mention server version with verbose output
Jeff King writes: > Of course, a server can also say "agent=git/none-of-your-business"; this > is just a syntactic question. You do not even have to advertise it in the first place, no? -- 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/4] revisions passed to cherry-pick should be in "default" order
Martin von Zweigbergk writes: > To connect to the other mail I sent on this thread (in parallel with > yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the > commits in the same order as "git cherry-pick HEAD~2..HEAD" (which > would give the same result if passed to 'rev-list --no-walk' for a > linear history) or in the order specified on the command line? Definitely the latter; I do not think of any semi-reasonable excuse to do otherwise. > I couldn't find any conclusive evidence of what was intended in > either log messages or test cases. Do not take the "multi-commit handling" that was bolted on to cherry-pick and revert long after these commands with a single commit form were polished and have become stable too seriously and its behaviour cast in stone. There is no reason to believe the bolted-on part was designed with sufficient thoughts behind it, nor was implemented with the same competency as the code before it was introduced. I recall myself applying these patches after only cursory review, saying "Meh, I wouldn't do multiple commits anyway, and bugs found by people can be fixed later" ;-). It is OK to consider its doneness as "the developers declared success based on their limited testing; it internally still sorts, but sorting a range by timestamp happens to yield the correct result most of the time, and this bug was not found until much later. There certainly are other bugs, at both implementation and design level, yet to be discovered." phase of its lifecycle. -- 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 4/4] fetch-pack: mention server version with verbose output
On Mon, Aug 13, 2012 at 12:07:35PM -0700, Junio C Hamano wrote:
> * And this is your 4 adjusted for the previous one, releaving the
>caller from having to figure out where the capability string
>ends.
> [...]
> @@ -829,8 +831,15 @@ static struct ref *do_fetch_pack(int fd[2],
> fprintf(stderr, "Server supports ofs-delta\n");
> } else
> prefer_ofs_delta = 0;
> - if (server_supports("agent"))
> +
> + if ((agent_feature = server_feature("agent", &agent_len)) != NULL &&
> + 5 < agent_len && agent_feature[5] == '=') {
> agent_supported = 1;
> + if (args.verbose) {
> + fprintf(stderr, "Server version is %.*s\n",
> + agent_len - 6, agent_feature + 6);
> + }
> + }
Yeah, this is exactly the kind of ugliness I was trying to avoid with my
allocating wrapper. Still, there is only one call site, so I do not care
overly much (and I as I've already said, I'm lukewarm on the final two
patches, anyway).
There is one difference in your code and mine. With mine, the server can
say simply "agent" to tell the client that it understands the extension
but does not wish to disclose its version. That might be considered
unfriendly (why would the client show theirs if the server is not
willing to do the same?), but it may be a practical decision (e.g.,
security policies may say that servers are higher-risk targets[1]).
Of course, a server can also say "agent=git/none-of-your-business"; this
is just a syntactic question.
-Peff
[1] I think you and I both agreed earlier that the "sharing versions is
a security risk" line of argument is not that compelling, but that
does not mean it is not made all the time.
-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 2/4] revisions passed to cherry-pick should be in "default" order
Martin von Zweigbergk writes: > By the way, I can see the usefulness of --reverse when giving a range, > but I think it's a little confusing when not giving a range. "git rev-list --reverse --root v1.0.0" is a way to say "give me a list of commits to be replayed in sequence" without having a bottom, no? Ah, you mean when we do _not_ walk. Yeah, that is why I said that when we do not walk, we should not even call into prepare_revision_walk() in the first place in my earlier message. We should take the commits as given from the revs->pending.objects list instead. With your "no_walk = NO_WALK_UNSORTED", calling prepare_revision_walk() would amont to the same thing, as you would not sort the commits and use them as given by the user. > So "git cherry-pick A B" will apply B first, then A. I am confused a bit. Are you describing a buggy behaviour in the current codebase, or are you saying we should fix it to behave that way? -- 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/4] revisions passed to cherry-pick should be in "default" order
On Mon, Aug 13, 2012 at 1:05 PM, Junio C Hamano wrote:
> y...@google.com writes:
>
>> From: Martin von Zweigbergk
>>
>> 'git cherry-pick' internally sets the --reverse option while walking
>> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
>> revisions starting at the oldest one. If no uninteresing revisions are
>> given, --no-walk is implied. Still, the documentation for 'git
>> cherry-pick --stdin' uses the following example:
>>
>> git rev-list --reverse master -- README | git cherry-pick -n --stdin
>>
>> The above would seem to reverse the revisions in the output (which it
>> does), and then pipe them to 'git cherry-pick', which would reverse
>> them again and apply them in the wrong order.
>
> I think we have cleared this confusion up in the previous
> discussion. It it sequencer's bug that reorders the commits when
> the caller ("rev-list --reverse" in this case) gives list of
> individual commits to replay.
>
> So I think we are all OK with chucking this patch. Am I mistaken?
I can't really say. I suppose the current patch is smaller (it can't
really get smaller than one line), but iterating over the arguments
the sequencer level might be more correct. Would the result be
different in some cases? I would be happy to add a test case at least,
although I'm not sure when I would have time to implement it in
sequencer.
To connect to the other mail I sent on this thread (in parallel with
yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
commits in the same order as "git cherry-pick HEAD~2..HEAD" (which
would give the same result if passed to 'rev-list --no-walk' for a
linear history) or in the order specified on the command line? I
couldn't find any conclusive evidence of what was intended in either
log messages or test cases.
--
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 4/4] cherry-pick/revert: default to topological sorting
y...@google.com writes: > From: Martin von Zweigbergk > > When 'git cherry-pick' and 'git revert' are used with ranges such as > 'git cherry-pick A..B', the order of the commits to pick are > determined by the default date-based sorting. If a commit has a commit > date before the commit date of its parent, it will therfore be applied > before its parent. Is that what --topo-order really means? I just tried this: $ git checkout v1.7.12-rc2 $ GIT_COMMITTER_DATE='@0 +' git commit --allow-empty -m old $ git log --pretty=fuller -2 and (obviously) the result shows the "old" one and then the v1.7.12-rc2. The point of --topo-order is to deal with merges more sensibly, I think, e.g. with a history with this shape with timestamps, ---1247 \ \ 3568--- "git log" may show "8 7 6 5 4 3 2 1", while "git log --topo-order" would give you "8 6 5 3 7 4 2 1". And indeed in the context of cherry-pick and revert, topo-order is a more sensible option. So there is nothing wrong in the patch, but the above explanation of yours is flawed. > In the context of cherry-pick/revert, this is most > likely not what the user expected, so let's enable topological sorting > by default. > > Signed-off-by: Martin von Zweigbergk > --- > builtin/revert.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/builtin/revert.c b/builtin/revert.c > index 98ad641..6880ce5 100644 > --- a/builtin/revert.c > +++ b/builtin/revert.c > @@ -194,6 +194,7 @@ static void parse_args(int argc, const char **argv, > struct replay_opts *opts) > opts->revs = xmalloc(sizeof(*opts->revs)); > init_revisions(opts->revs, NULL); > opts->revs->no_walk = REVISION_WALK_NO_WALK_UNSORTED; > + opts->revs->topo_order = 1; > if (argc < 2) > usage_with_options(usage_str, options); > memset(&s_r_opt, 0, sizeof(s_r_opt)); -- 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/4] revisions passed to cherry-pick should be in "default" order
On Sun, Aug 12, 2012 at 11:27 PM, wrote:
> From: Martin von Zweigbergk
>
> 'git cherry-pick' internally sets the --reverse option while walking
> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
> revisions starting at the oldest one.
By the way, I can see the usefulness of --reverse when giving a range,
but I think it's a little confusing when not giving a range. So "git
cherry-pick A B" will apply B first, then A. I thought I'd mention
that explicitly in case it wasn't clear.
--
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/4] revisions passed to cherry-pick should be in "default" order
y...@google.com writes:
> From: Martin von Zweigbergk
>
> 'git cherry-pick' internally sets the --reverse option while walking
> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
> revisions starting at the oldest one. If no uninteresing revisions are
> given, --no-walk is implied. Still, the documentation for 'git
> cherry-pick --stdin' uses the following example:
>
> git rev-list --reverse master -- README | git cherry-pick -n --stdin
>
> The above would seem to reverse the revisions in the output (which it
> does), and then pipe them to 'git cherry-pick', which would reverse
> them again and apply them in the wrong order.
I think we have cleared this confusion up in the previous
discussion. It it sequencer's bug that reorders the commits when
the caller ("rev-list --reverse" in this case) gives list of
individual commits to replay.
So I think we are all OK with chucking this patch. Am I mistaken?
--
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
Your branch and 'origin/master' have diverged
Hi all, A colleague of mine (after a relatively long absence) noticed the following when running "git status": # On branch master # Your branch and 'origin/master' have diverged, # and have 250 and 19 different commit(s) each, respectively. # nothing to commit (working directory clean) He asked me what to do and I told him to do what has always worked for me in the past when something like this happened: gitk, "reset master branch to here" (to a commit before the divergence and using --hard), git pull origin master. Problem solved. Well, not this one. This one is persistent. :-) I am at a loss what to do. "master" and "origin/master" do *not* point at the same commit. Even after the "git reset --hard ..." and "git pull". Running my silver bullet solution gets us in the same situation every time. I checked his .git/config and it looks fine. Any ideas? What information should I provide that might make it possible for you to help me? Cheers, Hilco -- 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: OSLC connectivity to GIT in Java
On Mon, Aug 13, 2012 at 8:12 AM, rahul.chandrashekar wrote: > I am interested to connect to a GIT SCM through OSLC. It seems to me a very strange request. There is a very well implemented, fit-for-purpose "git protocol". OSLC, after some googling, is a REST-style definition over HTTP. We already have a git-over-http protocol, not very efficient but opens a window of opportunity to those behind unreasonable firewalls. Perhaps it is a starting point for you. hth, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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 4/4] fetch-pack: mention server version with verbose output
Junio C Hamano writes: > Fetch-pack's verbose mode is more of a debugging mode (and in fact > takes two "-v" arguments to trigger via the porcelain layer). Let's > mention the server version as another possible item of interest. > > Signed-off-by: Jeff King > Signed-off-by: Junio C Hamano > --- > > * And this is your 4 adjusted for the previous one, releaving the >caller from having to figure out where the capability string >ends. Oops; this was a cut and paste error. There are these four (counting the blank after "Subject:") lines before the description. From: Jeff King Date: Fri, 10 Aug 2012 03:59:29 -0400 Subject: [PATCH] fetch-pack: mention server version with verbose output -- 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 4/4] fetch-pack: mention server version with verbose output
Fetch-pack's verbose mode is more of a debugging mode (and in fact
takes two "-v" arguments to trigger via the porcelain layer). Let's
mention the server version as another possible item of interest.
Signed-off-by: Jeff King
Signed-off-by: Junio C Hamano
---
* And this is your 4 adjusted for the previous one, releaving the
caller from having to figure out where the capability string
ends.
builtin/fetch-pack.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index fdec7f6..1633aa3 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -787,6 +787,8 @@ static struct ref *do_fetch_pack(int fd[2],
{
struct ref *ref = copy_ref_list(orig_ref);
unsigned char sha1[20];
+ const char *agent_feature = NULL;
+ int agent_len;
sort_ref_list(&ref, ref_compare_name);
@@ -829,8 +831,15 @@ static struct ref *do_fetch_pack(int fd[2],
fprintf(stderr, "Server supports ofs-delta\n");
} else
prefer_ofs_delta = 0;
- if (server_supports("agent"))
+
+ if ((agent_feature = server_feature("agent", &agent_len)) != NULL &&
+ 5 < agent_len && agent_feature[5] == '=') {
agent_supported = 1;
+ if (args.verbose) {
+ fprintf(stderr, "Server version is %.*s\n",
+ agent_len - 6, agent_feature + 6);
+ }
+ }
if (everything_local(&ref, nr_match, match)) {
packet_flush(fd[1]);
--
1.7.12.rc2.85.g1de7134
--
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 3/4] connect: learn to parse capabilities with values
Junio C Hamano writes:
> I forgot to mention it, but the above was done also to make it
> "possible but not mandatory" to pay extra allocation penalty. The
> caller can choose to parse the string into an int, for example,
> without extra allocation. Only the ones that want a string value
> and keep a copy around do have to do xmemdupz().
>
>> Anyway, do you think this is even worth doing at this point? I'm
>> lukewarm on the final two patches due to the existence of
>> GIT_TRACE_PACKET, which is much more likely to be useful.
>
> In the longer term, I think giving callers access to the parameter
> value given to a capability is necessary. If we had this facility
> in the old days, we wouldn't have done side-band-64k but spelled it
> as side-band=64k.
>
> For the agent=, certainly we don't need it.
Here are the first of two patches to replace your 3 and 4 without
extra allocations, primarily for further discussion.
-- >8 --
Subject: [PATCH 3/4] connect: expose the parameter to a capability
We already take care to parse a capability like "foo=bar" properly,
but the code does not provide a good way of actually finding out
what is on the right-hand side of the "=".
Based on the patch by Jeff King
Signed-off-by: Junio C Hamano
---
cache.h | 1 +
connect.c | 27 ---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 06413e1..d239cee 100644
--- a/cache.h
+++ b/cache.h
@@ -1030,6 +1030,7 @@ struct extra_have_objects {
};
extern struct ref **get_remote_heads(int in, struct ref **list, unsigned int
flags, struct extra_have_objects *);
extern int server_supports(const char *feature);
+extern const char *server_feature(const char *feature, int *len_ret);
extern const char *parse_feature_request(const char *features, const char
*feature);
extern struct packed_git *parse_pack_index(unsigned char *sha1, const char
*idx_path);
diff --git a/connect.c b/connect.c
index 912cdde..42640bc 100644
--- a/connect.c
+++ b/connect.c
@@ -99,12 +99,7 @@ struct ref **get_remote_heads(int in, struct ref **list,
return list;
}
-int server_supports(const char *feature)
-{
- return !!parse_feature_request(server_capabilities, feature);
-}
-
-const char *parse_feature_request(const char *feature_list, const char
*feature)
+static const char *parse_feature_request_1(const char *feature_list, const
char *feature, int *lenp)
{
int len;
@@ -117,13 +112,31 @@ const char *parse_feature_request(const char
*feature_list, const char *feature)
if (!found)
return NULL;
if ((feature_list == found || isspace(found[-1])) &&
- (!found[len] || isspace(found[len]) || found[len] == '='))
+ (!found[len] || isspace(found[len]) || found[len] == '=')) {
+ if (lenp)
+ *lenp = strcspn(found, " \t\n");
return found;
+ }
feature_list = found + 1;
}
return NULL;
}
+const char *parse_feature_request(const char *feature_list, const char
*feature)
+{
+ return parse_feature_request_1(feature_list, feature, NULL);
+}
+
+const char *server_feature(const char *feature, int *len)
+{
+ return parse_feature_request_1(server_capabilities, feature, len);
+}
+
+int server_supports(const char *feature)
+{
+ return !!server_feature(feature, NULL);
+}
+
enum protocol {
PROTO_LOCAL = 1,
PROTO_SSH,
--
1.7.12.rc2.85.g1de7134
--
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/4] Re: cherry-pick and 'log --no-walk' and ordering
On Mon, Aug 13, 2012 at 10:05 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: >> >> ... so is a migration desired? Or just >> change the default for --no-walk from "sorted" to "unsorted" in git >> 2.0? > > I think the proper support for Johannes's case should give users > more control on what to sort on, and that switch should not be tied > to "--no-walk". After all, being able to sort commits in the result > of limit_list() with various criteria would equally useful as being > able to sort commits listed on the command line with --no-walk. > Think about what "git shortlog A..B" does, for example. It is like > first enumerating commits within the given range, and sorting the > result using author as the primary and then timestamp as the > secondary sort column. > > So let's not even think about migration, and go in the direction of > giving "--no-walk" two flavours, for now. Either it keeps the order > commits were given from the command line, or it does the default > sort using the timestamp. We can later add the --sort-on option that > would work with or without --no-walk for people who want output that > is differently sorted, but that is outside the scope of your series. Makes sense. The shortlog example is a good example of sorting that completely reorders the commit graph sometimes even making sense for ranges. 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: Git add on deleted file
I think the message
no changes added to commit (use "git add" and/or "git commit -a")
is not clear enough since it lacks on the "git rm" command which
is shown above.
# (use "git add/rm ..." to update what will be committed)
Of course, applying this topic would solve this problem.
Alternatively we could adjust the message.
On Mon, Aug 13, 2012 at 7:54 PM, Junio C Hamano wrote:
> Angus Hammond writes:
>
>> ... Personally I'd like to see
>> "git add foo" here be equivalent "git rm --cached foo", but I can
>> understand how others might prefer git add not to be destructive like
>> that.
>
> Funny that you bring it up this week. As I wrote in
>
> http://git-blame.blogspot.com/2012/08/leftover-bits.html
>
> I think the following topic should be revisited:
>
> http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171841
>
> -- >8 --
> From: Junio C Hamano
> Date: Tue, 19 Apr 2011 12:18:20 -0700
> Subject: [PATCH] git add: notice removal of tracked paths by default
>
> When run without "-u" or "-A" option,
>
> $ edit subdir/x
> $ create subdir/y
> $ rm subdir/z
> $ git add subdir/
>
> does not notice removal of paths (e.g. subdir/z) from the working tree.
> Make "git add" to pretend as if "-A" is given when there is a pathspec on
> the command line. "git add" without any argument continues to be a no-op.
>
> When resolving a conflict to remove a path, the current code tells you to
> "git rm $path", but now with this patch you can say "git add $path". Of
> course you can do "git add -A $path" without this patch.
>
> In either case, the operation "git add" is about "adding the state of the
> path in the working tree to the index". The state may happen to be "path
> removed", not "path has an updated content".
>
> The semantic change can be seen by a breakage in t2200, test #15. There,
> a merge has conflicts in path4 and path6 (which are removed from the
> working tree), and test checks "git add path4" to resolve it must fail,
> and makes sure "add -u" needs to be used. We do not have to do this
> anymore.
>
> Signed-off-by: Junio C Hamano
> ---
> builtin/add.c | 3 +++
> t/t2200-add-update.sh | 4
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index 89dce56..4eae028 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -389,6 +389,9 @@ int cmd_add(int argc, const char **argv, const char
> *prefix)
>
> if (addremove && take_worktree_changes)
> die(_("-A and -u are mutually incompatible"));
> + /* default "git add pathspec..." to "git add -A pathspec..." */
> + if (!take_worktree_changes && argc)
> + addremove = 1;
> if (!show_only && ignore_missing)
> die(_("Option --ignore-missing can only be used together with
> --dry-run"));
> if ((addremove || take_worktree_changes) && !argc) {
> diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
> index 4cdebda..b2fcd01 100755
> --- a/t/t2200-add-update.sh
> +++ b/t/t2200-add-update.sh
> @@ -150,10 +150,6 @@ test_expect_success 'add -u resolves unmerged paths' '
> echo 2 >path3 &&
> echo 2 >path5 &&
>
> - # Explicit resolving by adding removed paths should fail
> - test_must_fail git add path4 &&
> - test_must_fail git add path6 &&
> -
> # "add -u" should notice removals no matter what stages
> # the index entries are in.
> git add -u &&
> --
> 1.7.12.rc2.85.g1de7134
>
> --
> 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
--
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 add on deleted file
Angus Hammond writes:
> ... Personally I'd like to see
> "git add foo" here be equivalent "git rm --cached foo", but I can
> understand how others might prefer git add not to be destructive like
> that.
Funny that you bring it up this week. As I wrote in
http://git-blame.blogspot.com/2012/08/leftover-bits.html
I think the following topic should be revisited:
http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171841
-- >8 --
From: Junio C Hamano
Date: Tue, 19 Apr 2011 12:18:20 -0700
Subject: [PATCH] git add: notice removal of tracked paths by default
When run without "-u" or "-A" option,
$ edit subdir/x
$ create subdir/y
$ rm subdir/z
$ git add subdir/
does not notice removal of paths (e.g. subdir/z) from the working tree.
Make "git add" to pretend as if "-A" is given when there is a pathspec on
the command line. "git add" without any argument continues to be a no-op.
When resolving a conflict to remove a path, the current code tells you to
"git rm $path", but now with this patch you can say "git add $path". Of
course you can do "git add -A $path" without this patch.
In either case, the operation "git add" is about "adding the state of the
path in the working tree to the index". The state may happen to be "path
removed", not "path has an updated content".
The semantic change can be seen by a breakage in t2200, test #15. There,
a merge has conflicts in path4 and path6 (which are removed from the
working tree), and test checks "git add path4" to resolve it must fail,
and makes sure "add -u" needs to be used. We do not have to do this
anymore.
Signed-off-by: Junio C Hamano
---
builtin/add.c | 3 +++
t/t2200-add-update.sh | 4
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 89dce56..4eae028 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -389,6 +389,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die(_("-A and -u are mutually incompatible"));
+ /* default "git add pathspec..." to "git add -A pathspec..." */
+ if (!take_worktree_changes && argc)
+ addremove = 1;
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with
--dry-run"));
if ((addremove || take_worktree_changes) && !argc) {
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index 4cdebda..b2fcd01 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -150,10 +150,6 @@ test_expect_success 'add -u resolves unmerged paths' '
echo 2 >path3 &&
echo 2 >path5 &&
- # Explicit resolving by adding removed paths should fail
- test_must_fail git add path4 &&
- test_must_fail git add path6 &&
-
# "add -u" should notice removals no matter what stages
# the index entries are in.
git add -u &&
--
1.7.12.rc2.85.g1de7134
--
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] help: correct behavior for is_executable on Windows
Heiko Voigt writes:
> Since the code for cygwin and windows in general is almost the same I would
> extract one function for them where I leave in one ifdef for cygwin.
>
> E.g. like this:
>
>
> static int is_executable(const char *name)
> {
> struct stat st;
>
> if (stat(name, &st) || /* stat, not lstat */
> !S_ISREG(st.st_mode))
> return 0;
>
> fill_platform_stat(name, &st);
>
> return st.st_mode & S_IXUSR;
> }
>
> which I could then define to a no op on posix. That way we avoid code
> duplication in the platform specific functions.
>
> What do you think?
Does having the "stat()" help on Windows in any way? Does it ever
return an executable bit by itself?
If not, Windows compat/ implementation may want to skip issuing a
useless stat() and write it as
if (has_extension(".exe"))
return 1;
if (contents_begins_with("MZ") || contents_begins_with("#!"))
return 1;
return 0;
without ever talking about stat() which is POSIXism compat/
implementation for Windows does not have to worry about.
And that was the reason I suggested making the whole implementation
of path_is_executable() overridable by compat/ layer.
But if having "stat()" helps on Windows, then your counterproposal
is good enough for me.
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: git svn clone, a non-standard layout question
>> [svn-remote "svn"] >> url = file:///home/chris/programs/svn/repo >> fetch = trunk:refs/remotes/svn/trunk >> branches = branches/*:refs/remotes/svn/* >> tags = tags/*:refs/remotes/svn/tags/* >> branches = branches/bdir/*:refs/remotes/svn/bdir2/* >> ignore-paths = ^branches/bdir$ >> ignore-refs = ^refs/remotes/bdir$ >> >> It doesn't seem to change anything. >> > > You need a git version new enough to include > cdb51a13c3cf4830d499d1138160eacdd2b8aa46, otherwise > it won't have any effect and will be silently ignored. > >> 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 >> Peter: I see what you mean. I will download a version of git that includes that commit and try again. Thanks for all your help, 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: git repack vs git gc --aggressive
Marc Branchaud writes: > On 12-08-10 04:09 PM, Junio C Hamano wrote: >> Felix Natter writes: >> >>> I have a few questions about this: >>> As I am coming from "large depth is harmful" school, I would recommend - "git repack -a -d -f" with large "--window" with reasonably short "--depth" once, >>> >>> So something like --depth=250 and --window=500? >> >> I would use more like --depth=16 or 32 in my local repositories. >> and mark the result with .keep; >>> >>> I guess you refer to a toplevel '.keep' file. >> >> Not at all. And it is not documented, it seems X-<. >> >> Typically you have a pair of files in .git/objects/pack, e.g. >> >> .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.idx >> .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.pack >> >> And you can add another file next to them >> >> .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.keep >> >> to prevent the pack from getting repacked. I think "git clone" does >> this for you after an initial import. > > 1.7.12.rc1 does not. Sorry, I misremembered. It was removed at 1db4a75 (Remove unnecessary pack-*.keep file after successful git-clone, 2008-07-08), so even when the sender gave you a crappy pack, you can repack locally to correct it. > Maybe clone should preserve the packs it gets from the upstream repo? That was part of the intention of the code 1db4a75 removed. > For > example, our main repo has a 690MB pack file that's marked .keep, but the > clone just ends up with a single 725MB pack file. Would our clones see > performance improvements if they that big 690MB pack separate from the others? There is no "pack boundary" in the object transfer protocol. What comes out of the wire is a single stream of pack data, so the above is not feasible without major surgery and backward incompatible change. -- 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 v2] Let submodule command exit with error status if path does not exist
Heiko Voigt writes:
> How about I update CodingGuidelines according to the rules you
> suggested? Then other people know how we prefer bash functions and if
> statements to look like.
OK. I was hoping that "imitate surrounding code" was sufficient,
but it seems many parts of the codebase have deteriorated enough to
make that rule no longer easy to follow.
>> Style:
>>
>> if test -z "$sm_path"
>> then
>> exit 1
>
> See above. If you agree I would add this style to the guidelines.
Likewise.
>> I know module_list would have said "error: pathspec 'no-such' did
>> not match any file(s) known to git. Did you forget to git add"
>> already, but because that comes at the very end of the input to the
>> filter written in perl (and with the way the filter is coded, it
>> will stay at the end), I am not sure if the user would notice it if
>> we exit like this. By the time we hit this exit, we would have seen
>> "Entering $sm_path..." followed by whatever message given while in
>> the submodule for all the submodules that comes out of module_list,
>> no?
>>
>> How about doing it this way to avoid that issue, to make sure we die
>> immediately after the typo is diagnosed without touching anything?
>
> I like it, your approach combines the atomicity of my first patch with
> the efficiency of not calling ls-files twice. I was hesitant to change
> to much code just to get the exit code right, but your approach looks
> good to me.
>
> Should I send an updated patch? Or do you just want to squash this in.
> Since now only the tests are from me what should we do with the
> ownership?
That is your itch and the idea and the bulk of the changes remains
to be yours in any case, methinks.
By the way, there is no reason for my patch to be unshifting the "#unmatch"
token into the array and spewing the array out, if the readers are always
going to stop upon seeing "#unmatch" without touching any submodule
that is named correctly on the command line. In other words, the
following should suffice:
while (<>) {
... accumulate in @out ...
}
if ($unmatched) {
print "#unmatched\n";
} else {
print for (@out);
}
--
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/4] Re: cherry-pick and 'log --no-walk' and ordering
Martin von Zweigbergk writes: > I also thought the sorting was just a bug. From what I understand by > looking how the code has evolved, the sorting in the no-walk case was > not intentional, but more of a consequence of the implementation. That > patch you suggested was my first attempt and led me to find the broken > cherry-pick test cases that I then fixed in patch 2/4. But, it clearly > would break the test case in t4202 called 'git log --no-walk > sorts by commit time'. So I started digging from there and found e.g. > > http://thread.gmane.org/gmane.comp.version-control.git/123205/focus=123216 > > For convenience, I have pasted the commit message of the commit > mentioned in that thread at the end of this email. So we would be > breaking at least Johannes's use case if we changed it. Ok. Having a way to conveniently sort based on committer date is indeed handy, and losing it would be a regression. Not that the accident that supports only on committer date is a nicely designed feature. The user may want to sort on author date instead, but there is no way to do so with --no-walk. So in that sense, Johannes's use case happens to work by accident. > ... so is a migration desired? Or just > change the default for --no-walk from "sorted" to "unsorted" in git > 2.0? I think the proper support for Johannes's case should give users more control on what to sort on, and that switch should not be tied to "--no-walk". After all, being able to sort commits in the result of limit_list() with various criteria would equally useful as being able to sort commits listed on the command line with --no-walk. Think about what "git shortlog A..B" does, for example. It is like first enumerating commits within the given range, and sorting the result using author as the primary and then timestamp as the secondary sort column. So let's not even think about migration, and go in the direction of giving "--no-walk" two flavours, for now. Either it keeps the order commits were given from the command line, or it does the default sort using the timestamp. We can later add the --sort-on option that would work with or without --no-walk for people who want output that is differently sorted, but that is outside the scope of your series. > By the way, git-log's documentation says "By default, the commits are > shown in reverse chronological order.", which to some degree is in > support of the current behavior. That is talking about the presentation order of the result of limit_list(), predates --no-walk, and was not adjusted to the new world order when --no-walk was introduced, so I would not take it as a supporting argument. But not regressing the current "you can see them sorted on the commit timestamp (this is merely an accident and not a designed feature, so you cannot choose to sort on other things)" behaviour is a reason enough not to disable sorting for the plain "--no-walk" option. 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: [PATCH] help: correct behavior for is_executable on Windows
On Sat, Aug 11, 2012 at 09:30:06PM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > help.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/help.c b/help.c
> > index 662349d..b41fa21 100644
> > --- a/help.c
> > +++ b/help.c
> > @@ -103,10 +103,19 @@ static int is_executable(const char *name)
> > return 0;
> >
> > #if defined(WIN32) || defined(__CYGWIN__)
> > + /* On Windows we cannot use the executable bit. The executable
> > +* state is determined by extension only. We do this first
> > +* because with virus scanners opening an executeable for
> > +* reading is potentially expensive.
> > +*/
> > + if (has_extension(name, ".exe"))
> > + return S_IXUSR;
> > +
> > #if defined(__CYGWIN__)
> > if ((st.st_mode & S_IXUSR) == 0)
> > #endif
> > -{ /* cannot trust the executable bit, peek into the file instead */
> > +{ /* now that we know it does not have an executable extension,
> > + peek into the file instead */
> > char buf[3] = { 0 };
> > int n;
> > int fd = open(name, O_RDONLY);
> > @@ -114,8 +123,8 @@ if ((st.st_mode & S_IXUSR) == 0)
> > if (fd >= 0) {
> > n = read(fd, buf, 2);
> > if (n == 2)
> > - /* DOS executables start with "MZ" */
> > - if (!strcmp(buf, "#!") || !strcmp(buf, "MZ"))
> > + /* look for a she-bang */
> > + if (!strcmp(buf, "#!"))
> > st.st_mode |= S_IXUSR;
> > close(fd);
> > }
>
> Would it make sense to move this to compat/win32/, compat/cygwin.c,
> and compat/posix.c, each exporting is_executable(const char *path),
> so that we do not have to suffer the #ifdef mess?
Yes that makes sense. But that means I need to test the code on multiple
platforms. To ease the merge in msysgit (the patch is already applied there)
I would suggest to post a follow up patch which would split up the function
into the platform specific parts.
Since the code for cygwin and windows in general is almost the same I would
extract one function for them where I leave in one ifdef for cygwin.
E.g. like this:
static int is_executable(const char *name)
{
struct stat st;
if (stat(name, &st) || /* stat, not lstat */
!S_ISREG(st.st_mode))
return 0;
fill_platform_stat(name, &st);
return st.st_mode & S_IXUSR;
}
which I could then define to a no op on posix. That way we avoid code
duplication in the platform specific functions.
What do you think?
Cheers Heiko
--
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 v2] Let submodule command exit with error status if path does not exist
Hi Junio,
thanks for such a thorough review.
On Sat, Aug 11, 2012 at 10:43:22PM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > I did not know that you prefer a space after the function name. I simply
> > imitated the style from C and there we do not have spaces. It makes the
> > style rules a bit more complicated. Wouldn't it be nicer to have the
> > same as in C so we have less rules?
>
> I do not think so, as they are different languages. The call site
> of C functions have name and opening parenthesis without a SP in
> between. The call site of shell functions do not even have
> parentheses.
>
> In any case, personal preferences (including mine) do not matter
> much, as there is no "this is scientificly superiour" in styles.
How about I update CodingGuidelines according to the rules you
suggested? Then other people know how we prefer bash functions and if
statements to look like.
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index aac575e..48014f2 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -109,7 +109,8 @@ resolve_relative_url ()
> > #
> > module_list()
> > {
> > - git ls-files --error-unmatch --stage -- "$@" |
> > + (git ls-files --error-unmatch --stage -- "$@" ||
> > + echo '16 0 ') |
>
> Is there a reason why the sentinel has to have the same mode pattern
> as a GITLINK entry, NULL SHA-1, stage #0? Or is the "path" being
> empty all that matters?
>
> Ah, OK, you did not want to touch the perl script downstream. I
> would have preferred a comment to document that, i.e.
I only described it in the commit message, sorry. Next time I will add a
comment.
> > @@ -385,6 +386,10 @@ cmd_foreach()
> > module_list |
> > while read mode sha1 stage sm_path
> > do
> > + if test -z "$sm_path"; then
> > + exit 1
>
> Style:
>
> if test -z "$sm_path"
> then
> exit 1
See above. If you agree I would add this style to the guidelines.
> I know module_list would have said "error: pathspec 'no-such' did
> not match any file(s) known to git. Did you forget to git add"
> already, but because that comes at the very end of the input to the
> filter written in perl (and with the way the filter is coded, it
> will stay at the end), I am not sure if the user would notice it if
> we exit like this. By the time we hit this exit, we would have seen
> "Entering $sm_path..." followed by whatever message given while in
> the submodule for all the submodules that comes out of module_list,
> no?
>
> How about doing it this way to avoid that issue, to make sure we die
> immediately after the typo is diagnosed without touching anything?
I like it, your approach combines the atomicity of my first patch with
the efficiency of not calling ls-files twice. I was hesitant to change
to much code just to get the exit code right, but your approach looks
good to me.
Should I send an updated patch? Or do you just want to squash this in.
Since now only the tests are from me what should we do with the
ownership?
> git-submodule.sh | 32 +---
> 1 file changed, 29 insertions(+), 3 deletions(-)
[...]
Cheers Heiko
--
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/4] Re: cherry-pick and 'log --no-walk' and ordering
On Mon, Aug 13, 2012 at 12:17 AM, Junio C Hamano wrote: > y...@google.com writes: > > [Administrivia: I somehow doubt y...@google.com would reach you, and > futzed with the To: line above] :-( Sorry, sendemail.from now set. (I apparently answered "y" instead of just to accept the default.) > I actually think --no-walk, especially when given any negative > revision, that sorts is fundamentally a flawed concept (it led to > the inconsistency that made "git show A..B C" vs "git show C A..B" > behave differently, which we had to fix recently). I completely agree. > Would anything break if we take your patch, but without two > possibilities to revs->no_walk option (i.e. we never sort under > no_walk)? That is, the core of your change would become something > like this: I also thought the sorting was just a bug. From what I understand by looking how the code has evolved, the sorting in the no-walk case was not intentional, but more of a consequence of the implementation. That patch you suggested was my first attempt and led me to find the broken cherry-pick test cases that I then fixed in patch 2/4. But, it clearly would break the test case in t4202 called 'git log --no-walk sorts by commit time'. So I started digging from there and found e.g. http://thread.gmane.org/gmane.comp.version-control.git/123205/focus=123216 For convenience, I have pasted the commit message of the commit mentioned in that thread at the end of this email. So we would be breaking at least Johannes's use case if we changed it. I would think almost everyone who doesn't already know would expect "git rev-list A B" to list them in that order, so is a migration desired? Or just change the default for --no-walk from "sorted" to "unsorted" in git 2.0? By the way, git-log's documentation says "By default, the commits are shown in reverse chronological order.", which to some degree is in support of the current behavior. commit 8e64006eee9c82eba513b98306c179c9e2385e4e Author: Johannes Schindelin Date: Tue Jul 24 00:38:40 2007 +0100 Teach revision machinery about --no-walk The flag "no_walk" is present in struct rev_info since a long time, but so far has been in use exclusively by "git show". With this flag, you can see all your refs, ordered by date of the last commit: $ git log --abbrev-commit --pretty=oneline --decorate --all --no-walk which is extremely helpful if you have to juggle with a lot topic branches, and do not remember in which one you introduced that uber debug option, or simply want to get an overview what is cooking. (Note that the "git log" invocation above does not output the same as $ git show --abbrev-commit --pretty=oneline --decorate --all --quiet since "git show" keeps the alphabetic order that "--all" returns the refs in, even if the option "--date-order" was passed.) For good measure, this also adds the "--do-walk" option which overrides "--no-walk". Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano -- 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 diff vs git diff-files
On Mon, Aug 13, 2012 at 5:02 PM, Thomas Rast wrote: > Can you share this repository? This weird behaviour doesn't even survive making a copy (cp -a) of the whole repository, so I very much doubt making it available would be illuminative. My disk's SMART data seems okay. The weird-quotient just rose a bit. Besides, .git/ is 60MB and my upload speed is 128kbps. A bit inconvenient. > Or at least the pre- and post-change > files, transferred in such a way that there won't be any whitespace > damage (your snippets above show obvious damage). You can use http://www.bpj-code.co.za/downloads.php/bugs/TwoStageAmp-output.net?text contains the output from git show a5ee1e7. Leave off the ?text for an application/octet-stream download. That file (with the Q1 line present) is consistent with the earlier commit that added the file. It's diff-files that's lying. > Do you have any diff config that could be of interest? A textconv > filter would be an obvious example that could produce the above, but > perhaps you could just look at Nothing that fancy. I have just diff.color = auto and user.* = blah in global config, and similarly benign config in the repository. -- 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 diff vs git diff-files
Bernd Jendrissek writes: > $ /usr/local/git/bin/git diff-files -p --color -- TwoStageAmp-output.net > diff --git a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net > b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net > index a5ee1e7..a9f3620 100644 > $ /usr/local/git/bin/git diff TwoStageAmp-output.netdiff --git > a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net > b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.n > index a5ee1e7..a9f3620 100644 What's surprising is that both diff show the same "index" line, so both commands actually diff the same content, and then show a different output. You can try something like git cat-file blob a5ee1e7 > /tmp/staged.txt diff -u /tmp/staged.txt TwoStageAmp-output.netdiff to recover the content from the index (Thomas' version should also work and give the same result), and use another diff tool. This "diff -u" should give you an output similar to one of "git diff" and "git diff-files" (my understanding is that it should match diff-files, and "git diff" is the one being wrong here). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 diff vs git diff-files
Bernd Jendrissek writes:
> $ /usr/local/git/bin/git diff-files -p --color -- TwoStageAmp-output.net
> diff --git a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> index a5ee1e7..a9f3620 100644
> --- a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> +++ b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> @@ -1,47 +1,47 @@
> -Part unknown { Name Cout }
> -Part unknown { Name R5 }
> -Part unknown { Name R4 }
> -Part unknown { Name RE2 }
> -Part unknown { Name Q2 }
> +Part unknown { Name R8 }
> Part unknown { Name A3 }
> -Part unknown { Name R3 }
> Part unknown { Name A2 }
> -Part unknown { Name RE1 }
> Part unknown { Name A1 }
> [snip]
>
> $ /usr/local/git/bin/git diff TwoStageAmp-output.netdiff --git
> a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.n
> index a5ee1e7..a9f3620 100644
> --- a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> +++ b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
> @@ -1,47 +1,47 @@
> -Part unknown { Name Cout }
> -Part unknown { Name R5 }
> -Part unknown { Name R4 }
> -Part unknown { Name RE2 }
> -Part unknown { Name Q2 }
> +Part unknown { Name R8 }
> Part unknown { Name A3 }
> -Part unknown { Name R3 }
> Part unknown { Name A2 }
> -Part unknown { Name RE1 }
> -Part unknown { Name Q1 } <--- Not present with diff-files output
> Part unknown { Name A1 }
> [snip]
Can you share this repository? Or at least the pre- and post-change
files, transferred in such a way that there won't be any whitespace
damage (your snippets above show obvious damage). You can use
git cat-file blob :gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
to get at the contents of the version in the index.
Do you have any diff config that could be of interest? A textconv
filter would be an obvious example that could produce the above, but
perhaps you could just look at
git config --get-regexp '.*diff.*'
grep diff .gitattributes .git/info/attributes
etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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 repack vs git gc --aggressive
On 12-08-10 04:09 PM, Junio C Hamano wrote: > Felix Natter writes: > >> I have a few questions about this: >> >>> As I am coming from "large depth is harmful" school, I would >>> recommend >>> >>> - "git repack -a -d -f" with large "--window" with reasonably short >>>"--depth" once, >> >> So something like --depth=250 and --window=500? > > I would use more like --depth=16 or 32 in my local repositories. > >>> and mark the result with .keep; >> >> I guess you refer to a toplevel '.keep' file. > > Not at all. And it is not documented, it seems X-<. > > Typically you have a pair of files in .git/objects/pack, e.g. > > .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.idx > .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.pack > > And you can add another file next to them > > .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.keep > > to prevent the pack from getting repacked. I think "git clone" does > this for you after an initial import. 1.7.12.rc1 does not. I even cloned from a repo with a few .keep files, but ended up with only one big .pack file. Maybe clone should preserve the packs it gets from the upstream repo? For example, our main repo has a 690MB pack file that's marked .keep, but the clone just ends up with a single 725MB pack file. Would our clones see performance improvements if they that big 690MB pack separate from the others? Perhaps the fact that clone creates a single pack file makes it impossible to preserve the .keep packs from the upstream? (I figure it's probably not a good idea for clone to .keep the single pack file it creates.) M. -- 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 svn clone, a non-standard layout question
On Mon, Aug 13, 2012 at 09:29:53AM -0400, Christopher Marshall wrote:
> >
> > I had a similar problem, but I solved it using "ignore-paths" and
> > "ignore-refs".
> > If I remember correctly, you need to set both to ignore bdir directly
> > without
> > ignoring b3, b4,...
> >
> > For ignore-refs, pls see cdb51a13c3cf4830d499d1138160eacdd2b8aa46, as it is
> > currently
> > undocumented.
> >
> > So I would try experimenting with the following settings:
> >
> > [svn-remote "svn"]
> > url = file:///home/chris/programs/svn/repo
> > fetch = trunk:refs/remotes/svn/trunk
> > tags = tags/*:refs/remotes/svn/tags/*
> > branches = branches/{b1,b2}:refs/remotes/svn/*
> > branches = branches/bdir/{b3,b4}:refs/remotes/svn/*
> >
> > # Operates on the imported git branches
> > ignore-refs = ^refs/remotes/bdir$
> >
> > # Operates on the SVN branches; you might try it first without this
> > statement
> > ignore-paths = ^branches/bdir$
> > --
>
> Peter:
>
> Thanks for the advice. I tried this:
>
> [svn-remote "svn"]
> url = file:///home/chris/programs/svn/repo
> fetch = trunk:refs/remotes/svn/trunk
> branches = branches/*:refs/remotes/svn/*
> tags = tags/*:refs/remotes/svn/tags/*
> branches = branches/bdir/*:refs/remotes/svn/bdir2/*
> ignore-paths = ^branches/bdir$
> ignore-refs = ^refs/remotes/bdir$
>
> It doesn't seem to change anything.
>
You need a git version new enough to include
cdb51a13c3cf4830d499d1138160eacdd2b8aa46, otherwise
it won't have any effect and will be silently ignored.
> 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
>
--
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 svn clone, a non-standard layout question
>
> I had a similar problem, but I solved it using "ignore-paths" and
> "ignore-refs".
> If I remember correctly, you need to set both to ignore bdir directly without
> ignoring b3, b4,...
>
> For ignore-refs, pls see cdb51a13c3cf4830d499d1138160eacdd2b8aa46, as it is
> currently
> undocumented.
>
> So I would try experimenting with the following settings:
>
> [svn-remote "svn"]
> url = file:///home/chris/programs/svn/repo
> fetch = trunk:refs/remotes/svn/trunk
> tags = tags/*:refs/remotes/svn/tags/*
> branches = branches/{b1,b2}:refs/remotes/svn/*
> branches = branches/bdir/{b3,b4}:refs/remotes/svn/*
>
> # Operates on the imported git branches
> ignore-refs = ^refs/remotes/bdir$
>
> # Operates on the SVN branches; you might try it first without this
> statement
> ignore-paths = ^branches/bdir$
> --
Peter:
Thanks for the advice. I tried this:
[svn-remote "svn"]
url = file:///home/chris/programs/svn/repo
fetch = trunk:refs/remotes/svn/trunk
branches = branches/*:refs/remotes/svn/*
tags = tags/*:refs/remotes/svn/tags/*
branches = branches/bdir/*:refs/remotes/svn/bdir2/*
ignore-paths = ^branches/bdir$
ignore-refs = ^refs/remotes/bdir$
It doesn't seem to change anything.
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
OSLC connectivity to GIT in Java
Hello, I am interested to connect to a GIT SCM through OSLC. I would prefer to use Java as a technology. I have come across an Eclipse proposal called Lyo, kindly let me know if this can fulfill my requirement, and if "Yes" --> How? Kindly do let know on any similar approaches. regds Rahul -- View this message in context: http://git.661346.n2.nabble.com/OSLC-connectivity-to-GIT-in-Java-tp7564860.html Sent from the git mailing list archive at Nabble.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
git diff vs git diff-files
I have a billion testsuite golden output files that have changed due
to an explicit ordering of objects I've imposed on output. A helper
script I wrote to help parse the diffs (to ignore order-only
differences) noticed that one hunk had a different number of additions
and deletions. I'm manually copying and pasting the hunks from git add
-i into the script. However, when I used git diff to get at the
changes, to discover which line was the offending one, all additions
and deletions were exactly matched!
With strace I noticed that git add -i calls git diff-files, and that's
about as far as I can conveniently trace where things are going weird.
Weird:
$ /usr/local/git/bin/git diff-files -p --color -- TwoStageAmp-output.net
diff --git a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
index a5ee1e7..a9f3620 100644
--- a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
+++ b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
@@ -1,47 +1,47 @@
-Part unknown { Name Cout }
-Part unknown { Name R5 }
-Part unknown { Name R4 }
-Part unknown { Name RE2 }
-Part unknown { Name Q2 }
+Part unknown { Name R8 }
Part unknown { Name A3 }
-Part unknown { Name R3 }
Part unknown { Name A2 }
-Part unknown { Name RE1 }
Part unknown { Name A1 }
[snip]
$ /usr/local/git/bin/git diff TwoStageAmp-output.netdiff --git
a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.n
index a5ee1e7..a9f3620 100644
--- a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
+++ b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
@@ -1,47 +1,47 @@
-Part unknown { Name Cout }
-Part unknown { Name R5 }
-Part unknown { Name R4 }
-Part unknown { Name RE2 }
-Part unknown { Name Q2 }
+Part unknown { Name R8 }
Part unknown { Name A3 }
-Part unknown { Name R3 }
Part unknown { Name A2 }
-Part unknown { Name RE1 }
-Part unknown { Name Q1 } <--- Not present with diff-files output
Part unknown { Name A1 }
[snip]
The index is clean on TwoStageAmp-output.net (but by now a million
other files are dirty in the index). While I discovered this issue
with Ubuntu's 1.7.1, I got the same behaviour with git
1.7.12.rc2.18.g61b472e
What's going on here? I'll leave my tree in whatever weird state it
might be, for a while, in case anyone wants me to try various things.
At this point I want to understand what's going on, in case there's
either a learning moment for me or a bug, rather than just finding a
workaround.
--
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 (Aug 2012, #03; Mon, 13)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. 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"] * bw/maint-1.7.9-solaris-getpass (2012-08-06) 2 commits (merged to 'next' on 2012-08-07 at d78bc37) + Enable HAVE_DEV_TTY for Solaris + terminal: seek when switching between reading and writing The recent update to terminal I/O interface to get passwords &c interactively didn't quite work on Solaris. -- [New Topics] * bc/receive-pack-stdout-protection (2012-08-06) 2 commits (merged to 'next' on 2012-08-07 at d7aa316) + receive-pack: do not leak output from auto-gc to standard output + t/t5400: demonstrate breakage caused by informational message from prune When "git push" triggered the automatic gc on the receiving end, a message from "git prune" that said it was removing cruft leaked to the standard output, breaking the communication protocol. Not urgent (non regression). * bc/prune-info (2012-08-07) 1 commit - prune.c: only print informational message in show_only or verbose mode Teach "git prune" without "-v" to be silent about leftover temporary files. Not urgent (non regression). * jc/tag-doc (2012-08-06) 1 commit - Documentation: do not mention .git/refs/* directories Our documentation used to assume having files in .git/refs/* directories was the only to have branches and tags, but that is not true for quite some time. Not urgent (non regression). * jk/docs-docbook-monospace-display (2012-08-07) 1 commit - docs: monospace listings in docbook output The documentation in the TeXinfo format was using indented output for materials meant to be examples that are better typeset in monospace. Not urgent (non regression). * jc/maint-protect-sh-from-ifs (2012-08-08) 1 commit - sh-setup: protect from exported IFS When the user exports a non-default IFS without HT, scripts that rely on being able to parse "ls-files -s | while read a b c..." start to fail. Protect them from such a misconfiguration. * jk/check-docs-update (2012-08-08) 8 commits - check-docs: get documented command list from Makefile - check-docs: drop git-help special-case - check-docs: list git-gui as a command - check-docs: factor out command-list - command-list: mention git-credential-* helpers - command-list: add git-sh-i18n - check-docs: update non-command documentation list - check-docs: mention gitweb specially Simplify "make check-docs" implementation and update its coverage. * js/gitweb-path-info-unquote (2012-08-09) 1 commit - gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO Stripping of PATH_INFO in gitweb did not take url style quoting into account, failing to notice directories with funny characters e.g. SP in their paths. * mg/rebase-i-onto-reflog-in-full (2012-08-10) 1 commit - rebase -i: use full onto sha1 in reflog The reflog entries left by "git rebase" and "git rebase -i" were inconsistent. * mz/empty-rebase-test (2012-08-09) 1 commit - add tests for 'git rebase --keep-empty' * jc/capabilities (2012-08-10) 1 commit - fetch-pack: do not ask for unadvertised capabilities (this branch uses jk/version-string.) Some capabilities were asked by fetch-pack even when upload-pack did not advertise that they are available. Fix fetch-pack not to do so. May have to be rebased to older maintenance tracks before moving forward. * pw/p4-use-client-spec-branch-detection (2012-08-11) 5 commits - git p4: make branch detection work with --use-client-spec - git p4: do wildcard decoding in stripRepoPath - git p4: set self.branchPrefixes in initialization - git p4 test: add broken --use-client-spec --detect-branches tests - git p4 test: move client_view() function to library -- [Stalled] * mz/rebase-range (2012-07-18) 7 commits . rebase (without -p): correctly calculate patches to rebase . rebase -p: don't request --left-right only to ignore left side . rebase -p: use --cherry-mark for todo file . git-rebase--interactive.sh: look up subject in add_pick_line . git-rebase--interactive: group all $preserve_merges code . git-rebase--interactive.sh: extract function for adding "pick" line . git-rebase--am.sh: avoid special-casing --keep-empty Expecting a reroll. Performance concerns from Windows folks. Also the series lacks proper sign-offs. * jl/submodule-rm (2012-07-05) 2 commits - rm: remove submodules from the index and the .gitmodules file - rm: don't fail when removing populated submodules Expecting a reroll. * ph/stash-rerere (2012-07-08) 2 commits - stash: invoke rerere in case of conflict - test: git-stash conflict sets up rerere Will be rerolled but is going in the right dir
Re: [PATCH/RFC] index-pack: produce pack index version 3
Nguyen Thai Ngoc Duy writes: > On Mon, Aug 13, 2012 at 2:49 AM, Junio C Hamano wrote: >> For example, the reachability bitmap would want to say something >> like "Traversing from commit A, these objects in this pack are >> reachable." The bitmap for one commit A would logically consist of >> N bits for a packfile that stores N objects (the resulting bitmap >> needs to be compressed before going to disk, perhaps with RLE or >> something). With the single "sorted by SHA-1" table, we can use the >> index in that single table to enumerate all reachable objects of any >> type in one go. With four separate tables, on the other hand, we >> would need four bitmaps per commit. > > No we still need one per commit. The n-th bit is in the order of the > object in the pack, not the index. How sha-1 is sorted does not > matter. Then what is the problem of using that same "N" that counts the object using the order of the objects in the pack as a short-hand to the object name instead, if your objective is to avoid having to repeat the full 20-byte object name in your secondary tables? That does not call for any split in the list of SHA-1s, no? >> Either way is _possible_, but I think the former is simpler, and the >> latter makes it harder to introduce new types of objects in the >> future, which I do not think we have examined possible use cases >> well enough to make that decision to say "four types is enough >> forever". > > New types can be put in one of those four tables, depending on its > purpose. The reason I split because I care particularly about commits > and trees. If the new type serves the same purpose as tree, for > example, then it's better put in tree table... And when there are multiple uses, one that wants to treat trees and commits more or less the same way, and another that wants to treat them in a distinct way, even without considering a new type, how would your "we have four separate tables" help? The former user wants three "commits+trees", "tags" and "blobs" table while the latter wants four, no? >> In either way, we would have such bitmap (or a set of four bitmaps >> in your case) for more than one commit (it is not necessary or >> desirable to add the reachability bitmap to all commits), and such a >> "reachability extension" would need to store a sequence of "the >> commit object name the bitmap (or a set of four bitmaps) is about, >> and the bitmap (or set of four bitmaps)". That object name does not >> have to be 20-byte but would be a varint representation of the >> offset into the "sorted by SHA-1" table. > > How do you reach the bitmap, given its commit sha-1? Look at the ordered list of SHA-1 in the pack idx file as an array of 20-byte entries, and find the commit SHA-1 in that array by Newton-Raphson/bisection. You have an index into the array that holds the object name. You can use it as the local object number in the packfile. Then you can find that object number (that is shorter than 20-byte object name) in your secondary table, no? -- 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/4] Re: cherry-pick and 'log --no-walk' and ordering
Junio C Hamano writes: > Would anything break if we take your patch, but without two > possibilities to revs->no_walk option (i.e. we never sort under > no_walk)? By the way, by "would anything break", I do not just mean if our existing tests trigger failures from "test_expect_success"; I suspect some do assume the sorting behaviour. I am wondering if the sorting makes sense in the real users; in other words, if the failing tests, if any, are expecting sensible and useful behaviour. After all, the sorting by the commit timestamp is made solely to optimize the limit_list() which wants to traverse commits ancestry near the tip of the history, and sorting by the commit timestamp is done because it is usually a good and quick approximation for topological sorting. -- 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/4] Re: cherry-pick and 'log --no-walk' and ordering
y...@google.com writes: [Administrivia: I somehow doubt y...@google.com would reach you, and futzed with the To: line above] > From: Martin von Zweigbergk > > This series adds supports for 'git log --no-walk=unsorted', which > should be useful for the re-roll of my mz/rebase-range series. It also > addresses the bug in cherry-pick/revert, which makes it sort revisions > by date. > > On Fri, Aug 10, 2012 at 11:28 PM, Junio C Hamano wrote: >> Range limited revision walking, e.g. "git cherry-pick A..B D~4..D", >> fundamentally implies sorting and you cannot assume B would appear >> before D only because B comes before D on the command line (B may >> even be inside D~4..D range in which case it would not even appear >> in the final output). > > Sorry, I probably wasn't clear; I mentioned "revision walking", but I > only meant the no-walk case. I hope the patches make sense. I actually think --no-walk, especially when given any negative revision, that sorts is fundamentally a flawed concept (it led to the inconsistency that made "git show A..B C" vs "git show C A..B" behave differently, which we had to fix recently). Would anything break if we take your patch, but without two possibilities to revs->no_walk option (i.e. we never sort under no_walk)? That is, the core of your change would become something like this: revision.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/revision.c b/revision.c index 9e8f47a..589d17f 100644 --- a/revision.c +++ b/revision.c @@ -2116,12 +2116,12 @@ int prepare_revision_walk(struct rev_info *revs) } e++; } - commit_list_sort_by_date(&revs->commits); if (!revs->leak_pending) free(list); if (revs->no_walk) return 0; + commit_list_sort_by_date(&revs->commits); if (revs->limited) if (limit_list(revs) < 0) return -1; -- 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 1/2] git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip
Steven Walter wrote:
> Consider the case where you have trunk, branchA of trunk, and branchB of
> branchA. trunk is merged back into branchB, and then branchB is
> reintegrated into trunk. The merge of branchB into trunk will have
> svn:mergeinfo property references to both branchA and branchB. When
> performing the check_cherry_pick check on branchB, it is necessary to
> eliminate the merged contents of branchA as well as branchB, or else the
> merge will be incorrectly ignored as a cherry-pick.
>
> Signed-off-by: Steven Walter
> ---
I think this series is good, but would feel more comfortable if
I got a second opinion from Sam.
This doesn't apply against Junio's master (nor mine on
git://bogomips.org/git-svn.git), though it works fine on Junio's maint.
> git-svn.perl|8 ++-
> t/t9163-git-svn-fetch-merge-branch-of-branch.sh | 60
> +++
> 2 files changed, 63 insertions(+), 5 deletions(-)
> create mode 100755 t/t9163-git-svn-fetch-merge-branch-of-branch.sh
>
> diff --git a/git-svn.perl b/git-svn.perl
> index ca038ec..abcec11 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -3657,14 +3657,14 @@ sub find_extra_svn_parents {
> my @merge_tips;
> my $url = $self->{url};
> my $uuid = $self->ra_uuid;
> - my %ranges;
> + my @all_ranges;
> for my $merge ( @merges ) {
> my ($tip_commit, @ranges) =
> lookup_svn_merge( $uuid, $url, $merge );
> unless (!$tip_commit or
> grep { $_ eq $tip_commit } @$parents ) {
> push @merge_tips, $tip_commit;
> - $ranges{$tip_commit} = \@ranges;
> + push @all_ranges, @ranges;
> } else {
> push @merge_tips, undef;
> }
> @@ -3679,8 +3679,6 @@ sub find_extra_svn_parents {
> my $spec = shift @merges;
> next unless $merge_tip and $excluded{$merge_tip};
>
> - my $ranges = $ranges{$merge_tip};
> -
> # check out 'new' tips
> my $merge_base;
> eval {
> @@ -3702,7 +3700,7 @@ sub find_extra_svn_parents {
> my (@incomplete) = check_cherry_pick(
> $merge_base, $merge_tip,
> $parents,
> - @$ranges,
> + @all_ranges,
> );
>
> if ( @incomplete ) {
> diff --git a/t/t9163-git-svn-fetch-merge-branch-of-branch.sh
> b/t/t9163-git-svn-fetch-merge-branch-of-branch.sh
> new file mode 100755
> index 000..13ae7e3
> --- /dev/null
> +++ b/t/t9163-git-svn-fetch-merge-branch-of-branch.sh
> @@ -0,0 +1,60 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2012 Steven Walter
> +#
> +
> +test_description='git svn merge detection'
> +. ./lib-git-svn.sh
> +
> +svn_ver="$(svn --version --quiet)"
> +case $svn_ver in
> +0.* | 1.[0-4].*)
> + skip_all="skipping git-svn test - SVN too old ($svn_ver)"
> + test_done
> + ;;
> +esac
> +
> +test_expect_success 'initialize source svn repo' '
> + svn_cmd mkdir -m x "$svnrepo"/trunk &&
> + svn_cmd mkdir -m x "$svnrepo"/branches &&
> + svn_cmd co "$svnrepo"/trunk "$SVN_TREE" &&
> + (
> + cd "$SVN_TREE" &&
> + touch foo &&
> + svn_cmd add foo &&
> + svn_cmd commit -m "initial commit" &&
> + svn_cmd cp -m branch "$svnrepo"/trunk
> "$svnrepo"/branches/branch1 &&
> + svn_cmd switch "$svnrepo"/branches/branch1 &&
> + touch bar &&
> + svn_cmd add bar &&
> + svn_cmd commit -m branch1 &&
> + svn_cmd cp -m branch "$svnrepo"/branches/branch1
> "$svnrepo"/branches/branch2 &&
> + svn_cmd switch "$svnrepo"/branches/branch2 &&
> + touch baz &&
> + svn_cmd add baz &&
> + svn_cmd commit -m branch2 &&
> + svn_cmd switch "$svnrepo"/trunk &&
> + touch bar2 &&
> + svn_cmd add bar2 &&
> + svn_cmd commit -m trunk &&
> + svn_cmd switch "$svnrepo"/branches/branch2 &&
> + svn_cmd merge "$svnrepo"/trunk &&
> + svn_cmd commit -m "merge trunk"
> + svn_cmd switch "$svnrepo"/trunk &&
> + svn_cmd merge --reintegrate "$svnrepo"/branches/branch2 &&
> + svn_cmd commit -m "merge branch2"
> + ) &&
> + rm -rf "$SVN_TREE"
> +'
> +
> +test_expect_success 'clone svn repo' '
> + git svn init -s "$svnrepo" &&
> + git svn fetch
> +'
> +
> +test_expect_success 'verify merge commit' 'x=$(git rev-parse HEAD^2) &&
> + y=$(git rev-parse branch2) &&
> + test "x$x" = "x$y"
> +'
> +
> +test_done
> --
> 1.7.9.5
--
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
