* Re: [PATCH] Document the simple way of using of git-cat-file
From: Jakub Narebski @ 2006-12-13 23:55 UTC (permalink / raw)
To: git
In-Reply-To: <20061213232056.11218.67473.stgit@lathund.dewire.com>
Robin Rosenberg wrote:
> Since you can give a version and a path name to git-cat-file,
> mention it in the man page.
Very nice, with the exception that git cat-file can be used also
for trees and commits (although hit-ls-tree and git-show are usually
used) and for tags, not only for files.
I thought rather about copying last (or two last) entries about
extended sha1 syntax from git-rev-parse(1).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Jakub Narebski @ 2006-12-13 23:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612140048120.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> BTW, how can I notify people that only pull from the http repository
>> that it will no longer be updated (rather than them thinking the
>> development stopped)? One solution would be to create a file with a
>> meaningful name in the top dir and hope people will notice it.
>
> IMHO removing it altogether would be a good idea. The website should carry
> the news of the new repository site.
By the way, would setting http-alternates help? I guess not, not without
having refs copied from the other place...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Average size of git bookkeeping data (related to Using git as a general backup mechanism)
From: Johannes Schindelin @ 2006-12-14 0:02 UTC (permalink / raw)
To: David Tweed; +Cc: git
In-Reply-To: <20061213193149.43284.qmail@web86909.mail.ukl.yahoo.com>
Hi,
On Wed, 13 Dec 2006, David Tweed wrote:
> How big is the "metadata" or "bookeeping data" in git related to a
> commit?
In my experience, a single commit (with the trees and blobs being
reachable from it) takes about the same space in a pack as the
corresponding tar ball.
When you add revisions, the pack grows approximately with the compressed
patch size.
So, if you can estimate the size of the initial tar ball and the size of
the subsequent patches, you have a ballpark figure of the metadata size of
the git repository. (This is for the bare case; for the regular case you
have to add the size of a checked out tree, of course.)
Hth,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-14 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vk60vbcfz.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 13 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > * git-cat-file is badly named. git-cat-object would be slightly
> > better.
>
> Not a Porcelain.
>
> We might want to add a pair of built-in internal aliases though:
>
> [alias]
> cat = cat-file -p
> less = -p cat-file -p
>
> or have these as samples in template .git/config file.
I sent a patch which makes "git show" have that functionality, and
frankly, I disagree "less" would be a good name for it. It uses the
_pager_, which is not always "less", and besides, what it does is to show
that particular blob. So obviously, I think my patch is the best approach.
BTW if you now say "git show master:README" it will show _nothing_, not
even an error message.
Ciao,
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-14 0:22 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200612132237.10051.andyparkins@gmail.com>
Hi,
On Wed, 13 Dec 2006, Andy Parkins wrote:
> On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:
>
> * git-revert should be called git-invert. It doesn't remove a change
> from history, it simply applies another commit that does the
> opposite of whatever commit you are "revert"ing. That's an inversion.
No. An inversion is the _opposite_. Not an undo.
Besides, The fact that revert _adds_ to history is a nice way to
document that you reverted that change. And you can even explain in the
commit message, why you did it.
> * git-fetch output is confusing:
> remote: Generating pack...
> remote: Done counting 189146 objects.
> remote: Result has 186566 objects.
> remote: Deltifying 186566 objects.
> remote: 100% (186566/186566) done
> Unpacking 186566 objects
> 24% (44792/186566) done
> Some questions from the point of view of a newbie: what is a pack? what is
> an object? Why is the remote counting them? Which remote am I reading
> from? What am I fetching? What is "Deltifying"? How much data do I have
> to download (number of objects doesn't tell me). How long has this taken?
> How long is left to go?
IMHO it is better for a newbie to see that _something_ is happening. A
newbie cannot, and does not want to, understand exactly what is going on.
So, think of it as our response to Windows' non-progress-bar: when you
start up Windows, there is a progress-bar, except that it does not show
progress, but a Knight Rider like movement, only indicating that it does
something.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document the simple way of using of git-cat-file
From: Johannes Schindelin @ 2006-12-14 0:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elq3pa$93b$1@sea.gmane.org>
Hi,
On Thu, 14 Dec 2006, Jakub Narebski wrote:
> Robin Rosenberg wrote:
>
> > Since you can give a version and a path name to git-cat-file,
> > mention it in the man page.
>
> Very nice, with the exception that git cat-file can be used also
> for trees and commits (although hit-ls-tree and git-show are usually
> used) and for tags, not only for files.
The point is: you are much more likely to look at a blob that at a tree.
And if you want to do that, you can always use git-ls-tree.
But as I mentioned in another thread, I'd rather see git-show do the job
of showing blobs, too, in addition to commits as it does already.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document the simple way of using of git-cat-file
From: Jakub Narebski @ 2006-12-14 0:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Robin Rosenberg
In-Reply-To: <Pine.LNX.4.63.0612140127520.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Thu, 14 Dec 2006, Jakub Narebski wrote:
>
>> Robin Rosenberg wrote:
>>
>>> Since you can give a version and a path name to git-cat-file,
>>> mention it in the man page.
>>
>> Very nice, with the exception that git cat-file can be used also
>> for trees and commits (although hit-ls-tree and git-show are usually
>> used) and for tags, not only for files.
>
> The point is: you are much more likely to look at a blob that at a tree.
> And if you want to do that, you can always use git-ls-tree.
>
> But as I mentioned in another thread, I'd rather see git-show do the job
> of showing blobs, too, in addition to commits as it does already.
More important is that git-cat-file is used for _tags_; git-show used
for tag takes tag as <commit-ish>, so it cannot show tag.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] git-add --interactive (wip)
From: Josef Weidendorfer @ 2006-12-13 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wn4mk9i.fsf@assigned-by-dhcp.cox.net>
On Wednesday 13 December 2006 06:34, Junio C Hamano wrote:
> >> > Just as a sidenote: after deciding to not apply hunks, you
> >> > lose them in this WIP, as you will find nothing in "unstaged" mode
> >> > afterwards :-(
> >>
> >> I do not understand this part. You can 'revert' to match the
> >> index to HEAD and run 'patch' to pick what you want again.
> >
> > I lost my changes in the working directory; there was nothing to
> > pick again any more.
>
> That's worrysome. By design, "git add" should not touch working
> tree at all (only read from there), so if you find cases that
> violates it that should be fixed; please let me know.
I just tried to reproduce the failure with exact the same hunk I used
the first time. I wasn't able to get any wrong result.
So perhaps I did something wrong the first time.
However, if I see something suspect, I will tell you ;-)
Thanks,
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-14 2:21 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <1166027289.21948.4.camel@systems03.lan.brontes3d.com>
On 11:28 Wed 13 Dec , Daniel Drake wrote:
>
> Sorry, apparently I was using the wrong git-svnimport in my last mail.
> The above command, with or without your svn_dir patch, doesn't solve the
> problem.
>
> With your patch:
Original patch is wrong, so only w/out this patch.
>
> # git-svnimport -v -i -C repo -r https://server/repo
>
> RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
> PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://svn) at
> git-svnimport line 364
>
> Without the patch, the error is the same as the 1st case in both
> situations.
Try this please:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..071777b 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -146,6 +146,7 @@ sub file {
print "... $rev $path ...\n" if $opt_v;
my (undef, $properties);
my $pool = SVN::Pool->new();
+ $path =~ s#^/*##;
eval { (undef, $properties)
= $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
$pool->clear;
@@ -181,6 +182,7 @@ sub ignore {
my($self,$path,$rev) = @_;
print "... $rev $path ...\n" if $opt_v;
+ $path =~ s#^/*##;
my (undef,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
if (exists $properties->{'svn:ignore'}) {
@@ -197,6 +199,7 @@ sub ignore {
sub dir_list {
my($self,$path,$rev) = @_;
+ $path =~ s#^/*##;
my ($dirents,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
return $dirents;
@@ -354,6 +357,7 @@ open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
+ $svnpath =~ s#^/*##;
my $kind = $svn->{'svn'}->check_path($svnpath,$revision,$pool);
$pool->clear;
return $kind;
Thanks,
^ permalink raw reply related
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-14 2:25 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Daniel Drake, git
In-Reply-To: <4b3406f0612111301m302dfe3dm81b09a432e67163d@mail.gmail.com>
On 05:01 Tue 12 Dec , Dongsheng Song wrote:
>
> git-svnimport -v -i -r -o master -l $mr -C $WC_ROOT/$REPO_NAME
> http://tortoisesvn.tigris.org/svn/tortoisesvn
Thanks.
I'm running now git-svnimport against
http://tortoisesvn.tigris.org/svn/tortoisesvn with follow patch:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..071777b 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -146,6 +146,7 @@ sub file {
print "... $rev $path ...\n" if $opt_v;
my (undef, $properties);
my $pool = SVN::Pool->new();
+ $path =~ s#^/*##;
eval { (undef, $properties)
= $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
$pool->clear;
@@ -181,6 +182,7 @@ sub ignore {
my($self,$path,$rev) = @_;
print "... $rev $path ...\n" if $opt_v;
+ $path =~ s#^/*##;
my (undef,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
if (exists $properties->{'svn:ignore'}) {
@@ -197,6 +199,7 @@ sub ignore {
sub dir_list {
my($self,$path,$rev) = @_;
+ $path =~ s#^/*##;
my ($dirents,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
return $dirents;
@@ -354,6 +357,7 @@ open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
+ $svnpath =~ s#^/*##;
my $kind = $svn->{'svn'}->check_path($svnpath,$revision,$pool);
$pool->clear;
return $kind;
And it works up to now.
This is the same patch as recently posted to Daniel. Could you try?
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Nicolas Pitre @ 2006-12-14 3:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612140113340.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 14 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 13 Dec 2006, Junio C Hamano wrote:
>
> > We might want to add a pair of built-in internal aliases though:
> >
> > [alias]
> > cat = cat-file -p
> > less = -p cat-file -p
> >
> > or have these as samples in template .git/config file.
>
> I sent a patch which makes "git show" have that functionality, and
> frankly, I disagree "less" would be a good name for it. It uses the
> _pager_, which is not always "less", and besides, what it does is to show
> that particular blob. So obviously, I think my patch is the best approach.
I think your approach is pretty sensible too.
^ permalink raw reply
* Performance problems in diffcore rename
From: Shawn Pearce @ 2006-12-14 3:39 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Johannes Schindelin
Originally I had thought I was running into an infinite loop in
git-merge-recursive while trying to merge two branches together
which have been troublesome in the past.
That's not the case. I spent some time debugging it tonight on
the private (unpublishable) repository that is showing the problem.
What is actually occuring is one of the branches has 6735 files
added between the merge base and its tip, and the other branch
has roughly the same number.
git-merge-recursive very quickly goes down into the diffcore code to
perform rename detection, at which point we come up with 6735 files
for rename_dst_nr (in diffcore_rename) and we almost immediately
wind up with contents_too = 1, which means we are now doing full
content comparsions in is_exact_match.
What really hurts is when we go into diff_populate_filespec we
proceed to take the optimization that Junio added in 6973dcae,
which is to favor mmap'ing the working tree file over inflating
the blob from the ODB.
Except that in my case I'm running on Cygwin/Windows 2000 and almost
everything is packed. So inflating the blob out of the ODB is a
thousand times faster than opening the working directory file and
mmap'ing it. If I modify work_tree_matches to always return false
the merge goes through in under 3 seconds.
Running the same merge on Solaris doesn't show the problem at all,
as that OS has reasonably well performing open and mmap syscalls.
But looking at is_exact_match I'm now wondering why we bother
to open the working tree file at all here. Its almost like
we are missing the following, as both src and dst are coming out
of tree objects and therefore their sha1's should match.
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 57a74b6..29480ca 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -105,6 +105,8 @@ static int is_exact_match(struct diff_filespec *src,
return 1;
if (!contents_too)
return 0;
+ if (src->sha1_valid && dst->sha1_valid)
+ return 0;
if (diff_populate_filespec(src, 1) || diff_populate_filespec(dst, 1))
return 0;
if (src->size != dst->size)
--
^ permalink raw reply related
* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Chris Riddoch @ 2006-12-14 5:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Kyle Moffett, git
In-Reply-To: <Pine.LNX.4.64.0612131156500.20138@iabervon.org>
So, I've been making little repositories for appropriately related
stuff. For example, I have a repository for my ~/.bashrc,
~/.bash_profile, ~/.bash_completions/*, and such.
I recall Linus's post in the "VCS Comparison Table" thread, and after
thinking about it, I decided the best thing to do would be to have a
couple extra files tracked in the repository, alongside other data.
I use a backup shell script to copy things from my system to the
repository, and then I run getfacl on it all to write out all the
details to a 'facl' file in my repository. Then I can make a commit.
Then there's a restore shell script to copy things back to my system,
and restore ownership and permissions with setfacl.
I store the backup and restore scripts in the repository. Paths are
currently hard-coded. I'm sure there's a more flexible way to do
this, though I'd need some means of representing the correspondence
between content in the repository and files in my filesystem.
On 12/13/06, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 12 Dec 2006, Kyle Moffett wrote:
>
> > Hmm, ok. It would seem to be a reasonable requirement that if you want to
> > change any of the "preserve_*_attributes" config options you need to blow
> away
> > and recreate your index, no? I would probably change the underlying index
> > format pretty completely and stick a new version tag inside it.
>
> You should be able to promote an insufficient-version index to a
> new-version index that's needs to be refreshed for every entry. (And then
> update-index would take care of the necessary rewrite-everything in the
> normal way). But I suspect that the right thing is to require that the
> repository be created with a "commits-include-directories-not-trees" flag,
> and this means that you always use the extra-detailed index, and the
> options only affect what information is filtered out in transit between
> the directory object and the index. Having more information in the index
> is merely a potential waste of space, not a correctness issue (we have
> extra information for trees in the index now, remember); it just means
> that there are more things that will cause git to reread the file, rather
> than declaring it unchanged with a stat().
>
> For that matter, it may be best for the directory objects to record what
> information in them is real, and keep the "what's content" mask in the
> index as well. If it changes over the history of a repository, you want to
> correctly interpret the historical commits.
>
> > Ok, seems straightforward enough. One other thing that crossed my mind
> was
> > figuring out how to handle hardlinks. The simplest solution would be to
> add
> > an extra layer of indirection between the "file inode" and the "file
> data".
> > Instead of your directory pointing to a "file-data" blob and
> "file-attributes"
> > object, it would point to an "file-inode" object with embedded attribute
> data
> > and a pointer to the file contents blob.
> >
> > I remember reading some discussions from the early days of GIT about how
> that
> > was considered and discarded because the extra overhead wouldn't give any
> real
> > tangible benefit. On the other hand for something like /etc the added
> > benefits of tracking extended attributes and hardlinks might outweigh the
> cost
> > of a bunch of extra objects in the database. A bit of care with the
> > construction of the index file should make it sufficiently efficient for
> > day-to-day usage.
>
> I was thinking this could be internal to the directory object, but you
> probably want to support hardlinks shared between dentries in different
> directory objects, so you're probably right that this makes sense.
>
> Alternatively, you could use a single "directory" object for the whole
> state (including subdirectories), making hardlinks out of the object
> clearly impossible, or you could use some scheme for sharing
> sub-"directory" objects that would imply that hardlinks are within an
> object (the hard part here is finding things when their locations aren't
> predictable by name).
>
> -Daniel
> *This .sig left intentionally blank*
> -
> 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
>
--
epistemological humility
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Martin Langhoff @ 2006-12-14 5:55 UTC (permalink / raw)
To: Florian v. Savigny; +Cc: git
In-Reply-To: <0MKwpI-1GuWVF2znk-0006fC@mrelayeu.kundenserver.de>
Florian,
a bit of a long shot, but you might be able to access it via Samba,
and just use git on linux. I have to confess to having setup a few git
checkouts for Win32 users this way... in some cases with cygwin+x11
and a shortcut that will do something like
ssh linuxhost gitk --all
or
ssh linuxhost qgit
but then again, I'm rumoured to be insane...
cheers,
^ permalink raw reply
* Re: Performance problems in diffcore rename
From: Junio C Hamano @ 2006-12-14 6:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Johannes Schindelin
In-Reply-To: <20061214033925.GA1408@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> But looking at is_exact_match I'm now wondering why we bother
> to open the working tree file at all here.
You are right. When we _know_ both SHA-1 can be trusted, we
should be able to do just this, regardless of contents_too
(whose only purpose is to delay comparing a cache dirty working
tree file with something else):
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 57a74b6..677db85 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -100,9 +100,8 @@ static int is_exact_match(struct diff_filespec *src,
struct diff_filespec *dst,
int contents_too)
{
- if (src->sha1_valid && dst->sha1_valid &&
- !hashcmp(src->sha1, dst->sha1))
- return 1;
+ if (src->sha1_valid && dst->sha1_valid)
+ return !hashcmp(src->sha1, dst->sha1);
if (!contents_too)
return 0;
if (diff_populate_filespec(src, 1) || diff_populate_filespec(dst, 1))
^ permalink raw reply related
* Re: Performance problems in diffcore rename
From: Shawn Pearce @ 2006-12-14 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v7iwvatrt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > But looking at is_exact_match I'm now wondering why we bother
> > to open the working tree file at all here.
>
> You are right. When we _know_ both SHA-1 can be trusted, we
> should be able to do just this, regardless of contents_too
> (whose only purpose is to delay comparing a cache dirty working
> tree file with something else):
>
> diff --git a/diffcore-rename.c b/diffcore-rename.c
> index 57a74b6..677db85 100644
> --- a/diffcore-rename.c
> +++ b/diffcore-rename.c
> @@ -100,9 +100,8 @@ static int is_exact_match(struct diff_filespec *src,
> struct diff_filespec *dst,
> int contents_too)
> {
> - if (src->sha1_valid && dst->sha1_valid &&
> - !hashcmp(src->sha1, dst->sha1))
> - return 1;
> + if (src->sha1_valid && dst->sha1_valid)
> + return !hashcmp(src->sha1, dst->sha1);
> if (!contents_too)
> return 0;
> if (diff_populate_filespec(src, 1) || diff_populate_filespec(dst, 1))
>
Have you tested the above patch? I have the exact same one in
my working directory right now and its failing a huge number of
the tests. At least great minds think alike that we can make this
optimization here, but there's something amiss...
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 6:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0612132231050.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Thu, 14 Dec 2006, Johannes Schindelin wrote:
>
>> I sent a patch which makes "git show" have that functionality, and
>> frankly, I disagree "less" would be a good name for it. It uses the
>> _pager_, which is not always "less", and besides, what it does is to show
>> that particular blob. So obviously, I think my patch is the best approach.
>
> I think your approach is pretty sensible too.
I think so too for a few reasons.
* cat-file is a very low level plumbing. Giving it -p was a
mistake made by somebody lazy long time ago back when we were
not all that hot about "user friendliness in Porcelain-ish"
(the option -p was not originally even meant to be the user
level; it was merely a helper feature for verify-tag).
* If we were to call something 'cat' and make a user-level
command, adding the feature to 'show' is a lot more sensible
than cat-file; the former takes more than one args already.
People expect 'cat' to concatenate the arguments. cat-file
doesn't.
* Throwing ls-tree output is the most sensible thing to do at
'cat-file -p <tree-ish>' level, but not at the UI level (Andy
compared ls-tree with 'svn list' today). With 'git show', it
would be more natural to show ls-tree --name-only by default
for tree-ish objects, and control the verbosity level with
command line option.
One minor issue we may need to decide is what to do when show is
given a tag object. Personally I think the current behaviour of
dereferencing it to commit is fine (people who want to see the
tag can always do 'git-verify-tag -v').
^ permalink raw reply
* git-show, was Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-14 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vy7pb9eit.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 13 Dec 2006, Junio C Hamano wrote:
> One minor issue we may need to decide is what to do when show is
> given a tag object. Personally I think the current behaviour of
> dereferencing it to commit is fine (people who want to see the
> tag can always do 'git-verify-tag -v').
How about adding the command line option "--tag" to git-show, which makes
it only show that tag. I'd also vote for a "--verbose|-v" flag to show the
contents of the tag _before_ showing the referenced object.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Update git-diff documentation
From: Junio C Hamano @ 2006-12-14 8:09 UTC (permalink / raw)
To: git
Porcelain documentation should talk in terms of end-user workflow, not
in terms of implementation details. Do not suggest update-index, but
git-add instead. Explain differences among 0-, 1- and 2-tree cases
not as differences of number of trees given to the command, but say
why user would want to give these number of trees to the command in
what situation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* The same idea as the previous "git commit" documentation.
Documentation/git-diff.txt | 55 ++++++++++++++++++++++++++++---------------
1 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 228c4d9..8888e0d 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -12,32 +12,49 @@ SYNOPSIS
DESCRIPTION
-----------
-Show changes between two trees, a tree and the working tree, a
-tree and the index file, or the index file and the working tree.
-The combination of what is compared with what is determined by
-the number of trees given to the command.
+This command shows changes between four combinations of states.
-* When no <tree-ish> is given, the working tree and the index
- file are compared, using `git-diff-files`.
+'git-diff' [--options] [--] [<path>...]::
-* When one <tree-ish> is given, the working tree and the named
- tree are compared, using `git-diff-index`. The option
- `--cached` can be given to compare the index file and
- the named tree.
+ This form is to view the changes you made relative to
+ the index (staging area for the next commit). In other
+ words, the differences are what you _could_ tell git to
+ further add to the index but you still haven't. You can
+ stage these changes by using gitlink:git-add[1].
+
+'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
+
+ This form is to view the changes you staged for the next
+ commit relative to the named <tree-ish>. Typically you
+ would want comparison with the latest commit, so if you
+ do not give <commit>, it defaults to HEAD.
+
+'git-diff' [--options] <commit> -- [<path>...]::
+
+ This form is to view the changes you have in your
+ working tree relative to the named <commit>. You can
+ use HEAD to compare it with the latest commit, or a
+ branch name to compare with the tip of a different
+ branch.
+
+* 'git-diff' [--options] <commit> <commit> -- [<path>...]
+
+ This form is to view the changes between two <commit>,
+ for example, tips of two branches.
+
+Just in case if you are doing something exotic, it should be
+noted that all of the <commit> in the above description can be
+any <tree-ish>.
-* When two <tree-ish>s are given, these two trees are compared
- using `git-diff-tree`.
OPTIONS
-------
---diff-options::
- '--diff-options' are passed to the `git-diff-files`,
- `git-diff-index`, and `git-diff-tree` commands. See the
- documentation for these commands for description.
+include::diff-options.txt[]
<path>...::
- The <path> arguments are also passed to `git-diff-\*`
- commands.
+ The <paths> parameters, when given, are used to limit
+ the diff to the named paths (you can give directory
+ names and get diff for all files under them).
EXAMPLES
@@ -51,7 +68,7 @@ $ git diff --cached <2>
$ git diff HEAD <3>
------------
+
-<1> changes in the working tree since your last git-update-index.
+<1> changes in the working tree not yet staged for the next commit.
<2> changes between the index and your last commit; what you
would be committing if you run "git commit" without "-a" option.
<3> changes in the working tree since your last commit; what you
--
1.4.4.2.g86bd
^ permalink raw reply related
* Re: git-show, was Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 8:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.63.0612140855400.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 13 Dec 2006, Junio C Hamano wrote:
>
>> One minor issue we may need to decide is what to do when show is
>> given a tag object. Personally I think the current behaviour of
>> dereferencing it to commit is fine (people who want to see the
>> tag can always do 'git-verify-tag -v').
>
> How about adding the command line option "--tag" to git-show, which makes
> it only show that tag. I'd also vote for a "--verbose|-v" flag to show the
> contents of the tag _before_ showing the referenced object.
Sounds sensible. Please make it so.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andreas Ericsson @ 2006-12-14 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vk60vbcfz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
>> * git-add has no output, whether it works or not
>
> "git add no-such-file" complains, and I think that is adequate.
> Now with Nico's 'add means adding contents, not path' change is
> in, we _might_ want to differentiate adding a path that was
> untracked before and updating the contents, but I think this
> again falls into "doing exactly as told" category.
>
Well, it should really let the user know if it fails. I for one would
like to know that. I wasn't aware of the fact that it was silent even in
those situations (perhaps because I've never run across it).
The errors that need to be reported are, afaics:
Content in 'path/to/file' is ignored according to path/to/.gitignore.
System error X happened while attempting Y.
Hash collisions.
Hash collisions wouldn't be too bad to check for in git add, because it
only has to compare a single object, although I agree that it probably
isn't necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] Update git-diff documentation
From: Johannes Schindelin @ 2006-12-14 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6v2aofs.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> -Show changes between two trees, a tree and the working tree, a
> -tree and the index file, or the index file and the working tree.
> -The combination of what is compared with what is determined by
> -the number of trees given to the command.
> +This command shows changes between four combinations of states.
I think the old explanation, while longer, is clearer.
I like the rest of your patch, though.
Ciao,
^ permalink raw reply
* Re: svn versus git
From: Andy Parkins @ 2006-12-14 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <20061213225627.GC32568@spearce.org>
On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:
> git cat-file -p $REV:$file
>
> not sure how much easier it gets than that. Load in the bash
> completion from contrib/completion and you can even tab complete
> the $file part.
Yes. I was a little unfair on that one; I forgot about the REV:file syntax.
However, it's still not simple for a new user; I think I'd say "draw" if
the "-p" weren't a requirement.
> Documentation flaw that the above wasn't clear? Or is "-file" and
> "-p" the losing part for Git?
Yep. Especially when combined with the fact that the command is called
git-cat-file. A new user could be forgiven for thinking that meant that they
could cat one of their files held by git. Also: they have to read a man page
to find out that they need an option and which option is correct. I reckon
git-cat-object would be a better name ("no chance!", I hear you cry ;-))
I've just noticed as well that the documentation is wrong:
$ git-cat-file HEAD:Makefile
usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
The square brackets indicate "optional", and those items clearly aren't. I'll
fix the documentation.
> > svn cleanup::
> > git fsck-objects::
> > git prune::
> > git repack::
> >
> > Subversion wins, as it only has one command and you don't need to
> > understand the repository in order to understand what its doing.
>
> True, but I'm not sure its fair to Git. svn cleanup is also a
> technical command that one needs to learn either when something
> went wrong or later once the user has gotten used to using SVN.
My point is that a user can run "svn cleanup" without thinking, or needing to
really know what it does. Not so for git's maintenance commands. Also,
there are more commands. I'm not saying they're not useful or necessary, but
it's certainly more complicated than subversion.
For example: I used subversion for a long time - I don't think I ever had
cause to run "cleanup", I'm not even really sure what it does. I /have/ had
cause to learn what git's maintenance commands do; which in turn meant I had
to learn how the git repository works. (I personally don't mind learning
those things, but it's wrong to expect every user to do so).
> The last time I ran fsck-objects was when I was trying to debug
> that empty tree object missing in git-merge-recursive. Usually I
> don't see repository corruption, and even there wasn't any.
Me too. I've never run it in fact; but the command exists and therefore needs
learning.
> or git merge now. :-)
Hurrah! However, at the time I wrote the comparison (and with
1.4.4.1.g3ece-dirty I've got here) git-merge is still the old, more
complicated, command line.
> This is one of Git's killer features over SVN. Git does merges
> right. SVN doesn't. Though I keep hearing its on their TODO list.
Absolutely. Although, even if SVN does implement it, it's going to be a hack.
It'll just be an extra svn:special property set somewhere in the repository,
or similar. I can't see how they can do merges properly with the methodology
that SVN uses.
> Some people like having the empty directory tracked by the VCS, as
> then the build system doesn't need to create it. I perfer keeping
You're right; as it happens I'd prefer it if git could store empty
directories. However, in terms of "what I have to learn", git definitely
wins this category because there is nothing to learn - make whatever
directories you like; it will generally sort itself out.
> How is it unfriendly? What specifically would you change to make
> it more friendly?
$ git-ls-tree v1.0.0
100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile
I'm a newbie: what's that number at the front? What's a blob? What's that
great big number - I've only seen commit hashes that look like that, and that
isn't one. Definitely not friendly.
$ svn list -r 14
Makefile
It could probably be fixed by making git-ls-files capable of understanding
tree-ish.
> > - svn cleanup: git-fsck-objects, git-prune and git-repack all need too
> > specific knowledge of git.
> >
> > They also need running too often on the user's initiative. It would
> > be nice, for example, if git-reset, git-rebase and git-branch could
> > detect when a prune is going to be needed and give the user a hint.
>
> You don't want to prune every time these happen. When you start to
You are correct of course. They don't need running regularly, and in a way
that makes it worse. How is a user who isn't familiar with git internals
meant to know they should run git-prune? How are they meant to know when
they should run it? How are they meant to know that it is git-reset, et al,
that create conditions that need them to run git-prune?
> make use of the reflog pruning too often is a huge loss. I actually
> maybe prune my active repositories once every couple of months,
> the extra garbage hanging out is usually peanuts.
Personally I like my repository pruned fairly often. This makes it much
easier to find the commit I need to restore when I've accidentally done a
git-reset I didn't mean to. If I had to search through three months worth of
dead objects it would take me all day. However, I don't think that affects a
new user at all. Recovery from disasters should be expected to be hard.
> As to the former it depends on your OS (Windows you want to pack
> more often) but git-count-objects gives you a good indication of how
> many loose objects exist. git-fsck-objects probably only needs to
> be run if something is not working right and you suspect an object
> is missing.
Yep, /I/ know. How is my imaginary new user meant to know?
My rhetorical questions are the key to making git friendly I think. Each one
represents a hole - it's not that there is no answer, it's that there
shouldn't be a question. The hard part (as always I suppose) is that we have
to imagine a new user; this makes all my babblings above highly subjective.
As such I won't be that upset if I'm told to "blow it out my ear". Whatever
that means.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Performance problems in diffcore rename
From: Shawn Pearce @ 2006-12-14 9:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v7iwvatrt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > But looking at is_exact_match I'm now wondering why we bother
> > to open the working tree file at all here.
>
> You are right. When we _know_ both SHA-1 can be trusted, we
> should be able to do just this, regardless of contents_too
> (whose only purpose is to delay comparing a cache dirty working
> tree file with something else):
>
> diff --git a/diffcore-rename.c b/diffcore-rename.c
> index 57a74b6..677db85 100644
> --- a/diffcore-rename.c
> +++ b/diffcore-rename.c
> @@ -100,9 +100,8 @@ static int is_exact_match(struct diff_filespec *src,
> struct diff_filespec *dst,
> int contents_too)
> {
> - if (src->sha1_valid && dst->sha1_valid &&
> - !hashcmp(src->sha1, dst->sha1))
> - return 1;
> + if (src->sha1_valid && dst->sha1_valid)
> + return !hashcmp(src->sha1, dst->sha1);
> if (!contents_too)
> return 0;
> if (diff_populate_filespec(src, 1) || diff_populate_filespec(dst, 1))
>
OK, I've stared at this problem for hours. The above patch breaks
a number of test cases (such as ./t4005-diff-rename-2.sh) as it
causes the rename/copy detection to come out differently.
It turns out the difference is not filling in the size field of
struct diff_filespec. By bypassing that step in is_exact_match
during the second pass we are altering the outcome.
--
^ permalink raw reply
* Re: svn versus git
From: Andy Parkins @ 2006-12-14 9:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vfybjbbsx.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006 December 13 23:45, Junio C Hamano wrote:
> ls-tree is not Porcelain and has right to expose the internals
Of course; but there is no porcelain to do that operation.
> by default. "git ls-tree --name-only" could be aliased to give
> "git ls" if you wanted to, but I wonder how often you would want
> to run:
>
> svn list -r538
>
> and for what purpose?
I've never done it. However, the command is there in subversion, so I was
comparing git's implementation of that command. I wouldn't completely write
it off though. It doesn't seem unreasonable to want to see what files were
in an old revision.
> I often find myself doing
> git diff -r --name-status v1.3.0 HEAD
I can live with that as an acceptable alternative to "svn list"; however, as
usual, how does my imaginary ex-svn user find out about that? man git-diff
isn't the first place /I'd/ go; and even if you do, you won't find the "-r"
or "--name-status" options; you have to go to git-diff-files, git-diff-index
or git-diff-tree - and you're meant to guess which is the right one.
Bear in mind that my current theme isn't "can git do...?" it's "how does a
user know that git can do...?"
> What do people use "svn list -r538" for and how often? In other
> words, when does it become necessary to get the full list of
> paths in an arbitrary revision?
Me: I don't do it often. It's not something I'd lose sleep over if git
doesn't have an easy way of doing it. However, it was in the output
of "svn --help"; so I included it.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ 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