On Sat, Oct 27, 2012 at 4:26 AM, Aaron Schrab wrote:
> I came across this odd question on stackoverflow:
> http://stackoverflow.com/q/13092854/1507392
>
>
> If git diff is run with "..." as a separate argument between two commit-ish
> arguments causes it to produce strange output. The dif
I'm trying to clone the following repository from Codeplex:
https://git01.codeplex.com/entityframework.git
git downloads all the objects, creates the directory "entityframework",
then displays "error: RPC failed; result=56, HTTP code = 200" and
immediately deletes the directory.
I can clone
Hi. Any pointers? Is there some bug tracking system to file a bug to?
Thanks.
On Wed, Oct 24, 2012 at 1:54 PM, Sergey Shelukhin
wrote:
> Hello.
> I am trying to apply a patch made via {git diff somehash^ somehash >
> } before (same version of Git, same machine). I have no-prefix
> enabled by
Scrolling notification works by callingscrolltext{}
with with 2 values between 0 and 1
for the beginning and the end of the view relative to the total length.
When a long diff with several files is loaded,
the diff view length is updated several times
and causes executions of scrolltext{} even when
I came across this odd question on stackoverflow:
http://stackoverflow.com/q/13092854/1507392
If git diff is run with "..." as a separate argument between two
commit-ish arguments causes it to produce strange output. The
differences seem to be the same as if "..." was left out, but ch
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann wrote:
[...]
>
> That is weird, "git diff --submodule" should show that too. Is there
> anything unusual about your setup? (The only explanation I can come
> up with after checking the code is that your submodule has neither a
> .git directory nor a g
Am 26.10.2012 21:54, schrieb Francis Moreau:
> On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann wrote:
>> Am 26.10.2012 16:07, schrieb Francis Moreau:
>>> I'm trying to use the --submodule switch with git-diff but doesnt
>>> understand the following behaviour:
>>>
>>> $ git diff 2c9a257718d1803de720f
On Fri, Oct 26, 2012 at 9:53 PM, Jens Lehmann wrote:
> Am 26.10.2012 16:03, schrieb Francis Moreau:
>> it seems to me that when passed an unknown rev or a wrong commit/sha1,
>> git-submodule-summary should at least exit with an error status. Even better
>> would be a error output.
>>
>> Test was d
Hi,
Thanks for answering
On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann wrote:
> Am 26.10.2012 16:07, schrieb Francis Moreau:
>> I'm trying to use the --submodule switch with git-diff but doesnt
>> understand the following behaviour:
>>
>> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
Am 26.10.2012 16:03, schrieb Francis Moreau:
> it seems to me that when passed an unknown rev or a wrong commit/sha1,
> git-submodule-summary should at least exit with an error status. Even better
> would be a error output.
>
> Test was done with git version 1.7.10.4 from debian wheezy.
Thanks fo
Signed-off-by: Phil Hord
---
t/t7403-submodule-sync.sh | 55 +--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 524d5c1..94e26c4 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t
The submodule sync command was somehow left out when
--recursive was added to the other submodule commands.
Teach sync to handle the --recursive switch by recursing
when we're in a submodule we are sync'ing.
Change the report during sync to show submodule-path
instead of submodule-name to be cons
[PATCHv3 1/2] Teach --recursive to submodule sync
Now with less noise and no redundant flags passed to the recursive call.
[PATCHv3 2/2] Add tests for submodule sync --recursive
The test remains unchanged.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
Am 26.10.2012 21:13, schrieb Phil Hord:
> A test in t7404-submodule-foreach purports to test that
> the --cached flag is properly noticed by --recursive calls
> to the foreach command as it descends into nested
> submodules. However, the test really does not perform this
> test since the change it
Am 26.10.2012 21:07, schrieb Phil Hord:
> On Fri, Oct 26, 2012 at 9:15 AM, Jeff King wrote:
>> On Fri, Oct 26, 2012 at 12:20:29AM +0200, Jens Lehmann wrote:
>>
>>> When renaming orig_args to orig_flags in 98dbe63d (submodule: only
>>> preserve flags across recursive status/update invocations) the
A test in t7404-submodule-foreach purports to test that
the --cached flag is properly noticed by --recursive calls
to the foreach command as it descends into nested
submodules. However, the test really does not perform this
test since the change it looks for is in a top-level
submodule handled by
On Fri, Oct 26, 2012 at 3:00 PM, Kacper Kornet wrote:
> On Fri, Oct 26, 2012 at 08:35:50PM +0200, Angelo Borsotti wrote:
>> Hello
>
>> Drew,
>> Kacper
>
>> thank you for the patch. To keep downward compatibility, the denial to
>> update tags should perhaps be enabled with some option.
>
> You
Am 26.10.2012 16:07, schrieb Francis Moreau:
> I'm trying to use the --submodule switch with git-diff but doesnt
> understand the following behaviour:
>
> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
> diff --git a/configs b/configs
> index 16c6a89..ce12289 16
> --- a/configs
> +++
On Fri, Oct 26, 2012 at 9:15 AM, Jeff King wrote:
> On Fri, Oct 26, 2012 at 12:20:29AM +0200, Jens Lehmann wrote:
>
>> When renaming orig_args to orig_flags in 98dbe63d (submodule: only
>> preserve flags across recursive status/update invocations) the call site
>> of the recursive cmd_status was f
On Fri, Oct 26, 2012 at 08:35:50PM +0200, Angelo Borsotti wrote:
> Hello
> Drew,
> I made some further tests on git-push to see if it handled branches
> and tags in the same way, and have discovered the following
> differences:
> - git push origin --delete master
> remote: error: By de
Am 26.10.2012 19:55, schrieb Phil Hord:
> On Fri, Oct 26, 2012 at 1:19 PM, Phil Hord wrote:
>>
>> Yes, thanks for catching that. I think I should add a test for that
>> except I notice that sync doesn't take any other flags useful for passing.
>
> Which, of course, suggests that I should not add
Hello
Drew,
I made some further tests on git-push to see if it handled branches
and tags in the same way, and have discovered the following
differences:
- git push origin --delete master
remote: error: By default, deleting the current branch is denied
- git push origin --delete vx
On Fri, Oct 26, 2012 at 02:07:09PM -0400, Drew Northup wrote:
> On Fri, Oct 26, 2012 at 1:42 PM, Kacper Kornet wrote:
> > On Thu, Oct 25, 2012 at 05:16:00PM -0400, Drew Northup wrote:
> >> On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti
> >> wrote:
> >> > Are remote repositories less protected t
On Thu, Oct 25, 2012 at 05:16:00PM -0400, Drew Northup wrote:
> On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti
> wrote:
> > Are remote repositories less protected than the local ones? I
> > think that to be consistent, the same strategy should be used on all
> > repositories, i.e. rejecting chan
On Fri, Oct 26, 2012 at 1:42 PM, Kacper Kornet wrote:
> On Thu, Oct 25, 2012 at 05:16:00PM -0400, Drew Northup wrote:
>> On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti
>> wrote:
>> > Are remote repositories less protected than the local ones? I
>> > think that to be consistent, the same strateg
On Fri, Oct 26, 2012 at 1:19 PM, Phil Hord wrote:
>
> Yes, thanks for catching that. I think I should add a test for that
> except I notice that sync doesn't take any other flags useful for passing.
Which, of course, suggests that I should not add this
flag-propagating-machinery to submodule-syn
Signed-off-by: Phil Hord
---
t/t7403-submodule-sync.sh | 55 +--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 524d5c1..94e26c4 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t
The submodule sync command was somehow left out when
--recursive was added to the other submodule commands.
Teach sync to handle the --recursive switch by recursing
when we're in a submodule we are sync'ing.
Change the report during sync to show submodule-path
instead of submodule-name to be cons
This one fixes "$orig_flags" problems noticed by Jens.
Copy-and-paste is gift from Satan.
Phil
--
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
Jens Lehmann wrote:
> Am 24.10.2012 01:15, schrieb Phil Hord:
>> The submodule sync command was somehow left out when
>> --recursive was added to the other submodule commands.
>>
>> Teach sync to handle the --recursive switch by recursing
>> when we're in a submodule we are sync'ing.
>>
>> Change
Looks like I got lost in the press of other issues. anyone?
On 10/22/2012 09:39 AM, Scott R. Godin wrote:
> As you can see from the below, I can't seem to get it to give me more
> verbose results of what's being merged (as in the actual merge below)
> with --stat or -v .. is it supposed to do that
On Fri, Oct 26, 2012 at 9:58 AM, David Michael Barr wrote:
> From a quick survey, it appears there are no more than 55 patches
> squashed into the submitted patch.
> As I have an interest in git-subtree for maintaining the out-of-tree
> version of vcs-svn/ and a desire to improve my rebase-fu, I a
t9200 defines $CVSROOT where cvs should init its repository
$CVSROOT is set to $PWD/cvsroot.
cvs init is supposed to create the repository inside $PWD/cvsroot/CVSROOT
"cvs init" (e.g. version 1.11.23) checks if the last element of the path is
"CVSROOT", and if a directory with e.g. $PWD/cvsroot/C
fetch_pack() is used by transport.c, part of libgit.a while it stays
in builtin/fetch-pack.c. Move it to fetch-pack.c so that we won't get
undefined reference if a program that uses libgit.a happens to pull it
in.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile | 1 +
builtin/fetc
This helps removes the hack in fetch_pack() that copies my_args to args.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fetch-pack.c | 160 ++-
1 file changed, 83 insertions(+), 77 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pa
send_pack() is used by transport.c, part of libgit.a while it stays in
builtin/send-pack.c. Move it to send-pack.c so that we won't get
undefined reference if a program that uses libgit.a happens to pull it
in.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile| 1 +
builtin/send-pac
This is used by diff-no-index.c, part of libgit.a while it stays in
builtin/diff.c. Move it to diff.c so that we won't get undefined
reference if a program that uses libgit.a happens to pull it in.
While at it, move check_pager from git.c to pager.c. It makes more
sense there and pager.c is also p
This is used by bisect.c, part of libgit.a while it stays in
builtin/rev-list.c. Move it to commit.c so that we won't get undefined
reference if a program that uses libgit.a happens to pull it in.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
bisect.h | 4
builtin/rev-list.c | 10 -
This function is used by bisect.c, part of libgit.a while
estimate_bisect_steps stays in builtin/rev-list.c. Move it to bisect.a
so we won't have undefine reference if a standalone program that uses
libgit.a happens to pull it in.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
bisect.c | 38 +
These functions are called in sequencer.c, which is part of
libgit.a. This makes libgit.a potentially require builtin/merge.c for
external git commands.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile | 1 +
builtin/merge.c | 106 +--
On Fri, Oct 26, 2012 at 7:02 PM, Jeff King wrote:
>> OK. I checked around for similar issues and found these used by
>> libgit.a but stay in builtin/ instead:
>
> Yeah, we have traditionally been kind of lazy about the distinction,
> because it doesn't really matter for our build system (i.e., lib
Hi,
On Thu, Oct 25, 2012 at 4:41 AM, Matt Arsenault wrote:
>
> On Oct 21, 2012, at 12:06 , Junio C Hamano wrote:
>>
>> - Why is it a bug not to pass "-s"? How does the bug happen?
>
> I encountered this one time after using it for months. One day I couldn't git
> p4 rebase
> with the key error
Hi,
On Fri, Oct 26, 2012 at 3:33 PM, Michael J Gruber
wrote:
> 'git replace' parses the revision arguments when it creates replacements
> (so that a sha1 can be abbreviated, e.g.) but not when deleting
> replacements.
>
> This sucks.
>
> Make it parse the argument to 'replace -d' in the same way.
Hi Drew,
git is an open source, community project, which means that it benefits
from all the contributions of many people, and they are not restricted
to patches.
If the only one suggestions that were taken into account were patches
sent by people that had the time to study the sources and propose
On Fri, Oct 26, 2012 at 9:13 AM, Drew Northup wrote:
> On Fri, Oct 26, 2012 at 9:59 AM, Chris Rorvick wrote:
>> On Fri, Oct 26, 2012 at 8:37 AM, Drew Northup wrote:
>>> (As for deleting the current branch, you can't really do that on a
>>> proper bare remote anyway as there is no such thing as a
On Fri, Oct 26, 2012 at 9:59 AM, Chris Rorvick wrote:
> On Fri, Oct 26, 2012 at 8:37 AM, Drew Northup wrote:
>> (As for deleting the current branch, you can't really do that on a
>> proper bare remote anyway as there is no such thing as a "current
>> branch" in that context.)
>
> Really? When I
Hi,
it seems to me that when passed an unknown rev or a wrong commit/sha1,
git-submodule-summary should at least exit with an error status. Even better
would be a error output.
Test was done with git version 1.7.10.4 from debian wheezy.
Thanks
--
Francis
--
To unsubscribe from this list: send t
On Thu, Oct 25, 2012 at 06:14:31PM -0400, W. Trevor King wrote:
> Should I rebase this so it lands cleanly atop 38ae92e4 in next?
>
> commit 38ae92e4d027063b9b87e51a9bf12809d10066f6
> Author: W. Trevor King
> Date: Tue Oct 23 17:00:21 2012 -0400
>
> git-submodule: wrap branch option
On Fri, Oct 26, 2012 at 8:37 AM, Drew Northup wrote:
> (As for deleting the current branch, you can't really do that on a
> proper bare remote anyway as there is no such thing as a "current
> branch" in that context.)
Really? When I clone a bare repository I see a HEAD, and Git doesn't
want me t
On Saturday, 27 October 2012 at 12:10 AM, Herman van Rink wrote:
> On 10/22/2012 04:41 PM, d...@cray.com (mailto:d...@cray.com) wrote:
> > Herman van Rink mailto:r...@initfour.nl)> writes:
> >
> > > On 10/21/2012 08:32 AM, Junio C Hamano wrote:
> > > > Herman van Rink mailto:r...@initfour.nl)> wri
On Fri, Oct 26, 2012 at 1:32 PM, Jeff King wrote:
> That's probably worth mentioning. Gunnlaugur, any objection to me
> amending your commit with:
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 64756c9..8b0d3ad 100644
> --- a/Documentation/git-svn.txt
> +++ b/Docume
On Wed, Oct 24, 2012 at 09:12:27PM -0400, W. Trevor King wrote:
> On Wed, Oct 24, 2012 at 02:12:18PM -0400, Phil Hord wrote:
> > + VAR_NAME=$(printf '%s'
> > "$VAR_NAME" | tr A-Z a-z | sed -e 's/^[^a-z]/_/' -e 's/[^a-z0-9]/_/g')
>
> Is there a reason why you
On Fri, Oct 26, 2012 at 2:42 AM, Angelo Borsotti
wrote:
> Hi Drew,
>
--Adding for clarity: On Thurs, Oct 25, 2012 at 17:16 EDT, Drew
Northup wrote:
>>
>> Changing the tag in the local repository is a tag modification
>> operation. Pushing that change to a remote repository DOES NOT execute
>>
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
This sucks.
Make it parse the argument to 'replace -d' in the same way.
Just in case someone lost the replacement object before deleting the
repl
On Fri, Oct 26, 2012 at 09:46:02AM +, Eric Wong wrote:
> > Thanks. Your description makes sense to me, but I do not have enough
> > git-svn knowledge to know if it covers all intended uses of the flag.
> > Eric?
> >
> > > +--log-window-size=;;
> > > +Fetch log entries per request when sc
On Thu, Oct 25, 2012 at 11:48:04PM +0100, Philip Oakley wrote:
> >+the commit that does not belong to the commit log message proper,
> >+and include it with the patch submission. While one can simply write
> >+these explanations after `format-patch` has run but before sending,
> >+keeping them as
On Fri, Oct 26, 2012 at 12:20:29AM +0200, Jens Lehmann wrote:
> When renaming orig_args to orig_flags in 98dbe63d (submodule: only
> preserve flags across recursive status/update invocations) the call site
> of the recursive cmd_status was forgotten. At that place orig_args is
> still passed into
On 10/22/2012 04:41 PM, d...@cray.com wrote:
> Herman van Rink writes:
>
>> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>>> Herman van Rink writes:
>>>
Junio, Could you please consider merging the single commit from my
subtree-updates branch? https://github.com/helmo/git/tree/subtree-
On Thu, Oct 25, 2012 at 02:50:37PM -0400, Phil Hord wrote:
> >> git pull --rebase does some clever tricks to find the base
> >> for $upstream , but it forgets that we may not have any
> >> branch at all. When this happens, git merge-base reports its
> >> "usage" help in the middle of an otherwise
On Thu, Oct 25, 2012 at 04:58:19PM +0100, Ben Walton wrote:
> Sed on Mac OS X doesn't handle \s in a sed expressions so use a more
> portable character set expression instead.
>
> Signed-off-by: Ben Walton
Thanks, I think this simple solution is the best.
-Peff
--
To unsubscribe from this list
On Thu, Oct 25, 2012 at 07:50:26PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 25, 2012 at 4:45 PM, Jeff King wrote:
> > On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote:
> >
> >> These functions are called in sequencer.c, which is part of
> >> libgit.a. This makes libgit
On 26/10/12 00:47, Jens Lehmann wrote:
Am 25.10.2012 17:06, schrieb Nicolas Morey-Chaisemartin:
At work, we use a lot of submodules (several levels of submodules actually).
As we also work with development branches, we use scripts to resync the whole
checked-out tree (mainly in automated integr
Jeff King wrote:
> On Tue, Oct 23, 2012 at 10:33:26AM +, Gunnlaugur Þór Briem wrote:
>
> > The --log-window-size parameter to git-svn fetch is undocumented.
> >
> > Minimally describe what it does and why the user might change it.
>
> Thanks. Your description makes sense to me, but I do not
On Thu, Oct 18, 2012 at 8:12 AM, Sverre Rabbelier wrote:
> On Wed, Oct 17, 2012 at 10:18 PM, Felipe Contreras
> wrote:
>> Right now I've just added an error when using remote repositories. But
>> it seems there's no way around it; if we want to have support for
>> remote repos, we need to make a
64 matches
Mail list logo