* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Martin Langhoff @ 2007-12-18 23:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sergei Organov, Andreas Ericsson, Jakub Narebski, Sebastian Harl,
Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181803070.23902@racer.site>
On Dec 19, 2007 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Sorry, I have no time for this kind of discussions.
Johannes,
the way you normally "say" that is by not replying. Please help keep
things civil.
cheers,
martin
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Johannes Schindelin @ 2007-12-18 23:26 UTC (permalink / raw)
To: Dana How; +Cc: Alex Riesen, Jakub Narebski, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <56b7f5510712181503l1e5dcacds23511d968f98aedb@mail.gmail.com>
Hi,
On Tue, 18 Dec 2007, Dana How wrote:
> On Dec 18, 2007 2:43 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 18 Dec 2007, Alex Riesen wrote:
> > > But the act of running "git-show <tree-ish>:<path>" does have a working
> > > directory relative to the project root.
> >
> > Not necessarily. My primary use of "git show <tree-ish>:<path>" (yes, I
> > already use the dash-less form ;-) is in _bare_ repositories.
> >
> > And I still maintain that expecting <tree-ish>:<path> to take the current
> > relative path into account would be just like if you expected
> >
> > C:\> cd WINDOWS
> > C:\WINDOWS> dir D:system32
> >
> > to show you the contents of D:\WINDOWS\system32.
> >
> > Or another, less Windowsy example:
> >
> > $ cd /usr/bin
> > $ scp home:bash ./
> >
> > No, this does not copy home:/usr/bin/bash but home:$HOME/bash.
>
> Both of your counterexamples use 2 disjoint directory trees:
> C: vs D:, or trees on different machines.
Well, the first actually only uses 1 "disjoint" directory tree. You did
not address the concern of the bare repository.
> The cases we are talking about are all subtrees of the working tree.
> There is a useful cwd suffix.
Not necessarily. You can be in a subdirectory that was not even created
in _any_ revision. Or you can access a different branch with a different
history.
It boils down to this: if you need relative paths _only_, you narrowed
yourself very much in your use cases.
> Don't you think that
> git <op> commit:./file.c
> could occasionally be more convenient than
> git <op> commit:very/long/and/boring/path/equal/to/cwd/file.c
> ?
Actually, it depends on the <op>. And guess what, for those operations
that I would like to have that, it already works! "grep", "diff", "log".
Ciao,
Dscho
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Junio C Hamano @ 2007-12-18 23:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, Jakub Narebski, git, Linus Torvalds, Dana How
In-Reply-To: <Pine.LNX.4.64.0712182239500.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> And I still maintain that expecting <tree-ish>:<path> to take the current
> relative path into account would be just like if you expected
>
> C:\> cd WINDOWS
> C:\WINDOWS> dir D:system32
>
> to show you the contents of D:\WINDOWS\system32.
>
> Or another, less Windowsy example:
>
> $ cd /usr/bin
> $ scp home:bash ./
>
> No, this does not copy home:/usr/bin/bash but home:$HOME/bash.
Please do not cc me on this topic, unless it is a patch implementing
suggestion from Linus to treat $commit^{tree} as relative to $(cwd) but
for only when the user directly specified that in full, including ^{tree}
part.
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-18 23:15 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Alex Riesen, git, Junio C Hamano,
Linus Torvalds, danahow
In-Reply-To: <200712190011.52613.jnareb@gmail.com>
On Dec 18, 2007 3:11 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Although Linus argument about thinking that cwd affects translation
> from _commit_ sha1 to _tree-ish_ is also sound. Nevertheless I'd rather
> have separate syntax for cwd-relative paths, i.e. <commit>:./<relpath>.
Cool -- so adding recognition for ":." will support relative paths
when useful and will not interfere with any current syntax.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Jakub Narebski @ 2007-12-18 23:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, git, Junio C Hamano, Linus Torvalds, Dana How
In-Reply-To: <Pine.LNX.4.64.0712182239500.23902@racer.site>
Johannes Schindelin wrote:
> On Tue, 18 Dec 2007, Alex Riesen wrote:
>> Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:
>>>
>>> What cwd? <path> in <tree-ish>:<path> syntax is "relative" to
>>> <tree-ish>.
>>
>> But the act of running "git-show <tree-ish>:<path>" does have a working
>> directory relative to the project root.
>
> Not necessarily. My primary use of "git show <tree-ish>:<path>" (yes, I
> already use the dash-less form ;-) is in _bare_ repositories.
>
> And I still maintain that expecting <tree-ish>:<path> to take the current
> relative path into account would be just like if you expected
[...]
> $ cd /usr/bin
> $ scp home:bash ./
>
> No, this does not copy home:/usr/bin/bash but home:$HOME/bash.
Great example! In scp <machine>:<path>, <path> by default is relative
to the login (ssh) directory on <machine>. In git's <tree-ish>:<path>,
<path> by default is relative to <tree-ish>.
Although Linus argument about thinking that cwd affects translation
from _commit_ sha1 to _tree-ish_ is also sound. Nevertheless I'd rather
have separate syntax for cwd-relative paths, i.e. <commit>:./<relpath>.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Jakub Narebski @ 2007-12-18 23:05 UTC (permalink / raw)
To: Alex Riesen
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Dana How
In-Reply-To: <20071218222032.GH2875@steel.home>
Dnia wtorek 18. grudnia 2007 23:20, Alex Riesen napisał:
> Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:
>> Not "relative to project root". Relative to tree-ish used on right hand
>> side in <tree-ish>:<path> extended SHA-1 syntax. It is usually project
>> root, because when you specify <commit> or <tag> as <tree-ish> it refers
>> to top/root directory of a project.
>
> I know. My problem: it is also awkward. git-show :test-l<Tab>ib.sh just
> does not do what I expect. Nor does git cat-file HEAD:test-l<Tab>ib.sh.
> And git cat-file HEAD:t/test-l<Tab> does not work at all. And this is
> very simple example. Normally the pathnames are about 100 characters
> long.
Doesn't bash completion (or zsh compltion) for git implement this?
Let me check... it does
$ . contrib/completion/git-completion.bash
$ git cat-file -p HEAD:t/test-<TAB>
$ git cat-file -p HEAD:t/test-lib.sh # autocompleted
It does work correctly also from within t/ directory.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-18 23:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, Jakub Narebski, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0712182239500.23902@racer.site>
On Dec 18, 2007 2:43 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 18 Dec 2007, Alex Riesen wrote:
> > But the act of running "git-show <tree-ish>:<path>" does have a working
> > directory relative to the project root.
>
> Not necessarily. My primary use of "git show <tree-ish>:<path>" (yes, I
> already use the dash-less form ;-) is in _bare_ repositories.
>
> And I still maintain that expecting <tree-ish>:<path> to take the current
> relative path into account would be just like if you expected
>
> C:\> cd WINDOWS
> C:\WINDOWS> dir D:system32
>
> to show you the contents of D:\WINDOWS\system32.
>
> Or another, less Windowsy example:
>
> $ cd /usr/bin
> $ scp home:bash ./
>
> No, this does not copy home:/usr/bin/bash but home:$HOME/bash.
Both of your counterexamples use 2 disjoint directory trees:
C: vs D:, or trees on different machines.
The cases we are talking about are all subtrees of the working tree.
There is a useful cwd suffix.
Don't you think that
git <op> commit:./file.c
could occasionally be more convenient than
git <op> commit:very/long/and/boring/path/equal/to/cwd/file.c
?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Johannes Schindelin @ 2007-12-18 23:02 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Linus Torvalds, Jakub Narebski, Alex Riesen, git
In-Reply-To: <56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com>
Hi,
On Tue, 18 Dec 2007, Dana How wrote:
> [lots about rev:path taking path to be relative to the project root,
> preferring it to be relative to the current prefix instead]
>
> Typing an extra "./" is a big improvement over a long path prefix.
Have you tried the path completion?
Alternatively, I suggest making a script
$ cat > $HOME/bin/git-showrel << \EOF
#!/bin/sh
git show "$(echo "$1" | sed "s|:|:$(git rev-parse --show-prefix)|")"
EOF
$ chmod a+x $HOME/bin/git-showrel
Then
$ git showrel HEAD:file
will do what you want.
(An alias will not work, since the cwd will be the project root.)
Hth,
Dscho
P.S.: I just tried "git show HEAD~20:<filename with : in it>" and it did
not work... I consider this a more serious issue than the relative path
one.
^ permalink raw reply
* RE: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-18 22:48 UTC (permalink / raw)
To: Gerald Gutierrez; +Cc: 'Matthieu Moy', 'Junio C Hamano', git
In-Reply-To: <000d01c841c5$386f7350$762a14ac@na.acco.com>
Hi,
On Tue, 18 Dec 2007, Gerald Gutierrez wrote:
[who said that? (I know, but would you know in a few weeks? Right.)]
> > What you seem to expect is to tell git "commit the changes except this
> > portion", what you have to tell git is actually "commit the new state,
> > but not if this portion is the only change". That sounds identical,
> > but it's actually a bit different.
>
> It's not what I'm saying.
>
> Here's what the git-commit manpage on kernel.org says: "git-commit -
> Record changes to the repository".
Yes. Changes, as in "take this _file_ instead". Not "edit this file,
remove those lines, add these here, etc.".
So I think that you were saying exactly what Matthieu suggested.
Ciao,
Dscho
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Johannes Schindelin @ 2007-12-18 22:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, git, Junio C Hamano, Linus Torvalds, Dana How
In-Reply-To: <20071218222032.GH2875@steel.home>
Hi,
On Tue, 18 Dec 2007, Alex Riesen wrote:
> Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:
> > On Tue, 18 Dec 2007, Alex Riesen wrote:
> >
> > > I think that we have parsing of the blob locators at the wrong
> > > level: so that git-show, git-log and git-diff can handle its
> > > pathnames as they handle path filters (relative to cwd),
> >
> > What cwd? <path> in <tree-ish>:<path> syntax is "relative" to
> > <tree-ish>.
>
> But the act of running "git-show <tree-ish>:<path>" does have a working
> directory relative to the project root.
Not necessarily. My primary use of "git show <tree-ish>:<path>" (yes, I
already use the dash-less form ;-) is in _bare_ repositories.
And I still maintain that expecting <tree-ish>:<path> to take the current
relative path into account would be just like if you expected
C:\> cd WINDOWS
C:\WINDOWS> dir D:system32
to show you the contents of D:\WINDOWS\system32.
Or another, less Windowsy example:
$ cd /usr/bin
$ scp home:bash ./
No, this does not copy home:/usr/bin/bash but home:$HOME/bash.
Hth,
Dscho
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-18 22:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Jakub Narebski, Alex Riesen, git,
Johannes Schindelin, danahow
In-Reply-To: <7vejdjy79y.fsf@gitster.siamese.dyndns.org>
On Dec 18, 2007 2:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > where the magic is *not* done by any "SHA1 path lookup" at all, but is
> > simply done by the commit->tree lookup. At least at that point it would
> > make logical sense (although it would probably be quite painful to
> > implement).
>
> It is not just painful to implement.
>
> Although I can buy that purely from the user (read: people who do not
> know how the world works) experience point of view, you have to be extra
> careful if you do this. There are existing codepaths that take a string
> that names a treeish from the end user, appends "^{tree}" to that
> string, and passes the result to get_sha1() to obtain a tree object name
> they want to operate on (the alternative is parse_tree_indirect() but it
> forces them to go through the object layer). You will need to update
> these callers to keep them working from subdirectories.
Thanks, I didn't know about those "^{tree}" codepaths.
How about this:
<tree-ish>:./path -> NEW: relative
<tree-ish>:../path -> NEW: relative
<tree-ish>:?pattern -> NEW: same as next (current :/ )
<tree-ish>:/pattern -> unchanged (sha1_name_oneline IIRC)
<tree-ish>:path -> unchanged: absolute
This shouldn't need to know if tree-ish references a commit or not.
Someday later, the last 2 cases could be changed to be more
like the Unix command line if desired. This is very similar to
Junio's response last May (by memory).
Typing an extra "./" is a big improvement over a long path prefix.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Alex Riesen @ 2007-12-18 22:29 UTC (permalink / raw)
To: Dana How
Cc: Linus Torvalds, Jakub Narebski, git, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <56b7f5510712181408g4aee55d2j2a7f0f13bf90323d@mail.gmail.com>
Dana How, Tue, Dec 18, 2007 23:08:33 +0100:
> When it *does* refer to a commit, then for commit:relpath you prefix
> relpath with the suffix of the cwd which is an extension beyond the root
> of the working tree.
...universally known as "prefix" (the last argument of builtin
commands) :)
> > where the magic is *not* done by any "SHA1 path lookup" at all, but is
> > simply done by the commit->tree lookup. At least at that point it would
> > make logical sense (although it would probably be quite painful to
> > implement).
>
> I must be missing something. The old patch I submitted did this.
> Its defect was that it did NOT make the cwd insertion conditional
> on whether the tree-ish involved a commit or not (a test which also
> _seems_ doable, but I don't think I finished it & sent it in).
It is also a bit painful: lots of funtions (sha1_name.c) will have
their prototypes changed to get the prefix (aka suffix). And their
callers...
^ permalink raw reply
* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-18 22:29 UTC (permalink / raw)
To: 'Matthieu Moy'
Cc: 'Junio C Hamano', 'Johannes Schindelin', git
In-Reply-To: <vpqsl1zfz8r.fsf@bauges.imag.fr>
> if (user_redefined_changed)
> if (user_defn_of_changed(work, head)) commit(work); else
> if (builtin_changed(work, head)) commit(work);
That didn't come out quite right. It should be:
if (user_redefined_changed) {
if (user_defn_of_changed(work, head)) { commit(work); }
} else {
if (builtin_changed(work, head)) { commit(work); }
}
^ permalink raw reply
* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-18 22:27 UTC (permalink / raw)
To: 'Matthieu Moy'
Cc: 'Junio C Hamano', 'Johannes Schindelin', git
In-Reply-To: <vpqsl1zfz8r.fsf@bauges.imag.fr>
> What you seem to expect is to tell git "commit the changes
> except this portion", what you have to tell git is actually
> "commit the new state, but not if this portion is the only
> change". That sounds identical, but it's actually a bit different.
It's not what I'm saying.
Here's what the git-commit manpage on kernel.org says: "git-commit - Record
changes to the repository".
What I am saying is that if the user defines a custom diff, it is reasonable
to believe that the user wants to teach git a new definition of "changes".
If that new definition says that the files have changed, then go ahead and
commit the new state. If that definition says there are no changes, then
there is nothing to commit. In other words:
if (user_redefined_changed)
if (user_defn_of_changed(work, head)) commit(work);
else
if (builtin_changed(work, head)) commit(work);
As it is, it's not a big deal to me. Instead of teaching git the different
concept of "changes", I teach the script that runs git instead. But teaching
git directly just seems cleaner and more intuitive.
Gerald.
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Junio C Hamano @ 2007-12-18 22:22 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <20071218154211.GB12549@alea.gnuu.de>
Jörg Sommer <joerg@alea.gnuu.de> writes:
> When it should go quick why don't use an alias. git stash can print the
> list and everyone who wants a quick stash can create an alias for this.
You are taking this completely backwards. The stash mechanism is all
about creating a quickie temporary pair of commits. Anybody who wants
otherwise can use alias or choose not to use stash at all.
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Junio C Hamano @ 2007-12-18 22:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jakub Narebski, Alex Riesen, git, Johannes Schindelin, Dana How
In-Reply-To: <alpine.LFD.0.9999.0712181347140.21557@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 18 Dec 2007, Jakub Narebski wrote:
>>
>> What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>.
>> IMHO "<tree-ish>:<path>" should be considered (and is considered) as
>> one object: current working directory doesn't matter at all there,
>> contrary to "<tree-ish> -- <pathspec>" where it is natural that <pathspec>
>> is relative to current working directory.
>
> Indeed.
>
> The <treeish>:<path> syntax *is* relative, but it's relative to the exact
> *treeish* that is given. It has nothing what-so-ever to do with the
> current working directory, since the user has explicitly given an exact
> tree object, and trying to fake that out would be actively wrong.
>
> That said, I can kind of understand the wish for something like this, and
> I suspect that we could make the "commit->tree" translation take the
> current path into account. In other words, maybe we should have something
> like this:
>
> /*
> * This sequence currently works
> */
> [torvalds@woody git]$ git rev-parse HEAD
> f9c5a80cdf2265f2df7712fad9f1fb7ef68b4768
>
> [torvalds@woody git]$ git rev-parse HEAD^{tree}
> 051fb0c0dff4371f97f8ad9407f9f1fd335b1682
>
> [torvalds@woody git]$ git rev-parse HEAD^{tree}:t
> 49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> /*
> * .. but this would be new
> */
> [torvalds@woody git]$ cd t
> [torvalds@woody t]$ git rev-parse HEAD^{tree}
> 49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> where the magic is *not* done by any "SHA1 path lookup" at all, but is
> simply done by the commit->tree lookup. At least at that point it would
> make logical sense (although it would probably be quite painful to
> implement).
It is not just painful to implement.
Although I can buy that purely from the user (read: people who do not
know how the world works) experience point of view, you have to be extra
careful if you do this. There are existing codepaths that take a string
that names a treeish from the end user, appends "^{tree}" to that
string, and passes the result to get_sha1() to obtain a tree object name
they want to operate on (the alternative is parse_tree_indirect() but it
forces them to go through the object layer). You will need to update
these callers to keep them working from subdirectories.
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Alex Riesen @ 2007-12-18 22:20 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Dana How
In-Reply-To: <200712182224.28152.jnareb@gmail.com>
Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:
> On Tue, 18 Dec 2007, Alex Riesen wrote:
> > I think that we have parsing of the blob locators at the wrong level:
> > so that git-show, git-log and git-diff can handle its pathnames as
> > they handle path filters (relative to cwd),
>
> What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>.
But the act of running "git-show <tree-ish>:<path>" does have a
working directory relative to the project root. And usually the
relative directory makes a lot of sense in git-show commands.
> What should git do in your proposal when we are on master branch in
> Documentation subdirectory, and want to check TODO file in todo branch?
> "git show todo:TODO" is most natural IMHO.
Yes, and that's why I NAKed the patches in the mail to Dana. I just
hope the problem gets some attention. Maybe I even get something out
of it, maybe not. It is not that hard to keep the patches in my tree.
> Note that for true <tree> as <tree-ish> you just don't know where
> in the working area directory hierarchy <tree> can be. This means you
> do't know relation of <tree> and <path> in <tree>:<path> to cwd.
I understand. But... How often do you think people use git show with a
tree which was not pointed by a commit?
> > and git-cat-file,
> > git-diff-tree, git-rev-list, etc can handle theirs always relative to
> > the project root.
>
> Not "relative to project root". Relative to tree-ish used on right hand
> side in <tree-ish>:<path> extended SHA-1 syntax. It is usually project
> root, because when you specify <commit> or <tag> as <tree-ish> it refers
> to top/root directory of a project.
I know. My problem: it is also awkward. git-show :test-l<Tab>ib.sh just
does not do what I expect. Nor does git cat-file HEAD:test-l<Tab>ib.sh.
And git cat-file HEAD:t/test-l<Tab> does not work at all. And this is
very simple example. Normally the pathnames are about 100 characters
long.
You know, it maybe as much correct as you wish, but is not very
usable (and no, I can't use the contributed completion. For lots of
reasons).
> > I actually do not see any problem for git-show (being porcelain-level
> > program) to treat *each and every* path anywhere relatively to the
> > current directory. It is just more comfortable.
>
> This breaks backward compatibility, hard. And IMHO breaks layers.
Maybe they should be broken in porcelain...
> But if (big if) it was to be implemented, default behavior should be
> unchanged, and relative to the cwd (layers!) should use new syntax,
> for example
>
> $ cd $GIT/t
> $ git show 570f32266:t/test-lib.sh # works
> $ git show 570f32266:test-lib.sh # should not work
Well... Frankly, I suggest changing this for porcelain-level
commands (show and diff) and leave it as it is for plumbing.
> $ git show 570f32266:./test-lib.sh # should work
Definitely. I even implemented a patch to allow just this, but scraped
it: it looked a bit small and the syntax is not obvious to the user.
Maybe that is what I end up with, though.
> $ git show 570f32266:/t/test-lib.sh # should perhaps work
> Currently ":/<text>" (but not "<ref>:/<text>") is taken; see
Yes, and it becomes more and more an obstacle. With just one user
standing, AFAICS (/me considers Dscho's assassination for moment...
Nah... Maybe poison?)
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-18 22:13 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <20071218154211.GB12549@alea.gnuu.de>
Hi,
[please do not cull me from the Cc list, should you reply to this]
On Tue, 18 Dec 2007, J?rg Sommer wrote:
> Junio C Hamano schrieb am Mon 17. Dec, 16:31 (-0800):
> > Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> >
> > >> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> > >>
> > >>> ... The current behavior of git stash is very
> > >>> dangerous ...
> > > ...
> > >> This is a plain FUD, isn't it? The first Oops should not happen
> > >> these days.
> >
> > But the original point by Sebastian hasn't been answered. He wanted
> > to make the command list the stash without arguments.
> >
> > This was discussed already in the early days of stash and there indeed
> > was a suggestion to do so (I think I sided with that), but the users
> > did not want it. IIRC, the argument went like: "when I say 'stash',
> > that is because I want a quick and immediate way to stash, and I do
> > not want a list. If I do not have to have a quick way, I would create
> > a temporary commit on the current branch, or switch to a temporary
> > branch and commit there."
>
> When it should go quick why don't use an alias. git stash can print the
> list and everyone who wants a quick stash can create an alias for this.
>
> I vote for stash print the list, because I dropped in the pitfall.
And in a fresh clone, this list is empty, showing nothing at all. Leading
the other half of the users to believe that the stash succeeded.
If stashing as the default operation of stash is ill-advised, showing the
list is even more so.
Ciao,
Dscho
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-18 22:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jakub Narebski, Alex Riesen, git, Junio C Hamano,
Johannes Schindelin, danahow
In-Reply-To: <alpine.LFD.0.9999.0712181347140.21557@woody.linux-foundation.org>
On Dec 18, 2007 1:53 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 18 Dec 2007, Jakub Narebski wrote:
> >
> > What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>.
> > IMHO "<tree-ish>:<path>" should be considered (and is considered) as
> > one object: current working directory doesn't matter at all there,
> > contrary to "<tree-ish> -- <pathspec>" where it is natural that <pathspec>
> > is relative to current working directory.
>
> Indeed.
>
> The <treeish>:<path> syntax *is* relative, but it's relative to the exact
> *treeish* that is given. It has nothing what-so-ever to do with the
> current working directory, since the user has explicitly given an exact
> tree object, and trying to fake that out would be actively wrong.
I think the solution is to use the cwd only when the tree-ish refers
to a commit.
If it refers explicitly to a tree (or to a tree through a tag w/o
going through a commit)
then you don't make any modification.
When it *does* refer to a commit, then for commit:relpath you prefix
relpath with the suffix of the cwd which is an extension beyond the root
of the working tree.
At the time I thought this through submodules didn't exist.
Clearly that case needs to be thought through as well.
> That said, I can kind of understand the wish for something like this, and
> I suspect that we could make the "commit->tree" translation take the
> current path into account. In other words, maybe we should have something
> like this:
>
> /*
> * This sequence currently works
> */
> [torvalds@woody git]$ git rev-parse HEAD
> f9c5a80cdf2265f2df7712fad9f1fb7ef68b4768
>
> [torvalds@woody git]$ git rev-parse HEAD^{tree}
> 051fb0c0dff4371f97f8ad9407f9f1fd335b1682
>
> [torvalds@woody git]$ git rev-parse HEAD^{tree}:t
> 49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> /*
> * .. but this would be new
> */
> [torvalds@woody git]$ cd t
> [torvalds@woody t]$ git rev-parse HEAD^{tree}
> 49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> where the magic is *not* done by any "SHA1 path lookup" at all, but is
> simply done by the commit->tree lookup. At least at that point it would
> make logical sense (although it would probably be quite painful to
> implement).
I must be missing something. The old patch I submitted did this.
Its defect was that it did NOT make the cwd insertion conditional
on whether the tree-ish involved a commit or not (a test which also
_seems_ doable, but I don't think I finished it & sent it in).
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Jörg Sommer @ 2007-12-18 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vfxy04ze7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
Hi,
Junio C Hamano schrieb am Mon 17. Dec, 16:31 (-0800):
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
> >> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> >>
> >>> ... The current behavior of git stash is very
> >>> dangerous ...
> > ...
> >> This is a plain FUD, isn't it? The first Oops should not happen these
> >> days.
>
> But the original point by Sebastian hasn't been answered. He wanted to
> make the command list the stash without arguments.
>
> This was discussed already in the early days of stash and there indeed
> was a suggestion to do so (I think I sided with that), but the users did
> not want it. IIRC, the argument went like: "when I say 'stash', that is
> because I want a quick and immediate way to stash, and I do not want a
> list. If I do not have to have a quick way, I would create a temporary
> commit on the current branch, or switch to a temporary branch and commit
> there."
When it should go quick why don't use an alias. git stash can print the
list and everyone who wants a quick stash can create an alias for this.
I vote for stash print the list, because I dropped in the pitfall.
Bye, Jörg.
--
Die beste Tarnung ist die Wahrheit. Die glaubt einem keiner!
(Max Frisch: ‚Biedermann und die Brandstifter‘)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about git-svn import
From: Jörg Sommer @ 2007-12-18 15:31 UTC (permalink / raw)
To: git list
In-Reply-To: <4767724A.9040207@obry.net>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
Hello Pascal,
Pascal Obry schrieb am Tue 18. Dec, 08:10 (+0100):
> Steven Walter a écrit :
> > Not sure if this is the best way, but I would recommend cloning into two
> > repositories, then combining them.
>
> I feared that :)
It's not as complicated as you might think.
> > So you already have the newer
> > changes with the standard layout. You would now:
> >
> > $ git svn init <repo>
> >
> > And only fetch the revisions before the layout change. You could then
> > combine the two repositories using .git/info/grafts and
> > git-rewrite-branch.
>
> Hum, looks like something not easy to do (at least for a Git beginner
> like me) ! Any documentation on this ? Would you mind showing this on
> the example script I sent ?
I had the same problem. We changed the structure of our SVN repository
from /trunk/pkg to /pkg/trunk and git-svn couldn't deal with this.
I used the script posted in
http://lists.alioth.debian.org/pipermail/pkg-jed-devel/2007-December/001719.html
to do the switch.
Some suggestions:
1. Import both parts into one git repo into their own branches. (use
--prefix)
2. Use gitk to insprect the history to find bad commits, e.g. empty
commits or things git-svn imported wrong.
3. Use git-filter-branch with the --parent-filter to join the branches.
HTH, Jörg.
--
Die am Lautesten reden, haben stets am wenigsten zu sagen.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-18 22:00 UTC (permalink / raw)
To: Gerald Gutierrez; +Cc: 'Junio C Hamano', 'Matthieu Moy', git
In-Reply-To: <000201c841c0$2e5e08e0$762a14ac@na.acco.com>
Hi,
On Tue, 18 Dec 2007, Gerald Gutierrez wrote:
> I don't understand how it is a benefit to have "git commit" and "git
> diff" do different diff functions. It confuses me.
Matthieu said it better than I ever could.
Ciao,
Dscho
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-18 21:51 UTC (permalink / raw)
To: Gerald Gutierrez
Cc: 'Junio C Hamano', 'Johannes Schindelin', git
In-Reply-To: <000101c841b7$5f1d1060$762a14ac@na.acco.com>
"Gerald Gutierrez" <ggmlfs@gmail.com> writes:
> Yes, but wouldn't it be slick to actually teach git's internal diff to do
> things like GNU diff can, like the ignore option -I, case insensitivity,
> etc. I thought that's what the external diff capability is for, but it is
> not so.
Don't confuse diff and commit.
Git is really snapshot oriented. When you commit, you don't say
"record the changes I made since HEAD", you say "record the current
state of the working tree, and also record the fact that this state is
based on HEAD".
See what a commit object looks like:
$ git cat-file -p 183f84365d
tree 3f9d576b4adc78188a411104bc21159d459fa3f4
parent b9c506f7d9f05a630fa7e31b77a9cf5081d7dbba
author Shun Kei Leung <kevinlsk@gmail.com> 1195614079 +0800
committer Junio C Hamano <gitster@pobox.com> 1195630064 -0800
git-p4: Fix typo in --detect-labels
Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$ _
The "tree" tells you the state of the project as recorded by commit,
and the "parent" tells you where the HEAD was pointing to at commit
time. That's really the raw information recorded by git.
Now, "diff" comes into the picture for two things: 1) storage
efficiency (you prefer a 1Mb pack file to a 1Gb uncompressed
repository), but that doesn't change the concept, and 2) user
interface.
When you say "git show HEAD", for example, git will recompute a diff,
and show it to you because this is what you expect. But this
information is computed at "git show" time, not at "git commit" time.
What you seem to expect is to tell git "commit the changes except this
portion", what you have to tell git is actually "commit the new state,
but not if this portion is the only change". That sounds identical,
but it's actually a bit different.
--
Matthieu
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Linus Torvalds @ 2007-12-18 21:53 UTC (permalink / raw)
To: Jakub Narebski
Cc: Alex Riesen, git, Junio C Hamano, Johannes Schindelin, Dana How
In-Reply-To: <200712182224.28152.jnareb@gmail.com>
On Tue, 18 Dec 2007, Jakub Narebski wrote:
>
> What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>.
> IMHO "<tree-ish>:<path>" should be considered (and is considered) as
> one object: current working directory doesn't matter at all there,
> contrary to "<tree-ish> -- <pathspec>" where it is natural that <pathspec>
> is relative to current working directory.
Indeed.
The <treeish>:<path> syntax *is* relative, but it's relative to the exact
*treeish* that is given. It has nothing what-so-ever to do with the
current working directory, since the user has explicitly given an exact
tree object, and trying to fake that out would be actively wrong.
That said, I can kind of understand the wish for something like this, and
I suspect that we could make the "commit->tree" translation take the
current path into account. In other words, maybe we should have something
like this:
/*
* This sequence currently works
*/
[torvalds@woody git]$ git rev-parse HEAD
f9c5a80cdf2265f2df7712fad9f1fb7ef68b4768
[torvalds@woody git]$ git rev-parse HEAD^{tree}
051fb0c0dff4371f97f8ad9407f9f1fd335b1682
[torvalds@woody git]$ git rev-parse HEAD^{tree}:t
49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
/*
* .. but this would be new
*/
[torvalds@woody git]$ cd t
[torvalds@woody t]$ git rev-parse HEAD^{tree}
49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
where the magic is *not* done by any "SHA1 path lookup" at all, but is
simply done by the commit->tree lookup. At least at that point it would
make logical sense (although it would probably be quite painful to
implement).
Linus
^ permalink raw reply
* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-18 21:51 UTC (permalink / raw)
To: 'Johannes Schindelin'
Cc: 'Junio C Hamano', 'Matthieu Moy', git
In-Reply-To: <Pine.LNX.4.64.0712182124410.23902@racer.site>
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> Sent: Tuesday, December 18, 2007 1:27 PM
> To: Gerald Gutierrez
> Cc: 'Junio C Hamano'; 'Matthieu Moy'; git@vger.kernel.org
> Subject: RE: git with custom diff for commits
>
> Hi,
>
> On Tue, 18 Dec 2007, Gerald Gutierrez wrote:
>
> > Yes, but wouldn't it be slick to actually teach git's
> internal diff to
> > do things like GNU diff can, like the ignore option -I, case
> > insensitivity, etc. I thought that's what the external diff
> capability
> > is for, but it is not so.
>
> I disagree. Your statement is misleading when you say you
> want the internal diff to do things like GNU diff can.
>
> What you want to do _in fact_ is not only modify the diff
> _output_, but the commit _input_.
>
> And I am not so keen on such filters. If I do not want to
> commit, I do not change it to begin with. Yes, your
> mysqldump is a special case here.
> But it is special anyway, as it is not source code.
I don't understand how it is a benefit to have "git commit" and "git diff"
do different diff functions. It confuses me. A scenario: I keep doing git
diff's and it says there is no difference, but then git commit keeps telling
me there is.
While I understand it was built for the kernel and everybody likes the plain
text format, it is not a stretch of the imagination to have files that are
semantically identical but have byte-wise differences. OpenDocument files,
image files, XML, etc. Cases can be made either way that "the same" means
semantically or byte-wise. It's perfectly fine that the default is
byte-wise. But, if the user takes the time to build a custom diff, then
wouldn't it be reasonable to assume that user means for git to do semantic
comparisons for diff, commit and other git functions, even if there are
inconsequential byte-wise differences in the file itself?
Gerald.
^ 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