* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-17 2:10 UTC (permalink / raw)
To: git
In-Reply-To: <44196DE7.8010205@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
>> isn't too grim, and shows how the git_exec shell function can be made
>> somewhat terser.
>
> But it breaks the convenience when testing.
I think that's OK. When I test things in the build directory
without installing I would usually do:
$ GIT_EXEC_PATH=`pwd` PATH=`pwd`:/usr/bin:/bin ./git-cmd-to-test
and the above would not break things.
^ permalink raw reply
* git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 2:37 UTC (permalink / raw)
To: git
Starting recently, git-cvsimport has always ended with "you
may need to merge manually". Why? It worked before. What
is it doing now?
$ cd /home/merlyn/Git/stonehenge.git || exit 1
$ git-cvsimport -v -k -o master -d /web/cvs stonehenge
.
.
.
skip patchset 323: 1142297290 before 1142351976
Fetching htdocs/courses.html v 1.4
Update htdocs/courses.html: 8767 bytes
Fetching htdocs/rates.html v 1.2
Update htdocs/rates.html: 2043 bytes
Tree ID 38280334da5eaa4fd80fe1011e63db4b527f1d13
Parent ID e93de754181fe963b8623423f509540021caead0
Committed patch 324 (master 2006-03-16 18:14:31)
Commit ID 985ca72d4e8a07d4189794231f035bac63c9e91d
DONE; you may need to merge manually.
$ git-status
#
# Updated but not checked in:
# (will commit)
#
# modified: htdocs/courses.html
# modified: htdocs/rates.html
#
Right... why didn't it commit those? I'm having to issue "fake"
commits now, so I've lost the cvs-log comments that were formerly
very complete and cool.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 2:43 UTC (permalink / raw)
To: git
In-Reply-To: <86veud23v0.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Starting recently, git-cvsimport has always ended with "you
> may need to merge manually". Why? It worked before. What
> is it doing now?
>
> $ cd /home/merlyn/Git/stonehenge.git || exit 1
> $ git-cvsimport -v -k -o master -d /web/cvs stonehenge
> .
> .
> .
> skip patchset 323: 1142297290 before 1142351976
> Fetching htdocs/courses.html v 1.4
> Update htdocs/courses.html: 8767 bytes
> Fetching htdocs/rates.html v 1.2
> Update htdocs/rates.html: 2043 bytes
> Tree ID 38280334da5eaa4fd80fe1011e63db4b527f1d13
> Parent ID e93de754181fe963b8623423f509540021caead0
> Committed patch 324 (master 2006-03-16 18:14:31)
> Commit ID 985ca72d4e8a07d4189794231f035bac63c9e91d
> DONE; you may need to merge manually.
> $ git-status
> #
> # Updated but not checked in:
> # (will commit)
> #
> # modified: htdocs/courses.html
> # modified: htdocs/rates.html
> #
>
> Right... why didn't it commit those? I'm having to issue "fake"
> commits now, so I've lost the cvs-log comments that were formerly
> very complete and cool.
I do not use cvsimport but I wonder what Commit ID 985ca7
contains. Can you try "git show 985ca7" and see if that is the
commit you want?
Also, which branch are you on when you run git-cvsimport, and
which branch did the commit 985ca7 go? I suspect it is storing
the tip commit 985ca7 to a branch that you are _not_ on
currently, but refraining from merging that to your current
branch, or something like that.
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu09x7puo.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> Right... why didn't it commit those? I'm having to issue "fake"
>> commits now, so I've lost the cvs-log comments that were formerly
>> very complete and cool.
Junio> I do not use cvsimport but I wonder what Commit ID 985ca7
Junio> contains. Can you try "git show 985ca7" and see if that is the
Junio> commit you want?
To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
"git-whatchanged -p" shows the most recent commit with the diff actually
*backed out* the most recent change in CVS, and the next change down was
actually the good one. Weird. Do I need to start all over again?
Junio> Also, which branch are you on when you run git-cvsimport, and
Junio> which branch did the commit 985ca7 go? I suspect it is storing
Junio> the tip commit 985ca7 to a branch that you are _not_ on
Junio> currently, but refraining from merging that to your current
Junio> branch, or something like that.
Nope. I'm on "master", and it should be writing "master".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86r75122yj.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
Randal> "git-whatchanged -p" shows the most recent commit with the diff actually
Randal> *backed out* the most recent change in CVS, and the next change down was
Randal> actually the good one. Weird. Do I need to start all over again?
Junio> Also, which branch are you on when you run git-cvsimport, and
Junio> which branch did the commit 985ca7 go? I suspect it is storing
Junio> the tip commit 985ca7 to a branch that you are _not_ on
Junio> currently, but refraining from merging that to your current
Junio> branch, or something like that.
Randal> Nope. I'm on "master", and it should be writing "master".
And now for grins, I did "git-reset --hard 'HEAD^^^^^^^'", verified
that the data was in a sensible state from a few weeks back, then
did the git-cvsimport, and it replayed the CVS changes to bring it current.
git-status showed that seven files were dirty, and "git-reset --hard"
cleared that, and the files were in the right state.
Huh?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 3:23 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Matthias Urlichs
In-Reply-To: <86r75122yj.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Junio> I do not use cvsimport but I wonder what Commit ID 985ca7
> Junio> contains. Can you try "git show 985ca7" and see if that is the
> Junio> commit you want?
>
> To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
> "git-whatchanged -p" shows the most recent commit with the diff actually
> *backed out* the most recent change in CVS, and the next change down was
> actually the good one. Weird. Do I need to start all over again?
So the commit ID reported before the command says Done. was
actually what you wanted, but that latest tree was not checked
out cvsimport, so "git status" reported "you have these changes"
(it should have said "you have these backed-out", but there is
no way for it to know), and obviously your commit on top of that
is to back it out.
I just tried it on a copy of my day-job CVS repository. Indeed
what it does seem quite strange.
...
skip patchset 1019: 1142562992 before 1142562992
skip patchset 1020: 1142563093 before 1142563093
Fetching Makefile v 1.10
Update Makefile: 871 bytes
Tree ID 4c51717e01fb08b6d15bc6e35d48142d2d5b94e7
Parent ID 98d49aa57b93552cea82ce20c880bad4bcc5ebfc
Committed patch 1021 (master 2006-03-17 03:04:31)
Commit ID ad6c4fb908df7057d5564bf22cf9e0f9f3e743f2
DONE
It updated the 'master' branch head, it reported the tip commit
ID before saying DONE, and that commit ID is stored in
refs/heads/master. However, it does not seem to touch index nor
working tree files (I did not get "you may need to do merge"
message, by the way).
Since I know I was just trying things out, I do not care what is
in my index nor in the working tree files, so I could at this
point say:
$ git reset --hard
to sync the master tree, but in general you may be running
cvsimport into a dirty tree, in which case you are screwed.
I think reverting this commit would help, but I do not remember
offhand what the breakage this patch was trying to fix.
commit a541211ef4136eb7464c4466d20b60b8580efc44
Author: Matthias Urlichs <smurf@smurf.noris.de>
Date: Tue Mar 7 10:08:34 2006 +0100
cvsimport: Remove master-updating code
The code which tried to update the master branch was somewhat broken.
=> People should do that manually, with "git merge".
Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... Ugh, and after I wrote all of the above, the version of git
I have at work predates that commit X-<. So maybe this was
fixed with that commit, and you are expected to say:
$ git pull . origin
assuming that you are on "master" branch and cvsimoprt tracks
CVS head with "origin" branch, that is.
Smurf, help?
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 3:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Urlichs
In-Reply-To: <7vk6at7o06.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Since I know I was just trying things out, I do not care what is
Junio> in my index nor in the working tree files, so I could at this
Junio> point say:
Junio> $ git reset --hard
Junio> to sync the master tree, but in general you may be running
Junio> cvsimport into a dirty tree, in which case you are screwed.
Yeah, this doesn't make sense. It used to "Just Work". I can
certainly add "git reset --hard" to my workflow, if that's the real
work around. And if so, the manpage should document that.
Junio> ... Ugh, and after I wrote all of the above, the version of git
Junio> I have at work predates that commit X-<. So maybe this was
Junio> fixed with that commit, and you are expected to say:
Junio> $ git pull . origin
Junio> assuming that you are on "master" branch and cvsimoprt tracks
Junio> CVS head with "origin" branch, that is.
Again, if that's the case, the manpage should say what's really
happening, so as not to confuse dumb people like me. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 4:16 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fylh20x6.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Yeah, this doesn't make sense. It used to "Just Work". I can
> certainly add "git reset --hard" to my workflow, if that's the real
> work around. And if so, the manpage should document that.
That should _not_ be the solution.
I think the behaviour we are seeing does not make much sense.
I'll take a deeper look at it tonight (or tomorrow if I am
unlucky), if nobody beats me to it.
Sorry about the breakage.
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 4:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylh7lkh.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> I think the behaviour we are seeing does not make much sense.
Junio> I'll take a deeper look at it tonight (or tomorrow if I am
Junio> unlucky), if nobody beats me to it.
Junio> Sorry about the breakage.
No, *thanks* for looking at it. Your tireless contributions
are well appreciated.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [RFC] exit code from git fetch
From: Junio C Hamano @ 2006-03-17 6:01 UTC (permalink / raw)
To: git
When "git fetch" fails because the remote unexpectedly rewound
its head and fast-forward check triggers, we issued a warning
but kept going anyway. This proposed patch makes the command
exit with non-zero status.
I think this is a sensible change and makes it easier to use
from scripts, but it might have other issues. For example when
you are tracking more than one heads from the remote, and the
first one fast-forwards but the second one doesn't, it updates
the first one and then stops. If we happen to process the
rewound one first, neither is updated because we stop at the
first one. I think this particular discrepancy probably is not
worth worrying about, but there may be other more serious
fallouts we need to fix if we did this.
Comments?
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..6835634 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -179,6 +179,7 @@ fast_forward_local () {
;;
*)
echo >&2 " not updating."
+ exit 1
;;
esac
}
^ permalink raw reply related
* Re: [RFC] exit code from git fetch
From: Andrew Morton @ 2006-03-17 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek116253.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> When "git fetch" fails because the remote unexpectedly rewound
> its head and fast-forward check triggers, we issued a warning
> but kept going anyway. This proposed patch makes the command
> exit with non-zero status.
>
> I think this is a sensible change and makes it easier to use
> from scripts, but it might have other issues. For example when
> you are tracking more than one heads from the remote, and the
> first one fast-forwards but the second one doesn't, it updates
> the first one and then stops. If we happen to process the
> rewound one first, neither is updated because we stop at the
> first one. I think this particular discrepancy probably is not
> worth worrying about, but there may be other more serious
> fallouts we need to fix if we did this.
>
> Comments?
>
> ---
> diff --git a/git-fetch.sh b/git-fetch.sh
> index 0346d4a..6835634 100755
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -179,6 +179,7 @@ fast_forward_local () {
> ;;
> *)
> echo >&2 " not updating."
> + exit 1
> ;;
> esac
> }
Thanks ;)
I guess you could exit with different exit codes according to what
went wrong. So if a script writer really cared about the fine details,
appropriate decisions could be made.
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: smurf @ 2006-03-17 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7vk6at7o06.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Hi,
Junio C Hamano:
> ... Ugh, and after I wrote all of the above, the version of git
> I have at work predates that commit X-<. So maybe this was
> fixed with that commit, and you are expected to say:
>
> $ git pull . origin
>
Exactly.
> assuming that you are on "master" branch and cvsimoprt tracks
> CVS head with "origin" branch, that is.
>
> Smurf, help?
>
What for? You got it, after all. *g*
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Sally sued for support; she was claimin'
Phil had fathered her baby (named Damon).
She said, "I ought to know,"
As she pointed below.
"'Cause this is the box that he came in."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: smurf @ 2006-03-17 7:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86fylh20x6.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
Hi,
Randal L. Schwartz:
> Yeah, this doesn't make sense. It used to "Just Work". I can
> certainly add "git reset --hard" to my workflow, if that's the real
> work around. And if so, the manpage should document that.
>
The real workaround is not to import into live branches,
which is not a git-cvs-specific problem, so I didn't add that
to its manpage.
I'm not opposed to an appropriate patch if you think its necessary.
If you do, keep in mind that there are other git-*import scripts out
there which presumably have the same problem. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
That which is good to be done, cannot be done too soon; and if it is
neglected to be done early, it will frequently happen that it will not be done
at all.
-- Bishop Mant
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 8:06 UTC (permalink / raw)
To: smurf; +Cc: Randal L. Schwartz, git
In-Reply-To: <20060317064618.GG14562@smurf.noris.de>
smurf@smurf.noris.de writes:
> Junio C Hamano:
>> ..., and you are expected to say:
>>
>> $ git pull . origin
>>
> Exactly.
I think the second and subsequent run of "git cvsimport"
currently is similar to "git fetch", but earlier one that tried
to do checkout was probably similar to "git pull". I think most
people would expect it to behave more like "git pull",
i.e. fetch from the upstream (that happens to be CVS) and merge
that into your branch. It may not be operated that way
correctly and that might have been the reason we removed the
"master updates" code, but if that is the case I'd rather fix it
properly.
>> assuming that you are on "master" branch and cvsimoprt tracks
>> CVS head with "origin" branch, that is.
>>
>> Smurf, help?
>>
> What for? You got it, after all. *g*
Not really, I am afraid. There is one snag _if_ you use the
current branch as the tracking branch. Merlyn's setup is
exactly that -- he has "master" which is given to the command
with -o flag. The branch head commit is already updated, but
the index and working tree is not.
Now, unlike git-fetch, git-cvsimport _requires_ you to have a
pristine tracking branch (otherwise we cannot discard already
seen patchsets from what we read from CVSPS), and leaving that
tracking branch checked out is calling for trouble because you
might be tempted to make your own commit on top of it. So we
could argue that one solution would be to forbid importing into
the current branch.
But that breaks well behaving people who are used to leave a
tracking branch checked out _and_ promises not to touch that
branch head from the git side.
So what I would suggest is to do something like this:
- Before starting to interpret CVSPS output, keep the commit
object name of the current branch tip.
- After we are done, read the current branch tip. If they are
different, we updated the current branch tip without matching
the index and working tree, so we match them just like
git-pull does. Otherwise, we run 'git-merge' to merge the
$opt_o branch into the current branch.
That is, perhaps, like this untested patch. What do you think?
-- >8 --
cvsimport: act more like pull, not fetch
After updating tracking branches with upstream CVS changes, if
the current branch is one of the tracking branches, match the
index and working tree just like "git-pull" that was started
with one of the tracking branches checked out. Otherwise, merge
the trunk ($opt_o) branch into the current branch. This would
match users' expectation more closely.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 02d1928..b9cebaf 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -453,6 +453,7 @@ chdir($git_tree);
my $last_branch = "";
my $orig_branch = "";
my %branch_date;
+my $tip_at_start = undef;
my $git_dir = $ENV{"GIT_DIR"} || ".git";
$git_dir = getwd()."/".$git_dir unless $git_dir =~ m#^/#;
@@ -487,6 +488,7 @@ unless(-d $git_dir) {
$last_branch = "master";
}
$orig_branch = $last_branch;
+ $tip_at_start = `git-rev-parse --verify HEAD`;
# populate index
system('git-read-tree', $last_branch);
@@ -873,7 +875,18 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if($orig_branch) {
- print "DONE; you may need to merge manually.\n" if $opt_v;
+ print "DONE.\n" if $opt_v;
+ my $tip_at_end = `git-rev-parse --verify HEAD`;
+ if ($tip_at_start ne $tip_at_end) {
+ print "Fetched into the current branch.\n" if $opt_v;
+ system(qw(git-read-tree -u -m),
+ $tip_at_start, $tip_at_end);
+ die "Fast-forward update failed: $?\n" if $?;
+ }
+ else {
+ system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+ die "Could not merge $opt_o into the current branch.\n" if $?;
+ }
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
^ permalink raw reply related
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 8:08 UTC (permalink / raw)
To: smurf; +Cc: git
In-Reply-To: <20060317072602.GH14562@smurf.noris.de>
smurf@smurf.noris.de writes:
> The real workaround is not to import into live branches,
> which is not a git-cvs-specific problem, so I didn't add that
> to its manpage.
Yes. I sufferred the same problem when I did git-fetch/git-pull,
and there is a clever/ugly workaround for that.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Mark Wooding @ 2006-03-17 10:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7z97rdr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> and the above would not break things.
Indeed. I just translated Junio's `git_exec' shell function into a
one-liner.
-- [mdw]
^ permalink raw reply
* Re: Possible --remove-empty bug
From: Marco Costalba @ 2006-03-17 10:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0603131058270.3618@g5.osdl.org>
On 3/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> However, to be honest, the only reason to ever use --remove-empty is for
> rename detection, and Frederik's approach of doing that through the
> library interface directly is actually a much superior option. So we might
> as well drop the compilcation of --remove-empty entirely, unless somebody
> has already started using it.
>
In case of a rather recent file --remove-empty option gives a good
speed up in history loading with git-rev-list. So qgit uses that
option.
Annotation in qgit it is little different from blame algorithm because
it works from oldest revision to latest instead of the contrary. This
is due because it calculates in one pass _all_ the annotations of all
the different revisions of a given file, starting from file history,
i.e. 'git-rev-list file_path' output.
The GUI interface of qgit let's the user quickly jump between two file
revisions. So the corresponding annotations should be already prepared
to make it snappy.
> The _real_ optimization would be to make the pathname based pruning be
> done incrementally instead of having to build up the whole tree.
Anything that speeds-up file git-rev-list history loading surely gives
a big boost to all annotation/blame stuff. I have made some profiling
on qgit (the public git repo version that is much faster, not the
qgit1.1 released one) and I found that 50% to 70% of the time is spent
on git-rev-list, of the remaining the 80% is spent on git-diff-tree -p
patch loading and only a small amount is spent on actually calculate
the annotation.
Of course these numbers can vary a little according to file/repo, but
the big picture stays the same.
Marco
^ permalink raw reply
* Re: [PATCH 1/4] Simplify wildcards for match files to be ignored
From: Jonas Fonseca @ 2006-03-17 17:19 UTC (permalink / raw)
To: Horst von Brand; +Cc: Petr Baudis, git
In-Reply-To: <200603110008.k2B08aCO004834@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> wrote Fri, Mar 10, 2006:
> Jonas Fonseca <fonseca@diku.dk> wrote:
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> >
> > ---
> >
> > Documentation/Makefile | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/Makefile b/Documentation/Makefile
> > index 3aad2fb..661c259 100644
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -1,4 +1,4 @@
> > -CG_IGNORE=$(wildcard ../cg-X* ../cg-*.orig ../cg-*.rej ../cg-*.in)
> > +CG_IGNORE=$(wildcard ../cg-X* ../cg-*.*)
>
> Nope. Better be specific in what you delete. It is not exactly
> performance-critical...
The intention was to ignore also cg-*.patch, but then ignoring any file
with a dot in makes sense and avoids a lot more errors when building
documentation in a dirty tree.
--
Jonas Fonseca
^ permalink raw reply
* Re: git-reset and clones
From: Jon Loeliger @ 2006-03-17 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paul, Git List
In-Reply-To: <7v4q1x95yo.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:
>
> You used to have something like this:
>
>
> o---o---o---A
> / ^ your HEAD used to point at here
> ---o---o---o
>
> and you forgot other people already have the commit chain up to
> commit A. But you rewound and did cleanups:
>
> o---o---o---A
> /
> ---o---o---o---o---o---B
> ^ your HEAD now points at here
>
> People who track your HEAD have A and your updated head B does
> not fast forward. Oops.
>
> The recovery consists of two steps. The first step is more
> important. To find what commits you lost that others already
> may have. You may be lucky and remember A's commit object name,
> but when I did that I had to ask around on the list X-<.
>
> The second step is a single command:
>
> $ git merge -s ours 'Graft the lost side branch back in' \
> HEAD A
>
> where A is the object name of that commit. On your current
> branch, this creates a merge commit between A and B (your
> current HEAD), taking the tree object from B.
>
> o---o---o---A
> / \
> ---o---o---o---o---o---B---M
Junio,
Can you explain a bit more why the "ours" strategy
comes into play here? I _think_ I understand, but
I'd like to hear a bit more explanation, please.
How is this different from just merging in A directly?
> You want to keep the contents of the cleaned-up HEAD, so that is
> why you are taking the tree from B.
And the "ours" strategy effectively says, "Favor the B
side of things when pulling in the A parts", right?
> With this commit M, you are
> telling the outside world that it is OK if they start from a
> commit on the now-recovered side branch.
This is mystical to me. How is the "A" (ie, side branch)
now in a "recovered" state?
Thanks,
jdl
^ permalink raw reply
* Re: git-reset and clones
From: Junio C Hamano @ 2006-03-17 20:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: paul, Git List
In-Reply-To: <1142623141.17536.225.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
>> ... On your current
>> branch, this creates a merge commit between A and B (your
>> current HEAD), taking the tree object from B.
>>
>> o---o---o---A
>> / \
>> ---o---o---o---o---o---B---M
>
> Can you explain a bit more why the "ours" strategy
> comes into play here? I _think_ I understand, but
> I'd like to hear a bit more explanation, please.
> How is this different from just merging in A directly?
>> You want to keep the contents of the cleaned-up HEAD, so that is
>> why you are taking the tree from B.
>
> And the "ours" strategy effectively says, "Favor the B
> side of things when pulling in the A parts", right?
Yes, it is stronger than that. "ours" says: "the tree from our
head commit B *is* the resulting tree -- whatever we are merging
into us does not matter".
>> With this commit M, you are
>> telling the outside world that it is OK if they start from a
>> commit on the now-recovered side branch.
>
> This is mystical to me. How is the "A" (ie, side branch)
> now in a "recovered" state?
Although their effects are superseded (B^{tree} == M^{tree}),
they are still in the ancestry chain.
To a downstream person who were lucky enough not to have made
commits on A yet, next pull from you would have involved merging
B and A.
If the upstream did not do the magic "ours" merge, the git-fetch
step would refuse to update the remote tracking branch head, so
the downstream person needs to force the fetch. After forcing
the fetch, the merge would have involved resolving the conflicts
coming from 3-way merge in this:
o---o---o---A---N
/ /
---o---o---o---o---o---B---'
Because the forked track leading to B was either to fix mistakes
or clean things up the upstream originally did in the track
leading to A, the commits on the tracks leading to A and B from
their fork point are almost guaranteed to have conflicting
changes, and resolution of that conflict is forced on the
downstream person. Worse yet, from this point on, since the
upstream discarded the track that contains A, the branch
downstream person has will _never_ converge to upstream branch,
even though the downstream person did _no_ development of his
own in the meantime. This is *B*A*D*.
If there is a magic "ours" merge, the downstream person's
repository records A as the last tip on the tracking branch, and
git-fetch sees the updated head M is a descendant of it, so it
simply fast-forwards:
o---o---o---A
/ \
---o---o---o---o---o---B---M
Now, if the downstream was unlucky and have commits based on A,
the story is a bit different, but the principles are the same.
Without the "ours" merge M, you will get this:
o---o---o---A---X---N
/ /
---o---o---o---o---o---B-------'
When creating the merge N, even if the change between A and X
(i.e. the downstream's own work) does not touch the paths that
differ between A and B, the downstream is forced to resolve
conflicts between A and B. This is unnecessary burden for him.
The upstream should have cleaned up his own mess.
With the "ours" merge M, you will get this:
o---o---o---A---X---N
/ \ /
---o---o---o---o---o---B---M---'
The downstream does not need to worry about the conflicts
between A and B. It has been already resolved at M.
Especially, if the change between A and X does not touch the
paths that differ in A and B, conflict resolution would be
purely about his own work.
In either case, since the downstream has his own development,
the heads of their branches never converge until the upstream
buys his changes (i.e. pull from the downstream that has "N"
commit), but that is not a problem but a feature and does not
have anything to do with this "oops, rewound by mistake" issue.
^ permalink raw reply
* Re: git-reset and clones
From: Jon Loeliger @ 2006-03-17 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paul, Git List
In-Reply-To: <7vslpgztzc.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-03-17 at 14:39, Junio C Hamano wrote:
> > And the "ours" strategy effectively says, "Favor the B
> > side of things when pulling in the A parts", right?
>
> Yes, it is stronger than that. "ours" says: "the tree from our
> head commit B *is* the resulting tree -- whatever we are merging
> into us does not matter".
Aha! This all makes much more sense now suddenly.
Thank you.
>
> o---o---o---A---N
> / /
> ---o---o---o---o---o---B---'
>
> Because the forked track leading to B was either to fix mistakes
> or clean things up the upstream originally did in the track
> leading to A, the commits on the tracks leading to A and B from
> their fork point are almost guaranteed to have conflicting
> changes, and resolution of that conflict is forced on the
> downstream person. Worse yet, from this point on, since the
> upstream discarded the track that contains A, the branch
> downstream person has will _never_ converge to upstream branch,
> even though the downstream person did _no_ development of his
> own in the meantime. This is *B*A*D*.
Wow. Yeah. Bad.
> If there is a magic "ours" merge, the downstream person's
> repository records A as the last tip on the tracking branch, and
> git-fetch sees the updated head M is a descendant of it, so it
> simply fast-forwards:
That's beautiful. I get it. This has been an
extraordinarily helpful explanation (for me)!
Thank you!
jdl
^ permalink raw reply
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-17 21:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, paul, Git List
In-Reply-To: <1142623141.17536.225.camel@cashmere.sps.mot.com>
I'm in sort of shallow waters, hoping that Junio or Linus will come
along and pull me off the shores in case I mis-step and say something
stupid that would have made an amusing pictograph had it been done right
by a cartoonist.
Jon Loeliger wrote:
> On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:
>
>
>>You used to have something like this:
>>
>>
>> o---o---o---A
>> / ^ your HEAD used to point at here
>> ---o---o---o
>>
>>and you forgot other people already have the commit chain up to
>>commit A. But you rewound and did cleanups:
>>
>> o---o---o---A
>> /
>> ---o---o---o---o---o---B
>> ^ your HEAD now points at here
>>
>>People who track your HEAD have A and your updated head B does
>>not fast forward. Oops.
>>
>>The recovery consists of two steps. The first step is more
>>important. To find what commits you lost that others already
>>may have. You may be lucky and remember A's commit object name,
>>but when I did that I had to ask around on the list X-<.
>>
>>The second step is a single command:
>>
>> $ git merge -s ours 'Graft the lost side branch back in' \
>> HEAD A
>>
>>where A is the object name of that commit. On your current
>>branch, this creates a merge commit between A and B (your
>>current HEAD), taking the tree object from B.
>>
>> o---o---o---A
>> / \
>> ---o---o---o---o---o---B---M
>
>
> Junio,
>
> Can you explain a bit more why the "ours" strategy
> comes into play here? I _think_ I understand, but
> I'd like to hear a bit more explanation, please.
> How is this different from just merging in A directly?
>
"Ours" is an algorithm you can invent yourself and pass as the defautl
merge strategy (useful if you know you'll always keep upstream as-is or
some such).
>
>>You want to keep the contents of the cleaned-up HEAD, so that is
>>why you are taking the tree from B.
>
>
> And the "ours" strategy effectively says, "Favor the B
> side of things when pulling in the A parts", right?
>
Yes, and/or no. "Ours"' is still whatever you want it to be. Perhaps we
should add some new strategies, like "favour-current" and "favour-new".
>
>> With this commit M, you are
>>telling the outside world that it is OK if they start from a
>>commit on the now-recovered side branch.
>
>
> This is mystical to me. How is the "A" (ie, side branch)
> now in a "recovered" state?
>
Because the commits pullers already have are now inside the respository
history, as seen by average pullers (again). The merge between "master"
(or some such) and "new-devel" (or some such) happen to coincide, which
means they share a mutual merge-base, which means they're both part of
the same chain of developemnt. If you intend to disimiss most of the
changes between (fork-point) and (point-of-new-weird-rebase) this might
not be the best solution, but...
Sorry, but to me this is friaday night and currently I can't logically
differ between a bluewhale and a kangaroo [*1]
/exon
[1]
Sadly, this has been empirically proven. [*2]
[2]
At some other time. I'm no *that* drunk right now.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 1/2] blame: Nicer output
From: Fredrik Kuivinen @ 2006-03-17 21:49 UTC (permalink / raw)
To: git; +Cc: junkio
As pointed out by Junio, it may be dangerous to cut off people's names
after 15 bytes. If the name is encoded in an encoding which uses more
than one byte per code point we may end up with outputting garbage.
Instead of trying to do something smart, just output the entire name.
We don't gain much screen space by chopping it off anyway.
Furthermore, only output the file name if we actually found any
renames.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/blame.c b/blame.c
index 1fb5070..8af4b54 100644
--- a/blame.c
+++ b/blame.c
@@ -742,6 +742,8 @@ int main(int argc, const char **argv)
struct commit_info ci;
const char *buf;
int max_digits;
+ size_t longest_file, longest_author;
+ int found_rename;
const char* prefix = setup_git_directory();
@@ -818,6 +820,25 @@ int main(int argc, const char **argv)
for (max_digits = 1, i = 10; i <= num_blame_lines + 1; max_digits++)
i *= 10;
+ longest_file = 0;
+ longest_author = 0;
+ found_rename = 0;
+ for (i = 0; i < num_blame_lines; i++) {
+ struct commit *c = blame_lines[i];
+ struct util_info* u;
+ if (!c)
+ c = initial;
+ u = c->object.util;
+
+ if (!found_rename && strcmp(filename, u->pathname))
+ found_rename = 1;
+ if (longest_file < strlen(u->pathname))
+ longest_file = strlen(u->pathname);
+ get_commit_info(c, &ci);
+ if (longest_author < strlen(ci.author))
+ longest_author = strlen(ci.author);
+ }
+
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
struct util_info* u;
@@ -828,14 +849,18 @@ int main(int argc, const char **argv)
u = c->object.util;
get_commit_info(c, &ci);
fwrite(sha1_to_hex(c->object.sha1), sha1_len, 1, stdout);
- if(compability)
+ if(compability) {
printf("\t(%10s\t%10s\t%d)", ci.author,
format_time(ci.author_time, ci.author_tz), i+1);
- else
- printf(" %s (%-15.15s %10s %*d) ", u->pathname,
- ci.author, format_time(ci.author_time,
- ci.author_tz),
+ } else {
+ if (found_rename)
+ printf(" %-*.*s", longest_file, longest_file,
+ u->pathname);
+ printf(" (%-*.*s %10s %*d) ",
+ longest_author, longest_author, ci.author,
+ format_time(ci.author_time, ci.author_tz),
max_digits, i+1);
+ }
if(i == num_blame_lines - 1) {
fwrite(buf, blame_len - (buf - blame_contents),
^ permalink raw reply related
* [PATCH 2/2] blame: Fix git-blame <directory>
From: Fredrik Kuivinen @ 2006-03-17 21:49 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20060317214928.23075.76032.stgit@c165>
Before this patch git-blame <directory> gave non-sensible output. (It
assigned blame to some random file in <directory>) Abort with an error
message instead.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/blame.c b/blame.c
index 8af4b54..9c97aec 100644
--- a/blame.c
+++ b/blame.c
@@ -180,11 +180,13 @@ static int get_blob_sha1_internal(unsign
unsigned mode, int stage);
static unsigned char blob_sha1[20];
+static const char* blame_file;
static int get_blob_sha1(struct tree *t, const char *pathname,
unsigned char *sha1)
{
int i;
const char *pathspec[2];
+ blame_file = pathname;
pathspec[0] = pathname;
pathspec[1] = NULL;
memset(blob_sha1, 0, sizeof(blob_sha1));
@@ -209,6 +211,10 @@ static int get_blob_sha1_internal(unsign
if (S_ISDIR(mode))
return READ_TREE_RECURSIVE;
+ if (strncmp(blame_file, base, baselen) ||
+ strcmp(blame_file + baselen, pathname))
+ return -1;
+
memcpy(blob_sha1, sha1, 20);
return -1;
}
^ permalink raw reply related
* [PATCH] Add git-show reference
From: Jon Loeliger @ 2006-03-18 0:21 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
e202e207b8da1ac771a98f039cdfac70ad9ea0d2
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 8610d36..de3934d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -329,6 +329,9 @@ gitlink:git-revert[1]::
gitlink:git-shortlog[1]::
Summarizes 'git log' output.
+gitlink:git-show[1]::
+ Show one commit log and its diff.
+
gitlink:git-show-branch[1]::
Show branches and their commits.
--
1.2.4.gdd7be
^ permalink raw reply related
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