* Re: [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Johannes Schindelin @ 2007-08-31 21:05 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, gitster
In-Reply-To: <20070831191921.GB2151@diana.vm.bytemark.co.uk>
Hi,
On Fri, 31 Aug 2007, Karl Hasselstr?m wrote:
> On 2007-08-31 20:06:27 +0100, Johannes Schindelin wrote:
>
> > It does _not_ undo the changeset corresponding to that commit, but
> > it _skips_ the revision. IOW its ancestors' tree objects remain the
> > same.
>
> While this is true too, I'm guessing you intended to say that its
> _descendants'_ tree objects remain the same. Right?
Right. So how about:
IOW no tree objects are changed by this.
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: repo.or.cz wishes?
From: Shawn O. Pearce @ 2007-08-31 21:09 UTC (permalink / raw)
To: Theodore Tso; +Cc: Johannes Schindelin, Petr Baudis, git
In-Reply-To: <20070829111345.GD29615@thunk.org>
Theodore Tso <tytso@mit.edu> wrote:
> On Wed, Aug 29, 2007 at 12:15:23AM -0400, Shawn O. Pearce wrote:
> > >
> > > git --git-dir=A gc
> > > ln A/.git/objects/pack/* B/.git/objects/pack
> > > git --git-dir=B gc --prune
> > > git --git-dir=A prune
> >
> > No, it won't work.
> >
> > The problem is that during the first `git --git-dir=A gc` call
> > you are deleting packfiles that may contain objects that B needs.
> > *poof*.
>
> But "git-gc" without the --prune doesn't delete any objects.
Yes, it does delete objects. Even without --prune. That is
because git-gc is running `git-repack -a -d -l`. repack -a means
repack all objects reachable from the current refs. The -d means
delete the packfiles that existed when the repack started, as it
is assumed that all needed (reachable) objects were copied into
the new output packfile(s). The -d also means delete any loose
objects that are now packed (git-prune-packed).
Yet there may be objects in A that A cannot reach anymore (deleted
or rewound branch) but that B needs and B does not have a copy of.
If these objects were in one of the prior packfiles of A and is
not in the new packfile(s) of A then those objects are gone. *poof*.
> So it
> should always be safe to use git-gc even if there are repositories
> that are relying on that repo's ODB. It's only if you use git-gc
> --prune that you could get in troudble. It might delete some
> packfiles containing objects needed by B, but only after consolidating
> all of the objects into a single packfile that contains all of the
> objects that had always been in A's ODB.
But when we repack we don't repack everything in A's ODB, we only
repack the things that A can reach. If A cannot reach something
because a branch was rewound or deleted it won't survive the repack.
Then the repack is behaving like at least partially like gc --prune.
> So I don't see why this wouldn't work.
It only works if A cannot delete a branch or rewind a branch.
In other words, once an object is stored in A's ODB it must always
be reachable from A's refs.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] filter-branch: provide the convenience functions also for commit filters
From: Johannes Schindelin @ 2007-08-31 21:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm07xvwa.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Obviously, I think that these two changes are simple enough to be
> > included even this late in the game for 1.5.3. But I understand
> > completely when people shout at me: "What exactly does deep
> > feature freeze mean to you *knocks on Dscho's head*?"
>
> My response to those people who might shout is that this is merely a
> step to complete a _new_ program that was not in _any_ released version
> to make it feature complete. You do not have to even pretend that
> filter-branch did not exist before -- it actually didn't. The new part
> might be buggier than other parts, but that's the same way as any other
> software development process. If the new 'map' does not work as
> advertised there is always 1.5.3.1.
Thank you for your encouraging words.
And yes, if there are bugs, I will be more than happy to fix them; and a
released version always gets more eyes than an unreleased one.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Add commands that git-gc runs underneath
From: Junio C Hamano @ 2007-08-31 21:12 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <46D7E058.9050001@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> When gc was a shell-script, it was fairly easy to find out the command-
>>> sequence...
>>
>> Maybe referring more advanced/curious users to contrib/examples/
>> directory is a good idea, but not necessarily from manpages of
>> the commands that have been rewritten in C.
>>
>> I think contrib/examples/ needs a README file that effectively
>> say "these are the last versions of shell script implementation
>> of the commands before they were rewritten in C. New features
>> may have been added to the built-in ones but these example
>> scripts are not kept up to date. They are here to serve as
>> examples to show you how you would pipeline the plumbing level
>> commands."
>
> Sensible, and also avoids the possible bitrot problem with the
> man-page should there be additional actions added to standard
> git-gc operations.
Oh, I did not mean to address bit-rot issue. I was addressing
"ah, in good old days we had tons of example scripts" issue.
If we want the manual to be explicit about what exactly happens
when you run "git-gc" (and I think we do), that needs to be done
independently. But my feeling is that we do not want to
describe what happens solely in terms of what other individual
commands do. Referring to other manual pages for more details
is fine, but that should not be the sole description.
In other words, instead of saying:
- runs "git pack-refs", "git reflog expire --all", "git repack
-a -d -l", ...
I think we would want to say it this way:
* Under such-and-such condition, loose refs are packed for
quicker access in $GIT_DIR/packed-refs file (runs "git
pack-refs --prune");
* Old reflog entries that record how tips of each branches were
moved are expired (runs "git-reflog expire --all");
* Packfiles are repacked along with loose object files, while
exclusing objects that are available from the alternates
(runs "git repack -a -d -l");
* Unreferenced loose objects are removed if --prune is given
(runs "git prune");
* Old rerere records that record resolutions to previously
conflicted merges are expired (runs "git rerere gc").
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Junio C Hamano @ 2007-08-31 21:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, Michael S. Tsirkin
In-Reply-To: <Pine.LNX.4.64.0708312154530.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Aug 2007, Jeff King wrote:
>
>> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:
>>
>> > If you set diff.autorefreshindex configuration variable, it
>> > squelches the empty "diff --git" output, and at the end of the
>> > command, it automatically runs "update-index --refresh" without
>> > even bothering the user. In other words, with the configuration
>> > variable set, people who do not care about the cache-dirtyness
>> > do not even have to see the warning.
>>
>> Nice. This is much more sane behavior, IMHO, and I think it should make
>> everyone happy.
>
> I could even imagine that this will eventually become the standard
> behaviour.
You sound as if you _like_ that behaviour...
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: David Kastrup @ 2007-08-31 21:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git, Michael S. Tsirkin
In-Reply-To: <Pine.LNX.4.64.0708312154530.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Aug 2007, Jeff King wrote:
>
>> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:
>>
>> > If you set diff.autorefreshindex configuration variable, it
>> > squelches the empty "diff --git" output, and at the end of the
>> > command, it automatically runs "update-index --refresh" without
>> > even bothering the user. In other words, with the configuration
>> > variable set, people who do not care about the cache-dirtyness
>> > do not even have to see the warning.
>>
>> Nice. This is much more sane behavior, IMHO, and I think it should make
>> everyone happy.
>
> I could even imagine that this will eventually become the standard
> behaviour.
>
>> > Same here. This patch saw only very light testing, but I
>> > personally think is a sane thing to do before 1.5.3 final.
>>
>> Passes my light testing as well, but I have a feeling we just tested the
>> same things...;)
>>
>> One question on the implementation (and remember that I am somewhat
>> ignorant of the structure of this part of the code, so the answer may be
>> "it's too ugly"): is there a good reason to refresh _after_ the diff?
>
> We do not need to do it always. After the diff, we know if the
> index needs refreshing. Before, we don't.
Hm. At the moment where it is first noticed, it should be still
possible to start a refresh. Is there a particular gain to be
expected? One thing I could think of is that when using a pager, the
diff might often die of SIGPIPE before being able to refresh.
>> It seems like when we are looking through the working tree and
>> index the first time, we notice that the stat information doesn't
>> match; why can't we update it then? That would save an extra
>> working tree traversal.
>
> But that would be intrusive in the diff machinery IMHO. It should
> stay as read-only as possible.
Hm. Not sure where the gain is in that, if a refresh is done, anyway.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Perl warning in git-svn (git v1.5.3-rc7-16-ge340d7d)
From: Junio C Hamano @ 2007-08-31 21:22 UTC (permalink / raw)
To: Eric Wong; +Cc: Robert Newson, git
In-Reply-To: <7v4pifzawc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I was almost going to suggest us to change "*.color = true" to
> mean 'auto'. Because git can internally use pager and has a way
> for the user to control enabling/disabling colors when the pager
> is used, there is no _logical_ reason to enable pager when the
> output is not going to a tty.
Gaah, sorry; I meant "no logical reason to enable _color_ when
the output is not going to a tty".
^ permalink raw reply
* Re: [PATCH] Add commands that git-gc runs underneath
From: David Kastrup @ 2007-08-31 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <7vlkbrxvbm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> But my feeling is that we do not want to describe what happens
> solely in terms of what other individual commands do. Referring to
> other manual pages for more details is fine, but that should not be
> the sole description.
>
> In other words, instead of saying:
[...]
> I think we would want to say it this way:
[...]
I would say your feeling is dead-on. Full agreement with that
proposal.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* git-svn: Protect against "diff.color = true".
From: Junio C Hamano @ 2007-08-31 21:29 UTC (permalink / raw)
To: Eric Wong, Robert Newson; +Cc: git
In-Reply-To: <7v4pifzawc.fsf@gitster.siamese.dyndns.org>
If the configuration of the user has "diff.color = true", the
output from "log" we invoke internally added color codes, which
broke the parser.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> We probably should do two things to resolve this.
>
> * Protect our scripts. When parsing from "git log" and any
> other Porcelain, explicitly give --no-color.
Here is my attempt -- I do not have an easy access to SVN repo
to interoperate with, so a testing by real-world users and an
Ack is appreciated. I think some fix for this issue (not
necessarily this patch) should be in 1.5.3 final.
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4e325b7..98218da 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -807,7 +807,7 @@ sub cmt_metadata {
sub working_head_info {
my ($head, $refs) = @_;
- my ($fh, $ctx) = command_output_pipe('log', $head);
+ my ($fh, $ctx) = command_output_pipe('log', '--no-color', $head);
my $hash;
my %max;
while (<$fh>) {
@@ -2072,7 +2072,7 @@ sub rebuild {
return;
}
print "Rebuilding $db_path ...\n";
- my ($log, $ctx) = command_output_pipe("log", $self->refname);
+ my ($log, $ctx) = command_output_pipe("log", '--no-color', $self->refname);
my $latest;
my $full_url = $self->full_url;
remove_username($full_url);
^ permalink raw reply related
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Johannes Schindelin @ 2007-08-31 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Michael S. Tsirkin
In-Reply-To: <7vhcmfxv4n.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 31 Aug 2007, Jeff King wrote:
> >
> >> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:
> >>
> >> > If you set diff.autorefreshindex configuration variable, it
> >> > squelches the empty "diff --git" output, and at the end of the
> >> > command, it automatically runs "update-index --refresh" without
> >> > even bothering the user. In other words, with the configuration
> >> > variable set, people who do not care about the cache-dirtyness
> >> > do not even have to see the warning.
> >>
> >> Nice. This is much more sane behavior, IMHO, and I think it should make
> >> everyone happy.
> >
> > I could even imagine that this will eventually become the standard
> > behaviour.
>
> You sound as if you _like_ that behaviour...
Heh. Almost. I'd like to believe that these complaints would stop.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Junio C Hamano @ 2007-08-31 21:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Karl Hasselström, git, gitster
In-Reply-To: <Pine.LNX.4.64.0708312204490.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 31 Aug 2007, Karl Hasselstr?m wrote:
>
>> On 2007-08-31 20:06:27 +0100, Johannes Schindelin wrote:
>>
>> > It does _not_ undo the changeset corresponding to that commit, but
>> > it _skips_ the revision. IOW its ancestors' tree objects remain the
>> > same.
>>
>> While this is true too, I'm guessing you intended to say that its
>> _descendants'_ tree objects remain the same. Right?
>
> Right. So how about:
>
> IOW no tree objects are changed by this.
Ok, will amend.
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Alex Riesen @ 2007-08-31 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael S. Tsirkin, Jeff King
In-Reply-To: <7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano, Fri, Aug 31, 2007 22:13:42 +0200:
> The "Consier running git-status" warning message we experimented
> during the 1.5.3 cycle turns out to be a bad idea. It robbed
> cache-dirty information from people who valued it, while still
> asking users to run "update-index --refresh". It was hoped that
> the new behaviour would at least have some educational value,
> but not showing the cache-dirty paths like before means the user
> would not even know easily which paths are cache-dirty.
>
> This commit reinstates the traditional behaviour as the default,
> but with a twist.
>
> If you set diff.autorefreshindex configuration variable, it
> squelches the empty "diff --git" output, and at the end of the
> command, it automatically runs "update-index --refresh" without
> even bothering the user. In other words, with the configuration
> variable set, people who do not care about the cache-dirtyness
> do not even have to see the warning.
I like this change.
So far my attempts to explain that warning to myself always left an
uneasy feeling of me having tricked myself into believing in its
usefullness.
^ permalink raw reply
* Re: git-svn: Protect against "diff.color = true".
From: Johannes Schindelin @ 2007-08-31 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Robert Newson, git
In-Reply-To: <7v4pifxuia.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Aug 2007, Junio C Hamano wrote:
> I do not have an easy access to SVN repo
> to interoperate with, so a testing by real-world users and an
> Ack is appreciated.
I just tested on a busybox clone: Works as expected. Without your patch,
I get the uninitialised values, with your patch it is fine.
ACK.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Johannes Schindelin @ 2007-08-31 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, git
In-Reply-To: <7vzm07wftf.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 31 Aug 2007, Karl Hasselstr?m wrote:
> >
> >> On 2007-08-31 20:06:27 +0100, Johannes Schindelin wrote:
> >>
> >> > It does _not_ undo the changeset corresponding to that commit, but
> >> > it _skips_ the revision. IOW its ancestors' tree objects remain the
> >> > same.
> >>
> >> While this is true too, I'm guessing you intended to say that its
> >> _descendants'_ tree objects remain the same. Right?
> >
> > Right. So how about:
> >
> > IOW no tree objects are changed by this.
>
> Ok, will amend.
Thanks; this was the next mail I wanted to send ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git svn dcommit not checking if up-to-date?
From: David Watson @ 2007-08-31 21:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, git
In-Reply-To: <Pine.LNX.4.64.0708312200480.28586@racer.site>
I believe I've had this same issue as well. Like you, I assumed it was
user error on my part - I had been doing a lot of 'rebase -i' with that
particular set of changes, and figured I had just messed up somehow.
In my case, my coworker's commit happened 15 minutes before my dcommit, so
it wasn't *that* close in time. I tried to reproduce at that point, but
was unable to. I may try to reproduce this weekend if I get a chance.
On Fri, Aug 31, 2007 at 10:04:24PM +0100, Johannes Schindelin wrote:
> Hi Eric,
>
> harningt just asked about known issues of git-svn on IRC, and I remembered
> that I had an issue: Accidentally, I forgot to "git svn fetch" before "git
> svn dcommit"ing, and unfortunately, a colleague had just checked in a
> change, which got undone by my dcommit.
>
> Is this a known issue, has it been fixed, am I a bad pilot?
>
> Ciao,
> Dscho
>
> P.S.: harningt promised to get his hands dirty, but I just realised that
> the issue could be fixed since long ago...
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Watson
Software Engineer
MIMvista Corp
^ permalink raw reply
* Re: git-svn: Protect against "diff.color = true".
From: Junio C Hamano @ 2007-08-31 21:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, Robert Newson, git
In-Reply-To: <Pine.LNX.4.64.0708312237340.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Aug 2007, Junio C Hamano wrote:
>
>> I do not have an easy access to SVN repo
>> to interoperate with, so a testing by real-world users and an
>> Ack is appreciated.
>
> I just tested on a busybox clone: Works as expected. Without your patch,
> I get the uninitialised values, with your patch it is fine.
>
> ACK.
Thanks.
It's customary that the privilege to issue Ack is reserved to
the primary owner of the code. We are a relatively small
friendly community and it is not a big deal, but if you ever
work on the kernel, be somewhat more careful. People are picky
over there on such details.
^ permalink raw reply
* Re: git-svn: Protect against "diff.color = true".
From: Johannes Schindelin @ 2007-08-31 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Robert Newson, git
In-Reply-To: <7vtzqfwf5c.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 31 Aug 2007, Junio C Hamano wrote:
> >
> >> I do not have an easy access to SVN repo
> >> to interoperate with, so a testing by real-world users and an
> >> Ack is appreciated.
> >
> > I just tested on a busybox clone: Works as expected. Without your patch,
> > I get the uninitialised values, with your patch it is fine.
> >
> > ACK.
>
> Thanks.
>
> It's customary that the privilege to issue Ack is reserved to
> the primary owner of the code. We are a relatively small
> friendly community and it is not a big deal, but if you ever
> work on the kernel, be somewhat more careful. People are picky
> over there on such details.
Happily, we are a much friendlier bunch here ;-)
Besides, since I feel we're really close to 1.5.3 now, I thought that you
might want to here as many positive votes as you can get.
But yes, I'll keep that in mind ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn: Protect against "diff.color = true".
From: Eric Wong @ 2007-08-31 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Newson, git
In-Reply-To: <7v4pifxuia.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> If the configuration of the user has "diff.color = true", the
> output from "log" we invoke internally added color codes, which
> broke the parser.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > We probably should do two things to resolve this.
> >
> > * Protect our scripts. When parsing from "git log" and any
> > other Porcelain, explicitly give --no-color.
>
> Here is my attempt -- I do not have an easy access to SVN repo
> to interoperate with, so a testing by real-world users and an
> Ack is appreciated. I think some fix for this issue (not
> necessarily this patch) should be in 1.5.3 final.
Works for me here, although switching back to git-rev-list
(--pretty=raw) would make me more comfortable.
Acked-by: Eric Wong <normalperson@yhbt.net>
> git-svn.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 4e325b7..98218da 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -807,7 +807,7 @@ sub cmt_metadata {
>
> sub working_head_info {
> my ($head, $refs) = @_;
> - my ($fh, $ctx) = command_output_pipe('log', $head);
> + my ($fh, $ctx) = command_output_pipe('log', '--no-color', $head);
> my $hash;
> my %max;
> while (<$fh>) {
> @@ -2072,7 +2072,7 @@ sub rebuild {
> return;
> }
> print "Rebuilding $db_path ...\n";
> - my ($log, $ctx) = command_output_pipe("log", $self->refname);
> + my ($log, $ctx) = command_output_pipe("log", '--no-color', $self->refname);
> my $latest;
> my $full_url = $self->full_url;
> remove_username($full_url);
--
Eric Wong
^ permalink raw reply
* Re: git-svn: Protect against "diff.color = true".
From: Junio C Hamano @ 2007-08-31 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, Robert Newson, git
In-Reply-To: <Pine.LNX.4.64.0708312251510.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Aug 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> ...
>> > I just tested on a busybox clone: Works as expected. Without your patch,
>> > I get the uninitialised values, with your patch it is fine.
>> >
>> > ACK.
>>
>> Thanks.
>>
>> It's customary that the privilege to issue Ack is reserved to
>> the primary owner of the code. We are a relatively small
>> friendly community and it is not a big deal, but if you ever
>> work on the kernel, be somewhat more careful. People are picky
>> over there on such details.
>
> Happily, we are a much friendlier bunch here ;-)
>
> Besides, since I feel we're really close to 1.5.3 now, I thought that you
> might want to here as many positive votes as you can get.
>
> But yes, I'll keep that in mind ;-)
Oh, I did not mean to sound like your testing does not count. I
was just cautioning about using the word "Ack".
I will have a "Tested-by: " line with your name on it, and I am
hoping I can get an Ack from Eric but it is such an "obviously
correct" looking change, so ...
^ permalink raw reply
* Re: git svn dcommit not checking if up-to-date?
From: Eric Wong @ 2007-08-31 22:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708312200480.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi Eric,
>
> harningt just asked about known issues of git-svn on IRC, and I remembered
> that I had an issue: Accidentally, I forgot to "git svn fetch" before "git
> svn dcommit"ing, and unfortunately, a colleague had just checked in a
> change, which got undone by my dcommit.
>
> Is this a known issue, has it been fixed, am I a bad pilot?
>
> Ciao,
> Dscho
>
> P.S.: harningt promised to get his hands dirty, but I just realised that
> the issue could be fixed since long ago...
I believe this was fixed a while back in commit
45bf473a7bc2c40c8aea3d34a0eab7a41e77a8ff
(Thu Nov 9 01:19:37 2006 -0800).
I just tested this on a live server, and it seems to be correctly
erroring out if the local files are not up-to-date.
The only currently known issues that could break commits is from using
merge or pull from another svn branch and trying to dcommit the result
(see CAVEATS section in the manpage). I hope to fix this soon (hoping
somebody beats me to it, of course)
Otherwise there's still open bugs on svn:// fetch connections dying and
permissions issues with some DAV repos, neither of which can cause data
corruption on either side.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Steven Grimm @ 2007-08-31 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael S. Tsirkin, Jeff King
In-Reply-To: <7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> This commit reinstates the traditional behaviour as the default,
> but with a twist.
>
> If you set diff.autorefreshindex configuration variable, it
> squelches the empty "diff --git" output, and at the end of the
> command, it automatically runs "update-index --refresh" without
> even bothering the user. In other words, with the configuration
> variable set, people who do not care about the cache-dirtyness
> do not even have to see the warning.
>
As the person who submitted the patch you're reversing with this, I
agree 100% this is the better approach. Having the system self-heal is
far preferable to requiring user action.
I would vote for reversing the sense of that config variable, actually:
my guess is that most users, especially new ones who won't necessarily
know about the config variable, would rather have git just keep itself
healthy without user intervention. Having to manually update the index
is (by virtue of requiring you to run a command that you wouldn't
otherwise need to run) a mode more suited to advanced / experienced
users, who are more likely to already be comfortable with the idea of
flipping config switches. Making the more novice-friendly mode require
that you know how to set a particular configuration variable doesn't
seem right to me.
-Steve
^ permalink raw reply
* Re: git svn dcommit not checking if up-to-date?
From: Johannes Schindelin @ 2007-08-31 23:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070831221814.GB31033@untitled>
Hi,
On Fri, 31 Aug 2007, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > harningt just asked about known issues of git-svn on IRC, and I
> > remembered that I had an issue: Accidentally, I forgot to "git svn
> > fetch" before "git svn dcommit"ing, and unfortunately, a colleague had
> > just checked in a change, which got undone by my dcommit.
>
> I believe this was fixed a while back in commit
> 45bf473a7bc2c40c8aea3d34a0eab7a41e77a8ff
> (Thu Nov 9 01:19:37 2006 -0800).
That is strange, since I had this issue in July or August (this year).
And I am quite certain that I ran with pretty up-to-date git (I usually
track "next" quite closely).
Ciao,
Dscho
^ permalink raw reply
* Re: Perl warning in git-svn (git v1.5.3-rc7-16-ge340d7d)
From: Sam Vilain @ 2007-08-31 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd4x3xuu3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> I was almost going to suggest us to change "*.color = true" to
>> mean 'auto'. Because git can internally use pager and has a way
>> for the user to control enabling/disabling colors when the pager
>> is used, there is no _logical_ reason to enable pager when the
>> output is not going to a tty.
>>
>
> Gaah, sorry; I meant "no logical reason to enable _color_ when
> the output is not going to a tty".
Sure there is, when the output is "less -R"
Sam.
^ permalink raw reply
* Re: git svn dcommit not checking if up-to-date?
From: David Watson @ 2007-08-31 23:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, git
In-Reply-To: <Pine.LNX.4.64.0709010017250.28586@racer.site>
I just reproduced this one in a live repository. Here's what you do:
$ git checkout -b breakme trunk
$ vi file1.txt
$ git-commit -a -m 'first change'
$ vi file2.txt
$ git-commit -a -m 'second change'
..... Full moon, become a werewolf ......
C:\svnrepo> edit file2.txt
C:\svnrepo> svn commit -m 'this will be gone'
..... Become yourself again ....
$ git svn fetch --all # (not sure if this is necessary)
$ git svn dcommit
$ git log -p
The change to file2 by your hairier, fanged self will be gone.
The critical thing is that you must dcommit *multiple* commits, and the
first one can't be the conflicting file, otherwise it will stop. At the
time the first commit of the dcommit has gone through, git-svn now thinks
it's all up-to-date.
On Sat, Sep 01, 2007 at 12:17:33AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 31 Aug 2007, Eric Wong wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > harningt just asked about known issues of git-svn on IRC, and I
> > > remembered that I had an issue: Accidentally, I forgot to "git svn
> > > fetch" before "git svn dcommit"ing, and unfortunately, a colleague had
> > > just checked in a change, which got undone by my dcommit.
> >
> > I believe this was fixed a while back in commit
> > 45bf473a7bc2c40c8aea3d34a0eab7a41e77a8ff
> > (Thu Nov 9 01:19:37 2006 -0800).
>
> That is strange, since I had this issue in July or August (this year).
> And I am quite certain that I ran with pretty up-to-date git (I usually
> track "next" quite closely).
>
> Ciao,
> Dscho
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Watson
Software Engineer
MIMvista Corp
^ permalink raw reply
* Re: Perl warning in git-svn (git v1.5.3-rc7-16-ge340d7d)
From: Johannes Schindelin @ 2007-08-31 23:51 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46D8A886.5060701@vilain.net>
Hi,
On Sat, 1 Sep 2007, Sam Vilain wrote:
> Junio C Hamano wrote:
> >> I was almost going to suggest us to change "*.color = true" to
> >> mean 'auto'. Because git can internally use pager and has a way
> >> for the user to control enabling/disabling colors when the pager
> >> is used, there is no _logical_ reason to enable pager when the
> >> output is not going to a tty.
> >>
> >
> > Gaah, sorry; I meant "no logical reason to enable _color_ when
> > the output is not going to a tty".
>
> Sure there is, when the output is "less -R"
This argument was already raised by Junio himself. But your _option_ to
use "git log | less -R" does not make it a good option. Since "git log"
is so much more elegant already.
Hth,
Dscho
^ 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