* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 14:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612141205490.18171@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 14 Dec 2006, Shawn Pearce wrote:
>
>> But I'm not sure that git-add should output anything. Last I checked
>> the 'mv' command in Linux doesn't say "Move 5 files" when I move 5
>> files into a directory. Likewise I don't think that knowing that
>> 6781 files were added is useful, what if it should have really been
>> 6782 files? I'm unlikely to know, care, or realize it.
>
> git-add -v does output added files already.
Ha! Now only get it to accept --verbose as long alternative to -v option,
and add -v/--verbose option to other similar commands (git-mv for example).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 14:39 UTC (permalink / raw)
To: git
In-Reply-To: <45810B49.2000706@op5.se>
Andreas Ericsson wrote:
> 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.
This is not an error, just a warning. Sometimes user want's to add a file
which is otherwise ignored (e.g. due to glob), sometimes user adds ignored
file by mistake.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Provide more meaningful output from 'git init-db'.
From: Shawn Pearce @ 2006-12-15 14:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eluaf0$v7q$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
>
> > So now we print out what we did ("Initialized empty" or
> > "Reinitialized existing"), what type of repository ("" or "shared"),
> > and what location the repository will be in ("$GIT_DIR").
>
> > ----------------
> > -defaulting to local storage area
> > +Initialized empty Git repository in .git/
> > ----------------
>
> > + printf("%s%s Git repository in %s/\n",
-------------------------------------^^^^
> It seems like this lack this " in " part you have mentioned in
> commit message and in tutorial.
Uh, no it doesn't. See above.
--
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Shawn Pearce @ 2006-12-15 15:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Carl Worth, git
In-Reply-To: <eluasq$v7q$3@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Carl Worth wrote:
>
> > On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote:
>
> >> * gitweb made it appear as though a whole lot of Carl's recent
> >> work was somehow undone in the merge.
> >
> > That looks like a simple gitweb bug. None of the other tools, (gitk,
> > git log -p), consider a trivial merge commit like this as having
> > anything interesting in it worth displaying.
>
> It's not a bug, it is rather lack of feature (or misfeature).
Its a bug.
I'm not a gitweb user (meaning I almost never look at something
in gitweb). But I'm clearly also not a Git newbie. ;-)
I could not fathom why that merge commit was being displayed that
way in gitweb. I had to clone the cairo project just so I could
actually look at the commit with log/show/whatchanged/diff-tree,
because I couldn't believe what I was seeing from gitweb.
--
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Shawn Pearce @ 2006-12-15 15:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eltr9v$b4q$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
>
> > +# Define NO_FAST_WORKING_DIRECTORY if accessing objects in pack files is
> > +# generally faster on your platform than accessing the working directory.
> > +#
>
> Hmmm... I wonder if generated by autoconf ./configure script can autodetect
> that. Probably not.
I think it would be difficult to perform an automatic performance
test prior to building Git to determine how we should build Git on
the current platform. Besides, Cygwin users tend to not use the
./configure script as it takes longer than just using the Makefile.
AFAIK the only "OS" which suffers from this problem is Windows.
Anything else that Git has been ported too has reasonably fast
syscalls for file IO, which means this should be unset.
--
^ permalink raw reply
* Re: [PATCH 1/2] Suggest use of 'git add' when 'nothing to commit' gets shown.
From: Shawn Pearce @ 2006-12-15 15:06 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, Andy Parkins
In-Reply-To: <458266D4.5050301@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn O. Pearce wrote:
> > else
> > if [ -z "$(git-ls-files)" ]; then
> >- echo >&2 Nothing to commit
> >+ echo >&2 "Nothing to commit (use \"git add\" include for
> >commit)"
>
> s/git add include/git add to include/
Thanks! I'm going to rewrite this patch series as I clearly fumbled
a few items, which you were kind enough to take the time to point
out for me.
> It would probably be nice to use one and the same message everywhere though.
That was my intent. My fingers failed me somehow. ;-)
--
^ permalink raw reply
* Re: git-cvsimport feature request
From: Nguyen Thai Ngoc Duy @ 2006-12-15 15:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612122305060.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On 12/13/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On 12/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > It could be done easily, but it is almost as easy to edit the command line
> > > to substitute "git " with "git repo-config alias.cvsup '" (note the
> > > single apostrophe at the end) and append and apostrophe at the end of the
> > > line.
> >
> > Thanks. I know that (and am doing that). Just think that it may be
> > more convenient typing the command once.
>
> Something like this?
It works great. Thanks.
--
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Shawn Pearce @ 2006-12-15 15:09 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
In-Reply-To: <45825E0B.5010200@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn Pearce wrote:
> >Nicolas Pitre <nico@cam.org> wrote:
> >>It is nicer to let the user know when a commit succeeded all the time,
> >>not only the first time. Also the commit sha1 is much more useful than
> >>the tree sha1 in this case.
> >
> >I agree the commit sha1 is more useful than the tree sha1, but I'm
> >not really sure its useful to show the commit sha1 post commit.
> >If you want to show something the diffstat like what git merge does
> >is better.
> >
>
> diffstats can be huge though. I'd rather have those only with -v option.
But they are on by default for pull/merge, and disabled by -n.
They are on to tell you what you just got during the pull/merge.
If we want commit to confirm it did something successfully, I think
having it confirm what it committed by way of diffstat makes a lot
of sense.
Unfortunately -n is taken to mean --no-verify by git-commit, so
we probably cannot repurpose it to mean --no-summary, like it is
for merge/pull.
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <200612141136.59041.andyparkins@gmail.com>
Andy Parkins wrote:
By the way, could you use slightly smaller number of columns? TIA.
> On Thursday 2006 December 14 10:21, Junio C Hamano wrote:
>> But you never communicate with your own git repository using the
>> SHA-1 object names when talking about commits you made recently
>
> How's this then:
>
> $ git commit
> $ git commit
> $ git commit
> $ git reset HEAD^^^
>
> "AGGGHHHHHH! I meant HEAD^^"
>
> At this point I start running "git-prune -n | grep commit" and some liberal
> use of git-show to try and find the hash of the object so I can do
>
> $ git reset --hard HASH_OF_OBJECT_I_STUPIDLY_ORPHANED
That is what reflog is for. By the way, is core.logAllRefUpdates set
to "true" (or "heads") by default now?
Although I'm not against
$ git commit -v
Revision XXXXXXXXXXXXXXXXXX successfully added.
Notice -v/-verbose option.
>> So I do not think "git commit" is a valid example. I also agree
>> with Shawn that "git add" that says 6781 files were added is
>> pointless.
>
> Okay.
And git-add has -v option (although not --verbose).
>>> I've always thought that programs that needed an expert/beginner split
>>> were badly designed.
>>
>> There probably is a truth in that. Let's not add verbosity
>> unnecessarily.
>
> My habit is always to be overly verbose in program output; however, I realise
> that not everybody likes that. None of these things cause me any difficulty
> in my use of git. However, my Dad also is an engineer, but he's not so
> comfortable with VCS; for him almost every part of git is a mystery.
> Commands that run and don't say anything are confusing because he didn't
> really know what they were /meant/ to do; he's just got a set of recipes that
> he knows to type. He's probably an extreme case, and not a good model for
> typical user - on the other hand, I would say that if he can use it, then it
> is officially newbie-friendly. :-)
It would be nice to have some generic place in git config to specify
default options to git commands (at least for interactive shell). It
cannot be done using aliases. Perhaps defaults.<command> config variable?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Horst H. von Brand @ 2006-12-15 15:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elu0n5$u0i$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Andy Parkins wrote:
>
> > 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.
>
> $ git repo-config alias.less "-p cat-file -p"
> $ git repo-config alias.cat "cat-file -p"
>
> remedies that.
>
> [...]
> >> 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.
> The number in front is octal mode of a file or directory. "blob"
> is a file (or symbolic link), "tree" is a directory, all of this
> can be found in git(7).
I don't want to come through as rude, but that you can find the explanation
somewhere (and as an old(ish) Unix/git hand you know (or should be able to
guess easily) what it means) doesn't help the _newbie_ confronted with this
gibberish one iota. Explaining it it the git list also doesn't help. Either
make it self-explanatory, relegate this command to git-plumbing or axe its
output (perhaps show this only with --verbose or such, with Unix you get
fast to the point where you know --verbose is probably totally mistifying
except for /real/ experts :-).
[...]
> Perhaps we should add git-ls which would be porcelain frontend
> to git-ls-files and git-ls-tree, just like git-diff is frontend
> to git-diff-files, git-diff-index and git-diff-tree (and also does
> pure blob diff).
That is a more newbie-friendly answer.
--
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
^ permalink raw reply
* Re: svn versus git
From: Nguyen Thai Ngoc Duy @ 2006-12-15 15:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612150118190.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On 12/15/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
>
> > On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > > - have you seen the patch for git-show today, which would include this
> > > > > functionality?
> > > >
> > > > I didn't. From the patch, it seems git-show can show the index via
> > > > ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
> > > > not intuitive though. Perhaps you should mention that it can show
> > > > index (and how) in the git-show document
> > >
> > > Well, you can reference blobs that way, but not trees.
> >
> > Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?
> > git-show --index will show the index. git-show --index file will show
> > the file content. This makes git-show a little unconsistent though as
> > it may or may not require argument <object>.
> >
> > Another option is treat '::' alone specially -- call git-ls-files.
>
> Hmm. I don't know... It would make the code rather messy. And are you
> really interested in the content stored in the index? In all cases I can
> think of, you are better off with a diff vs. working directory or ref.
When I worked with index the first time, I had difficulty knowing what
was in index. Index is, unlike working directory, intangible. I could
use git-diff (and actually did), but it was still better if I could
have seen what exactly was in index.
To me, index and object database are (to some extent) the same: both
are used to store files. If I can examine git object database, why not
index?
About adding index support to git-show, yes it's really messy. index
doesn't have tree objects. If a user wants to list a subdirectory in
index, git-show will have to do more work, I think. Perhaps we should
forget this for now.
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Nicolas Pitre @ 2006-12-15 15:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eluemi$gc0$1@sea.gmane.org>
On Fri, 15 Dec 2006, Jakub Narebski wrote:
> It would be nice to have some generic place in git config to specify
> default options to git commands (at least for interactive shell). It
> cannot be done using aliases. Perhaps defaults.<command> config variable?
I would say the alias facility has to be fixed then.
In bash you can alias "ls" to "ls -l" and it just works.
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Andreas Ericsson @ 2006-12-15 15:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20061215150909.GE17860@spearce.org>
Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn Pearce wrote:
>>> Nicolas Pitre <nico@cam.org> wrote:
>>>> It is nicer to let the user know when a commit succeeded all the time,
>>>> not only the first time. Also the commit sha1 is much more useful than
>>>> the tree sha1 in this case.
>>> I agree the commit sha1 is more useful than the tree sha1, but I'm
>>> not really sure its useful to show the commit sha1 post commit.
>>> If you want to show something the diffstat like what git merge does
>>> is better.
>>>
>> diffstats can be huge though. I'd rather have those only with -v option.
>
> But they are on by default for pull/merge, and disabled by -n.
>
Yes, but it makes sense for merges where you generally pull someone
elses work or one of your topic branches because it gives a general feel
for the amount of modifications and are a sort of conclusion. Commits
are a different thing, because you should know what kind of changes
you've just done. If you don't you have other problems. I for one run
git diff quite frequently when I'm getting close to a commit to make
sure I don't get only the changes I want. I imagine others do too, so
getting a diffstat when issuing the actual commit would just be noisy
and irritating.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 15:38 UTC (permalink / raw)
To: git
In-Reply-To: <200612142250.27766.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2006, December 14 21:58, Junio C Hamano wrote:
>
>> Correct but a bad example that does not demonstrate the real
>> power of reflog. Andy's AGGGHHHHHH can be recovered with a
>> simple:
>>
>> $ git reset ORIG_HEAD
>
> HAHA! I knew reading this mailing list would pay off.
>
> It amazes me that there is always an answer. It's almost becoming a
> pantomime - I say "well git can't do this", and you say "oh yes it can".
And it is mentioned in git-reset(1), although:
* it would be nice to have example with ORIG_HEAD about how
to recover from bad (wrong) git reset in EXAMPLES section.
* it would be nice to mention that the first example can
be now done with simply "edit; git commit -a --amend"
instead of "git reset --soft HEAD^; edit; git commit -a -c ORIG_HEAD"
(which can fail for merges).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Shawn Pearce @ 2006-12-15 15:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
In-Reply-To: <4582C022.3030706@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Yes, but it makes sense for merges where you generally pull someone
> elses work or one of your topic branches because it gives a general feel
> for the amount of modifications and are a sort of conclusion. Commits
> are a different thing, because you should know what kind of changes
> you've just done. If you don't you have other problems. I for one run
> git diff quite frequently when I'm getting close to a commit to make
> sure I don't get only the changes I want. I imagine others do too, so
> getting a diffstat when issuing the actual commit would just be noisy
> and irritating.
I do the same (diff a lot before commit) and thus find commit
outputting anything at all to be noisy and irritating. Frankly
the new
git-diff-tree --summary --root --no-commit-id HEAD
that Junio put on the end is already irritating.
But it was added to help users verify that commit did what they
thought it would (see 61f5cb7f). By the same token sometimes users
accidentally commit files they didn't mean to, or forget to include
files they meant to include. Showing a diffstat would also be a
final sanity check for them.
--
^ permalink raw reply
* Re: svn versus git
From: Andreas Ericsson @ 2006-12-15 15:41 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Jakub Narebski, git
In-Reply-To: <200612151519.kBFFJSYn012227@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Andy Parkins wrote:
>>
>>> 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.
>> $ git repo-config alias.less "-p cat-file -p"
>> $ git repo-config alias.cat "cat-file -p"
>>
>> remedies that.
>>
>> [...]
>>>> 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.
>
>> The number in front is octal mode of a file or directory. "blob"
>> is a file (or symbolic link), "tree" is a directory, all of this
>> can be found in git(7).
>
> I don't want to come through as rude, but that you can find the explanation
> somewhere (and as an old(ish) Unix/git hand you know (or should be able to
> guess easily) what it means) doesn't help the _newbie_ confronted with this
> gibberish one iota.
I think it would help if we could write out things ls-style though and
I'm all for axing the SHA1 (I don't even think the SHA1 of specific
files of a tree can be *used* for anything), so the above would be
-rw-r--r-- Makefile
which most newbies should grok fairly quickly. Not least because it's
familiar, and we can even toss in the size in that string without taking
up too much screen real estate. If we try really hard to cater to people
who have never seen ls output we're gonna end up annoying the other side
of the camp so much that they'll walk away in disgust.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andreas Ericsson @ 2006-12-15 15:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0612151029080.18171@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
>> It would be nice to have some generic place in git config to specify
>> default options to git commands (at least for interactive shell). It
>> cannot be done using aliases. Perhaps defaults.<command> config variable?
>
> I would say the alias facility has to be fixed then.
>
> In bash you can alias "ls" to "ls -l" and it just works.
>
I think this is because git scripts that need a certain git command to
work a certain way don't want some alias to kick in and destroy things
for them. Shell-scripts would have the same problem if you alias "awk"
to "grep" f.e., which is why prudent shell-scripters use the "unalias
-a" thing.
Anyways, this should be largely solvable by inventing a "--no-aliases"
switch to the git wrapper, or by the scripts calling the programs they
need directly which, afaik, bypasses the alias logic. If it doesn't, it
should.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Andreas Ericsson @ 2006-12-15 15:50 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20061215154025.GF17860@spearce.org>
Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Yes, but it makes sense for merges where you generally pull someone
>> elses work or one of your topic branches because it gives a general feel
>> for the amount of modifications and are a sort of conclusion. Commits
>> are a different thing, because you should know what kind of changes
>> you've just done. If you don't you have other problems. I for one run
>> git diff quite frequently when I'm getting close to a commit to make
>> sure I don't get only the changes I want. I imagine others do too, so
>> getting a diffstat when issuing the actual commit would just be noisy
>> and irritating.
>
> I do the same (diff a lot before commit) and thus find commit
> outputting anything at all to be noisy and irritating. Frankly
> the new
>
I could live with one line (Committed revision %d), but a diffstat is
always 3 lines minimum, which might well turn out to be 2 lines more
than I changed. That's way too noisy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Jakub Narebski @ 2006-12-15 15:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Carl Worth, git
In-Reply-To: <20061215150130.GB17860@spearce.org>
Shawn Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Carl Worth wrote:
>>
>>> On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote:
>>
>>>> * gitweb made it appear as though a whole lot of Carl's recent
>>>> work was somehow undone in the merge.
>>>
>>> That looks like a simple gitweb bug. None of the other tools, (gitk,
>>> git log -p), consider a trivial merge commit like this as having
>>> anything interesting in it worth displaying.
>>
>> It's not a bug, it is rather lack of feature (or misfeature).
>
> Its a bug.
>
> I'm not a gitweb user (meaning I almost never look at something
> in gitweb). But I'm clearly also not a Git newbie. ;-)
>
> I could not fathom why that merge commit was being displayed that
> way in gitweb. I had to clone the cairo project just so I could
> actually look at the commit with log/show/whatchanged/diff-tree,
> because I couldn't believe what I was seeing from gitweb.
Do you mean "commit" view or "commitdiff" view in gitweb for merges
is confusing?
If it is "commit" view, it is fairly easy to remove difftree/whatchanged
output below commit message for merges. However while git-show nor
git-diff-tree doesn't show diff for merge messages, the diftree output
in "commit" view might be taken as 'damages'; git diff --summary always
takes summary of diff against first parent.
If it is "commitdiff" view... well, I plan on adding combined diff
output to commitdiff, but I need raw (whatchanged) output with the
same files which would be shown in git-diff --cc for merges (compact
combined diff output). Otherwise I'd have to use combined (-c) output
in gitweb, rather than more terse --cc output.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Nicolas Pitre @ 2006-12-15 16:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20061215150909.GE17860@spearce.org>
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > It is nicer to let the user know when a commit succeeded all the time,
> > not only the first time. Also the commit sha1 is much more useful than
> > the tree sha1 in this case.
>
> I agree the commit sha1 is more useful than the tree sha1, but I'm
> not really sure its useful to show the commit sha1 post commit.
It is useful, even if it is not essential.
Since I believe it is a good thing to display _something_ by default
(and not only with -v as suggested -- please see the reasoning I posted
yesterday as to what should have some output and what shouldn't), it
doesn't hurt to display the commit sha1 as well.
First it has the very desirable side effect of making the user slightly
aware of how git identifies things. From the first commit a new user
will notice that git doesn't use any incremental version number but a
unique identifier that has nothing to do with sequence. It is not
expected that people will start _using_ the information printed, but it
will at least give a feel of how git works. And it is not like if the
whole thing took multiple lines to be displayed.
Next it _might_ be used by people. The fact that it is there might turn
to be useful. It is useful in the context of Documentation/tutorial-2.txt
for one where the notion of objects and their relationship is explained
based on the least amount of steps possible.
So in short I do think there should be something shown after a
successful commit, and including the commit sha1 doesn't hurt.
> If you want to show something the diffstat like what git merge does
> is better.
>
> For one thing it confirms that git accepted the changes. For another
> it shows you *which* changes it accepted. Plus it responds just
> like git-merge or git-pull does.
I disagree. My patch does confirm that git accepted the change with
only one line. As to which changes were accepted I think that when you
do the commit you certainly have a pretty good idea already of what is
going to be committed (you modified/added/removed files yourself, and by
default git-commit provides you with a summary in the text editor for
the commit message).
On Fri, 15 Dec 2006, Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
> > diffstats can be huge though. I'd rather have those only with -v option.
>
> But they are on by default for pull/merge, and disabled by -n.
>
> They are on to tell you what you just got during the pull/merge.
The pull/merge case is different. You are most likely to not know in
advance what the overall changes will be. Of course you're supposed to
know what you're pulling, but unlikely to know about the detail since
what you merge is remote to your current working tree by definition, and
even if you happen to be the one who did the changes in the other
branch/repo, it is certainly not as fresh in your mind than the changes
you did prior a commit.
And it is true that diffstat can be quite large. I wouldn't mind the
diffstat to be added to the commit message summary in the text editor
though. And displaying it when -v is used makes also a lot of sense.
But not by default please.
^ permalink raw reply
* Re: [RFC] requiring Perl SVN libraries for git-svn
From: Seth Falcon @ 2006-12-15 16:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061213202142.GE8179@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Are there any git-svn users out there who would be seriously hurt if I
> dropped support for using the svn command-line client in git-svn?
>
> The API of the SVN:: libraries seem to be relatively stable these days
> and are *much* faster than the command-line client. I plan on
> maintaining compatibility with version 1.1 of the SVN libraries for at
> least another year; or more if it's not a big problem.
I've been using the SVN:: libraries and agree that that they work well
(and faster). One downside I see is that the svn command-line stuff
will Just Work for a lot of folks, whereas obtaining or building svn's
Perl bindings can be more of a chore [*1*].
OTOH, using git-svn via the svn CLI is slow and much less fun than
with SVN::. So I can also see an additional argument to drop so that
people's first impression of git-svn won't be, "gaah, slow" -- because
with the SVN:: libs, my experience has been, "yaah, much faster!" :-)
My $0.02.
+ seth
[*1*] I asked our sysadmin to install the Perl libraries on one of our
new servers and although they seem to be installed, they are
non-functional. git-svn stiffles the error messages, but a simple
script that just tries to require SVN::Core gives:
Can't load
'/usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/SVN/_Core/_Core.so'
for module SVN::_Core:
/usr/local/src/subversion-1.4.2/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so.0:
undefined symbol: PKCS12_SAFEBAG_free at
/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
Anyone else seen this? I guess that if you drop the svn command-line
support, that it would then make sense to error out with more complete
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Shawn Pearce @ 2006-12-15 16:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Carl Worth, git
In-Reply-To: <200612151657.06909.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Do you mean "commit" view or "commitdiff" view in gitweb for merges
> is confusing?
The commit view was what was confusing me.
> If it is "commit" view, it is fairly easy to remove difftree/whatchanged
> output below commit message for merges. However while git-show nor
> git-diff-tree doesn't show diff for merge messages, the diftree output
> in "commit" view might be taken as 'damages'; git diff --summary always
> takes summary of diff against first parent.
I can see that, but it depends on what the current branch was when
you do the merge. In the cairo case I was looking at yesterday the
"damages" from the merge were actually what was already considered to
be in the mainline as part of the project due to committer pulling
the remote master into his own master before pushing.
Given that the "push; whoops; pull; push" pattern is so common to
Git I think it is sort of misleading to show a merge like this;
lots of activity may have been pulled in from the central branch
during that pull.
iirc git whatchanged for a merge shows only files which cannot be
found in any of the parents; these the files which the merge commit
itself contributed directly. If that set is empty then the commit
just isn't shown by git whatchanged.
--
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Nicolas Pitre @ 2006-12-15 16:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20061215154025.GF17860@spearce.org>
On Fri, 15 Dec 2006, Shawn Pearce wrote:
> I do the same (diff a lot before commit) and thus find commit
> outputting anything at all to be noisy and irritating. Frankly
> the new
>
> git-diff-tree --summary --root --no-commit-id HEAD
>
> that Junio put on the end is already irritating.
>
> But it was added to help users verify that commit did what they
> thought it would (see 61f5cb7f). By the same token sometimes users
> accidentally commit files they didn't mean to, or forget to include
> files they meant to include. Showing a diffstat would also be a
> final sanity check for them.
Make it with -v.
If the --summary is already irritating to you, imagine how a diffstat
could be.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Nicolas Pitre @ 2006-12-15 16:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
In-Reply-To: <4582C3CE.3000902@op5.se>
On Fri, 15 Dec 2006, Andreas Ericsson wrote:
> Nicolas Pitre wrote:
> > On Fri, 15 Dec 2006, Jakub Narebski wrote:
> >
> > > It would be nice to have some generic place in git config to specify
> > > default options to git commands (at least for interactive shell). It
> > > cannot be done using aliases. Perhaps defaults.<command> config variable?
> >
> > I would say the alias facility has to be fixed then.
> >
> > In bash you can alias "ls" to "ls -l" and it just works.
> >
>
> I think this is because git scripts that need a certain git command to work a
> certain way don't want some alias to kick in and destroy things for them.
> Shell-scripts would have the same problem if you alias "awk" to "grep" f.e.,
> which is why prudent shell-scripters use the "unalias -a" thing.
Wouldn't it be possible for aliases to be effective only when issued
from an interactive shell? It is certainly true that aliases just make
no sense in a script.
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Shawn Pearce @ 2006-12-15 16:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0612151032240.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 15 Dec 2006, Shawn Pearce wrote:
> > Andreas Ericsson <ae@op5.se> wrote:
> > > diffstats can be huge though. I'd rather have those only with -v option.
> >
> > But they are on by default for pull/merge, and disabled by -n.
>
> And it is true that diffstat can be quite large. I wouldn't mind the
> diffstat to be added to the commit message summary in the text editor
> though. And displaying it when -v is used makes also a lot of sense.
> But not by default please.
OK, two votes against diffstats by default in commit. Since I
haven't written a patch for it yet consider it dropped. ;-)
--
^ 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