Make sure t9164 conforms with the coding guidelines:
- remove spaces after redirection operators;
- insert spaces between function names and parentheses;
- split `if ...; then' lines;
- use `test' instead of `['.
Signed-off-by: Robert Luberda
---
t/t9164-git-svn-dcommit-concurrent.sh | 69
On Thu, Aug 30, 2012 at 02:46:03PM -0700, Paul E. McKenney wrote:
> On Thu, Aug 30, 2012 at 11:56:09AM -0700, Josh Triplett wrote:
> > On Thu, Aug 30, 2012 at 11:44:48AM -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > This series covers changes to rcutorture and documentation updates.
> >
With paint_down_to_common(), we can tell if "commit" is reachable
from "reference" by simply looking at its object flag, instead of
iterating over the merge bases.
---
commit.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/commit.c b/commit.c
index 0058fa5.
The get_merge_bases_many() function reduces the result returned by
the merge_bases_many() function, which is a set of possible merge
bases, by excluding commits that can be reached from other commits.
We used to do N*(N-1) traversals for this, but we can check if one
commit reaches which other (N-1
In many scripted Porcelain commands, we find this idiom:
if test "$(git rev-parse --verify A)" = "$(git merge-base A B)"
then
... A is an ancestor of B ...
fi
But you do not have to compute exact merge-base only to see if A is
an ancestor of B. Give them a more direct way to
Introduce a new helper function paint_down_to_common() that takes
the same parameters as merge_bases_many(), but without the first
optimization of not painting anything when "one" is one of the
"twos" (or vice versa), and the last clean-up of removing the common
ancestor that is known to be an ance
This replaces the topmost commit from the earlier series that tried
to optimize N*(N-1) loop with N traversals. With this, running the
following script in the kernel repository:
-- >8 --
#!/bin/sh
git rev-list --committer=torva...@linux-foundation.org \
--max-parents=2 --min-parents=2 --pare
When using the {word,[...]} style of configuration for tags and branches,
it appears the intent is to only match whole path parts, since the words
in the {} pattern are meta-character quoted.
When the pattern word appears in the beginning or middle of the url,
it's matched completely, since the le
On Sat, Aug 11, 2012 at 11:37:05PM +0200, Sven Strickroth wrote:
> Am 11.08.2012 22:53 schrieb René Scharfe:
> > The standard says we need to convert to CP437, or to UTF-8, or provide
> > both versions. A more interesting question is: What's supported by which
> > programs?
> >
> > The ZIP func
Jeff King writes:
> So the issue is that when you do a recursive merge with multiple bases,
> the order in which you visit the recursive bases is going to impact the
> exact conflicts you see.
Yeah, that explains it.
> So the test is not broken or racy, which is good. It is just testing
> somet
Jeff King writes:
> Compared to dropping an O(n^2) operation to O(lg n), that's
> probably not even going to be noticeable.
Yeah, that is something we would want to use when we eventually
update the main revision traverser, not this codepath localized to
the merge-base.
Thanks. I like (and agr
On Thu, Aug 30, 2012 at 09:33:48AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The script originally comes from here:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/33566/focus=33852
> >
> > and the discussion implies that the AUTHOR_DATEs were added to avoid a
> > r
Thomas Ackermann writes:
> I am using MsysGit 1.7.11 on WinXP 32 bit and experience the folllowing
> strange behaviour:
>
> For a file like "File.txt" in the repo, "git blame file.txt" (note the lower
> case)
> shows "Not commited yet" for every single line in the file.
> "git blame File.txt
On Thu, Aug 30, 2012 at 09:23:25AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Anyway, since this isn't yielding any performance benefit, I'm not going
> > to go down that route. But stability of the queue is something that we
> > need to consider if we ever do replace commit_list wit
Martin von Zweigbergk writes:
> Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't
> currently work. Add a test case to demonstrate it.
>
> Signed-off-by: Martin von Zweigbergk
> ---
> t/t3508-cherry-pick-many-commits.sh | 15 +++
> 1 file changed, 15 insertions(
car...@cmartin.tk (Carlos Martín Nieto) writes:
> Junio C Hamano writes:
>
>> Carlos Martín Nieto writes:
>>
>>> As a result of making --unset-upstream fail if the given branch
>>> doesn't exist, I discovered a copy-paste error in on the the tests in
>>> the patch after it, so I'm resending the
Erik Faye-Lund writes:
> On Mon, Aug 27, 2012 at 12:04 AM, Philipp A. Hartmann wrote:
>> From: "Philipp A. Hartmann"
>>
>> This patch is an experiment to port the wincred helper
>> to the generic implementation. As of know, it is
>> completely untested.
>>
>> In addition to porting the helper
Junio C Hamano writes:
> Carlos Martín Nieto writes:
>
>> As a result of making --unset-upstream fail if the given branch
>> doesn't exist, I discovered a copy-paste error in on the the tests in
>> the patch after it, so I'm resending the whole thing.
>>
>> The changes from the last reroll are t
On Mon, Aug 27, 2012 at 12:04 AM, Philipp A. Hartmann wrote:
> From: "Philipp A. Hartmann"
>
> This patch is an experiment to port the wincred helper
> to the generic implementation. As of know, it is
> completely untested.
>
> In addition to porting the helper to the generic API,
> this patch c
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
> behaviour. To work around this, introduce --set-upstream-to which
> accepts a compulsory argument indicating what the new upstream branch
> should be and one optinal argument indicating which branch to change,
> defaulting to HEAD.
>
C
Carlos Martín Nieto writes:
> As a result of making --unset-upstream fail if the given branch
> doesn't exist, I discovered a copy-paste error in on the the tests in
> the patch after it, so I'm resending the whole thing.
>
> The changes from the last reroll are the tightening of the situations
>
Florian Achleitner wrote:
> Hi!
>
> Thanks for your fixups. I'm currently integrating them in a new series.
> On what platform did you find that problems?
> Tried to reproduce them on 64bit Linux. Anyways the fixes look very
> reasonable.
I found the problem on Linux, cygwin and MinGW. That wou
Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
>> On Sat, Aug 25, 2012 at 7:13 PM, Ramsay Jones
>> wrote:
>>>
>>> The getline() function is a GNU extension (you need to define
>>> _GNU_SOURCE before including stdio.h) and is, therefore, not
>>> portable. In particular, getline() is not availab
Erik Faye-Lund wrote:
> On Sat, Aug 25, 2012 at 7:13 PM, Ramsay Jones
> wrote:
>>
>> The getline() function is a GNU extension (you need to define
>> _GNU_SOURCE before including stdio.h) and is, therefore, not
>> portable. In particular, getline() is not available on MinGW.
>
> Actually, getline
This interface is error prone, and a better one (--set-upstream-to)
exists. Add a message listing the alternatives and suggest how to fix
a --set-upstream invocation in case the user only gives one argument
which causes a local branch with the same name as a remote-tracking
one to be created. The t
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstre
We have ways of setting the upstream information, but if we want to
unset it, we need to resort to modifying the configuration manually.
Teach branch an --unset-upstream option that unsets this information.
Signed-off-by: Carlos Martín Nieto
---
Documentation/git-branch.txt | 5 +
builtin/
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Thursday, August 30, 2012 7:14 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
>
> "Joachim Schmitz" writes:
>
> >> I see no existing code calls setitimer() wit
Hi all,
As a result of making --unset-upstream fail if the given branch
doesn't exist, I discovered a copy-paste error in on the the tests in
the patch after it, so I'm resending the whole thing.
The changes from the last reroll are the tightening of the situations
where git will show an error me
"Joachim Schmitz" writes:
>> I see no existing code calls setitimer() with non-NULL ovalue, and I
>> do not think we would add a new caller that would do so in any time
>> soon, so it may not be a bad idea to drop support of returning the
>> remaining timer altogether from this emulation layer (j
Marco Stornelli writes:
> The current script has got the following problems:
>
> 1) It doesn't work if the language used by Thunderbird is not English;
> 2) The field To: filled by format-patch is not evaluated;
> 3) The field Cc: is loaded only from Cc used in the commit message
> instead of usi
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, August 28, 2012 10:16 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH 1/2] Support for setitimer() on platforms lacking it
>
> "Joachim Schmitz" writes:
>
> > Implementation includes getitimer(), but for
Jeff King writes:
> The script originally comes from here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/33566/focus=33852
>
> and the discussion implies that the AUTHOR_DATEs were added to avoid a
> race condition with the timestamps. But why would that ever have worked?
I do not
Jeff King writes:
> Anyway, since this isn't yielding any performance benefit, I'm not going
> to go down that route. But stability of the queue is something that we
> need to consider if we ever do replace commit_list with a different data
> structure.
>
> Here's the patch to make the existing p
Nguyễn Thái Ngọc Duy writes:
> Changes since v2 (the first two patches are not resent):
> ...
> - merge cmd_checkout_entry() into checkout_paths()
I didn't think of this when I reviewed the previous one; I think it
makes sense. Thanks.
--
To unsubscribe from this list: send the line "unsubsc
Oswald Buddenhagen writes:
>> Doesn't
>>
>> git push $over_there 'refs/*:refs/remotes/mine/*'
>>
>> push your tag v1.0 to refs/remotes/mine/v1.0 over there? The
>> version of git I ship seems to do this just fine.
>>
> as i wrote before, i'm pulling, not pushing,...
You would need to de
Junio C Hamano writes:
> Jeff King writes:
>
>> I wonder if you can
>> define the weight as a recursive function of the parents.
>
> I do not think we can. A merge Z between X (that has N commits
> behind it) and Y (that has M commits behind it) has at most N+M+1
> commits behind it (counting i
"Philip Oakley" writes:
> Is "--weight" the right term to use for the user (cli) interface?
> Wouldn't '--oldest' (or similar) be a better statement of what is
> desired (absent clock skew).
>
> While 'weight' may be a good internal technical description it didn't
> convey to me what was being so
On Wed, Aug 29, 2012 at 7:16 PM, Junio C Hamano wrote:
...
> Martin von Zweigbergk
>
> I'll collect responses to this message, and update the file sometime
> late next week.
>
Ralf Thielow
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
On Wed, Aug 29, 2012 at 7:16 PM, Junio C Hamano wrote:
> We have the "mailmap" mechanism to unify entries for a person with
> multiple e-mail addresses into one "Name ", but it seems
> that the .mailmap file hasn't been keeping up to the changes in the
> real world.
>
> Does any of you contributor
On Thu, Aug 30, 2012 at 4:22 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Aug 30, 2012 at 8:12 PM, Orgad and Raizel Shaneh
> wrote:
>>> Could be path normalization. What does "git rev-parse --git-dir" say?
>>> Try to run it at top working directory and a subdirectory as well.
>>>
>>> If you set GIT_
On Thu, Aug 30, 2012 at 09:03:27AM -0400, Jeff King wrote:
> So I was able to have my queue behave just like commit_list by fixing
> the stability issue. But I still have no clue what is going on in t6024.
> It does this for each commit it makes:
>
> [...]
> GIT_AUTHOR_DATE="2006-12-12 23:00:
On Thu, Aug 30, 2012 at 8:12 PM, Orgad and Raizel Shaneh
wrote:
>> Could be path normalization. What does "git rev-parse --git-dir" say?
>> Try to run it at top working directory and a subdirectory as well.
>>
>> If you set GIT_OBJECT_DIRECTORY environment variable to
>> //server/share/foo/repo/.g
On Thu, Aug 30, 2012 at 3:51 PM, Nguyen Thai Ngoc Duy wrote:
>
> On Wed, Aug 29, 2012 at 1:43 PM, Orgad and Raizel Shaneh
> wrote:
> > Hi,
> >
> > I have a repo accessed through //server/share/foo/repo (Using msysgit).
> >
> > .git/objects/info/alternates contains '../../../bare/objects'
> >
> >
On Thu, Aug 30, 2012 at 08:54:21AM -0400, Jeff King wrote:
> On Wed, Aug 29, 2012 at 05:05:40PM -0400, Jeff King wrote:
>
> > You would want this on top:
> > [...]
> > but t6024 still fails (it clearly is finding a different merge base than
> > the test expects). I'll trace through it, but it wi
On Wed, Aug 29, 2012 at 05:05:40PM -0400, Jeff King wrote:
> You would want this on top:
> [...]
> but t6024 still fails (it clearly is finding a different merge base than
> the test expects). I'll trace through it, but it will have to be later
> tonight.
The problem in t6024 is caused by the fa
checkout operates in three different modes. On top of that it tries to
be smart by guessing the branch name for switching. This results in
messy option handling code. This patch reorders it so that
- cmd_checkout() is responsible for parsing, preparing input and
determining mode
- Code of ea
On Wed, Aug 29, 2012 at 1:43 PM, Orgad and Raizel Shaneh
wrote:
> Hi,
>
> I have a repo accessed through //server/share/foo/repo (Using msysgit).
>
> .git/objects/info/alternates contains '../../../bare/objects'
>
> Running 'git status' (or almost any other action) gives the following output:
> er
Hi all,
I am using a repository that has a sub module which is being committed
to frequently by myself as well as others. Because of the heavy
concurrent development I need to do a lot of rebasing. Since the sub
module commit hashes referenced by the parent repository can become
dangling as a
On Wed, Aug 29, 2012 at 08:52:27AM -0700, Junio C Hamano wrote:
> (I won't comment on the other parts in this discussion).
>
which is kinda unfortunate. ;)
> Oswald Buddenhagen writes:
> > i did exacty that. the tags are *still* not populated - git just tries
> > very hard to treat them speciall
The current script has got the following problems:
1) It doesn't work if the language used by Thunderbird is not English;
2) The field To: filled by format-patch is not evaluated;
3) The field Cc: is loaded only from Cc used in the commit message
instead of using even the Cc field filled by format
The current script has got the following problems:
1) It doesn't work if the language used by Thunderbird is not English;
2) The field To: filled by format-patch is not evaluated;
3) The field Cc: is loaded from Cc used in the commit message
instead of using the Cc field filled by format-patch in
Hi,
I am using MsysGit 1.7.11 on WinXP 32 bit and experience the folllowing strange
behaviour:
For a file like "File.txt" in the repo, "git blame file.txt" (note the lower
case)
shows "Not commited yet" for every single line in the file.
"git blame File.txt" (correct upper case spelling) gi
From: "Junio C Hamano"
Sent: Wednesday, August 29, 2012 10:17 PM
So here is an attempt to teach "name-rev" a mode that tries to base
its name on oldest tag that can reach the commit. It needs the
reset_revision_walk() call recently added to the revision traversal
API, and applies to bcc0a3e (v1
54 matches
Mail list logo
