* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-01-20 21:27 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky
In-Reply-To: <7v622rn1bh.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>> this as a bug, and think this should be changed. This has been discussed
>> several times here, but no one took the time to actually do the change
>
> Did we ever agree that it is a good change to begin with? Pointers?
I think you can guess but I no longer need pointers. Others may
still be helped, though.
The argument IIRC boils down to
- "git add -u" was made a whole-tree operation when there weren't
the ":/" magic pathspec, but "add -u" is very often something you
want to do whole tree, and "(cd ../../..; git add -u)" or "git
add -u ../../.." are too cumbersome to type.
- "git add -u ." to limit it to the current directory is easy to
type.
- As we have the "from the root" magic pathspec these days,
requiring "git add -u :/" when the user really means to add
everything is no longer too much of a burden, but if we suddenly
changed "git add -u" to mean "git add -u .", that is too much of
a change in the semantics.
^ permalink raw reply
* Re: [PATCH 0/7] guilt patches, including git 1.8 support
From: Per Cederqvist @ 2013-01-20 21:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Josef 'Jeff' Sipek, git, Theodore Ts'o, Iulian Udrea,
Axel Beckert
In-Reply-To: <20130116022606.GI12524@google.com>
On 01/16/13 03:26, Jonathan Nieder wrote:
> Hi Jeff and other guilty parties,
>
> I collected all the guilt patches I could find on-list and added one
> of my own. Completely untested, except for running the regression
> tests. These are also available via git protocol from
>
> git://repo.or.cz/guilt/mob.git mob
>
> Thoughts?
Regarding the "Change git branch when patches are applied" feature,
it has saved me a number of times since I implemented it. I've been
using it extensively, and have not had any problems with it.
Nevertheless, for backwards compatibility with the currently
released guilt version I think it should be conditional, and
disabled per default for one full release cycle. I've implemented
this. My code is available from git://repo.or.cz/guilt/ceder.git
The following commits are not included in your list:
a194375 Added guilt.reusebranch configuration option.
1dd97bd Minor testsuite fix.
640caee The tests should not fail if guilt.diffstat is set.
I don't want Guilt to fork. Jeff, it would be really great if
you could set up a public repo again!
/ceder
> Jonathan Nieder (1):
> Drop unneeded git version check.
>
> Per Cederqvist (6):
> get rid of "cat: write error: Broken pipe" error message
> The tests should not fail if log.date or log.decorate are set.
> Testsuite: get rid of "Broken pipe" errors from yes.
> Handle empty patches and patches with only a header.
> Fix fatal "guilt graph" error in sha1sum invocation.
> Change git branch when patches are applied.
>
> Documentation/guilt.7 | 4 +
> guilt | 73 +++++---
> guilt-branch | 12 +-
> guilt-commit | 7 +
> guilt-import-commit | 4 +-
> guilt-repair | 7 +-
> os.Darwin | 7 +-
> os.Linux | 7 +-
> os.SunOS | 7 +-
> regression/scaffold | 7 +-
> regression/t-029.sh | 6 +-
> regression/t-052.out | 24 +--
> regression/t-052.sh | 7 +-
> regression/t-061.out | 468 ++++++++++++++++++++++++++++++++++++++++++++++++++
> regression/t-061.sh | 148 ++++++++++++++++
> 15 files changed, 743 insertions(+), 45 deletions(-)
> create mode 100644 regression/t-061.out
> create mode 100755 regression/t-061.sh
>
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-20 22:08 UTC (permalink / raw)
To: Jeff King; +Cc: git, spearce, mfick
In-Reply-To: <7vpq0zn2za.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>>> [uploadPack]
>>> hiderefs = refs/changes
>>
>> Would you want to do the same thing on receive-pack? It could benefit
>> from the same reduction in network cost (although it tends to be invoked
>> less frequently than upload-pack).
> ...
> As I said, I view this primarily as solving the cluttering issue.
> The use of hiderefs to hide these refs that point at objects I do
> not consider belong to my repository from the pushers equally makes
> sense as such, I think.
Now that raises one question. Should this be transfer.hiderefs that
governs both upload-pack and receive-pack? I tend to think the
answer is yes.
It may even make sense to have "git push" honor it, excluding them
from "git push --mirror" (or "git push --all" if some of the
branches are hidden); I haven't thought things through, though.
^ permalink raw reply
* Re: [RFC] git rm -u
From: Martin von Zweigbergk @ 2013-01-20 22:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Jonathan Nieder, Eric James Michael Ritz, git,
Tomas Carnecky
In-Reply-To: <7vobgjk0iw.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>>> this as a bug, and think this should be changed. This has been discussed
>>> several times here, but no one took the time to actually do the change
>
> - As we have the "from the root" magic pathspec these days,
> requiring "git add -u :/" when the user really means to add
> everything is no longer too much of a burden, but if we suddenly
> changed "git add -u" to mean "git add -u .", that is too much of
> a change in the semantics.
And I think someone (Jeff?) pointed out that that last part is even
more true for "git clean", which also currently works on the current
directory if not told otherwise.
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Eric S. Raymond @ 2013-01-20 23:20 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130120200922.GC7498@serenity.lan>
John Keeping <john@keeping.me.uk>:
> I don't think there is any way to solve this without giving cvsps more
> information, probably the last commit time for all git branches, but
> perhaps I'm missing a fast-import feature that can help solve this
> problem.
Yes, you are. The magic incantation is
from refs/heads/<branch>^0
I've just pushed a cvsps-3.9 with an -i option that generates these at
each branch root. Combine it with -d and you get incremental
fast-export.
You get to integrate this. I think the transition strategy Junio
has chosen is seriously mistaken, leading to unnecessary grief for users
who will be fooled into thinking it's OK to still use cvsps-2.x. Because
I do not wish to encourage or endorse this mistake and am tired of arguing
against stubborn determination to do the wrong thing, I am not going to
sink more effort into the git project's end of the CVS-lifting problem.
There are too many better uses for my time.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Jonathan Nieder @ 2013-01-20 23:34 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: John Keeping, git
In-Reply-To: <20130120232008.GA25001@thyrsus.com>
Eric S. Raymond wrote:
> You get to integrate this. I think the transition strategy Junio
> has chosen is seriously mistaken, leading to unnecessary grief for users
> who will be fooled into thinking it's OK to still use cvsps-2.x.
So our choices are:
a. support current users, offend ESR, don't benefit from ESR
improvements
b. give up on current users, please ESR, benefit from ESR
improvements
c. some option yet undiscovered
In that case, (c) sounds like our best bet. Do I understand
correctly?
Sigh,
Jonathan
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Jonathan Nieder @ 2013-01-20 23:42 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: John Keeping, git
In-Reply-To: <20130120232008.GA25001@thyrsus.com>
Eric S. Raymond wrote:
> You get to integrate this. I think the transition strategy Junio
> has chosen is seriously mistaken, leading to unnecessary grief for users
> who will be fooled into thinking it's OK to still use cvsps-2.
Ah, I missed a detail on first reading. I think there has been a
small misunderstanding.
Junio proposed a transition strategy, but I don't think it's fair to
say he has chosen it without discussion or is imposing it on you. If
you or someone else comes up with a better transition strategy, you
are free to completely ignore Junio's proposal. If the affected users
generally prefer your alternate proposal, in my experience that means
it will be integrated.
Hoping that clarifies a little,
Jonathan
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Junio C Hamano @ 2013-01-21 0:01 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Eric S. Raymond, John Keeping, git
In-Reply-To: <20130120233422.GB3474@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Eric S. Raymond wrote:
>
>> You get to integrate this. I think the transition strategy Junio
>> has chosen is seriously mistaken, leading to unnecessary grief for users
>> who will be fooled into thinking it's OK to still use cvsps-2.x.
>
> So our choices are:
>
> a. support current users, offend ESR, don't benefit from ESR
> improvements
>
> b. give up on current users, please ESR, benefit from ESR
> improvements
>
> c. some option yet undiscovered
>
> In that case, (c) sounds like our best bet. Do I understand
> correctly?
>
> Sigh,
> Jonathan
Isn't (c) is to just build on cvsimport-2 and cvsimport-3 combo?
If Eric does not want to get involved in cvsimport-2 (and cvsps2),
that is perfectly fine. We have the beginning of cvsimport-3 code
that was released with Sign-off, and as long as cvsps3 produces a
"more corrrect" output stream (either traditional cvsps2 style or as
a fast-import stream) than cvsps2 conversion describes, cvsimport-3
can get the full benefit of his work, no?
I do not think that Eric will be the only person who understands
cvsps3 output who can fix bugs that may potentially still exist in
cvsimport-3 code [*1*].
We live in real world, and distro inertia makes it likely that a new
version of git that does not work for people who have been happy
with cvsps2 will get resistance from them, when they do not trust
the 0.x releases of a new piece of software "cvsps3" that happens to
have a name similar to what they have been shipping, i.e. "cvsps2".
Shipping such a crippled Git will not be an effective way to promote
adoption of "cvsps3".
[Footnote]
*1* This of course assumes Eric's two major claims are true, that
is, (1) cvsimport-3 is already mature and better than cvsimport-2,
and (2) the code is so simple that it does not even need its own
tests as long as the front-end conversion that happens at the cvsps3
end is tested well. Choosing b. will have to assume them to be true
anyway, so I do not think it is a big loss to rely on the same
assumptions and choose b. from our point of view.
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Junio C Hamano @ 2013-01-21 0:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Eric S. Raymond, John Keeping, git
In-Reply-To: <7vehhfjteu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ..., so I do not think it is a big loss to rely on the same
> assumptions and choose b. from our point of view.
Of course the last sentence is a typo: "choose c." is what I meant.
^ permalink raw reply
* Re: [PATCH] mergetools: Add tortoisegitmerge helper
From: Junio C Hamano @ 2013-01-21 0:43 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Sebastian Schuberth, davvid, Jeff King
In-Reply-To: <50FBD4AD.2060208@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
> (starting with 1.8.0) in order to make clear that this one has special
> support for git and prevent confusion with the TortoiseSVN TortoiseMerge
> version.
> - The tortoisemerge mergetool does not work with filenames which have
> a space in it. Fixing this required changes in git and also in
> TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
>
> The new tortoisegitmerge helper was added so that people can still use
> TortoiseMerge from TortoiseSVN (and older TortoiseGit versions).
>
> Signed-off-by: Sven Strickroth <email@cs-ware.de>
> Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
> ---
Applying: mergetools: Add tortoisegitmerge helper
fatal: corrupt patch at line 56
That comes from here:
> diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
> index 9bb4956..a047646 100644
> --- a/Documentation/merge-config.txt
> +++ b/Documentation/merge-config.txt
> @@ -55,9 +55,9 @@ merge.tool::
> Controls which merge resolution program is used by
> linkgit:git-mergetool[1]. Valid built-in values are: "araxis",
> "bc3", "diffuse", "ecmerge", "emerge", "gvimdiff", "kdiff3", "meld",
> - "opendiff", "p4merge", "tkdiff", "tortoisemerge", "vimdiff"
> - and "xxdiff". Any other value is treated is custom merge tool
> - and there must be a corresponding mergetool.<tool>.cmd option.
> + "opendiff", "p4merge", "tkdiff", "tortoisegitmerge", "tortoisemerge",
> + "vimdiff" and "xxdiff". Any other value is treated is custom merge
> + tool and there must be a corresponding mergetool.<tool>.cmd option.
> merge.verbosity::
> Controls the amount of output shown by the recursive merge
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
Notice that we have three pre-context lines but only two
post-context lines for this hunk. There is one context line missing
at the end of this hunk.
I'd usually try to queue a corrupt patch by manually fixing up when
it is a trivial corruption, but a corruption that _loses_ lines is
too dangerous to be handled that way. There may be additions in
other hunks you wanted to make that were lost for the same reason
why the post-context line was lost here, and my fix-up would end up
committing a wrong patch.
Please investigate how this happened, and re-send after hearing
reviews from others.
Thanks.
^ permalink raw reply
* Re: git-cvsimport-3 and incremental imports
From: Eric S. Raymond @ 2013-01-21 1:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: John Keeping, git
In-Reply-To: <20130120234205.GC3474@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com>:
> Junio proposed a transition strategy, but I don't think it's fair to
> say he has chosen it without discussion or is imposing it on you.
I have said everything I could about the bad effects of encouraging
people to continue to use cvsps-2.x, it didn't budge Junio an
inch, and I'm tired of fighting about it. Quibbling about the
semantics of 'impose' will neither change these facts nor make
me any less frustrated with the outcome.
I will continue to do what I can to make cvsps-3.x and cvs-fast-export as
bug-free as possible, given the innate perverseness of CVS. They
won't be perfect; they will be *better*.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH 1/2] git-svn: Add test for git-svn repositories with a gitdir link
From: Barry Wardell @ 2013-01-21 1:22 UTC (permalink / raw)
To: git; +Cc: Barry Wardell
In-Reply-To: <1358731322-44600-1-git-send-email-barry.wardell@gmail.com>
Signed-off-by: Barry Wardell <barry.wardell@gmail.com>
---
t/t9100-git-svn-basic.sh | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 749b75e..4fea8d9 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -306,5 +306,13 @@ test_expect_success 'git-svn works in a bare repository' '
git svn fetch ) &&
rm -rf bare-repo
'
+test_expect_success 'git-svn works in in a repository with a gitdir: link' '
+ mkdir worktree gitdir &&
+ ( cd worktree &&
+ git svn init "$svnrepo" &&
+ git init --separate-git-dir ../gitdir &&
+ git svn fetch ) &&
+ rm -rf worktree gitdir
+ '
test_done
--
1.8.0
^ permalink raw reply related
* [PATCH 2/2] git-svn: Simplify calculation of GIT_DIR
From: Barry Wardell @ 2013-01-21 1:22 UTC (permalink / raw)
To: git; +Cc: Barry Wardell
In-Reply-To: <1358731322-44600-1-git-send-email-barry.wardell@gmail.com>
Since git-rev-parse already checks for the $GIT_DIR environment
variable and that it returns an actual git repository, there is no
need to repeat the checks again here.
This also fixes a problem where git-svn did not work in cases where
.git was a file with a gitdir: link.
Signed-off-by: Barry Wardell <barry.wardell@gmail.com>
---
git-svn.perl | 36 +++++++++++++-----------------------
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index bd5266c..3bcd769 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -61,8 +61,6 @@ my $cmd_dir_prefix = eval {
command_oneline([qw/rev-parse --show-prefix/], STDERR => 0)
} || '';
-my $git_dir_user_set = 1 if defined $ENV{GIT_DIR};
-$ENV{GIT_DIR} ||= '.git';
$Git::SVN::Ra::_log_window_size = 100;
if (! exists $ENV{SVN_SSH} && exists $ENV{GIT_SSH}) {
@@ -325,27 +323,19 @@ for (my $i = 0; $i < @ARGV; $i++) {
};
# make sure we're always running at the top-level working directory
-unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
- unless (-d $ENV{GIT_DIR}) {
- if ($git_dir_user_set) {
- die "GIT_DIR=$ENV{GIT_DIR} explicitly set, ",
- "but it is not a directory\n";
- }
- my $git_dir = delete $ENV{GIT_DIR};
- my $cdup = undef;
- git_cmd_try {
- $cdup = command_oneline(qw/rev-parse --show-cdup/);
- $git_dir = '.' unless ($cdup);
- chomp $cdup if ($cdup);
- $cdup = "." unless ($cdup && length $cdup);
- } "Already at toplevel, but $git_dir not found\n";
- chdir $cdup or die "Unable to chdir up to '$cdup'\n";
- unless (-d $git_dir) {
- die "$git_dir still not found after going to ",
- "'$cdup'\n";
- }
- $ENV{GIT_DIR} = $git_dir;
- }
+if ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
+ $ENV{GIT_DIR} ||= ".git";
+} else {
+ git_cmd_try {
+ $ENV{GIT_DIR} = command_oneline([qw/rev-parse --git-dir/]);
+ } "Unable to find .git directory\n";
+ my $cdup = undef;
+ git_cmd_try {
+ $cdup = command_oneline(qw/rev-parse --show-cdup/);
+ chomp $cdup if ($cdup);
+ $cdup = "." unless ($cdup && length $cdup);
+ } "Already at toplevel, but $ENV{GIT_DIR} not found\n";
+ chdir $cdup or die "Unable to chdir up to '$cdup'\n";
$_repository = Git->repository(Repository => $ENV{GIT_DIR});
}
--
1.8.0
^ permalink raw reply related
* [PATCH v3 0/2] Make git-svn work with gitdir links
From: Barry Wardell @ 2013-01-21 1:22 UTC (permalink / raw)
To: git; +Cc: Barry Wardell
In-Reply-To: <20120308005103.GA27398@dcvr.yhbt.net>
These patches fix a bug which prevented git-svn from working with repositories
which use gitdir links.
Changes since v2:
- Rebased onto latest master.
- Added test case which verifies that the problem has been fixed.
- Fixed problems with git svn (init|clone|multi-init).
- All git-svn test cases now pass (except two in t9101 which also failed
before these patches).
Barry Wardell (2):
git-svn: Add test for git-svn repositories with a gitdir link
git-svn: Simplify calculation of GIT_DIR
git-svn.perl | 36 +++++++++++++-----------------------
t/t9100-git-svn-basic.sh | 8 ++++++++
2 files changed, 21 insertions(+), 23 deletions(-)
--
1.8.0
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-21 1:34 UTC (permalink / raw)
To: Eric Raymond; +Cc: John Keeping, git, Junio C Hamano
In-Reply-To: <CAEUsAPaw8EUcZFbODDj9Z-=3Ppd1CC=jvYDvuyntFkX_3V0ynQ@mail.gmail.com>
On Sun, Jan 20, 2013 at 2:17 PM, Chris Rorvick <chris@rorvick.com> wrote:
> On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
>>>> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping <john@keeping.me.uk> wrote:
>>>>> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
>>>>>> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
>>>>>> tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent
>>>>>> to Eric (fixes revision map.)
>>>>>
>>>>> Did you post the fix for the revision map publicly anywhere?
>>>>
>>>> It's in Eric's repo and included in version 3.8:
>>>>
>>>> https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6
>>>
>>> Thanks. For some reason I thought the fix would be to
>>> git-cvsimport-3.py. Obviously I should have read more carefully.
>>>
>>> Sorry for the noise.
>>
>> This is not a noise, though.
>>
>> Chris, how would we want to proceed? I'd prefer at some point to
>> see cvsimport-3 to be in sync when the one patched and tested in
>> Eric's repository is proven enough. Will Eric be the gatekeeper, or
>> will you be sending patches this way as well?
>
> I probably won't be sending any more patches on this. My hope was to
> get cvsimport-3 (w/ cvsps as the engine) in a state such that one
> could transition from the previous version seamlessly. But the break
> in t9605 has convinced me this is not worth the effort--even in this
> trivial case cvsps is broken. The fuzzing logic aggregates commits
> into patch sets that have timestamps within a specified window and
> otherwise matching attributes. This aggregation causes file-level
> commit timestamps to be lost and we are left with a single timestamp
> for the patch set: the minimum for all contained CVS commits. When
> all commits have been processed, the patch sets are ordered
> chronologically and printed.
>
> The problem is that is that a CVS commit is rolled into a patch set
> regardless of whether the patch set's timestamp falls within the
> adjacent CVS file-level commits. Even worse, since the patch set
> timestamp changes as subsequent commits are added (i.e., it's always
> picking the earliest) it is potentially indeterminate at the time a
> commit is added. The result is that file revisions can be reordered
> in resulting Git import (see t9605.) I spent some time last week
> trying to solve this but I coudln't think of anything that wasn't a
> substantial re-work of the code.
>
> I have never used cvs2git, but I suspect Eric's efforts in making it a
> potential backend for cvsimport are a better use of time.
>
> Chris
Hi Eric,
I noticed you were taken off this thread. As I mention above, I
looked into the bug tested in the t9605 patch Junio applied on top of
your cvsimport patch. The test was actually written for master to
test the Perl/cvsps2 import, but with minor modification you can
verify the problem still exists in the 3.x versions of cvsps.
I think the email above explains the problem pretty well. It's not
clear to me what all the nastiness is that you've resolved with cvsps
since taking over; I've been mostly concerned with importing an almost
branchless repository which I thought avoided the types of problems
you were addressing. But this bug can actually cause Git's main
import branch to become inconsistent with CVS HEAD and you don't have
to do anything too weird to get hit by it.
Fixing this seemed like it would require splitting the processing out
into a couple phases and would be a fair amount of work, but maybe I'm
just not looking at the problem right.
Chris
^ permalink raw reply
* Re: [PATCH] unpack-trees: do not abort when overwriting an existing file with the same content
From: Duy Nguyen @ 2013-01-21 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9s3n1my.fsf@alter.siamese.dyndns.org>
On Mon, Jan 21, 2013 at 1:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> + /*
>> + * If it has the same content that we are going to write down,
>
> write down???
hmm.. "overwrite" then.
>> + * there's no point in complaining. We still overwrite it in the
>> + * end though. Permission is not checked so it may be lost.
>> + */
>
> That is a regression, isn't it? Is it too cumbersome to avoid
> losing the permission bits by stopping in that case?
I'm not sure how to deal with this case. (Lack of) Executable bit can
be easily restored (unlike file content) if we give the user the list
of changed files. On the other hand, not everybody runs git with a
huge scrollback buffer and warnings can be lost. I guess abort is a
safe choice.
--
Duy
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Linus Torvalds @ 2013-01-21 1:45 UTC (permalink / raw)
To: Rusty Russell, Junio C Hamano, Git Mailing List
Cc: LKML, Alexander Graf, Prarit Bhargava, Sasha Levin
In-Reply-To: <87fw1vwcao.fsf@rustcorp.com.au>
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
> like it succeeds, except the warning, but (as we learned last time I
> screwed up), it doesn't put the branchname because it can't know.
I think this should be fixed in modern git versions.
And it sure as hell knows the proper tag name, since you *gave* it the
name and it used it for generating the actual contents. The fact that
some versions then screw that up and re-write the tag-name to
something randomly matching that isn't a tag was just a bug.
> For want of a better solution, I'll now resort to sending pull requests
> with the anti-social gitolite URL in it, like so:
That's even worse, fwiw. It means that the pull request address makes
no sense to anybody who doesn't have a kernel.org address, and then
I'm forced to just edit things by hand instead to not pollute the
kernel changelog history with crap.
Junio, didn't "git request-pull" get fixed so that it *warns* about
missing tagnames/branches, but never actually corrupts the pull
request? Or did it just get "fixed" to be a hard error instead of
corrupting things? Because this is annoying.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Duy Nguyen @ 2013-01-21 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <7v38xxnfv3.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 2:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> Should the client side learn how to list hidden refs too? I'm thinking
>> of an extreme case where upload-pack advertises nothing (or maybe just
>> refs/heads/master) and it's up to the client to ask for the ref
>> selection it's interested in. upload-pack may need more updates to do
>> that, I think.
>
> What you are talking about is a different goal.
>
> Look at this as a mechanism for the repository owner to control the
> clutter in what is shown to the intended audience of what s/he
> publishes in the repository. Network bandwidth reduction of
> advertisement is a side effect of clutter reduction, and not
> necessarily the primary goal.
Probably stupid question: does gitnamespaces.txt attempt to achieve
the same? The document says smart http supports passing namespace,
nothing about git protocol so I guess we need some extension in
upload-pack (or git-daemon) for specifying namespace over git
protocol.
--
Duy
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Jeff King @ 2013-01-21 1:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Kelly, git
In-Reply-To: <7v8v7nli2a.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 12:23:41PM -0800, Junio C Hamano wrote:
> In any case, the intent of the author timestamp is to record the
> time the author _started_ working on the change and came up with an
> initial, possibly a partial, draft. It does not record the time
> when the commit was finalized. "git commit --amend" preserves the
> original timestamp, doesn't it?
And we have "--reset-author" if you want to do that. It seems like just
doing "git commit --amend --reset-author" at the end[1] would solve the
original problem. Perhaps that is something that we could better
support directly from the instruction sheet.
-Peff
[1] or after an "edit" break in the instruction sheet, if it is in the
middle of a set of commits
^ permalink raw reply
* Re: [PATCH v3 0/2] Make git-svn work with gitdir links
From: Junio C Hamano @ 2013-01-21 1:50 UTC (permalink / raw)
To: Barry Wardell; +Cc: git, Eric Wong, Carlos Martín Nieto
In-Reply-To: <1358731322-44600-1-git-send-email-barry.wardell@gmail.com>
Barry Wardell <barry.wardell@gmail.com> writes:
> These patches fix a bug which prevented git-svn from working with repositories
> which use gitdir links.
>
> Changes since v2:
> - Rebased onto latest master.
> - Added test case which verifies that the problem has been fixed.
> - Fixed problems with git svn (init|clone|multi-init).
> - All git-svn test cases now pass (except two in t9101 which also failed
> before these patches).
>
> Barry Wardell (2):
> git-svn: Add test for git-svn repositories with a gitdir link
> git-svn: Simplify calculation of GIT_DIR
Thanks for your persistence ;-) As this is a pretty old topic, I'll
give two URLs for people who are interested to view the previous
threads:
http://thread.gmane.org/gmane.comp.version-control.git/192133
http://thread.gmane.org/gmane.comp.version-control.git/192127
You would want to mark it as test_expect_failure in the first patch
and then flip it to text_expect_success in the second patch where
you fix the breakage? Otherwise, after applying the first patch,
the testsuite will break needlessly.
I've Cc'ed Eric Wong (git-svn maintainer) and CMN who helped in the
previous round. If the only issue is the above success/failure one,
I think Eric can tweak the patches while applying them (I didn't
look at the changes carefully myself, by the way).
Thanks.
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Junio C Hamano @ 2013-01-21 2:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rusty Russell, Git Mailing List, LKML, Alexander Graf,
Prarit Bhargava, Sasha Levin
In-Reply-To: <CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
>> like it succeeds, except the warning, but (as we learned last time I
>> screwed up), it doesn't put the branchname because it can't know.
>
> I think this should be fixed in modern git versions.
> ...
> Junio, didn't "git request-pull" get fixed so that it *warns* about
> missing tagnames/branches, but never actually corrupts the pull
> request? Or did it just get "fixed" to be a hard error instead of
> corrupting things? Because this is annoying.
What you mean by "corrupt" is not clear to me, but the last change
to the script is from 6 months ago to solve a related (perhaps the
same?) problem, which should be in v1.7.11.2 and later:
request-pull: really favor a matching tag
After tagging the tip of "dev" branch with a "for-linus" tag and
pushing both out, running
$ git request-pull $url $last_release dev
would produce an output asking the 'dev' branch of $url to be
pulled, because that is what the user asked the message to say.
We already detect this situation locally and include the
contents of the tag in the output; if the $url has that tag,
favor that tag (i.e. "for-linus") in the generated message over
the branch name the user gave us (i.e. "dev") from the command
line, to make the output look more consistent.
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Linus Torvalds @ 2013-01-21 2:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Rusty Russell, Git Mailing List, LKML, Alexander Graf,
Prarit Bhargava, Sasha Levin
In-Reply-To: <7vpq0zi9c7.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> What you mean by "corrupt" is not clear to me
Some versions would just silently change the actual name you were using.
So if you said "for-linus", it might change it to "linus", just
because that branch happened to have the same SHA1 commit ID.
That's not right.
Other versions would replace the "for-linus" with "**missing-branch**"
because "for-linus" hadn't mirrored out yet.
That's not right either.
Basically, if "git request-pull" is given a branch/tag name, that is
the only valid output (although going from branch->tag *might* be
acceptable). The whole "verify that it actually exists on the remote
side" must never *ever* actually change the message itself, it should
just cause a warning outside of the message.
I can't say from the commit message whether that's the thing that
fixed it or not, but at least some people stopped sending me broken
pull requests after updating to git. I'm just not sure which of the
two different failure cases they happened to have (Rusty seems to have
hit both)
Linus
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Eric S. Raymond @ 2013-01-21 2:43 UTC (permalink / raw)
To: Chris Rorvick; +Cc: John Keeping, git, Junio C Hamano
In-Reply-To: <CAEUsAPYdpsbhCZfp-1w91ZiyqgEa=8TNf2MJihMViqVZmW3sRw@mail.gmail.com>
> > I probably won't be sending any more patches on this. My hope was to
> > get cvsimport-3 (w/ cvsps as the engine) in a state such that one
> > could transition from the previous version seamlessly. But the break
> > in t9605 has convinced me this is not worth the effort--even in this
> > trivial case cvsps is broken. The fuzzing logic aggregates commits
> > into patch sets that have timestamps within a specified window and
> > otherwise matching attributes. This aggregation causes file-level
> > commit timestamps to be lost and we are left with a single timestamp
> > for the patch set: the minimum for all contained CVS commits. When
> > all commits have been processed, the patch sets are ordered
> > chronologically and printed.
> >
> > The problem is that is that a CVS commit is rolled into a patch set
> > regardless of whether the patch set's timestamp falls within the
> > adjacent CVS file-level commits. Even worse, since the patch set
> > timestamp changes as subsequent commits are added (i.e., it's always
> > picking the earliest) it is potentially indeterminate at the time a
> > commit is added. The result is that file revisions can be reordered
> > in resulting Git import (see t9605.) I spent some time last week
> > trying to solve this but I coudln't think of anything that wasn't a
> > substantial re-work of the code.
I've lost who was who in the comment thread, but I think it is rather likely
that the above diagnosis is correct in every respect.
I won't know for certain until I finish the test suite and apply it to
all three tools (cvsps, cvs2git, cvs-fast-export) but what I've seen
of their code indicates that cvsps has the weakest changeset analysis of
the three, even after my fixes.
> > I have never used cvs2git, but I suspect Eric's efforts in making it a
> > potential backend for cvsimport are a better use of time.
Agreed. I didn't add multiengine support to csvsimport at random or
just because Heiko Vogt was bugging me about parsecvs. I was
half-expecting cvsps to manifest a showstopper like this - hoping it
wouldn't, but hedging against the possibility by making alternate
engines easy to plug into git-cvsimport seemed like a *really good
idea* from the beginning of my work on it. Sometimes being that kind
of right really sucks.
While I am going to have a try at modifying cvsps to make Chris's
t9605 case work, I'm going to strictly limit the amount of time I
spend on that effort since (as you imply) it is fairly likely this
would be throwing good money after bad.
> Fixing this seemed like it would require splitting the processing out
> into a couple phases and would be a fair amount of work, but maybe I'm
> just not looking at the problem right.
Actually I think you've called it *exactly* right. The job has to be
done in multiple clique-spitting phases - that's why cvs2git has 7 passes
(though a few of those, perhaps as many as 3, are artifactual).
This is why the next step in my current work plan for CVS-related stuff will
be unbundling my test suite from the cvsps tree and running it to see if
cvs-fast-export dominates cvsps.
I'm expecting that it will, in which case my plan will be to salvage
the CVS client code out of cvsps (*that* part is quite good - fast,
clean, effective) gluing it to the better analysis stage in
cvs-fast-export, and then shooting cvsps through the head and burying
it behind the barn.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Rusty Russell @ 2013-01-21 2:57 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano, Git Mailing List
Cc: LKML, Alexander Graf, Prarit Bhargava, Sasha Levin
In-Reply-To: <CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
>> like it succeeds, except the warning, but (as we learned last time I
>> screwed up), it doesn't put the branchname because it can't know.
>
> I think this should be fixed in modern git versions.
>
> And it sure as hell knows the proper tag name, since you *gave* it the
> name and it used it for generating the actual contents. The fact that
> some versions then screw that up and re-write the tag-name to
> something randomly matching that isn't a tag was just a bug.
I'm confused. The default argument is HEAD: what does it know about tag
names?
git request-pull master korg
The bug is that if it can't find that commit at the remote end, it
still generates a valid-looking request (with a warning at the end),
where it guesses you're talking about the master branch.
>> For want of a better solution, I'll now resort to sending pull requests
>> with the anti-social gitolite URL in it, like so:
>
> That's even worse, fwiw. It means that the pull request address makes
> no sense to anybody who doesn't have a kernel.org address, and then
> I'm forced to just edit things by hand instead to not pollute the
> kernel changelog history with crap.
Since I use a wrapper script now for your pull requests I can use sed to
unscrew it:
[alias]
for-linus = !check-commits && TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus && git tag -f -u D1ADB8F1 $TAGNAME HEAD && git push korg tag $TAGNAME && git request-pull master korg | sed s,gitolite@ra.kernel.org:/pub,git://git.kernel.org/pub, && git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'stable@kernel.org' | sed 's/^/Cc: /'
> Junio, didn't "git request-pull" get fixed so that it *warns* about
> missing tagnames/branches, but never actually corrupts the pull
> request? Or did it just get "fixed" to be a hard error instead of
> corrupting things? Because this is annoying.
Here: git version 1.7.10.4
Cheers,
Rusty.
^ permalink raw reply
* Re: [PULL] Module fixes, and a virtio block fix.
From: Linus Torvalds @ 2013-01-21 3:15 UTC (permalink / raw)
To: Rusty Russell
Cc: Junio C Hamano, Git Mailing List, LKML, Alexander Graf,
Prarit Bhargava, Sasha Levin
In-Reply-To: <871udfw8e0.fsf@rustcorp.com.au>
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> I'm confused. The default argument is HEAD: what does it know about tag
> names?
Ugh. I actually thought that if you give it the tag name directly (as
the "end") it will use that.
But no. It figures it out with "git describe --exact" internally.
Regardless, if your HEAD is actually tagged, it *will* have the
tag-name in git-request-pull.
And it will have it based on your *local* repo, so the fact that it
hasn't been mirrored out yet doesn't really matter. git request-pull
knows that tag name regardless of mirroring issues.
> The bug is that if it can't find that commit at the remote end, it
> still generates a valid-looking request (with a warning at the end),
> where it guesses you're talking about the master branch.
It really shouldn't do that any more, but you seem to have the older
version with the bug.
At least one of the annoying problems was fixed in the 1.7.11 series,
you have 1.7.10.
The nice thing about git is that it is *really* easy to upgrade. Just
fetch the sources, do "make; make install" all as a normal user, and
you do not need to worry about package management or distro issues or
any crap like that. It installs into your $(HOME)/bin, and as long as
your PATH has that first, you'll get it. I've long suggested that as
the workaround for distros having old versions (some more so than
others).
> Since I use a wrapper script now for your pull requests I can use sed to
> unscrew it:
>
> [alias]
> for-linus = !check-commits && TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus && git tag -f -u D1ADB8F1 $TAGNAME HEAD && git push korg tag $TAGNAME && git request-pull master korg | sed s,gitolite@ra.kernel.org:/pub,git://git.kernel.org/pub, && git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'stable@kernel.org' | sed 's/^/Cc: /'
Heh. Ok. That will at least hide the breakage. But I suspect you could
fix it by just updating git.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox