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.
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 als
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
suspec
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
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-publi
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 co
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
>
> 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.
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,
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,
>>
>> S
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/com
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/gi
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
ro
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
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
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 +1
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
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 d
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 sh
>> [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/*
>>
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;
>
>
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
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.
Alternativel
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 o
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
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 t
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
> ---
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
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
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 im
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 o
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 i
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 oldes
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 bot
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],
>
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
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.k
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 respon
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_p
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) {
> >> + fpri
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 unsubs
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
>
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
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/20
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 +++--
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 defaul
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
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
> c
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
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
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] == '=') {
> > >>
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 inter
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 Solut
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-
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_f
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-op
56 matches
Mail list logo
