* Re: Two crazy proposals for changing git's diff commands
From: Linus Torvalds @ 2006-02-09 1:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vfymtl43b.fsf@assigned-by-dhcp.cox.net>
On Wed, 8 Feb 2006, Junio C Hamano wrote:
>
> So we could even implement that with
>
> $ git commit --preview [other flags] [paths...]
My argument for "git status" was that it very much _is_ about "what would
I commit". So I'd much rather extend on "git status" than add a
"--preview" flag to "git commit".
At least to me, "git status" is very much a "what is pending" kind of
command. The fact that you can't con it into giving a diff is actually a
downside: I would at times have preferred to have the "git commit" message
contain an extended status that contained the diffs too.
Another way of saying that: I think it would make sense to have a verbose
status report, and maybe also have that verbose flag passed into "git
commit" so that you can see the verbose status when you edit the commit
message.
Under that logic, "git status -v" would show all the diffs (not just
filenames) and "git commit -v .." would be the same as "git commit .." but
the "-v" flag would have been passed down to the "git status" call, so the
commit message file would be pre-populated with the diff.
For small commits, it's actually nice to see the diff itself as you write
the commit message.
Linus
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Linus Torvalds @ 2006-02-09 1:21 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602081643570.2458@g5.osdl.org>
On Wed, 8 Feb 2006, Linus Torvalds wrote:
>
> The largest reason for why "git diff" defaults to diffing against the
> index (and not head) is _literally_ that it's faster. Yes, I'm ashamed,
> but "git diff HEAD" takes 0.35 seconds for me, and "git diff" takes 0.07
> seconds, and largely based entirely on that (and not "what would users
> want"), I made the bad choice to default to git-diff-files for the "no
> arguments" case.
>
> I hang my head in shame. I just like the _instantness_ of "nothing
> changed". That's a bad reason for choice of interfaces, though.
Btw, it was kind of luck (but it's definitely true) that the current "git
diff" semantics happen to also be what you do want during merges when you
try to resolve a conflict (while "git diff HEAD" is much less useful).
So making "git diff" default to diffing against HEAD is actually the wrong
thing to do during merging, where the current behaviour is exactly what
you'd want.
So I dunno.
Linus
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Junio C Hamano @ 2006-02-09 1:21 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87slqtcr2f.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Can anyone else think of common use cases for these various
> operations that I've missed?
If there is none, then that means we have covered everything.
But a more interesting question to ask is "are there useful
comparisons that the existing diff lowlevel does not give me
with a single command". And the answer is of course yes.
For example, you cannot preview "git commit --include paths..."
with a single low-level command. You would need to run
"git-diff-index --cached HEAD" for paths that are _not_
specified, and "git-diff-index HEAD" output for paths that you
will give to "--include" when you make that commit.
> Proposal 1: Make diff-index use HEAD if no <tree> is specified
No need. "git diff --cached" does it, as you discovered. I am
open to update the lowlevel if there is a need, but this does
not justify it.
> If "git diff" is learned as a commit preview, (during a larval
> index-unaware stage), then this behavior will have to be unlearned
> when the user starts using the index. At that point "git diff" becomes
> a way to examine what will *not* be committed by "git commit" rather
> than what *will* be committed by "git commit -a".
Of course, learning various flags to give "git diff" is part of
understanding the index, so if the user understands index, "git
diff" without arguments will _not_ be the only diff command the
user uses for a preview. And I suspect that depending on what
development style you would use, the definition of "useful
comparisons" would be different.
You are assuming that the user graduated from "larval unaware"
in this part of the discussion, no?
> And I think this goes toward my which-diff confusion. Consider the
> three diff operations that allow for investigating un-committed trees:
>
> <tree> -> index diff-index --cached <tree>
> index -> files diff-files
> <tree> -> files diff-index <tree>
>
> Here, "diff-index" is the only one of the three commands that does not
> operate on the index. One can notice a similar thing in the ASCII
> diagram from the core tutorial where diff-index is the only one of
> these three operations that completely bypasses the index (!).
By the way, diff-index without --cached *does* use index.
Unindexed paths are not shown. All this means that there is
still inconsistent understanding on your part.
> Proposal #2: Provide the following 4 diff commands:
Forget about renaming the core-level commands. This is
UNNEGOTIABLE, at least with something like the reasoning
presented in your message. You need to have something stronger
than that.
I'm VERY open to give friendlier interface to 'git-diff'
wrapper, though. And I appreciate that part of your discussion
very much. The end users, once the improvement proposal like
yours is done right, should NOT need to use the lowlevel diff
command directly AT ALL, so renaming low-level serves no useful
purpose other than confusing Porcelain people and me.
> The goal here is that using diff, diff-index, and diff-files without
> any tree argument and without any options (such as --cached) should
> cover the most common cases. So there's less typing in general.
No, the goal should be for normal workflows there should be *no*
need to use lowlevel commands by end users day-to-day. Myself,
I have not typed lowlevel commands from the command line for
quite a long time, except when I am debugging, and except when I
wanted to see "diff-tree --cc" output for a single commit, only
because there was no suitable wrapper. The last reason is now
gone thanks to "git-show" Linus added. So as far as *MY*
workflow is concerned, that goal has already been achieved.
I am not saying there is something wrong with your workflow --
the tool may still not give an easier way to get a diff you
would want in your workflow. I've given one example already
about the --include commit preview. So let's concentrate on
this question:
What are the useful workflows, in which during various
phases of that workflow, existing "git diff" wrapper
does not give us a useful comparison?
Then we can fill what is lacking. During the course of this
exercise, it _might_ turn out that the low-level may need to be
updated to make generation of such an output easier and/or more
efficient, but first we need know what we want to add to the end
result. Mucking with the machinery to generate output must come
after that.
While I suspect what people would want most would be commit
previews, I purposely said "useful comparison" instead of
"commit preview" in the above. Reviewing a conflicted merge
with "git diff" falls into "useful comparison but not commit
preview" category.
Commit preview alone is rather easy. No matter how your worklow
is (one extreme being no update-index until you are ready to
commit, and say "git commit -a" to commit everything --- the
other extreme being frequent update-index between commit, even
multiple update-index on the same paths, and do "git commit
--include paths..."), there are only four ways to make commits:
$ git commit
=> git diff --cached
$ git commit -a
=> git diff HEAD
$ git commit --only paths...
=> git diff HEAD paths...
$ git commit --include paths...
... there is no support in "git diff"; it cannot be done
... with a single low-level.
So we could even implement that with
$ git commit --preview [other flags] [paths...]
and three quarters of necessary things are already there.
There are obvious two other alternatives:
$ git commit-preview [commit flags and paths...]
$ git diff --preview [commit flags and paths...]
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Linus Torvalds @ 2006-02-09 1:05 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87slqtcr2f.wl%cworth@cworth.org>
On Wed, 8 Feb 2006, Carl Worth wrote:
>
> I would be using this before every "got commit" to get a preview, and
> it seems like a painfully long name for such a common operation. Even
> its shortcut form:
>
> git diff --cached HEAD
>
> is among the longest of the "git diff" shortcuts.
[ snip snip ]
Yeah, I agree. The "git diff" semantics are incomplete, and the choices
may not be (aka "almost certainly aren't") the best. The recent "git show"
actually came from a very common use (well, for me, at least) for
"git-diff-tree" that the "git diff" command simply didn't support.
I don't think it's really worth changing the low-level command naming:
nopefully few enough people use them that it doesn't matter, but that's
also what scripts out there are likely to have, so the pain factor when
something breaks is high enough.
But making "git diff" itself more often "Do The Right Thing(tm)" would
probably be a good idea.
In particular, I think the real culprit is the plain "git diff" with no
arguments at all. Right now it ends up showing just a piece of the
picture, and the piece it shows is incomplete enough to be irritating.
So I would prefer a slightly different fix from yours: instead of changing
the core commands (which hopefully people mainly use in scripts where
stability is more important than "intuitive and easy defaults"), how about
_just_ changing the meaning of "git diff"?
Right now a plain "git diff" only shows the differences in the current
tree against the index. I think that was just the wrong choice. I think
almost everybody would actually prefer the default to be to show the
difference against HEAD.
The largest reason for why "git diff" defaults to diffing against the
index (and not head) is _literally_ that it's faster. Yes, I'm ashamed,
but "git diff HEAD" takes 0.35 seconds for me, and "git diff" takes 0.07
seconds, and largely based entirely on that (and not "what would users
want"), I made the bad choice to default to git-diff-files for the "no
arguments" case.
I hang my head in shame. I just like the _instantness_ of "nothing
changed". That's a bad reason for choice of interfaces, though.
One option is to realize that "git status" is actually a much better thing
to use (because it shows _both_ the "HEAD to index" _and_ "index to
current tree" format).
Teaching "git status" to take a "-p" flag (for "patch" - or -v for
"verbose") might actually be a good thing. Then, instead of "git diff",
you'd use "git status -p" and it would show you what the differences are
in the index, and what they are in the tree, so you'd _really_ know what
"git commit" in all its glory would do.
Linus
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Mark Wooding @ 2006-02-09 0:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vacd1mkk9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Correct modulo s/git-daemon/git-shell/.
D'oh! Finger trouble!
> Now, you brought up an interesting way to do this without using
> unix uid. Some sshd installations do not honour environment=
> settings, but that problem aside, you could define a token, say
> GIT_USER, with different value on each line in the shared
> authorized_keys file so that you can distinguish incoming
> developers that share the same "home directory", and change the
> example hook Carl gave us to use that token instead of the unix
> user identity. I'd imagine that would work quite well.
Quite possibly.
Don't give me the credit here, by the way. I completely stole this
whole idea from the Subversion documentation: see `SSH configuration
tricks' in
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html
at the bottom.
Oh, any my mistake: the `environment...' options go at the beginning of
an authorized_keys line, not at the end.
It's so time I went to sleep.
-- [mdw]
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Junio C Hamano @ 2006-02-09 0:40 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrndul2bq.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> It's important that your users can't use this SSH access to mess with
> the shared user's SSH configuration itself, but, hey, that sort of
> restricted access is what git-daemon is for, right?
Correct modulo s/git-daemon/git-shell/.
> I think the problem there is more that the commits themselves were
> created elsewhere, where this server wasn't watching, and therefore it
> pretty much has to take the committer and author information there on
> trust.
That's an different issue. Anybody could create bogus commits
all they want based on somebody else's history. Making
refs/{heads,tags}/ pointers to point at the tip of a development
tail that contains such bogus commits is something you would
want to have control upon.
For example, Documentation/howto/update-hook-example shows
Carl's idea to implement access control using the unix user
identity (because it assumes you set up one home directory per
developer to use public key authentication to cause sshd to give
a true unix uid to an incoming connection) to make sure who can
update which head. By updating a branch head, the developer is
asserts that the development trail that led to it is something
she feels valid.
Now, you brought up an interesting way to do this without using
unix uid. Some sshd installations do not honour environment=
settings, but that problem aside, you could define a token, say
GIT_USER, with different value on each line in the shared
authorized_keys file so that you can distinguish incoming
developers that share the same "home directory", and change the
example hook Carl gave us to use that token instead of the unix
user identity. I'd imagine that would work quite well.
^ permalink raw reply
* Two crazy proposals for changing git's diff commands
From: Carl Worth @ 2006-02-09 0:29 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 11756 bytes --]
So, here I am as a newly converted index-embracer---no more index
denying from me.
However, I'm still trying to wrap my brain around the various diff
commands that git provides and how they would fit into my workflow,
Junio and I have touched on this already in a previous thread, but I'm
starting here with more fresh and complete analysis of the UI around
diff.
The motivation for the *long* (my apologies) message below is largely
the fact that I realized my workflow would use the following command
very regularly:
git diff-index --cached HEAD
I would be using this before every "got commit" to get a preview, and
it seems like a painfully long name for such a common operation. Even
its shortcut form:
git diff --cached HEAD
is among the longest of the "git diff" shortcuts.
My other motivation is that in spite of having what I think is a
fairly good grasp of the structure of git, (the object database, the
index, etc.), I still have one heck of a time trying to remember which
diff commands are which.
So here we go...
Background
==========
At a conceptual level, there are 4 diff operations each of which acts
on an ordered pair (from->to) of trees. One operation takes two
explicit tree objects, while the other three act on 0 or 1 explicit
trees and 2 or 1 implicit trees (based on either the index or files in
the working directory). Specifically, these are tree->index,
index->files, and the composite of the two, tree->files.
To get at these 4 different operations, git provides 4 commands named
diff-tree, diff-index --cached, diff-files, and diff-index. On top of
these, git also provides some syntactic sugar in the form of "diff"
shortcuts for a total of 8 different diff commands.
This is all summarized in the following table:
Operation (from -> to) Core command Shortcut command
----------------------- ------------ ---------------
diff <treeA> -> <treeB> diff-tree <treeA> <treeB> diff <treeA> <treeB>
diff <tree> -> index diff-index --cached <tree> diff --cached <tree>
diff index -> files diff-files diff
diff <tree> -> files diff-index <tree> diff <tree>
I think this background is fairly complete, at least as far as the
functionality exposed by git-diff goes---I am ignoring git-diff-stages
for now, and throughout the remainder of this message.
Use cases
=========
After understanding things that far, I asked myself what each of the
four operations are useful for. The tree->tree case is easiest as it
simply shows the difference between two trees that exist in the object
store.
The remaining three cases are more interesting because they provide
mechanisms for querying trees that don't yet (or may never) exist in
the object store. Here are the questions I have been able to come up
with so far that the operations can help in answering:
<treeA> -> <treeB> (diff-tree <treeA> <treeB>, or diff <treeA> <treeB>)
What changed between two trees?
<tree> -> index (diff-index --cached <tree>, diff --cached <tree>)
When <tree> is HEAD: What will "git commit" do?
index -> files (diff-files, diff)
What work have I done that I haven't updated into the index yet?
Or, if not manually updating the index: What will "git commit -a" do?
<tree> -> files (diff-index <tree>, diff <tree>)
When <tree> is HEAD: What will "git commit -a" do?
Can anyone else think of common use cases for these various
operations that I've missed?
Subjective comments/proposals
=============================
Everything above should be pretty much objective descriptions of how
things exist. From here on out, I'll start in with my opinions and
hopefully some useful proposals, (ordered by increasing likelihood of
being controversial).
It's interesting to me that both variants of diff-index (with and
without --cached) require a tree argument, while at the same time,
both variants seem most useful when used with HEAD. So it looks like
there's a reasonable default value for that option that is
missing. This should be pretty painless to fix, (no user retraining
required):
Proposal 1: Make diff-index use HEAD if no <tree> is specified
With this proposal, my most-common command now shrinks to:
git diff-index --cached
(And I was quite surprised to just learn that the shortcut
version of "git diff --cached" already does default to HEAD
rather than calling git-diff-files and erroring out on the
unknown --cached argument. That's handy, even if a bit
unexpected from the documentation of "git diff".)
So, my common command is a bit shorter, but I'd like to shrink it
more, and I still haven't addressed my which-diff-command-do-I-want
confusion.
First, I see a potential problem in the use cases table above. The
"git diff" command is taught in the tutorial as a way to preview what
will be committed by "commit -a". But I think this lays a trap for git
newcomers.
If "git diff" is learned as a commit preview, (during a larval
index-unaware stage), then this behavior will have to be unlearned
when the user starts using the index. At that point "git diff" becomes
a way to examine what will *not* be committed by "git commit" rather
than what *will* be committed by "git commit -a".
This seems an unkind thing to do to new users. Instead, users of
"commit -a" should be provided with a HEAD->files diff operation for
previewing commits. That's what they really want to see, (and not the
index->files diff that only happens to match in the case they haven't
manually dirtied the index).
So the 'correct' preview command for "commit -a" is currently one of
"diff HEAD" or "diff-index HEAD", and under Proposal 1 it would be
"diff-index".
So, without using the shortcut version, the tutorial's preview command
is down to a single name "diff-index", but it is rather awkward to
have a "-index" command in the index-avoidance stage of the tutorials.
And I think this goes toward my which-diff confusion. Consider the
three diff operations that allow for investigating un-committed trees:
<tree> -> index diff-index --cached <tree>
index -> files diff-files
<tree> -> files diff-index <tree>
Here, "diff-index" is the only one of the three commands that does not
operate on the index. One can notice a similar thing in the ASCII
diagram from the core tutorial where diff-index is the only one of
these three operations that completely bypasses the index (!).
All that just to say that there's some inconsistent naming in the core
commands. This is papered over somewhat by the "git diff" shortcuts
but at the same time that also adds even _more_ diff commands for
people like me to have to learn.
So, here, finally is a proposal to change the names of some diff
commands. I expect this to be more controversial than proposal #1 as
it is sure to run up against ingrained muscle memory in some cases.
But I've tried to minimize that as much as possible, and I hope it
will be workable.
Proposal #2: Provide the following 4 diff commands:
Operation (from -> to) Proposal
----------------------- --------
diff <treeA> -> <treeB> diff <treeA> <treeA>
diff <tree> -> index diff-index <tree> (default to HEAD)
diff index -> files diff
diff <tree> -> files diff-files <tree> (default to HEAD)
The goal here is that using diff, diff-index, and diff-files without
any tree argument and without any options (such as --cached) should
cover the most common cases. So there's less typing in general.
These 3 diff commands can be presented as fundamental, and usable
without needing a layer of sugar above. So there is already less to
learn.n
Also, diff-index and diff-files have parallel structure and naming,
each performing a diff from HEAD or the given tree to either the
current index or files, respectively. So the names should also be
easier to learn.
Under this proposal, my "git commit" preview becomes:
git diff-index
and the tutorial's "git commit -a" preview becomes:
git diff-files
which looks pretty nice to me [*].
Let's examine the impact this proposal would have on the existing core
and shortcut diff commands. Here's an explanation of the Notes column
entries below:
"no change": The existing command is provided in an identical form
under the proposal.
"compatible": The existing command will continue to function
identically for backwards compatibility with muscle
memory. But some things (such as --cached options)
will simply be ignored and "unadvertised" under the
new proposal
incompatible[*]:The proposal is not compatible with existing usage, so
some amount of retraining will be needed. In each
case, I've made notes on ways that might make this
bearable.
Current core command After proposal Notes
-------------------- -------------- -----
diff-tree <treeA> <treeB> diff <treeA> <treeB> compatible
diff-index --cached <tree> diff-index <tree> compatible
diff-files diff incompatible[1]
diff-index <tree> diff-files <tree> incompatible[2]
[1] Existing "diff-files" is index->files while the proposed
"diff-files" would be HEAD->files. Fortunately the retraining here is
to a simpler command ("diff") which already exists. Hopefully, current
users already prefer the simpler command anyway.
[2] Existing "diff-index <tree>" is <tree>->files while the proposed
"diff-index <tree>" would be <tree>->index. Fortunately the existing
"diff-index <tree>" has an existing shortcut as "diff <tree>" which
can be maintained compatibly. So hopefully, current users already
prefer the simpler command anyway. Otherwise, retraining for this
command will involves an index->files substitution, but hopefully the
consistent naming under the new proposal will help here.
Current shortcut command After proposal Notes
------------------------ -------------- -----
diff <treeA> <treeB> diff <treeA> <treeB> no change
diff --cached <tree> diff-index <tree> compatible [3]
diff diff no change
diff <tree> diff-files <tree> compatible [3]
[3] The proposal doesn't recommend any version of "git diff" with a
single <tree> argument. Fortunately we can continue to provide
compatible support for both such existing uses since they differ based
on the presence or absence of the --cached option.
Anyway, that's a proposal for some diff commands if we had the
opportunity to do it from scratch. I'm not a trained user of git that
would be impacted by this change, so I can't make any fair comment on
whether the change would be worth making or not. But I would
definitely be interested in hearing what existing users of git think
of the idea.
And of course, I am glad to fix up the implementation and all the
documentation as necessary to implement this proposal if people think
it's a good idea.
-Carl
[*] It's not the original topic of this post, but now that I've
finished this, I realize that if the diff proposal were implemented
then "commit-files" would make a dandy replacement for "commit
-a". That could lead to finally providing the parallel preview
commands I originally wanted:
git diff-index # as preview for
git commit-index
and:
git diff-files # as preview for
git commit-files
Then "git commit" would just be a shortcut for git commit-index.
(Oh, and that would also lead to a natural "git ci" abbreviation too,
if desired. This would parallel the "ci == checkin" abbreviation that
some other systems provide.)
I think the separate notions of commit-index and commit-files would do
a good job of allowing for simple tutorials, (eliminates the "what the
heck is -a all about?" questions), that also don't contribute to
general index-unawareness lead to later index-confusion as the current
"git diff; git commit -a" does.
This might even lead to a natural distinction between "git
status-index" and "git status files" too.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Nicolas Vilz 'niv' @ 2006-02-09 1:16 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0602081545330.2458@g5.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 9 Feb 2006, Nicolas Vilz 'niv' wrote:
>
>>So, how do i tell git to send my identity-file to sshd? And could I set an
>>alias like in .git/remotes for that location / identity?
>
>
> Use a "fake host".
>
[...ssh config...]
>
> (Yeah, I forget the exact ssh config file format, so you should
> double-check that.)
i will do that.. :))
I thank you all for your help.
Nicolas
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Mark Wooding @ 2006-02-09 0:14 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q39o3xs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> So while you could make a repository "/pub/project.git" the home
> directory of _one_ UNIX user, and store her key in the file
> "/pub/project.git/.ssh/authorized_keys", that would not work
> very well for a shared repository setup if you want to be able
> to tell more than one physical users apart.
Ahh! But you can. The trick is to set the remote user's identity based
on the key he uses to authenticate himself. This doesn't work if you
use password authentication. You add items of the form
`environment="VAR=VALUE"' to the end of each authorized_keys entry, as
appropriate for whoever it is that owns the corresponding private key;
the GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} variables are ideal choices to
set here. You could set some other variables and do some more
sophisticated checking of who's doing what, which would require souping
up git-daemon somewhat, but I don't think it's beyond the realms of
possibility.
It's important that your users can't use this SSH access to mess with
the shared user's SSH configuration itself, but, hey, that sort of
restricted access is what git-daemon is for, right?
> You _could_ tell them to use the same -l option and log-in as the same
> UNIX user with their own keys, though. But that way you cannot tell
> which developer pushed into the repository (of course if you trust the
> commits, commit log message would say the committer ident).
I think the problem there is more that the commits themselves were
created elsewhere, where this server wasn't watching, and therefore it
pretty much has to take the committer and author information there on
trust.
-- [mdw]
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Nicolas Vilz 'niv' @ 2006-02-09 1:06 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vzml1mmmh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Vilz 'niv' <niv@iaglans.de> writes:
>
>
>>So, how do i tell git to send my identity-file to sshd? And could I
>>set an alias like in .git/remotes for that location / identity?
>
>
> That is not a git question but you are using me as an ssh
> helpdesk. See ssh_config(5).
i didn't recognize that it had nothing to do with git.
Thank you very much for your help and your time. :)
Nicolas
^ permalink raw reply
* Re: gitweb: View graphes & get tar
From: Alan Chandler @ 2006-02-09 0:03 UTC (permalink / raw)
To: git
In-Reply-To: <4fb292fa0602081534x7f6e74c1veb8c4ea7ad5a83cc@mail.gmail.com>
On Wednesday 08 February 2006 23:34, Bertrand Jacquin wrote:
> Hi,
>
> Is gitweb maintainer planned to allow people to get from gitweb ? It
> could be something good for ungited/remote people to get a tar for a
> specific tree.
> gd provide to create graphs and is often use in "web project" to
> generate graphe. Could it here generated a graph of branches like in
> gitk ?
> It also could be cool to allow people to get binary files in an other
> mimetype that text/plain.
>
> Here are my wish :D it's worth what it's worth.
You can do some of that a different way.
I have it set up so that when I push a tag into my public git repositories,
that a post-update hook creates a tarball of the site and puts it into the
download directory.
The hook is of the following form
#!/bin/sh
#
# This script is used to create a tarball of the project and place it into the
"files"
# directory of the web site whenever a release is tagged in the repository
#
PROJECT=akcmoney
# this should look at each positional parameter
for ref ; do
#if its a tag then create a tarball
if [ "${ref:0:10}" == "refs/tags/" ] ; then
git-tar-tree ${ref:10} $PROJECT | gzip -9
> /var/www/chandlerfamily/files/$PROJECT/$PROJECT-${ref:10}.tar.gz
fi
done
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* [PATCH] Allow using --cc when showing a merge.
From: Junio C Hamano @ 2006-02-09 0:02 UTC (permalink / raw)
To: Kay Sievers; +Cc: Linus Torvalds, git
In-Reply-To: <7vu0b9mmij.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This does not do the colorized diff, but just to show ideas
where to put the link to ask for the combined diff.
gitweb.cgi | 60 +++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 47 insertions(+), 13 deletions(-)
1f19febaefbf90dc04a6b37d79ba3a9337decaff
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..d2659ea 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -191,6 +191,9 @@ if (!defined $action || $action eq "summ
} elsif ($action eq "commitdiff_plain") {
git_commitdiff_plain();
exit;
+} elsif ($action eq "combinediff") {
+ git_combinediff();
+ exit;
} elsif ($action eq "history") {
git_history();
exit;
@@ -1762,7 +1765,15 @@ sub git_commit {
"</tr>\n";
print "<tr><td>committer</td><td>" . esc_html($co{'committer'}) . "</td></tr>\n";
print "<tr><td></td><td> $cd{'rfc2822'}" . sprintf(" (%02d:%02d %s)", $cd{'hour_local'}, $cd{'minute_local'}, $cd{'tz_local'}) . "</td></tr>\n";
- print "<tr><td>commit</td><td style=\"font-family:monospace\">$co{'id'}</td></tr>\n";
+ print "<tr><td>commit</td><td style=\"font-family:monospace\">$co{'id'}</td>";
+ if (1 < @{$co{'parents'}}) {
+ print '<td class="link">';
+ print $cgi->a({-href => "$my_uri?" .
+ esc_param("p=$project;a=combinediff;".
+ "h=$hash")}, "combinediff");
+ print '</td>';
+ }
+ print "</tr>\n";
print "<tr>" .
"<td>tree</td>" .
"<td style=\"font-family:monospace\">" .
@@ -2044,6 +2055,38 @@ sub git_commitdiff {
git_footer_html();
}
+sub git_combinediff {
+ mkdir($git_temp, 0700);
+ my $fd;
+ my $refs = read_info_ref("tags");
+ open $fd, "-|", "$gitbin/git-describe $hash";
+ my ($tagname) = <$fd>;
+ chomp($tagname);
+ close $fd;
+ print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"git-$hash.patch\"");
+ my %co = git_read_commit($hash);
+ my %ad = date_str($co{'author_epoch'}, $co{'author_tz'});
+ my $comment = $co{'comment'};
+ print "From: $co{'author'}\n" .
+ "Date: $ad{'rfc2822'} ($ad{'tz_local'})\n".
+ "Subject: $co{'title'}\n";
+ if (defined $tagname) {
+ print "X-Git-Tag: $tagname\n";
+ }
+ print "\n";
+
+ foreach my $line (@$comment) {;
+ print "$line\n";
+ }
+ print "---\n\n";
+
+ open $fd, "-|", "$gitbin/git-diff-tree --cc $hash";
+ while (<$fd>) {
+ print $_;
+ }
+ close $fd;
+}
+
sub git_commitdiff_plain {
mkdir($git_temp, 0700);
open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
@@ -2051,20 +2094,11 @@ sub git_commitdiff_plain {
close $fd or die_error(undef, "Reading diff-tree failed.");
# try to figure out the next tag after this commit
- my $tagname;
my $refs = read_info_ref("tags");
- open $fd, "-|", "$gitbin/git-rev-list HEAD";
- chomp (my (@commits) = <$fd>);
+ open $fd, "-|", "$gitbin/git-describe $hash";
+ my ($tagname) = <$fd>;
+ chomp($tagname);
close $fd;
- foreach my $commit (@commits) {
- if (defined $refs->{$commit}) {
- $tagname = $refs->{$commit}
- }
- if ($commit eq $hash) {
- last;
- }
- }
-
print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"git-$hash.patch\"");
my %co = git_read_commit($hash);
my %ad = date_str($co{'author_epoch'}, $co{'author_tz'});
--
1.1.6.gbb042
^ permalink raw reply related
* [PATCH] Use describe to come up with the closest tag.
From: Junio C Hamano @ 2006-02-09 0:01 UTC (permalink / raw)
To: Kay Sievers; +Cc: Linus Torvalds, git
In-Reply-To: <7vu0b9mmij.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This gives saner output than what is currently there. It
does not have direct relation to the diff-tree --cc patch,
but over there I already use describe so this patch is to
make things consistent.
gitweb.cgi | 15 +++------------
1 files changed, 3 insertions(+), 12 deletions(-)
3fb28888448edc8b2d4aeab55bc13d78746e5a45
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..3c43695 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -2051,20 +2051,11 @@ sub git_commitdiff_plain {
close $fd or die_error(undef, "Reading diff-tree failed.");
# try to figure out the next tag after this commit
- my $tagname;
my $refs = read_info_ref("tags");
- open $fd, "-|", "$gitbin/git-rev-list HEAD";
- chomp (my (@commits) = <$fd>);
+ open $fd, "-|", "$gitbin/git-describe $hash";
+ my ($tagname) = <$fd>;
+ chomp($tagname);
close $fd;
- foreach my $commit (@commits) {
- if (defined $refs->{$commit}) {
- $tagname = $refs->{$commit}
- }
- if ($commit eq $hash) {
- last;
- }
- }
-
print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"git-$hash.patch\"");
my %co = git_read_commit($hash);
my %ad = date_str($co{'author_epoch'}, $co{'author_tz'});
--
1.1.6.gbb042
^ permalink raw reply related
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-08 23:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602081532360.2458@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So it would be much nicer if gitweb had some alternate approach to showing
> merge diffs. My suggested approach would be to just let the user choose:
> have separate "diff against fist/second[/third[/..]] parent" buttons. And
> one of the choices would be the "conflict view" that git-diff-tree --cc
> gives (I'd argue for that being the default one, because it's the only one
> that doesn't have a "preferred parent").
I have something very rough, but I will be sending them out
anyways.
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Junio C Hamano @ 2006-02-08 23:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43EA8DDA.3070906@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> writes:
> So, how do i tell git to send my identity-file to sshd? And could I
> set an alias like in .git/remotes for that location / identity?
That is not a git question but you are using me as an ssh
helpdesk. See ssh_config(5).
The answers are:
IdentityFile
User
For example, I have this in my .ssh/config on my local machine:
Host osiris.pyramid.com
User junio
IdentityFile ~/.ssh/osiris-pub
ForwardAgent no
ForwardX11 no
Without "User", it would send out "junkio", so I have that line
to override it (I could do it with -l command line, but there is
no point because that is I would use _always_ to go there).
Without "IdentityFile" it would use ~/.ssh/identity (same
rationale with -i), which is the identity file I usually use for
other sites.
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Linus Torvalds @ 2006-02-08 23:50 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43EA8DDA.3070906@iaglans.de>
On Thu, 9 Feb 2006, Nicolas Vilz 'niv' wrote:
>
> So, how do i tell git to send my identity-file to sshd? And could I set an
> alias like in .git/remotes for that location / identity?
Use a "fake host".
Ie, let's say that your project is "project@host.com", then make each user
just have in their .ssh/config:
host project.host.com
User project
HostName host.com
IdentityFile /home/myhome/project-key
and there you are. Just use "project.host.com:repo-name" as the thing you
pull and push from.
(Yeah, I forget the exact ssh config file format, so you should
double-check that.)
Linus
^ permalink raw reply
* gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-08 23:44 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
I just did an arm merge that needed some (very trivial) manual fixups
(commit ID cce0cac1, in case anybody cares).
As usual, git-diff-tree --cc does a beautiful job on it, but I also
checked the gitweb output, which seems to not do as well (the commit
message about a manual conflict merge doesn't make any sense at all).
Now, in this case, what gitweb shows is actually "sensible": it will show
the diff of what the merge "brought in" to the mainline kernel, and in
that sense I can certainly understand it. It basically diffs the merge
against the first parent.
So looking at that particular example, arguably gitweb does something
"different" from what the commit message is talking about, but in many
ways it's a perfectly logical thing.
However, diffing against the first parent, while it sometimes happens to
be a sane thing to do, really isn't very sane in general. The merge may go
the other way (subdevelopers merging my code), like in commit b2faf597,
and sometimes there might not be a single reference tree, but more of a
"couple of main branches" approach with merging back and forth). Then the
current gitweb behaviour makes no sense at all.
So it would be much nicer if gitweb had some alternate approach to showing
merge diffs. My suggested approach would be to just let the user choose:
have separate "diff against fist/second[/third[/..]] parent" buttons. And
one of the choices would be the "conflict view" that git-diff-tree --cc
gives (I'd argue for that being the default one, because it's the only one
that doesn't have a "preferred parent").
Kay?
Linus
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Nicolas Vilz 'niv' @ 2006-02-09 0:43 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0602081438390.2458@g5.osdl.org>
Linus Torvalds wrote:
> Create a "project" account on some shared machine, create the project(s)
> in that accounts home directory, and set the login shell for that
> project to "git-shell".
done..
> It _should_ all work perfectly fine. There are features you may want to
> add, like logging (but sshd does some of that for you) and various "admin"
> commands in addition to just plain push/pull. git-shell was really just a
> quick hack, and I don't know if anybody actually uses it.
I would like to use it.. i searched for something like scponly for ssh
just for git.. and I found git-shell.
as long as i can modify and setup git-repositories myself, i haven't
needed admin-commands, yet...
as mentioned in the thread, i still search for a posibility to tell git
to send my identify-file... and possibly set an alias for this command :)
ssh with bash for this account and the keys works... ssh with git-shell
does work, too... (What do you think I am? A shell?) but git with keys
and ssh transport, that is what i don't get working :)
Nicolas
^ permalink raw reply
* gitweb: View graphes & get tar
From: Bertrand Jacquin @ 2006-02-08 23:34 UTC (permalink / raw)
To: git
Hi,
Is gitweb maintainer planned to allow people to get from gitweb ? It
could be something good for ungited/remote people to get a tar for a
specific tree.
gd provide to create graphs and is often use in "web project" to
generate graphe. Could it here generated a graph of branches like in
gitk ?
It also could be cool to allow people to get binary files in an other
mimetype that text/plain.
Here are my wish :D it's worth what it's worth.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Alan Chandler @ 2006-02-08 23:35 UTC (permalink / raw)
To: git
In-Reply-To: <43EA7D57.7040409@iaglans.de>
On Wednesday 08 February 2006 23:23, Nicolas Vilz 'niv' wrote:
> in my case it would be only one system-user which has full access to
> several repositories. At this time, the users which use that account,
> have to give a password, which isn't that bad... it would be easier and
> more secure for me, not to give a password, but ask the users for the
> ssh pubkey..
This sounds like you haven't got sshd set up correctly. You can get it to log
you in soley based on keys, and whether or not you give a password is then
dependent soley on whether your private key has a pass phrase or not and then
whether or not you are using some ssh-agent to remember them for you.
I have it setup so that access to ssh controlled accounts is soley via key.
Private keys remaining on fixed computers at home have no passphrase, my
laptop has a private key with a passphrase which I enter once on login.
I have several accounts around the place with my public keys enumerated in
their .ssh/authorized_keys file, so I have been able to contact git
repositories with urls like
git@www.chandlerfamily.org.uk
www-data@www.chandlerfamily.org.uk
and for my own account
just www.chandlerfamily.org.uk
all without entering a password.
But following the discussion thread Junio pointed to I have converted
everything to shared repositories and I now only use my own account to log
in.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Nicolas Vilz 'niv' @ 2006-02-09 0:33 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q39o3xs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Vilz 'niv' <niv@iaglans.de> writes:
>
>
>>in my case it would be only one system-user which has full access to
>>several repositories. At this time, the users which use that account,
>>have to give a password, which isn't that bad... it would be easier
>>and more secure for me, not to give a password, but ask the users for
>>the ssh pubkey..
[... how sshd operates ...]
> You _could_ tell them to use the same -l option and log-in as
> the same UNIX user with their own keys, though. But that way
> you cannot tell which developer pushed into the repository (of
> course if you trust the commits, commit log message would say
> the committer ident).
I think this (last) scenario would match my thoughts best :)
Exactly that was, what i was trying to do, although I couldn't tell git
to send my identify-file. That was (more or less) my initial-question
(howto do that, the ssh option -i) :)
You got a point which i haven't recognized, yet...
I really can't tell later on which developer pushed unless i trust the
commit-messages. I will think about that.
So, how do i tell git to send my identity-file to sshd? And could I set
an alias like in .git/remotes for that location / identity?
Thank you very much for your explanations and help.
Sincerly
Nicolas
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Junio C Hamano @ 2006-02-08 22:56 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43EA7D57.7040409@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> writes:
> in my case it would be only one system-user which has full access to
> several repositories. At this time, the users which use that account,
> have to give a password, which isn't that bad... it would be easier
> and more secure for me, not to give a password, but ask the users for
> the ssh pubkey..
I do not know where you are getting the password idea.
The conclusion of that thread is that it is not worth trying to
co-mingle more than one physical developer into one home
directory, and does not have much to do with use of password or
public key authentication.
That thread describes:
- you can use ssh public key authentication for developers;
- you do not have to give them full shell access by using
git-shell;
- HOWEVER you cannot tell each developers apart if you add one
key per developer to the same $HOME/.ssh/authorized_keys file.
The last point is not about git at all, but comes from how ssh
daemon operates. It roughly goes like this:
- The client says "I am me at the remote host, use this public
key to prove that to the other end". Often you do not have
to give -l and -i but when you fully spell out the command
line, it would be something like:
$ ssh -l me -i identity-file remote.host.example.com
Your client sends "me" and the public key to the remote end.
- The ssh daemon running on the remote site says, "Hmph, let's
see if you are really "me" as you claim." It does the
following things:
1. Look "me" up from its user database (be it /etc/passwd,
NIS or LDAP) to find out the user's home directory.
Let's say the "struct passwd.pw_dir" says it is
"/home/me".
2. Check to see if /home/me/.ssh/authorized_keys exists, all
the elements in the path to the file is secure (e.g. if
/home/me/.ssh can be modified by somebody other than
"me", what is in authorized_keys is not trustworthy).
That means /home/me/.ssh/authorized_keys must be owned by
"me" and at least mode 0644 or stricter.
3. Reads the keys in that file, and finds what is sent as
the public key from the client.
4. Uses that public key to challenge the client to make sure
the client has the corresponding private key.
What this implies is that sharing the home directory among
multiple UNIX users would not work with ssh daemon the way you
expect. The check in step 2 would fail for all but one user.
Being able to list more than one key in authorized_keys is so
that you can use more than one key to become the _same_ user,
and does not give you the ability to become a user other than
the one that owns that home directory on that remote host.
So while you could make a repository "/pub/project.git" the home
directory of _one_ UNIX user, and store her key in the file
"/pub/project.git/.ssh/authorized_keys", that would not work
very well for a shared repository setup if you want to be able
to tell more than one physical users apart.
You _could_ tell them to use the same -l option and log-in as
the same UNIX user with their own keys, though. But that way
you cannot tell which developer pushed into the repository (of
course if you trust the commits, commit log message would say
the committer ident).
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Linus Torvalds @ 2006-02-08 22:45 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43EA7D57.7040409@iaglans.de>
On Thu, 9 Feb 2006, Nicolas Vilz 'niv' wrote:
>
> in my case it would be only one system-user which has full access to several
> repositories. At this time, the users which use that account, have to give a
> password, which isn't that bad... it would be easier and more secure for me,
> not to give a password, but ask the users for the ssh pubkey..
That is very much part of how the whole git-shell usage was envisioned.
Create a "project" account on some shared machine, create the project(s)
in that accounts home directory, and set the login shell for that
project to "git-shell".
Then you ask people who are part of the project to send in some ssh key
for that project. Then add those keys to the authorized_keys2 file for the
project, and voila, you all your participants can pull and push into it
but do not get any other access to the machine.
It _should_ all work perfectly fine. There are features you may want to
add, like logging (but sshd does some of that for you) and various "admin"
commands in addition to just plain push/pull. git-shell was really just a
quick hack, and I don't know if anybody actually uses it.
In other words, it hasn't exactly been tested,
Linus
^ permalink raw reply
* Re: Handling large files with GIT
From: Martin Langhoff @ 2006-02-08 22:35 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87slqty2c8.fsf@mid.deneb.enyo.de>
On 2/9/06, Florian Weimer <fw@deneb.enyo.de> wrote:
> In your mbox case, you should simply try Maildir. The tree object
> (which lists all files in the Maildir folder) will still be rather
> large (about 40 to 50 bytes per message stored), though.
I did suggest maildir, where GIT is bound to do well as the content
of the emails doesn't change but they just move around a lot. Though
yes, trees are going to be nasty.
But the interesting case I gues is the general one of large files
changing slowly. My guess is that supporting delta transfers in the
git protocol would make it a lot more manageable. For local storage
git isn't so bad, and the problem is perhaps harder to resolve.
cheers,
martin
^ permalink raw reply
* Re: git + ssh + key authentication feature-request
From: Nicolas Vilz 'niv' @ 2006-02-08 23:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd79o6m5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Vilz 'niv' <niv@iaglans.de> writes:
>
>
>>I would like to ask if it is possible to use ssh keys to authenticate
>>via ssh on a git repository via git-pull/git-push. Since ssh supports
>>them, wouldn't it be nice to use them in git, too?
>
>
> Please read what has been discussed within the last couple of
> weeks at least. I could say the last couple of months but I
> know that is asking too much ;-).
>
> http://thread.gmane.org/gmane.comp.version-control.git/15462
>
Sorry, i haven't found that, yet, so i asked..
in my case it would be only one system-user which has full access to
several repositories. At this time, the users which use that account,
have to give a password, which isn't that bad... it would be easier and
more secure for me, not to give a password, but ask the users for the
ssh pubkey..
I can still live with the password thing :)
Sincerly
Nicolas
^ 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