* 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: What's in git.git (stable)
From: Peter Baumann @ 2006-12-13 23:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vk60vbcfz.fsf@assigned-by-dhcp.cox.net>
>> * git-branch is not verbose enough when creating a new
>> branch, for a new user a little reassurance that what they
>> meant to happen has happened would be nice.
>
> The same comment applies here.
>
> However, perhaps you could make lack of "[user] expert = true"
> in ~/.gitconfig to trigger more verbose messages that say "yes
> sir I did what I was told to do".
>
> Not interested in implementing that myself at all, though.
>
>> Tell them if they
>> made a branch as well, which branch they are now on.
>
> I think you are talking about "checkout -b" not commit here;
> this might be a borderline (branch creation is less often done
> and it might warrant assuring feedback), but I think it still
> falls into the "doing exactly what it was told to do" category.
>
Yes. checkout -b works. But only _if_ you have read the manpage.
Someone thinking about branching at the current commit would just have
git branch
in mind (so would I). Its not obvious to say
git checkout -b <newbranchname> oldbranch
becouse checkout implies to advance to another version.
-Peter
^ permalink raw reply
* Re: StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Johannes Schindelin @ 2006-12-13 23:50 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <b0943d9e0612131409x4a894f72if9c4d44cfa970be@mail.gmail.com>
Hi,
On Wed, 13 Dec 2006, Catalin Marinas wrote:
> On 13/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 12 Dec 2006, Junio C Hamano wrote:
> >
> > > Although I would feel very happy about this change, Catalin
> > > might want to be informed about potential interaction this
> > > change might have with his commit 8d41555 in StGIT.
> >
> > Indeed. Catalin, do you have any suggestion how to proceed? Do you want to
> > introduce a check if the file exists prior to re-generating it? Or do you
> > need some version check?
>
> It currently checks whether the file exists and, if it doesn't, it is
> re-generated. I think the patch is good idea.
Thanks.
> > BTW why is StGit not on kernel.org?
>
> Why would it be? Unless you know who to talk to for this :-), it's not
> really a derivative of the Linux kernel.
There is plenty of stuff on kernel.org which is only related to the Linux
kernel. And StGit (even if I did not try it yet), seems to be very
valuable for working on the kernel.
> > Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
> > that machine? I am a happy user of the gitweb interface on that box...
>
> Hopefully, when I get a bit of time, I'll try to give up the
> http-hosted repository and use Pasky's one exclusively.
>
> 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.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Document the simple way of using of git-cat-file
From: Robin Rosenberg @ 2006-12-13 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <20061213221841.GB4928@fieldses.org>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Since you can give a version and a path name to git-cat-file,
mention it in the man page.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-cat-file.txt | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 5e9cbf8..7abbf27 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -8,13 +8,14 @@ git-cat-file - Provide content or type i
SYNOPSIS
--------
-'git-cat-file' [-t | -s | -e | -p | <type>] <object>
+'git-cat-file' [-t | -s | -e | -p | <type>] [<object> | <commit-ish>:<path> ]
DESCRIPTION
-----------
Provides content or type of objects in the repository. The type
is required unless '-t' or '-p' is used to find the object type,
-or '-s' is used to find the object size.
+or '-s' is used to find the object size. The more user friendly variant
+takes a revision and a path name corresponding to the blob you want to see.
OPTIONS
-------
@@ -57,6 +58,9 @@ If '-p' is specified, the contents of <o
Otherwise the raw (though uncompressed) contents of the <object> will
be returned.
+If you don't know the object id, you can supply a version identifies,
+such as a branch name, a commit id or tag followed by a colon and a
+path name.
Author
^ permalink raw reply related
* Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Johannes Schindelin @ 2006-12-13 23:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, git
In-Reply-To: <b0943d9e0612131401s6cde6d0du5e3c6d2e34bfbbb2@mail.gmail.com>
Hi,
On Wed, 13 Dec 2006, Catalin Marinas wrote:
> On 13/12/06, Junio C Hamano <junkio@cox.net> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Unify the handling for cases C (add/add) and D (modify/modify).
> > >
> > > On Tue, 12 Dec 2006, Junio C Hamano wrote:
> > >
> > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > >
> > > > > How about this: if there is an add/add conflict, we treat it
> > > > > as if there _was_ an empty file, and we let the shiny new
> > > > > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > > > > the file from the index, adding both files with different
> > > > > "~blabla" markers appended to their file names to the working
> > > > > directory.
>
> What is this new xdl_merge()? Is it a better replacement for diff3? In
> this situation diff3 would actually show two confict parts, each of them
> being the full file, with an empty ancestor.
xdl_merge(), as Git uses it, tries harder to find the true conflicts. So,
if the files actually differ in only one line, just this line will be
shown as conflict.
There is a flag passed to xdl_merge(), which tells it how hard it should
try to make sense of the conflict. We use the "zealous" option, which is
most accurate, but also slowest (although I have no numbers).
> > This fixes the behaviour in "both branches add the path
> > differently" case. Previously merge-recursive did not create
> > the working tree file, but now it does just like merge-resolve.
> >
> > Although I would feel very happy about this change, Catalin
> > might want to be informed about potential interaction this
> > change might have with his commit 8d41555 in StGIT.
>
> I don't think it affects StGIT. Previously, "git-read-tree -m" left a
> file in the tree in this conflict situation. When I switched to
> git-merge-recursive (to handle renames better), I noticed that the
> file was no longer there and my merge algorithm failed. It now checks
> whether the file is missing and it generates one.
Great!
Ciao,
Dscho
^ permalink raw reply
* Re: svn versus git
From: Junio C Hamano @ 2006-12-13 23:45 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612132200.41420.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> ... The output of git-ls-tree is not user friendly; it
> requires some understanding of git internals.
ls-tree is not Porcelain and has right to expose the internals
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 often find myself doing
git diff -r --name-status v1.3.0 HEAD
to check if a file was already in v1.3.0 version, and I could do
the same thing with
git list v1.3.0 >/var/tmp/1
git list HEAD >/var/tmp/2
diff -u /var/tmp/[12]
but that certainly is awkward.
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?
^ permalink raw reply
* Re: [PATCH] Allow subcommand.color and color.subcommand color configuration
From: Eric Wong @ 2006-12-13 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vodq7e90z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > While adding colour to the branch command it was pointed out that a
> > config option like "branch.color" conflicts with the pre-existing
> > "branch.something" namespace used for specifying default merge urls and
> > branches. The suggested solution was to flip the order of the
> > components to "color.branch", which I did for colourising branch.
> > ...
> > Unfortunately git-svn reads "diff.color" and "pager.color"; which I
> > don't like to change unilaterally.
>
> I think doing the same makes sense. Something like this?
It works great for me after I fixed some syntax errors (patch below).
> -- >8 --
> git-svn: allow both diff.color and color.diff
>
> The list concensus is to group color related configuration under
> "color.*" so let's be consistent.
>
> Inspired by Andy Parkins's patch to do the same for diff/log
> family.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net> (with the following
fixes of course :)
diff --git a/git-svn.perl b/git-svn.perl
index 2893e3b..73ab8d8 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -926,7 +926,7 @@ sub cmt_showable {
sub log_use_color {
return 1 if $_color;
my ($dc, $dcvar);
- $dcvar = 'color.diff'
+ $dcvar = 'color.diff';
$dc = `git-repo-config --get $dcvar`;
if ($dc eq '') {
# nothing at all; fallback to "diff.color"
@@ -948,7 +948,7 @@ sub log_use_color {
}
}
chomp($pc);
- if (-t *STDOUT || (defined $_pager && $pc eq 'true') {
+ if (-t *STDOUT || (defined $_pager && $pc eq 'true')) {
return ($ENV{TERM} && $ENV{TERM} ne 'dumb');
}
return 0;
--
^ permalink raw reply related
* Re: svn versus git
From: Peter Baumann @ 2006-12-13 23:32 UTC (permalink / raw)
To: git
In-Reply-To: <elpun9$qp1$1@sea.gmane.org>
[...]
>> svn revert::
>> Restore pristine working copy file (undo most local edits).
>> git reset --hard::
>> Reset the repository to an arbitrary point in the past, updating the
>> working copy as well.
>> git checkout -f HEAD <file>::
>> Checks out <file> from HEAD, forcing an overwrite of any working
>> directory changes to that file.
>>
>> Draw. There is no easy way to undo changes that have already been
>> committed to a subversion repository, so git would win. However, it's
>> uncomfortable to revert a single file using checkout.
>
> There was talk about adding "git reset [<commit-ish>] -- <file>".
>
I would appreciate this. The first thing which comes to my mind if I
have to actualy revert a change I made was
git reset file
After that didn't work I figured out I have to use the seperating -- and typed
git reset -- file
and that didn't work, too. After several hours (ok, I'am just
exaggerating, it took me only about 15 minutes) reading manpages I figured out
that I have to use git checkout [<revision>] -- file
After putting some thought into the mental model behind git checkout -- file
this command it looks obvious and understantable, but in _my_ mental modell
git reset [<revision] -- file
would be a much better fit.
-Peter
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-13 23:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612132237.10051.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> The major barrier to implementing these sorts of changes is, I
> think, worries about users of the output of these commands in
> scripts. I say: screw them, porcelain is there for the
> breaking :-)
I like that ;-).
Thanks for the list. I'll comment only on no brainers. Things
I cannot decide to agree or disagree are not mentioned in this
message.
> * git-fetch has to be in working root. If I can do git-push
> from anywhere in my tree, why can't I do git-fetch?
> * git-reset has to be in working root. If you typically sit
> in, say "src/", it's annoying to have to change directory to
> do a reset.
> * git-verify-tag would be nicer as a switch to git-tag
True and true and true; let's make them happen.
> * git-commit doesn't (generally) have output - after a
> commit, it's difficult to know if anything happened. Get
> users used to the idea of hashes to identify commits by
> telling them which one they just made.
I am moderately against making a command verbosely report when
it did exactly what it was told to do, _unless_ the command is
expected to take longer than other commands in git suite, or it
is something the user rarely runs.
> * git-branch is not verbose enough when creating a new
> branch, for a new user a little reassurance that what they
> meant to happen has happened would be nice.
The same comment applies here.
However, perhaps you could make lack of "[user] expert = true"
in ~/.gitconfig to trigger more verbose messages that say "yes
sir I did what I was told to do".
Not interested in implementing that myself at all, though.
> Tell them if they
> made a branch as well, which branch they are now on.
I think you are talking about "checkout -b" not commit here;
this might be a borderline (branch creation is less often done
and it might warrant assuring feedback), but I think it still
falls into the "doing exactly what it was told to do" category.
> * git-init-db says "defaulting to local storage area", as if that is
> meant to be a helpful message
It probably used to be back when the original tutorial Linus
wrote was still called tutorial.txt; but I agree that the
message is not helpful anymore.
> * git-merge output is horrible - this affects git-pull,
> git-rebase, and git-cherry-pick. Issuing "fatal" errors and
> then carrying on is very confusing. Errors in merges appear
> multiple times. The files upon which which there is a
> conflict are spread throughout the output. Most of the
> output is not relevant to an average user.
Yes.
> * git-apply output is horrible. It says a few things about
> whitespace on stdin then just finishes. When it succeeds.
> When it fails, it just says failed, it doesn't say why a
> particular hunk failed.
No. It either says patch is corrupt, or a hunk at this line
does not apply. I do not see what more would you would want to
ask it to say.
> * git-commit without "-a" and without an "update-index" says "nothing
> to commit", which isn't an adequate message to help a user who hasn't
> realised they need to update the index
Perhaps.
"\n(hint: 'git add' to stage your changes, or 'git commit --all')\n"
in wt-status.c under "[user] expert = false" mode?
> * git-rebase --skip requires that the offending file be clean with
> git-checkout HEAD file
> before the skip will work. Why? The fact of the skip is enough
> knowledge for rebase to know that I don't care if the merge is lost
As long as your solution does not accidentally lose local,
unrelated changes, changing "git-rebase --skip" to do the needed
clean-up itself for the user would be Ok (I think we would want
to loosen the requirement for starting in a totally clean
working tree in the future).
> * git-rebase/git-cherry-pick/git-reset/etc should all tell
> the user that they need to run git-prune to tidy up after
> themselves.
While I agree the users need to be taught about 'prune', I do
think immediately after running the above commands is exactly
the wrong point to run 'prune'. 'prune' should not be run while
you are busily munging the tip of the branch with rebase and
reset to come up with something that you can call "oh, I am done
with this series for now." Otherwise even lost-found would not
be able to help you.
Also, this sequence creates crufts that need to be pruned:
edit hello.c
git add hello.c
edit hello.c
git add hello.c
I do not think we would want to suggest 'git prune' upon every
'git add'.
> * 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.
> * 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.
> * In general the principle for messages should be the same as for
> presentations:
> - say what you're going to do
> - do it
> - say what you did
> So for example, "git-branch newbranch existingbranch" would say
> Branching at "existingbranch", hash XXXXXXXXXXXXXXXXXX
> - created branch "newbranch"
> - your working branch is "existingbranch"
> Rather than the nothing that it currently outputs.
In general the principle ought to be not to say anything if the
command does exactly what it was told to do successfully, unless
the operation is expected to take longer than other normal
commands in the git suite, or something that is rarely used.
Perhaps under "[user] expert" control.
^ permalink raw reply
* Re: StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Robin Rosenberg @ 2006-12-13 23:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Johannes Schindelin, Junio C Hamano, git, Petr Baudis
In-Reply-To: <b0943d9e0612131409x4a894f72if9c4d44cfa970be@mail.gmail.com>
onsdag 13 december 2006 23:09 skrev Catalin Marinas:
> 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.
If you also remove all other files, people will notice.
^ permalink raw reply
* Re: svn versus git
From: Shawn Pearce @ 2006-12-13 23:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elq1ig$4ie$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> 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.
>
> Actually, tab completion allows to complete both $REV and $file part.
Good point. Unless $REV is a SHA1 in hex format, as tab completion
for commits in hex SHA1 isn't supported.
Though I have thought about implementing it. ;-)
--
^ permalink raw reply
* Re: changing log entries
From: Jakub Narebski @ 2006-12-13 23:22 UTC (permalink / raw)
To: git
In-Reply-To: <1166051281.1808.1.camel@jcm.boston.redhat.com>
Jon Masters wrote:
> Anyway, now I would like to change an existing log entry to make it a
> bit cleaner (read: add a first line that's under 80 characters). What's
> the best way to change an existing log entry for a commit?
See top two answers in http://git.or.cz/gitwiki/GitTips
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: changing log entries
From: Shawn Pearce @ 2006-12-13 23:24 UTC (permalink / raw)
To: Jon Masters; +Cc: git
In-Reply-To: <1166051281.1808.1.camel@jcm.boston.redhat.com>
Jon Masters <jcm@redhat.com> wrote:
> Hi,
>
> So I figured out that the problem with "Can't lock ref" was down to not
> having set one of the scripts executable on the http server. Great.
>
> Anyway, now I would like to change an existing log entry to make it a
> bit cleaner (read: add a first line that's under 80 characters). What's
> the best way to change an existing log entry for a commit?
If its the most recent commit on that branch, "git commit --amend".
Otherwise dump out the branch to patches with git format-patch,
amend the commit in question, then replay the patches with git am.
Or use StGIT to uncommit the changes, pop them off, fix the commit,
then repush the patches and recommit in StGIT.
Note that any of the above methods change the SHA1 of that commit
and every commit which follows it on that branch. Consequently it
is generally considered to be impolite to edit commits without
warning which you have already published, as another person may be
basing their own work off that commit.
--
^ permalink raw reply
* Re: svn versus git
From: Robin Rosenberg @ 2006-12-13 23:24 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612132200.41420.andyparkins@gmail.com>
onsdag 13 december 2006 23:00 skrev Andy Parkins:
[...]
> svn checkout::
> Checkout a working copy from a repository. You may check out an
> arbitrary revision.
> git clone::
> git checkout::
> Git, of course, is different from subversion, as the whole repository is
> always available. git-checkout is nearest in concept to svn-checkout
> though. It changes the current working directory to a particular
> branch. You may not checkout an arbitrary revision. git-clone might
> also be considered as an svn checkout analog. However,
>
> Subversion wins. The output from Subversion's checkout is clear. The
> output from git-clone gives output that is only understandable by
> someone familiar with git internals.
I'd say svn clone is the nearest equivalent as it does the initial fetch of
data, no checkout is necessary after clone. it checks out master. Then
you git-checkout to switch branch, which corresponds to svn switch.
> svn commit::
> Pushes changes to the upstream respository from your working copy.
> git commit -a::
> Saves changes to the working copy as a new revision in the local
> repository.
>
> The need for "-a" (or not) because of git's staging area (the index)
> here makes it more confusing than svn-commit for new users. However,
> the ability to do "git --amend" more than makes up for it. Fixing a
> typo in your last log message is difficult in subversion. Also, git's
> commit message template is much better: both uses the output of their
> status commands which is far clearer in git than in Subversion.
>
> Git wins.
You'll need to push too in order to get a copy in a central repository.
git-commit stays locally, and you need a place to push to. If your SVN
repo isn't local this does not apply. git gives more freedom here.
> svn copy::
> Duplicate something in working copy or repository, remembering history.
> cp A B; git add B::
> Git doesn't have a direct equivalent of svn copy. It's arguable whether
> it needs it once the user knows they can git-add so easily.
>
> Git wins. Git's ability to detect copies after-the-fact, mean that a
> git-copy isn't necessary.
svn copy is more like git checout -b, i.e. it's primary purpose is not
to "copy" things, it is to create branches. You generally do not copy
code (I hope).
> svn move::
> Move and/or rename something in working copy or repository.
> git-mv::
> Move or rename a file, directory or symlink.
>
> Git wins. The two are equivalent except that git can do multiple moves
> in one command, just like normal "mv". So "git mv src/* newsrc/" works
> while "svn mv src/* newsrc/" doesn't. Additionally, if you forget to do
> moves with git and instead use the command line, you can easily use
> "update-index" to tell git about the move after the fact. In subversion
> you have to undo all the moves and do them again with subversion. This
> makes it inconvenient to use tools like "rename" to do regexp moves.
In svn this also renames a branch.
> svn switch::
> Update the working copy to a different URL.
> [no git equivalent]::
> git is distributed and can fetch from any number of remote repositories.
> The URL can be typed on the command line of git-fetch, or can be given a
> shortcut as a "remote". If we're talking about a single repository
> (which we have to to compare against subversion), the repository is
> local anyway.
>
> Git wins. Command is unnecessary.
svn switch corresponds to git-checkout. I don't think you can change the URL
unless the new URL actually points to the same repository.
> Discussion
> ----------
[...]
> - svn revert: it's not easy to revert a single file in git; especially
> once we bring the index into play. Restoring a single file in the index
> to HEAD while leaving the rest of the index AND the working directory
> untouched requires something like
> ----------------------------------------------------
> git-ls-tree file | git-update-index --index-info
> ----------------------------------------------------
> Which isn't simple enough for a typical user.
Typically the user want to restore the index AND the working directory.
Comparing typical workflows is more interesting than finding exact
equivalents.
^ permalink raw reply
* Re: svn versus git
From: Jakub Narebski @ 2006-12-13 23:17 UTC (permalink / raw)
To: git
In-Reply-To: <20061213225627.GC32568@spearce.org>
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.
Actually, tab completion allows to complete both $REV and $file part.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Shawn Pearce @ 2006-12-13 23:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elq1c8$37d$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Andy Parkins wrote:
>
> >> Hmmm... I thought that some progress indicator of download/upload was
> >> added... guess I was wrong.
> >
> > You're not wrong, there is a progress indicator, but it's measured
> > in "objects" not megabytes. It's got a percentage as well. Neither of these
> > things is a whole lot of use if I want to know how much data (in megabytes)
> > has been transferred, how much is there left to go and how long is it going
> > to take.
>
> No, what you see is if I understand correctly progress indicator for
> local and remote generating pack to send / exploding pack into loose
> objects (or not). There was some patch to add download/upload progress
> indicator, but I guess it was not applied.
There is one that gets started when the transfer is taking a while,
but it shows the total number of MiB transferred and the current
transfer rate. I don't think there's a way to tell when it will be
done, just that its running and running slower than you might like.
:-)
Part of the problem is the remote end doesn't know how many bytes
are needed for the pack its sending until after it has finished
sending the pack. Sort of a catch-22.
--
^ permalink raw reply
* changing log entries
From: Jon Masters @ 2006-12-13 23:08 UTC (permalink / raw)
To: git
Hi,
So I figured out that the problem with "Can't lock ref" was down to not
having set one of the scripts executable on the http server. Great.
Anyway, now I would like to change an existing log entry to make it a
bit cleaner (read: add a first line that's under 80 characters). What's
the best way to change an existing log entry for a commit?
Jon.
^ permalink raw reply
* Re: svn versus git
From: Jakub Narebski @ 2006-12-13 23:14 UTC (permalink / raw)
To: git
In-Reply-To: <200612132251.17202.andyparkins@gmail.com>
Andy Parkins wrote:
>> Hmmm... I thought that some progress indicator of download/upload was
>> added... guess I was wrong.
>
> You're not wrong, there is a progress indicator, but it's measured
> in "objects" not megabytes. It's got a percentage as well. Neither of these
> things is a whole lot of use if I want to know how much data (in megabytes)
> has been transferred, how much is there left to go and how long is it going
> to take.
No, what you see is if I understand correctly progress indicator for
local and remote generating pack to send / exploding pack into loose
objects (or not). There was some patch to add download/upload progress
indicator, but I guess it was not applied.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Shawn Pearce @ 2006-12-13 22:56 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612132200.41420.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> svn cat::
> Output the contents of specified files or URLs. Optionally at a
> specific revision.
> git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::
better:
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.
> Subversion wins. This is a distinctly non-user friendly way of reading
> a file.
Documentation flaw that the above wasn't clear? Or is "-file" and
"-p" the losing part for Git?
> 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.
Git's fsck-objects, prune and repack aren't usually needed until
the user has had a chance to use it for a while and accumulate a
number of loose objects.
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.
> svn merge::
> Apply the differences between two sources to a working copy path.
> git pull::
> Pull and merge from another repository or a local branch.
>
> It could be argued that "pull" is a bad name for this command. Apart
> from that however, git-pull is significantly easier to use than svn
> merge. It's output isn't as easy to understand, as it dumps loads of
> confusing information to the user.
or git merge now. :-)
> Git wins. Once you've used it, it's nowhere near as terrifying to use,
> because it can be easily undone. It's harder to do damage because git
> tracks merges whereas svn doesn't. It's better at merging. You will
> spend a good five minutes thinking about what you must type for an
> svn-merge. git-pull is a no-brainer.
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.
> svn mkdir::
> Create a new directory under version control.
> [no git equivalent]::
> Git doesn't track directories, so doesn't need this command. Simply
> adding content that is in a subdirectory is sufficient.
>
> Git wins. It does the right thing for you and you needn't remember to
> wrap your "mkdir"s with your VCS. Also, one-less-command.
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
all object files in a single directory which the build system
creates, as cleaning up is just "rm -rf output" (or whatever it is)
so I could care less about empty directory tracking; I think most
people are that way.
> - svn cat: the git equivalent is too complicated.
> It wouldn't be hard to write a git-cat; if git's aliases allowed
> pipes, it could be done instantly.
See above.
> - svn list: this only wins because the default output of git-ls-tree is
> so user unfriendly.
How is it unfriendly? What specifically would you change to make
it more friendly?
> - 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
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.
> As to git-repack and git-fsck-objects - when _should_ these be run?
> How is the user meant to know?
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.
--
^ permalink raw reply
* Re: [PATCH] Allow subcommand.color and color.subcommand color configuration
From: Andy Parkins @ 2006-12-13 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq7e90z.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006, December 13 22:16, Junio C Hamano wrote:
> I think doing the same makes sense. Something like this?
Perfect - yes that is the solution.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: svn versus git
From: Andy Parkins @ 2006-12-13 22:51 UTC (permalink / raw)
To: git
In-Reply-To: <elpun9$qp1$1@sea.gmane.org>
> You can use extended sha1 syntax, described in git-rev-parse(1) (although
> it would be nice to have relevant parts of documentation repeated in
> git-cat-file(1)), namely
> git cat-file -p REV:file
> (and you can use "git cat-file -p ::file" to get index/staging area
> version)
Yes; I didn't remember that one. However, it's still not friendly.
> git-fsck-objects is needed only if something doesn't work when
> it should. "git repack" is safe, "git repack -a -d" is almost safe,
> while "git prune" is not.
Yes - /I/ know that; bear in mind though that this is intended as a comparison
against subversion for a user who doesn't want to know how it works. How is
that sort of user meant to know when they should run each of these commands?
Git doesn't tell them, it doesn't even give hints. As you say, "git-prune"
is not necessarilly safe - how does a new user know that? It's in the output
of "git".
> Perhaps git-archive should support "tree" format, i.e. writing
> unversioned copy of a tree to filesystem.
I think git is pretty good in the archive department. git-archive does
exactly what it says on the tin, which is exactly what you would want.
> There was discussion about adding thin wrapper around git-update-index
> to specifically mark resolved merge conflicts. The option to pick up
> ours, theirs, ancestor version is another argument for having such command.
I think it's definitely a good idea. If you introduce git-update-index as a
command a normal user will type, you've got a lot of explaining to do as to
what else it does and why it does it.
> It can be done without pipes: "git cat-file -p REV:file".
> You can use aliases to have shorter name for that.
This is the problem though. I realise that git can technically do an awful
lot of these things, how many new users are going to stick around when you
tell them that they have to learn about the config file and aliases before
they can use the command they want?
> Hmmm... I thought that some progress indicator of download/upload was
> added... guess I was wrong.
You're not wrong, there is a progress indicator, but it's measured
in "objects" not megabytes. It's got a percentage as well. Neither of these
things is a whole lot of use if I want to know how much data (in megabytes)
has been transferred, how much is there left to go and how long is it going
to take.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-13 22:48 UTC (permalink / raw)
To: git
In-Reply-To: <200612132237.10051.andyparkins@gmail.com>
Andy Parkins wrote:
> This is what I have in my "niggles" list. These are surface level things that
> I think are easy to fix. A large part of the scariness is (I think) git's
> unfriendly output. Too many messages require understanding of git internals.
Nice list, although I'd rather add extra output only if command is used
with -v/--verbose (or -V/--verbose) option; if not, then add -q/--quiet
(or -s/--silent) option to be used in scripts. I'm partial to --verbose
solution, as advanced users are not interested in any output; they know
the commands, and want them to be fast. C.f GNU tar: it outputs something
only with -v/--verbose option.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andy Parkins @ 2006-12-13 22:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v4przfpir.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:
> I am hoping that we can start a stabilization cycle for v1.5.0
> based on what we have in 'master'. The theme is "usability and
> teachability".
This is what I have in my "niggles" list. These are surface level things that
I think are easy to fix. A large part of the scariness is (I think) git's
unfriendly output. Too many messages require understanding of git internals.
The major barrier to implementing these sorts of changes is, I think, worries
about users of the output of these commands in scripts. I say: screw them,
porcelain is there for the breaking :-)
* git-fetch has to be in working root. If I can do git-push from anywhere in
my tree, why can't I do git-fetch?
* git-reset has to be in working root. If you typically sit in, say "src/",
it's annoying to have to change directory to do a reset.
* git-commit doesn't (generally) have output - after a commit, it's difficult
to know if anything happened. Get users used to the idea of hashes to
identify commits by telling them which one they just made. Tell them if
they made a branch as well, which branch they are now on.
* git-init-db says "defaulting to local storage area", as if that is
meant to be a helpful message
* 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.
* git-merge output is horrible - this affects git-pull, git-rebase,
and git-cherry-pick. Issuing "fatal" errors and then carrying on is very
confusing. Errors in merges appear multiple times. The files upon which
which there is a conflict are spread throughout the output. Most of the
output is not relevant to an average user.
* git-apply output is horrible. It says a few things about whitespace on
stdin then just finishes. When it succeeds. When it fails, it just says
failed, it doesn't say why a particular hunk failed.
* git-branch is not verbose enough when creating a new branch, for a new user
a little reassurance that what they meant to happen has happened would be
nice.
* git-commit without "-a" and without an "update-index" says "nothing
to commit", which isn't an adequate message to help a user who hasn't
realised they need to update the index
* git-rebase --skip requires that the offending file be clean with
git-checkout HEAD file
before the skip will work. Why? The fact of the skip is enough
knowledge for rebase to know that I don't care if the merge is lost
* git-rebase/git-cherry-pick/git-reset/etc should all tell the user that they
need to run git-prune to tidy up after themselves.
* git-add has no output, whether it works or not
* git-cat-file is badly named. git-cat-object would be slightly
better.
* 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?
* Similar things can be said about git-clone
* Similar things can be said about git-push
* git-show-branch output is cryptic.
* In general the principle for messages should be the same as for
presentations:
- say what you're going to do
- do it
- say what you did
So for example, "git-branch newbranch existingbranch" would say
Branching at "existingbranch", hash XXXXXXXXXXXXXXXXXX
- created branch "newbranch"
- your working branch is "existingbranch"
Rather than the nothing that it currently outputs.
* It would be really nice to be able to do an arbitrary checkout, rather than
having to make a branch for it. Then I could do
git-checkout remotes/origin/master && make
(obviously committing with a non-branch HEAD would be prevented)
* git-verify-tag would be nicer as a switch to git-tag
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: svn versus git
From: Jakub Narebski @ 2006-12-13 22:29 UTC (permalink / raw)
To: git
In-Reply-To: <200612132200.41420.andyparkins@gmail.com>
By the way, it would be nice to have this discussion added to GitWiki:
http://git.or.cz/gitwiki/GitSvnComparsion
Andy Parkins wrote:
> svn cat::
> Output the contents of specified files or URLs. Optionally at a
> specific revision.
> git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::
> git-ls-tree lists the object ID for $file in revision $REV, this is cut
> out of the output and used as an argument to git-cat-file, which should
> really be called git-cat-object, and simply dumps that object to stdout.
You can use extended sha1 syntax, described in git-rev-parse(1) (although
it would be nice to have relevant parts of documentation repeated in
git-cat-file(1)), namely
git cat-file -p REV:file
(and you can use "git cat-file -p ::file" to get index/staging area
version)
As for alias: what about "alias.less = --paginate cat-file -p",
set using "git repo-config alias.less '--paginate cat-file -p'"?
> svn cleanup::
> Recursively clean up the working copy, removing locks, resuming
> unfinished operations, etc.
> git fsck-objects::
> git prune::
> git repack::
> Check the repository for consistency, remove unreferenced objects, or
> recompress existing objects.
>
> They don't really serve the exact same purpose, but they are all
> maintenance commands.
>
> Subversion wins, as it only has one command and you don't need to
> understand the repository in order to understand what its doing.
git-fsck-objects is needed only if something doesn't work when
it should. "git repack" is safe, "git repack -a -d" is almost safe,
while "git prune" is not.
> svn export::
> Create an unversioned copy of a tree.
> git archive::
> Creates an archive of the files in the named tree.
>
> Git wins. It can make zip/tar directly and add directory prefixes
> should you want them. It could perhaps be a modicum easier if it had a
> default output format so that "git-archive HEAD" would do something.
Perhaps git-archive should support "tree" format, i.e. writing
unversioned copy of a tree to filesystem.
> svn resolved::
> Remove 'conflicted' state on working copy files or directories.
> git update-index::
> git checkout::
> Git doesn't have a direct "resolved"; after you fix conflicts, you push
> the changes into the staging area with "git-update-index".
> Alternatively you can simply accept the version in HEAD by checking out
> that version.
>
> Draw. "svn-resolved" is rubbish, as it doesn't do any checks, it just
> removes the conflict markers. Git could do with something that makes
> life easier than understanding the index.
There was discussion about adding thin wrapper around git-update-index
to specifically mark resolved merge conflicts. The option to pick up
ours, theirs, ancestor version is another argument for having such command.
> svn revert::
> Restore pristine working copy file (undo most local edits).
> git reset --hard::
> Reset the repository to an arbitrary point in the past, updating the
> working copy as well.
> git checkout -f HEAD <file>::
> Checks out <file> from HEAD, forcing an overwrite of any working
> directory changes to that file.
>
> Draw. There is no easy way to undo changes that have already been
> committed to a subversion repository, so git would win. However, it's
> uncomfortable to revert a single file using checkout.
There was talk about adding "git reset [<commit-ish>] -- <file>".
> Discussion
> ----------
>
> What would git need to do to win in every section?
>
> Subversion won:
> - svn cat: the git equivalent is too complicated.
> It wouldn't be hard to write a git-cat; if git's aliases allowed
> pipes, it could be done instantly.
It can be done without pipes: "git cat-file -p REV:file".
You can use aliases to have shorter name for that.
> - svn checkout: the output from git-clone is unfriendly.
> -------------------
> remote: Generating pack...
> remote: Done counting 6 objects.
> remote: Deltifying 6 objects.
> remote: 100% (6/6) done
> Indexing 6 objects.
> remote: Total 6, written 6 (delta 0), reused 0 (delta 0)
> 100% (6/6) done
> -------------------
> What are "objects"? What is deltifying? Why does object count
> matter to me? What is indexing? How much data was transferred? How
> long did it take? How big is my local clone?
>
> While transferring: how long is it going to take to finish? How much
> data is there to transfer in total?
Hmmm... I thought that some progress indicator of download/upload was
added... guess I was wrong.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Junio C Hamano @ 2006-12-13 22:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Johannes Schindelin, git
In-Reply-To: <b0943d9e0612131401s6cde6d0du5e3c6d2e34bfbbb2@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 13/12/06, Junio C Hamano <junkio@cox.net> wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
> What is this new xdl_merge()? Is it a better replacement for diff3? In
> this situation diff3 would actually show two confict parts, each of
> them being the full file, with an empty ancestor.
The calls to xdl_merge() from merge-recursive replace
invocations to external "merge" from RCS suite.
An older merge-recursive had a bug (as you noticed and adjusted
StGIT with the commit 8d41555) in that it did not leave anything
in the working tree in add/add situation, while merge-resolve
would have left its best attempt of ancestor-less two file merge
(which is not necessarily the straight diff3 "no common section,
full copies from both" result). The change in question corrects
that problem and merge-recursive would create a file in the
working tree just like merge-resolve would.
You were CC'ed just in case this change in behaviour might
interact with the abovementioned change in StGIT, but as you say
the change would not break StGIT, we would all be happy ;-).
^ 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