* Re: [ANNOUNCE] GIT 1.4.3
From: Al Viro @ 2006-10-21 5:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqo6i6da.fsf@assigned-by-dhcp.cox.net>
On Fri, Oct 20, 2006 at 10:29:37PM -0700, Junio C Hamano wrote:
> Al Viro <viro@ftp.linux.org.uk> writes:
>
> > Speaking of irritations... There is a major (and AFAICS fixable)
> > suckitude in git-cherry. Basically, what it does is...
>
> Yeah, that sucks big time. I never realized there are people
> who still are using it, though. git-format-patch used to use it,
> but the version was retired exactly five months ago, and there
> is no in-tree users anymore.
Huh? If you have a saner way to do reordering/changeset-by-changeset
rebasing of branches... git-cherry followed by selective cherry-pick
works and is much more convenient than messing with implementing what
I need via git-am and shitloads of editing...
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.3.1
From: Junio C Hamano @ 2006-10-21 5:32 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.3.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.3.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.3.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.3.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.3.1-1.$arch.rpm (RPM)
This is primarily to work around changes in the recent GNU diff output
format. Also it contains irritation fix for "git diff" which now
paginates its output by default.
----------------------------------------------------------------
Changes since v1.4.3 are as follows:
Junio C Hamano (1):
pager: default to LESS=FRS
Lars Hjemli (1):
Fix typo in show-index.c
Linus Torvalds (1):
git-apply: prepare for upcoming GNU diff -u format change.
Nguyễn Thái Ngọc Duy (2):
Reject hexstring longer than 40-bytes in get_short_sha1()
Add revspec documentation for ':path', ':[0-3]:path' and git-describe
Nicolas Pitre (1):
reduce delta head inflated size
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 12:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, bazaar-ng, git, Matthieu Moy
In-Reply-To: <200610171345.32313.jnareb@gmail.com>
On Tue, 17 Oct 2006 13:45:31 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> Git cannot do that remotely (with exception of git-tar-tree/git-archive
> which has --remote option), yet. But you can get contents of a file
> (with "git cat-file -p [<revision>:|:<stage>:]<filename>"), list
> directory (with "git ls-tree <tree-ish>") and compare files or
> directories (git diff family of commands) without need for working
> directory.
Interesting, I didn't know about the --remote option. So in fact as long
as the remote has enabled upload-tar then anyone can do a "light checkout".
However, it appears that kernel.org for instance doesn't enable this feature.
Sean
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Junio C Hamano @ 2006-10-21 5:29 UTC (permalink / raw)
To: Al Viro; +Cc: git
In-Reply-To: <20061021021235.GA29920@ftp.linux.org.uk>
Al Viro <viro@ftp.linux.org.uk> writes:
> Speaking of irritations... There is a major (and AFAICS fixable)
> suckitude in git-cherry. Basically, what it does is...
Yeah, that sucks big time. I never realized there are people
who still are using it, though. git-format-patch used to use it,
but the version was retired exactly five months ago, and there
is no in-tree users anymore.
I guess we could separate out the revision filtering logic in
builtin-log.c:cmd_format_patch() and implement git-cherry as a
new built-in.
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-18 23:49 UTC (permalink / raw)
To: Charles Duffy; +Cc: bazaar-ng, git
In-Reply-To: <eh6dgr$pu8$1@sea.gmane.org>
On Wed, 18 Oct 2006 18:31:32 -0500
Charles Duffy <cduffy@spamcop.net> wrote:
> Granted, I'm speaking with my IT hat on here rather than my developer
> hat -- but plugins are a pretty clear usability win.
Sure they can be. But their value I think is overstated, especially
in an open source project where anyone can grab a copy of the source
and update it with a trial feature. This updated copy can be wrapped
in a nice GUI installer just as easily as any plugin.
Now, I suppose plugins let end users mix and match trial features
slightly easier, but hopefully your base package isn't so devoid of
features that this is honestly necessary.
As Petr pointed out, all this comes to Bzr essentially for free
since it's a part of python. So be it, but I've yet to hear an
example where plugins were anything more than a minor convenience
rather than a fundamental win over the way Git is developing.
For an example, just look how few lines of git were needed to
implement the essential features of the bzr bundle feature.
With no plugins or monkey business needed ;o)
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 14:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <vpqejt73vln.fsf@ecrins.imag.fr>
On Tue, 17 Oct 2006 15:44:36 +0200
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > How does bzr avoid a merge when you're pushing changes from 3
> > separate machines?
>
> Err, the same way people have been doing for years ;-). If you don't
> have local commits, "bzr update" will work in the same way as "cvs
> update", it keeps your local changes, without recording history. Like
> "git pull" does if you have uncommited changes I think.
Ah, okay. Well Git can definitely manage this. Just means you have to
rebase any local changes before pushing. This will keep the history
linear and make sure that no merges are needed in the case you were asking
about.
So far, it sounds to me like bazaar and git are more alike than they are
different. Each have a few commands the other doesn't but all in all
they sound very similar. But i'm a Git fanboy so I aint switching
now ;o)
Sean
^ permalink raw reply
* Re: On blame/pickaxe
From: Junio C Hamano @ 2006-10-21 3:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061017004429.GC20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> >> If the user is not prepared to see code movement, pickaxe can be
>> >> run without -M nor -C to get the classic blame output.
>
> Ok, so in this case -M and -C does not mean just looking for
> copies/movements in other files but inside the same file as well.
>
> Perhaps we might want to differentiate those two cases since searching
> in all files might be significantly slower.
I do not personally worry about people confusing -M/-C to
pickaxe with -M/-C given to diff (to pickaxe, use of diff is
purely an internal implementation issue), and reused -M and -C
to mean quite different things. -M is to detect line movement
inside a file (it is not strictly limited to "line movement",
though. It _is_ about "copies and moves within the same file").
On the other hand, -C (and its stronger form -C -C) is to detect
copies and moves across file boundaries (but wholesale "file
rename" comes as part of the basic algorithm so you do not have
to ask for it with -M nor -C). So in that sense pronouncing M
"move" and C "copy" is not accurate. Their differences is
already what you said "we might want".
However they match the cost expectation people are used to in
diff options pretty well. -M is not so expensive and -C is
somewhat. -C -C is like find-copies-harder and is quite
expensive.
Also currently the code does not do "move" detection at all.
Contrary to intuition, move detection is more expensive than
copy detection in this case.
^ permalink raw reply
* Re: git-merge-recursive, was Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-21 2:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610210359040.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 20 Oct 2006, Linus Torvalds wrote:
>
>> Git just slurps in all three trees. I actually think that the current
>> merge-recursive.c does it the stupid way (ie it expands all trees
>> recursively, regardless of whether it's needed or not), but I should
>> really check with Dscho, since I had nothing to do with that code.
>
> AFAIR yes, it does the dumb thing, namely it does not take advantage of
> trees being identical when their SHA1s are identical.
>
> This will be a _tremendous_ speed-up.
While we are talking about merge-recursive, I could use some
help from somebody familiar with merge-recursive to complete the
read-tree changes Linus mentioned early this month.
The issue is that we would want to remove one verify_absent()
call in unpack-tree.c:threeway_merge(). When read-tree decides
to leave higher stages around, we do not want it to check if the
merge could clobber a working tree file, because having an
unrelated file at the same path in the working tree sometimes is
and sometimes is not a conflict, depending on the outcome of the
merge, and that part of the code does not _know_ the outcome
yet.
What this means is that we would need to have the equivalent
check in the merge strategy that uses read-tree for three-way
merge when we remove this overcautious safety check from
read-tree. I've adjusted merge-one-file to do so, but not many
people use 'resolve' strategy these days, and we would need the
matching change in merge-recursive.
If you are interested, you can see the details in commit 0b35995.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Al Viro @ 2006-10-21 2:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610201709430.3962@g5.osdl.org>
On Fri, Oct 20, 2006 at 05:14:39PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 20 Oct 2006, Junio C Hamano wrote:
> >
> > I am considering the following to address irritation some people
> > (including me, actually) are experiencing with this change when
> > viewing a small (or no) diff. Any objections?
>
> Not from me. I use "git diff" just to check that the tree is empty, and
> the fact that it now throws me into an empty pager is irritating.
Speaking of irritations... There is a major (and AFAICS fixable)
suckitude in git-cherry. Basically, what it does is
* use git-rev-list to find commits on our branches
* do git-diff-tree -p for each commit
* do git-patch-id on each delta
* compare sets.
For one thing, there are better ways to do set comparison than creating
a file for each element in one set and going through another checking
if corresponding files exist (join(1) and sort(1) or just use perl hashes).
That one is annoying on journalling filesystems (a lot of files being
created, read and removed - fsckloads of disk traffic), but it's actually
not the worst problem.
Far more annoying is that we keep recalculating git-diff-tree -p | git-patch-id
again and again; try to do git cherry on a dozen short branches forked at
2.6.18 and you'll see the damn thing recalculated a dozen of times for
each commit from 2.6.18 to current. It's not cheap, to put it mildly.
git-rev-list ^v2.6.18 HEAD|while read i; do git-diff-tree -p $i; done |git-patch-id >/dev/null
out of hot cache on 2GHz amd64 box (Athlon 64 3400+) takes 3 minutes of
wall time. Repeat that for each branch and it's starting to get old very
fast.
Note that we are calculating a function of commit; it _never_ changes.
Even if we don't just calculate and memorize it at commit time, a cache
somewhere under .git would speed the things up a lot...
^ permalink raw reply
* git-merge-recursive, was Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Johannes Schindelin @ 2006-10-21 2:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Aaron Bentley, Jakub Narebski, Jan Hudec, bazaar-ng,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0610201333240.3962@g5.osdl.org>
On Fri, 20 Oct 2006, Linus Torvalds wrote:
> On Fri, 20 Oct 2006, Aaron Bentley wrote:
> >
> > Agreed. We start by comparing BASE and OTHER, so all those comparisons
> > are in-memory operations that don't hit disk. Only for files where BASE
> > and OTHER differ do we even examine the THIS version.
>
> Git just slurps in all three trees. I actually think that the current
> merge-recursive.c does it the stupid way (ie it expands all trees
> recursively, regardless of whether it's needed or not), but I should
> really check with Dscho, since I had nothing to do with that code.
AFAIR yes, it does the dumb thing, namely it does not take advantage of
trees being identical when their SHA1s are identical.
This will be a _tremendous_ speed-up.
> > > So recursive basically generates the matrix of similarity for the
> > > new/deleted files, and tries to match them up, and there you have your
> > > renames - without ever looking at the history of how you ended up where
> > > you are.
> >
> > So in the simple case, you compare unmatched THIS, OTHER and BASE files
> > to find the renames?
>
> Right. Some cases are easy: if one of the branches only added files (which
> is relatively common), that obviously cannot be a rename. So you don't
> even have to compare all possible combinarions - you know you don't have
> renames from one branch to the other ;)
>
> But I'm not even the authorative person to explain all the details of the
> current recursive merge, and I might have missed something. Dscho?
> Fredrik? Anything you want to add?
Not me. Only that there is much potential for optimization (meaning
performance, not the basic algorithm).
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 1:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfydijw5x.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Oct 2006, Junio C Hamano wrote:
>
> I was not talking about "git pull". I was talking about "git
> show".
Duh. I don't know why I misread that.
Yeah, that makes no sense at all. I _think_ "git show" should be the same
thing as a single-entry "git log -p".
Linus
^ permalink raw reply
* [PATCH] make cg-commit --review restore original tree state afterwards
From: Sam Vilain @ 2006-10-21 1:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
If you delete hunks from the patch that 'cg-commit -p' shows you, then
they are lost 'forever'. Let's put back everything how it was
beforehand instead.
---
cg-commit | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/cg-commit b/cg-commit
index 01a4eb7..81b3619 100755
--- a/cg-commit
+++ b/cg-commit
@@ -568,18 +568,16 @@ else
fi
rm "$LOGMSG2"
+pine_for_darcs() {
+ die "unable to revert the new patch; the original patch is available in $PATCH, your edited patch is available in $PATCH2, your log message is in $LOGMSG, your working copy is in undefined state now and the world is about to end in ten minutes, have a nice day"
+}
+
if [ "$review" ]; then
if ! cmp -s "$PATCH" "$PATCH2"; then
echo "Reverting the original patch..."
- if ! cg-patch -R < "$PATCH"; then
- die "unable to revert the original patch; the original patch is available in $PATCH, your edited patch is available in $PATCH2, your log message is in $LOGMSG, your working copy is in undefined state now and the world is about to end in ten minutes, have a nice day"
- fi
+ cg-patch -R < "$PATCH" || pine_for_darcs
echo "Applying the edited patch..."
- if ! cg-patch < "$PATCH2"; then
- # FIXME: Do something better to alleviate this situation.
- # At least restore the tree to the original state.
- die "unable to apply the edited patch; the original patch is available in $PATCH, your edited patch is available in $PATCH2, your log message is in $LOGMSG, your working copy is in undefined state now and the world is about to end in five minutes, have a nice day"
- fi
+ cg-patch < "$PATCH2" || pine_for_darcs
fi
fi
@@ -625,6 +623,17 @@ if [ "$amend" ]; then
fi
treeid="$(git-write-tree ${missingok})"
+
+if [ "$review" ]; then
+ if ! cmp -s "$PATCH" "$PATCH2"; then
+ echo "Reverting the new patch..."
+ cg-patch -R < "$PATCH2" || pine_for_darcs
+ echo "Applying the old patch..."
+ cg-patch < "$PATCH" || pine_for_darcs
+ fi
+fi
+
+
[ "$treeid" ] || die "git-write-tree failed"
if [ ! "$force" ] && [ ! "$merging" ] && [ "$oldhead" ] &&
[ "$treeid" = "$(cg-object-id -t)" ]; then
--
1.4.2.g0ea2
^ permalink raw reply related
* Re: VCS comparison table
From: Junio C Hamano @ 2006-10-21 1:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610201818210.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 20 Oct 2006, Junio C Hamano wrote:
>>
>> There is another one similar to the gitweb one you mentioned:
>> git-show --stat on a merge. We deliberately chose to show the
>> difference from the first parent; it is called "showing the
>> changes the person who made this merge saw".
>
> Well, that one actually makes sense. It's just the stat from the previous
> state, after all, and it actually is done _together_ with the operation
> that causes the diffs.
>
> So that one I don't think you can really even claim.
>
> Also, it's not even the "first parent". Look closer. It's literally
> "previous state", because it does so for a fast-forward too. It's from
> ORIG_HEAD.
I was not talking about "git pull". I was talking about "git
show".
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-21 1:26 UTC (permalink / raw)
To: git; +Cc: Jan Hudec, bazaar-ng, Jeff Licquia, Linus Torvalds,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610201630000.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Both of these things that git can actually do. Admittedly it does not do
> that in any _released_ version, so you'd have to work with the development
> branch, and it's a fairly early thing, but currently it can actually
> notice that our "revision.c" file largely came from the "rev-list.c" file
> that still exists!
>
> And btw, that's not just some random feature that happened to get
> implemented last week. Yes, it actually _did_ get implemented last week,
> but this was something I outlined when I started git in April of last
> year, and tried to explain to people WHY TRACKING FILE ID'S ARE WRONG!
>
> You can find me explaining these things to people in April-2005, which
> should tell you something: the initial revision of "git" was on Thursday,
> April 7. So the lack of file identity tracking has been controversial from
> the very beginning, but I was right then, and I'm right now.
For people new to the list, the message is:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
I think I've quoted this link at least three times on this list;
I consider it is _the_ most important message in the whole list
archive. If you haven't read it, read it now, print it out,
read it three more times, place it under the pillow before you
sleep tonight. Repeat that until you can recite the whole
message. It should not take more than a week.
To me, personally, achieving that ideal "drill down" dream was
one of the more important goals of my involvement in this
project. I did diffcore-rename to fill some part of the dream,
and then diffcore-pickaxe to fill some other part. Neither was
even close. I think the recent round of pickaxe is getting much
closer.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vy7rajwyn.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Oct 2006, Junio C Hamano wrote:
>
> There is another one similar to the gitweb one you mentioned:
> git-show --stat on a merge. We deliberately chose to show the
> difference from the first parent; it is called "showing the
> changes the person who made this merge saw".
Well, that one actually makes sense. It's just the stat from the previous
state, after all, and it actually is done _together_ with the operation
that causes the diffs.
So that one I don't think you can really even claim.
Also, it's not even the "first parent". Look closer. It's literally
"previous state", because it does so for a fast-forward too. It's from
ORIG_HEAD.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Junio C Hamano @ 2006-10-21 1:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610201702580.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And "gitweb" does consider the first one special, since it shows diffs
> against that one (although I've argued that it probably shouldn't, and
> that there should be some way to show branches against arbitrary parents)
>
> So we're a bit confused. Not that it probably really ever matters.
There is another one similar to the gitweb one you mentioned:
git-show --stat on a merge. We deliberately chose to show the
difference from the first parent; it is called "showing the
changes the person who made this merge saw".
^ permalink raw reply
* Re: Signed git-tag doesn't find default key
From: Horst H. von Brand @ 2006-10-21 0:52 UTC (permalink / raw)
To: Andy Parkins; +Cc: Linus Torvalds, git
In-Reply-To: <200610202021.58157.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
[...]
> I'm going to advocate my change of only searching on the email address
> for finding the key - there shouldn't be two keys with the same email
> address anyway, so there shouldn't be a danger of ambiguity of key.
There very well might be... say you have a key for signing git stuff,
another one for emailing, another one for signing RPMs you create, ... I
believe that is the idea of the GPG comment field, precisely.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Nicolas Pitre @ 2006-10-21 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v4ptylfvw.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Oct 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > - git-diff paginates its output to the tty by default. If this
> > irritates you, using LESS=RF might help.
>
> I am considering the following to address irritation some people
> (including me, actually) are experiencing with this change when
> viewing a small (or no) diff. Any objections?
I think this is an excellent idea.
Nicolas
^ permalink raw reply
* [RFC] Syntax highlighting for combined diff
From: Jakub Narebski @ 2006-10-21 0:35 UTC (permalink / raw)
To: git
Linus Torvalds wrote in "Re: VCS comparison table"
> And "gitweb" does consider the first parent special, since it shows diffs
> against that one (although I've argued that it probably shouldn't, and
> that there should be some way to show branches against arbitrary parents)
So the question is how to color combined diff format (what should be syntax
highlighting for combined diff format). If branches columns have only
pluses we use the same color as for adding line in ordinary diff; if
branches column consist only of minuses we use the same color as for
removing line in ordinary diff. Can there be mixture of plusses and
minuses? How git-diff --color solves this?
Should we in gitweb output change color slightly depending on number of
plusses or minuses?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Linus Torvalds @ 2006-10-21 0:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <20061021002251.GO20017@pasky.or.cz>
On Sat, 21 Oct 2006, Petr Baudis wrote:
>
> > That said, "LESS=FRS" doesn't really help that much. It still clears the
> > screen. Using "LESS=FRSX" fixes that, but the alternate display sequence
> > is actually nice _if_ the pager is used.
>
> Hmm, what terminal emulator do you use? The reasonable ones should
> restore the original screen. At least xterm does, and I *think*
> gnome-terminal does too (although I'm too lazy to boot up my notebook
> and confirm).
Not xterm, at least.
Not gnome-terminal either, for that matter.
I just tried.
LESS=FRS git diff
clears the screen and leaves the thing at the end.
LESS=FRSX git diff
works fine, but for people who _like_ the alternate screens (and I do,
once I really use a pager) it also disables the alternate screen.
It might depend on the termcap, of course. I'm running FC5.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Petr Baudis @ 2006-10-21 0:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610201709430.3962@g5.osdl.org>
> That said, "LESS=FRS" doesn't really help that much. It still clears the
> screen. Using "LESS=FRSX" fixes that, but the alternate display sequence
> is actually nice _if_ the pager is used.
Hmm, what terminal emulator do you use? The reasonable ones should
restore the original screen. At least xterm does, and I *think*
gnome-terminal does too (although I'm too lazy to boot up my notebook
and confirm).
(I personally consider alternate screen an abomination. It would be so
nice if the terminal emulators would just make it optional.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Linus Torvalds @ 2006-10-21 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v4ptylfvw.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Oct 2006, Junio C Hamano wrote:
>
> I am considering the following to address irritation some people
> (including me, actually) are experiencing with this change when
> viewing a small (or no) diff. Any objections?
Not from me. I use "git diff" just to check that the tree is empty, and
the fact that it now throws me into an empty pager is irritating.
That said, "LESS=FRS" doesn't really help that much. It still clears the
screen. Using "LESS=FRSX" fixes that, but the alternate display sequence
is actually nice _if_ the pager is used.
Still, I think I'd prefer FRSX as the default.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-21 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vlknalgne.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Oct 2006, Junio C Hamano wrote:
>
> I am not bold enough to say _exactly_ N places, but you missed
> at least one more important one. Merge simplification favors
> the earlier parents over later ones.
Which is probably slightly inconsistent (although I seriously doubt
anybody really cares - when we simplify a merge we obvioously do it
exactly because the parents are identical wrt the files we are following).
Most of the rest of commit traversal tend to have a rule that says
"traverse youngest parent first", simply by virtue of the fact that
revlist() normally pops off the queue in date order. But Jakub is
certainly correct that when we do "^" we just take the first one.
And "gitweb" does consider the first one special, since it shows diffs
against that one (although I've argued that it probably shouldn't, and
that there should be some way to show branches against arbitrary parents)
So we're a bit confused. Not that it probably really ever matters. We
might as well say that parent order is random, and that our "random number
generators" are pretty damn lazy ;)
Linus
^ permalink raw reply
* Re: [PATCH] Use diff3 instead of merge in merge-recursive.
From: Johannes Schindelin @ 2006-10-21 0:06 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20061020211121.GB3024@cepheus.pub>
Hi,
On Fri, 20 Oct 2006, Uwe Zeisberger wrote:
> Johannes Schindelin wrote:
>
> > I have to dig a little where I have it, but I think I can give it a try in
> > a few hours (imagine this lyrics to the melody of the day job blues).
>
> Seems to be a long blues because you didn't sent any results. :-(
Yes. It was a long blues, and now instead of going to sleep I tested it.
In the long run, it was negligible, with a high local variability (which
stems from the fact that I had to run this test while the machine was
under high load, which it will be for another 48 hours minimum).
It makes sense that performance-wise, it will not make a great difference.
After all, the expensive operation is not the file-writing, but the
merging pass.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Linus Torvalds @ 2006-10-20 23:59 UTC (permalink / raw)
To: Jeff Licquia; +Cc: Jan Hudec, bazaar-ng, git, Jakub Narebski
In-Reply-To: <1161382416.9241.19.camel@localhost.localdomain>
On Fri, 20 Oct 2006, Jeff Licquia wrote:
>
> After this conflict is resolved, merging from b causes conflicts, while
> merging from c appears to work fine. This continues until b merges from
> a (and resolves a conflict in a similar manner to a), at which time
> merging/pulling works as you'd expect between the branches. Whenever b
> is marked as conflicting before it merges from a, bzr preserves b's
> changes by moving b's modified file.
This sounds somewhat like what I think BK did. I'm not sure if BK actually
marked it as a conflict or whether BK just warned about "changes to
deleted file" or something similar, but it didn't entirely _silently_
throw them away.
But I hope this shows some of the basic problems.
The much more _serious_ problem of "file identity" tracking is actually
that you can't track partial file movement or file copies sanely. The
thing is, tracking things at file boundaries simply is fundamnetally a
broken notion, simply because _code_ doesn't get done at file boundaries.
Both of these things that git can actually do. Admittedly it does not do
that in any _released_ version, so you'd have to work with the development
branch, and it's a fairly early thing, but currently it can actually
notice that our "revision.c" file largely came from the "rev-list.c" file
that still exists!
And btw, that's not just some random feature that happened to get
implemented last week. Yes, it actually _did_ get implemented last week,
but this was something I outlined when I started git in April of last
year, and tried to explain to people WHY TRACKING FILE ID'S ARE WRONG!
You can find me explaining these things to people in April-2005, which
should tell you something: the initial revision of "git" was on Thursday,
April 7. So the lack of file identity tracking has been controversial from
the very beginning, but I was right then, and I'm right now.
Because the _fact_ is, that as long as you track stuff on a file basis,
you're _never_ going to be able to do the things that git alreadt does,
and that are very natural.
Here's the real-world example of something that git CAN DO TODAY:
- we used to have a file called "rev-list.c", which did a lot of the
commit history revision traversal, and is the source of the git command
"git rev-list".
- I (and others) extended it a lot, and turned it into a more generic
library interface, so that other commands could traverse the commit
graph on their own, rather than forking and executing "git-rev-list"
and piping the output between them.
- as a result, the old "rev-list.c" still exists (except it was renamed
to "builtin-rev-list.c" since it's now a builtin command to the main
"git" binary).
- HOWEVER, a lot of the actual code got split into the library file,
called "revision.c", which contains the real smarts of the program.
See? There was a file rename involved (rev-list.c => builtin-rev-list.c),
but that actually happened after a lot of the really _interesting_ code
had been excised from that file, and put into the new internal library
file (revision.c).
Now, as a result, in many ways the rename is _much_ less interesting than
the question about the history of the code in "revision.c" (because that's
really some very core code). And that was never a rename at all. That was
just a file create, where a lot of the contents happened to come from a
file that continued to exist.
Wouldn't you want "annotate" to be able to follow this kind of data
movement? Notice how there is no "file" that moved at all. Only code that
moved between files.
I tell you: as long as you work with "file ID's", you'll always be
inferior. You'll never be able to see that some code was copied
_partially_ from one file into another. You'll never be able to see an
important function moving between file boundaries.
Unless you work with "git", that is. Because git isn't so _stupid_ as to
think that file boundaries matter. Git knows better. The only thing that
matters is the actual _data_, and file boundaries are just one way of
delimiting that data.
Just try it out. Get the "next" branch of the git repository (that's the
"stable development" branch in git.git - ie it's going to be in the next
release and is expected to work, unless some of the more "experimental
development" that is in the "pu" branch - pu = proposed updates), compile
it, and run
git pickaxe -C revision.c | less -S
and marvel. Marvel at my shining intelligence (and the small matter of
programming, which was all done by Junio, but I'm taking all the credit
_anyway_, because *dammit* I talked about this last year when people
didn't understand! And besides, I always take all the credit regardless,
so what are you whining about? Get off my back!).
More seriously, Junio really did a kick-ass job. I really had nothing at
all to do with it, and deserve no real credit. But I _did_ forsee it, and
yes, it really is about the fact that git tracks _contents_.
As somebody smarter that I have said (*): "I'm always right, but this time
I'm even more right than usual".
Linus
(*) Just kidding. It was me. Of course.
^ 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