* [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 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
* 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
* 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: 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: 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: 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: 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: 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: [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: [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: [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: [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: Josef 'Jeff' Sipek @ 2013-01-20 21:24 UTC (permalink / raw)
To: Per Cederqvist
Cc: Jonathan Nieder, git, Theodore Ts'o, Iulian Udrea,
Axel Beckert
In-Reply-To: <50FC5F6B.6070103@opera.com>
On Sun, Jan 20, 2013 at 10:19:39PM +0100, Per Cederqvist wrote:
> 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.
At $WORK, we started doing thorough reviews before committing. I'm kinda
sold on this feature. I agree with the off-by-default config flag.
> I don't want Guilt to fork. Jeff, it would be really great if
> you could set up a public repo again!
Yep. I'm trying to reclaim control of the repo.or.cz guilt repo... I no
longer have access to jsipek@cs.sunysb.edu and I don't remember the
password.
Jeff.
--
NT is to UNIX what a doughnut is to a particle accelerator.
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-20 21:17 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git
In-Reply-To: <20130120192412.GA7498@serenity.lan>
On Sun, Jan 20, 2013 at 1:24 PM, John Keeping <john@keeping.me.uk> wrote:
> On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
>> 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?
>
> In this case the patch was to the C portion of cvsps, not the Python
> cvs-import, so not relevant for this particular case.
Oh, I think I misunderstood the question. The only time I passed a
patch specifically for git-cvsimport.py directly to Eric was before
the his patch was in Junio's repository. Unless I'm mistaken, only
the second patch Eric sent was actually imported. Subsequent to this
I would have submitted any patches for git-cvsimport.py directly to
the git list. I just didn't have any--cvsps had several problems that
needed to be worked out before it made sense to look at the importer.
In other words, I don't think Eric should be a gatekeeper of this code.
Chris
^ permalink raw reply
* Re: Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Junio C Hamano @ 2013-01-20 21:08 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: davvid, git
In-Reply-To: <775908345.1391972.1358713010522.JavaMail.ngmail@webmail12.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
>> If I were to decide today to change the spellings, with an explicit
>> purpose of making things more consistent across documentation, it
>> may make sense to use even a simpler rule that is less error-prone
>> for people who write new sentences that has to have the word. How
>> about treating it just like any other ordinary word? That is, we
>> say "git" (without double-quotes, of course), unless it comes at the
>> beginning of a sentence?
>>
>
> The widely used books on Git by Scott Chacon or Jon Loeliger (and
> many others) are using 'Git' instead of 'git' when talking about the
> whole system. So IMHO it would not be wise to change our internal
> documentation from using 'GIT'/'Git' to using 'git'. The internal
> documentation should be a natural continuation of these books
> by content and style.
That argument is going the other way around (we _are_ the
authoritative source).
But I am OK with "Git" as a proper noun (which always begins with
capital letter), using "git" only when it is something the user
would type. Just come up with a simple-to-explain rule so that
people will have no doubt which one to use in their new text and
stick to it.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] Allow Git::get_tz_offset to properly handle DST boundary times
From: Junio C Hamano @ 2013-01-20 21:03 UTC (permalink / raw)
To: Ben Walton; +Cc: Eric Raymond, git
In-Reply-To: <CAP30j14Og7YLaZj0dbpAhUHFfuy0Y=bEn_3EqGzxR5PRA7vQXA@mail.gmail.com>
Ben Walton <bdwalton@gmail.com> writes:
> also avoids the oddball 1/2 hour DST shift. I can re-roll the series
> with your code (and credit for it) or you can apply you change on top
> of my series...whichever is easiest for you.
Please reroll, as I do not have patience either to set up a test
case and verify the end result is correct, or to come up with a test
case for it. For this particular case, I think the identification
of the issue weighs more than the implementation for fix it, so
please retain the authorship for the fix; mentioning "taking the
implementation idea from Junio" in the log message is the right
amount of credit due to me.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
From: Brandon Casey @ 2013-01-20 21:03 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git, Pete Wyckoff
In-Reply-To: <20130120192831.GB7498@serenity.lan>
On Sun, Jan 20, 2013 at 11:28 AM, John Keeping <john@keeping.me.uk> wrote:
> On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
>>> 2.8 will never exist [1], it is most concise to just list the supported
>>> versions.
>>
>> Thanks; Eric's patch recently updated git-p4.py to require 2.4 I
>> think. Shouldn't it also be updated?
Actually, the script does not support python 2.4 in its current state
since it uses subprocess.check_call which was introduced in python
2.5.
But, this can be trivially worked around. I made the changes in my
own tree on Friday and planned to submit them after using it myself
for a few days.
Personally, I prefer to continue to provide the ability to compile and
install a fully working git on platforms in common use without pulling
in additional dependencies. At least while it's fairly easy to do so.
So, in my opinion, git-p4 should be patched to support python 2.4 and
the comment in INSTALL should be updated. But, this opinion should be
taken with the appropriate grain of salt since I'm not really a
contributor to any of the python infrastructure.
-Brandon
^ permalink raw reply
* Re: [PATCH v2] Make git selectively and conditionally ignore certain stat fields
From: Junio C Hamano @ 2013-01-20 20:30 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, j sixt, Shawn Pearce
In-Reply-To: <1999787368.3950248.1358711511739.JavaMail.root@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> ----- Ursprungligt meddelande -----
>
>> That configurability is a slipperly slope to drag us into giving
>> users
>> more complexity that does not help them very much, I suspect.
>>
>> Earlier somebody mentioned "size and mtime is often enough", so I
>> think a single option core.looseStatInfo (substitute "loose" with
>> short, minimum or whatever adjective that is more appropriate---I am
>> not good at picking phrases, it sounds to me a way to more loosely
>> define stat info cleanliness than we usually do) that makes us
>> ignore all fields (regardless of their zero-ness) other than those
>> two fields might not be a bad way to go.
>
> Would something like this be good?
>
> core.statinfo =
> default = all fields
> minimal = whole seconds of mtime and size
> medium = seconds, nanos of mtime and size
> nonzero = all non-zero fields
>
> -- robin
If you mean to exclude ctime and other fields we already exclude as
useless from your "all", that may make sense, but do we really need
that much "flexibility", or do "more choices" just confuse users? I
have this suspicion that it may be the latter.
Wouldn't a single boolean that lets users choose between your
"minimal" and "default" be sufficient?
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Junio C Hamano @ 2013-01-20 20:23 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <kdhfk6$von$1@ger.gmane.org>
Stephen Kelly <steveire@gmail.com> writes:
> Junio C Hamano wrote:
>> Sorry, but I do not understand what you are trying to solve.
>>
>> How can 1313a5e, which fixes misakes made in c2f62a3, come before
>> that commit in the first place?
>
> One scenario is something like this:
>
> Start with a clean HEAD (always a good idea :) )
> hack hack hack
> make multiple commits
> realize that a hunk you committed in an early patch belongs in a later one.
> use git rebase -i to fix it.
>
> Is that more clear?
Not really.
If you think that the author timestamp is the time the author
finished working on the commit, shouldn't the squashed result get
the timestamp when you finished squashing, not the timestamp of
either of the commits that were squashed? Unlike "fixup" and
"reword", the change you are making is very different from any of
the original constituent commmits, and you finished working on that
change when you squashed these commits into one. Propagating the
timestamp from the later ones sounds equally wrong for that purpose.
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?
In your example:
> pick 07bc3c9 Good commit.
> pick 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
you can view 1313a5e as a "preparatory clean-up for the real change
in c2f62a3", which could be a separate commit in the final history.
If you choose to squash them together into one, the time you
recorded 1313a5e was when you started working on the combined
change, so it does not sound so wrong to take that author timestamp
for the result.
^ permalink raw reply
* Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Thomas Ackermann @ 2013-01-20 20:16 UTC (permalink / raw)
To: gitster, davvid; +Cc: th.acker, git
>
> If I were to decide today to change the spellings, with an explicit
> purpose of making things more consistent across documentation, it
> may make sense to use even a simpler rule that is less error-prone
> for people who write new sentences that has to have the word. How
> about treating it just like any other ordinary word? That is, we
> say "git" (without double-quotes, of course), unless it comes at the
> beginning of a sentence?
>
The widely used books on Git by Scott Chacon or Jon Loeliger (and
many others) are using 'Git' instead of 'git' when talking about the
whole system. So IMHO it would not be wise to change our internal
documentation from using 'GIT'/'Git' to using 'git'. The internal
documentation should be a natural continuation of these books
by content and style.
- Just my thoughts.
---
Thomas
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-20 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, git
In-Reply-To: <7vsj5vlm1d.fsf@alter.siamese.dyndns.org>
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
^ permalink raw reply
* git-cvsimport-3 and incremental imports
From: John Keeping @ 2013-01-20 20:09 UTC (permalink / raw)
To: git; +Cc: Eric S. Raymond
I've now spent some time looking at git-cvsimport-3.py from
jc/cvsimport-upgrade and made some progress in making it pass more of
the Git test suite (my work in progress is at [1]).
However, I think there is a fundamental problem with the way it handles
incremental imports and I'm hoping someone with more git-fast-import
experience can point me in the right direction.
Currently, cvsps-3 never writes a "from ..." line in the first commit it
outputs for a branch, even when the output is restricted by date (i.e. a
continuation of a previously imported branch), which results in failure
to update branches since git-fast-import is run without "--force". If I
make a simple modification so that it does this, it can end up
outputting an empty commit (a duplicate of the current tip commit on the
branch).
Given that the start date for the import is currently just read from
HEAD there is probably scope for this being worse on other branches if
they have more recent commits than the current branch.
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.
[1] https://github.com/johnkeeping/git/tree/cvsimport-3
John
^ permalink raw reply
* Re: [PATCH 2/3] Allow Git::get_tz_offset to properly handle DST boundary times
From: Ben Walton @ 2013-01-20 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Raymond, git
In-Reply-To: <7vy5frtymt.fsf@alter.siamese.dyndns.org>
On Thu, Jan 17, 2013 at 7:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ben Walton <bdwalton@gmail.com> writes:
>
>> The Git::get_tz_offset is meant to provide a workalike replacement for
>> the GNU strftime %z format specifier. The algorithm used failed to
>> properly handle DST boundary cases.
>>
>> For example, the unix time 1162105199 in CST6CDT saw set_tz_offset
>> improperly return -0600 instead of -0500.
>>
>> TZ=CST6CDT date -d @1162105199 +"%c %z"
>> Sun 29 Oct 2006 01:59:59 AM CDT -0500
>>
>> $ zdump -v /usr/share/zoneinfo/CST6CDT | grep 2006
>> /usr/share/zoneinfo/CST6CDT Sun Apr 2 07:59:59 2006 UTC = Sun Apr 2
>> 01:59:59 2006 CST isdst=0 gmtoff=-21600
>> /usr/share/zoneinfo/CST6CDT Sun Apr 2 08:00:00 2006 UTC = Sun Apr 2
>> 03:00:00 2006 CDT isdst=1 gmtoff=-18000
>> /usr/share/zoneinfo/CST6CDT Sun Oct 29 06:59:59 2006 UTC = Sun Oct 29
>> 01:59:59 2006 CDT isdst=1 gmtoff=-18000
>> /usr/share/zoneinfo/CST6CDT Sun Oct 29 07:00:00 2006 UTC = Sun Oct 29
>> 01:00:00 2006 CST isdst=0 gmtoff=-21600
>>
>> To determine how many hours/minutes away from GMT a particular time
>> was, we calculated the gmtime() of the requested time value and then
>> used Time::Local's timelocal() function to turn the GMT-based time
>> back into a scalar value representing seconds from the epoch. Because
>> GMT has no daylight savings time, timelocal() cannot handle the
>> ambiguous times that occur at DST boundaries since there are two
>> possible correct results.
>>
>> To work around the ambiguity at these boundaries, we must take into
>> account the pre and post conversion values for is_dst as provided by
>> both the original time value and the value that has been run through
>> timelocal(). If the is_dst field of the two times disagree then we
>> must modify the value returned from timelocal() by an hour in the
>> correct direction.
>
> It seems to me that it is a very roundabout way. It may be correct,
> but it is unclear why the magic +/-3600 shift is the right solution
> and I suspect even you wouldn't notice if I sent you back your patch
> with a slight change to swap $gm += 3600 and $gm -= 3600 lines ;-).
>
> For that timestamp in question, the human-readable representation of
> gmtime($t) and localtime($t) look like these two strings:
>
> my $t = 1162105199;
> print gmtime($t), "\n"; # Sun Oct 29 06:59:59 2006
> print localtime($t), "\n"; # Sun Oct 29 01:59:59 2006
>
> As a human, you can easily see that these two stringified timestamps
> look 5 hours apart. Think how you managed to do so.
>
> If we convert these back to the seconds-since-epoch, as if these
> broken-down times were both in a single timezone that does not have
> any DST issues, you can get the offset (in seconds) by subtraction,
> and that is essentially the same as the way in which your eyes saw
> they are 5 hours apart, no? In other words, why do you need to run
> timelocal() at all?
>
> my $t = 1162105199;
> my $lct = timegm(localtime($t));
> # of course, timegm(gmtime($t)) == $t
>
> my $minutes = int(($lct - $t)/60);
> my $sign "+";
> if ($minutes < 0) {
> $sign = "-";
> $minutes = -$minutes;
> }
> my $hours = int($minutes/60);
> $minutes -= $hours * 60;
> sprintf("%s%02d%02d", $sign, $hours, $minutes);
>
> Confused...
>
>>
>> Signed-off-by: Ben Walton <bdwalton@gmail.com>
>> ---
>> perl/Git.pm | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/perl/Git.pm b/perl/Git.pm
>> index 5649bcc..788b9b4 100644
>> --- a/perl/Git.pm
>> +++ b/perl/Git.pm
>> @@ -528,7 +528,27 @@ If TIME is not supplied, the current local time is used.
>> sub get_tz_offset {
>> # some systmes don't handle or mishandle %z, so be creative.
>> my $t = shift || time;
>> + # timelocal() has a problem when it comes to DST ambiguity so
>> + # times that are on a DST boundary cannot be properly converted
>> + # using it. we will possibly adjust its result depending on whehter
>> + # pre and post conversions agree on DST
>> my $gm = timelocal(gmtime($t));
>> +
>> + # we need to know whether we were originally in DST or not
>> + my $orig_dst = (localtime($t))[8];
>> + # and also whether timelocal thinks we're in DST
>> + my $conv_dst = (localtime($gm))[8];
>> +
>> + # re-adjust $gm based on the DST value for the two times we're
>> + # handling.
>> + if ($orig_dst != $conv_dst) {
>> + if ($orig_dst == 1) {
>> + $gm -= 3600;
>> + } else {
>> + $gm += 3600;
>> + }
>> + }
>> +
>> my $sign = qw( + + - )[ $t <=> $gm ];
>> return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
>> }
Sorry for the slow response, I didn't have a good chance to look at
this until now. You are correct; your solution appears simpler and
also avoids the oddball 1/2 hour DST shift. I can re-roll the series
with your code (and credit for it) or you can apply you change on top
of my series...whichever is easiest for you.
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself. Much more happiness,
truth, beauty and wisdom will come to you that way.
-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
From: Junio C Hamano @ 2013-01-20 19:54 UTC (permalink / raw)
To: John Keeping; +Cc: Eric S. Raymond, git, Pete Wyckoff
In-Reply-To: <20130120192831.GB7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
>>> 2.8 will never exist [1], it is most concise to just list the supported
>>> versions.
>>
>> Thanks; Eric's patch recently updated git-p4.py to require 2.4 I
>> think. Shouldn't it also be updated?
>
> I haven't done a thorough audit to check what the actual minimum
> supported version is, this is just the minimal change to say "not
> Python 3".
>
> Personally, I'm not sure of the value of having version checks at the
> top of the Python scripts, I would rather set a project-wide minimum
> supported version (as in my recent CodingGuidelines patch) and check it
> once in the Makefile.
OK; I'll leave that for later a day (Cc'ed Eric but stakeholders of
other Python scripts may want to express their opinions), and will
apply this patch as is.
If we end up deciding to rip out the "prerequisite per file", that
will be a tree-wide change that is independent from your patch we
are discussing in this thread. If we end up not doing that, then we
would instead be updating git-p4.py to set a higher floor to the
prerequiste but that can come as a separate patch.
Thanks.
^ 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