Sivakumar Selvam writes:
>I ran git repack on a single larger repository abc.git where the pack
> file size 34 GB. Generally it used to take 20-25 minutes in my server to
> complete the repacking. During repacking I noticed, disk usage was more, So
> I thought of splitting the pack file into
Max Kirillov writes:
> The option name used in blame's UI is `--reverse`.
>
> Signed-off-by: Max Kirillov
> ---
;-)
It is surprising that nobody noticed this which was in the very
original of --reverse. Thanks.
> builtin/blame.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
Max Kirillov writes:
> If history contains merges from feature branches, `blame --reverse`
> reports not the commit when the line was actually edited, but head of
> the last merged branch which was created before the edit.
>
> As a workaround, `blame --reverse --first-parent` could be used to fin
Hi,
I ran git repack on a single larger repository abc.git where the pack
file size 34 GB. Generally it used to take 20-25 minutes in my server to
complete the repacking. During repacking I noticed, disk usage was more, So
I thought of splitting the pack file into 4 GB chunks. I used the followi
Sorry, forgot to fix the tests. Will send another batch some later.
--
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
On Mon, Oct 26, 2015 at 07:26:54AM +0200, Max Kirillov wrote:
> * Change aproach - instead of assuming children content build them explicitly,
> also accurately verifying that the specified range is along the
> first-parent chain
> * Fix error message
Sent by mistake, ignore this, please
--
To
The option name used in blame's UI is `--reverse`.
Signed-off-by: Max Kirillov
---
builtin/blame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 98b1810..f89bc9e 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2697,7 +2697,7 @@
* Change aproach - instead of assuming children content build them explicitly,
also accurately verifying that the specified range is along the first-parent
chain
* Fix error message
Max Kirillov (4):
Add test to describe expectation of blame --reverse with branched
history
blame: extrac
Change aproach - instead of assuming children content build them explicitly,
also accurately verifying that the specified range is along the first-parent
chain
Max Kirillov (3):
Add test to describe expectation of blame --reverse with branched
history
blame: extract find_single_final
bl
Signed-off-by: Max Kirillov
---
builtin/blame.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 295ce92..38f6267 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2401,16 +2401,11 @@ static struct com
If history contains merges from feature branches, `blame --reverse`
reports not the commit when the line was actually edited, but head of
the last merged branch which was created before the edit.
As a workaround, `blame --reverse --first-parent` could be used to find
the merge of branch containing
Allow combining --reverse and --first-parent if initial commit of
specified range is at the first-parent chain starting from the final
commit. Disable the prepare_revision_walk()'s builtin children
collection, instead picking only the ones which are along the first
parent chain.
Signed-off-by: Max
On Mon, Oct 26, 2015 at 7:10 AM, John Smith wrote:
> When would people routinely check out a branch and want to stay with the
> submodules as
> the have been checked out for the old branch?
I do this a lot. At my $dayjob we have a super project with bunch of
sub projects.
Each subproject has its
Paul Wise writes:
> It definitely wouldn't be appropriate to add screen scraping and
> parsing of different version control systems to myrepos.
Huh? If the tool claims to support VCS X and Y and Z, it needs to
know how to cause X and Y and Z to "fetch" in their own ways, and it
needs to know ho
On Sun, Oct 25, 2015 at 12:29 PM, Karthik Nayak wrote:
> In ref-filter.c the comparison of refs while sorting is handled by
> cmp_ref_sorting() function. When sorting as per numerical values
> (e.g. --sort=objectsize) there is no fallback comparison when both
> refs hold the same value. This can c
On Mon, Oct 26, 2015 at 12:10 PM, John Smith wrote:
> I found that I use submodules much, much more often in my git projects than I
> used externals
> in Subversion and the reason is that git encourages/forces to organize large
> projects into
> smaller repositories, one reason for this being th
On Sun, 2015-10-25 at 11:34 -0700, Junio C Hamano wrote:
> I ignored your patch when you sent it the first time the last week,
> due to the same issues I had with this round (see below) and forgot
> about it.
Thanks for the feedback this round.
> I cannot tell if you are trying to say if that i
I found that I use submodules much, much more often in my git projects than I
used externals
in Subversion and the reason is that git encourages/forces to organize large
projects into
smaller repositories, one reason for this being that subversion allows to check
out parts of
a repository while
I think there's something "odd" in the way that branch was created. If
I take a look at another branch:
$ svn log -v --stop-on-copy
https://svn.php.net/repository/pear/packages/Net_LDAP2/tags/RELEASE_2_0_0RC2
r255575 | cvs2sv
Johannes Schindelin writes:
> Chad Boles reported that `git rebase -i` recently started producing
> errors when the editor saves files with DOS line endings. The symptom
> is:
>
> Warning: the command isn't recognized in the following line:
>-
>
> You can fix this with 'git re
Hello Christian,
> > Did you try with -r revision-number:HEAD?
>
> Good idea. I tried it, and now I have the tags and branches:
Unfortunately, the tag branches only have a single commit and have no
relation to the trunk branch:
$ git log --oneline origin/tags/Net_LDAP2-2.0.12
0bc9db1 Tagging t
Paul Wise writes:
I ignored your patch when you sent it the first time the last week,
due to the same issues I had with this round (see below) and forgot
about it.
> By default when fetching one remote nothing is printed unless there
> are changes that need fetching. This makes fetching multiple
Lars Schneider writes:
> (1) Make upload-pack wait for a response (with timeout) before it
> closes the pipe. However, I believe this would not be in line with
> the general Git philosophy stated in "git.c" (added in 7559a1be):
> "Many parts of Git have subprograms communicate via pipe, expect
>
Noam Postavsky writes:
> On Tue, Oct 20, 2015 at 10:35 PM, Noam Postavsky
> wrote:
>> On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano wrote:
>>> I cannot speak for the person who was primarily responsible for
>>> designing this behaviour, but I happen to agree with the current
>>> behaviour in
Max Kirillov writes:
> This additionally forbids having several end commits
> (git blame --reverse --first-parent ^A B C ...), but
> this does not seem to have much practical use.
Even if there were practical uses for a request with multiple end
points, a solution that
(1) guarantees that "bla
Hello Edmundo,
> Using -r single-revision-number (against tha same repo), I was not
> able to pull much (on that revision only the standard layout was set
> up so nothing would come out for git)
It's actually the standard layout here; I only used the single
parameters to rule out problems with -
In ref-filter.c the comparison of refs while sorting is handled by
cmp_ref_sorting() function. When sorting as per numerical values
(e.g. --sort=objectsize) there is no fallback comparison when both
refs hold the same value. This can cause unexpected results (i.e. the
order of listting refs with eq
Using -r single-revision-number (against tha same repo), I was not
able to pull much (on that revision only the standard layout was set
up so nothing would come out for git)
Did you try with -r revision-number:HEAD?
.
.
.
r255572 = 73d7692d844ee6baae8b4b2e5fc0f07a4118d09e (refs/remotes/svn/trunk
On 20 Oct 2015, at 19:33, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> If not, what do you think about a patch that adds a "url" section
>> similar to the one in git config to a .gitmodules file?
>>
>> Example:
>> --
>> [submodule "git"]
>> path = git
>>url=git://g
Hi,
Using git 2.6.2 to clone an SVN repository misses out branches and tags.
The clone command:
$ git svn clone --trunk=trunk --tags=tags --branches=branches
--prefix=origin/
https://svn.php.net/repository/pear/packages/Net_LDAP2 -r 255346
The final repository's tag and branch list is empt
On 20 Oct 2015, at 00:07, Stefan Beller wrote:
> On Mon, Oct 19, 2015 at 12:28 PM, Lars Schneider
> wrote:
>> Hi,
>>
>> I have a closed source Git repo which references an Open Source Git repo as
>> Submodule. The Open Source Git repo references yet another Open Source repo
>> as submodule.
This is the correct thing to do, really: we already specify LF as
field separator.
Incidentally, this fixes the problem interactive rebase has when the
editor wants to save text with CR/LF line endings, as WordPad does
in Windows 10.
Signed-off-by: Johannes Schindelin
---
git-sh-setup.sh
Chad Boles reported that `git rebase -i` recently started producing
errors when the editor saves files with DOS line endings. The symptom
is:
Warning: the command isn't recognized in the following line:
-
You can fix this with 'git rebase --edit-todo'.
Or you can
Based on a bug report by Chad Boles.
Signed-off-by: Johannes Schindelin
---
t/t3404-rebase-interactive.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 3de0b1d..5dfa16a 100755
--- a/t/t3404-rebase-interactive
Hi Brian,
On Sun, 25 Oct 2015, Johannes Schindelin wrote:
> On Sun, 25 Oct 2015, brian m. carlson wrote:
>
> > On Sun, Oct 25, 2015 at 01:50:32PM +0100, Johannes Schindelin wrote:
> > > This is the correct thing to do, really: we already specify LF as
> > > field separator.
> > >
> > > Incident
Thanks for your explanation Fredrik! However, I believe your 4. step is not
what happens in the current implementation as the write call in wrapper.c dies
directly. I see three ways to fix the problem:
(1) Make upload-pack wait for a response (with timeout) before it closes the
pipe. However, I
Hi Philip,
On Sun, 25 Oct 2015, Philip Oakley wrote:
> From: "Johannes Schindelin"
> > @@ -13,7 +13,7 @@ unset CDPATH
> > # do not equate an unset IFS with IFS with the default, so here is
> > # an explicit SP HT LF.
>
> Doesn't this comment also need an update, given the patch title?
Yes, you
Hi Brian,
re-Cc:ing the Git mailing list.
On Sun, 25 Oct 2015, brian m. carlson wrote:
> On Sun, Oct 25, 2015 at 01:50:32PM +0100, Johannes Schindelin wrote:
> > This is the correct thing to do, really: we already specify LF as
> > field separator.
> >
> > Incidentally, this fixes the problem i
From: "Johannes Schindelin"
This is the correct thing to do, really: we already specify LF as
field separator.
Incidentally, this fixes the problem interactive rebase has when the
editor wants to save text with CR/LF line endings, as WordPad does
in Windows 10.
Signed-off-by: Johannes Schindel
Based on a bug report by Chad Boles.
Signed-off-by: Johannes Schindelin
---
t/t3404-rebase-interactive.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 3de0b1d..5dfa16a 100755
--- a/t/t3404-rebase-interactive
This is the correct thing to do, really: we already specify LF as
field separator.
Incidentally, this fixes the problem interactive rebase has when the
editor wants to save text with CR/LF line endings, as WordPad does
in Windows 10.
Signed-off-by: Johannes Schindelin
---
git-sh-setup.sh
Chad Boles reported that `git rebase -I` recently started producing
errors when the editor saves files with DOS line endings. The symptom
is:
Warning: the command isn't recognized in the following line:
-
You can fix this with 'git rebase --edit-todo'.
Or you can
On Thu, Oct 22, 2015 at 12:11:23PM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>> On Wed, Oct 21, 2015 at 09:25:37PM -0700, Junio C Hamano wrote:
>>
>>> The logic you implemented feels solid to me, at least at a first
>>> glance. What kind of gotchas are you worried about?
>>
>> The fact
Hey all,
git fetch --dry-run modifies the repository if --unshallow is passed:
$ git --version
git version 2.1.4
$ git fetch --dry-run --unshallow
remote: Counting objects: 30603, done.
remote: Compressing objects: 100% (6843/6843), done.
remote: Total 30603 (delta 24564), reused 29164 (delta 233
I think the following happens:
1. The remote upload-pack finds out "not our ref"
2. The remote send a response and close the pipe
3. fetch-pack still tries to write commands to the remote upload-pack
4. Because the connection has already been closed, writing will fail
with EPIPE which is detected b
On Sun, Oct 25, 2015 at 5:48 AM, Eric Sunshine wrote:
> On Sat, Oct 24, 2015 at 10:42 AM, Karthik Nayak wrote:
>> In ref-filter.c the comparison of refs while sorting is handled by
>> cmp_ref_sorting() function. When sorting as per numerical values
>> (e.g. --sort=objectsize) there is no fallback
46 matches
Mail list logo
