* 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: 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 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: git-stash: RFC: Adopt the default behavior to other commands
From: André Goddard Rosa @ 2007-12-18 23:32 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <20071218154211.GB12549@alea.gnuu.de>
On Dec 18, 2007 1:42 PM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> 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.
>
I got caught by this default too. One vote more!
Regards,
--
[]s,
André Goddard
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Martin Langhoff @ 2007-12-18 23:41 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <20071218154211.GB12549@alea.gnuu.de>
On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> I vote for stash print the list, because I dropped in the pitfall.
I've dropped there myself, and work with a large team where we are
both fans of stash, and scarred by it. Any newcomer to git that
"discovers" stash gets hit by it a dozen times, this is completely
unnecesary.
All state-changing commands need parameters or are interactive (as
it's the case with git-commit). That Johannes & early adopters,
including me, have gotten used to the unintuitive (and dangerously
surprising) behaviour of stash is no excuse to inflict it upon actual
end users. It's way too early for git and the stash command to stick
to a misfeature in the name of backwards compat. We'll adapt, as we
have in the past, to an evolving ui.
And if -- in a new repo -- the list is empty, we can just say so:
Nothing has been stashed yet. Which looks completely different from a
successful stash 'save' command.
cheers,
m
^ permalink raw reply
* Re: git with custom diff for commits
From: Martin Langhoff @ 2007-12-18 23:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, Matthieu Moy, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712182246230.23902@racer.site>
On Dec 19, 2007 11:48 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Yes. Changes, as in "take this _file_ instead". Not "edit this file,
> remove those lines, add these here, etc.".
Exactly. GIT is a "content tracker" that doesn't care about any
semantic meaning in your files. Here's the file, git will store it, as
is. No conversions, not fancy interpretations. Strict, safe and fast.
(There's a small exception there for DOS-style newlines, which was
much resisted.)
You can add external machinery that is aware of your content semantics
-- as you've done with calling GNU diff with ignore patterns to decide
whether to commit or not. But when you tell GIT to commit something,
there's no guessing or transformation involved.
A lot of what GIT achieves is based on that founding principle. Remove
it, and we're toast. For starters, the internal machinery is based on
SHA1 digests that change if you flip a single byte. That's what makes
git fast and realiable. It's not merely an end-user thing.
cheers,
m
^ permalink raw reply
* [BUG] Invalid rebase command leaves unclean status
From: ulrik @ 2007-12-19 0:47 UTC (permalink / raw)
To: git
Hello git list
A bug in rebase -i: A typo in the command (for example in the branch
name) still makes later invocations of rebase think a rebase is
already in process.
I found this bug in master, and it was already reported to the mailing
list under version 1.5.3.5, but there were no follow-ups to that mail.
I'm using 1.5.3.7 and it is still present, and looking at the maint
branch it does not seem to be mentioned in post-x.3.7 changes there.
So I am now reporting this bug again. I'm sorry for not checking this
in master, I'll have to ask someone on the list to do that.
Original email:
http://marc.info/?l=git&m=119410951019002&w=2
Date: 2007-11-03 17:04:51
Message-ID: 200711031804.52259.elendil () planet ! nl
# A sample session:
# Invoking rebase with a typo, there is no "muster" branch
$ git rebase -i muster
fatal: Needed a single revision
Invalid base
$ git rebase -i master
Interactive rebase already started
$ git rebase --abort
fatal: Needed a single revision
# Even though rebase --abort reports an error, rebase's internal state
is now cleared
Regards,
Ulrik Sverdrup
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Linus Torvalds @ 2007-12-19 1:16 UTC (permalink / raw)
To: Dana How
Cc: Johannes Schindelin, Alex Riesen, Jakub Narebski, git,
Junio C Hamano
In-Reply-To: <56b7f5510712181503l1e5dcacds23511d968f98aedb@mail.gmail.com>
On Tue, 18 Dec 2007, Dana How wrote:
>
> 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.
No.
The cases we're talking of are *not* subtrees of the working tree.
The SHA1 of a commit may well be a totally disjoint tree. Try it in the
git repository with something like
git show origin/man:man1/git-fsck.1
or
git show origin/todo:TODO
and realize that Dscho's examples of using the DOS/Windows drive letters
is actually a really good example of what that <commit>:<pathname> syntax
is.
In fact, you can very well think of the commit/tree as a "drive letter".
It really does go into another namespace entirely. It's just that often
that namespace does bear some relationship to the currently checked out
branch. But that's just an "often", it's not at all a given.
> 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
It's not about "convenience". It's about *sanity* and good design. And the
fact is, that "commit:path" format really has nothing to do with the CWD
in the general case.
Linus
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-19 1:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Alex Riesen, Jakub Narebski, git, danahow
In-Reply-To: <alpine.LFD.0.9999.0712181711100.21557@woody.linux-foundation.org>
On Dec 18, 2007 5:16 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 18 Dec 2007, Dana How wrote:
> > The cases we are talking about are all subtrees of the working tree.
> > There is a useful cwd suffix.
>
> No.
>
> The cases we're talking of are *not* subtrees of the working tree.
>
> The SHA1 of a commit may well be a totally disjoint tree. Try it in the
> git repository with something like
Agreed, but note you wrote *may*.
I'd like to move some stuff currently in a p4 repository into git.
The directory structure within the repo is 13 levels deep;
I didn't design it nor can I change it.
For the majority of the cases of interest to me git already accepts
relative paths. However, one thing people do often in p4 (or any SCM)
is look at (or compare, etc) specific revisions. Unfortunately, these are
not part of branches or commits, they are just file-specific revisions
(don't get me started on p4 "branches"). The equivalent in git is
to use a commit name (or a tag) and then name the file. The
basic commit:file syntax doesn't accept relative paths. I am not
specifically hung up on the commit:./path syntax; I just want some
notation that will get those 13 directories from $cwd instead of
making me type them again. Yes, sometimes that might not make
sense to request.
There was some mention of bash/zsh completions Unfortunately,
much of our CAD environment is not configured in bash/zsh,
so although I use bash for some scripting,
it's not the default for command-line, and won't be used by
others I need to drag along with me...
> In fact, you can very well think of the commit/tree as a "drive letter".
> It really does go into another namespace entirely. It's just that often
> that namespace does bear some relationship to the currently checked out
> branch. But that's just an "often", it's not at all a given.
>
> > 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
>
> It's not about "convenience". It's about *sanity* and good design. And the
> fact is, that "commit:path" format really has nothing to do with the CWD
> in the general case.
Yes I frequently get to be one of the people here pushing for
(and sometimes losing the case for) "good design".
But I will never be able to successfully argue for retyping 13 directories
already in the cwd because it's the "good" or "sane" thing to do.
Given that the root of the current working tree, the commit, the cwd,
and the path (suffix) given on the command line are all known precisely,
it does not seem dangerous to come up with an exact rule to combine them
which is only triggered by some specific syntax.
This does not need to work in bare repositories.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
(Junio removed from cc: at his request)
^ permalink raw reply
* bug with .gitattributes diff and embedded NUL
From: Eric Blake @ 2007-12-19 5:07 UTC (permalink / raw)
To: git
The man page for gitattributes suggests that one use of the diff attribute
is to force text-based diffs, even when the file contains embedded NULs.
Yet actually trying this falls flat, since git generates invalid diffs
when encountering embedded NUL.
Here is a pared-down example showing the bug. I based it off of what I
was trying to do in the git repository for GNU m4, where I was working on
adding testcases to make m4 seamlessly handle embedded NUL.
$ git --version
git version 1.5.4.rc0.67.gf9c5
$ mkdir sample
$ cd sample
$ git init
Initialized empty Git repository in .git/
$ printf 'context with\0embedded nul\nbefore\nmore context\n' > file
$ git add file
$ git commit -m initial
Created initial commit 25108f6: initial
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
$ git tag t1
$ sed -i 's/before/after/' file
$ git add file
$ git commit -m later
Created commit a5ee10c: later
1 files changed, 0 insertions(+), 0 deletions(-)
$ git tag t2
$ git reset --hard t1
HEAD is now at 25108f6... initial
$ sed -i 's/more/some &/' file
$ echo 'file diff' > .gitattributes
$ git add .gitattributes file
$ git commit -m 'switch file to text mode'
Created commit 0f2a9b2: switch file to text mode
2 files changed, 2 insertions(+), 1 deletions(-)
create mode 100644 .gitattributes
$ git tag t3
$ git reset --hard t2
HEAD is now at a5ee10c... later
$ git rebase --onto t3 t1
First, rewinding head to replay your work on top of it...
HEAD is now at 0f2a9b2... switch file to text mode
Applying later
error: patch failed: file:1
error: file: patch does not apply
Using index info to reconstruct a base tree...
error: patch failed: file:1
error: file: patch does not apply
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.
Patch failed at 0001.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
Looking closer at .dotest/0001, the diff is indeed invalid, containing the
single line
context with-before
instead of the desired two lines
context with^@embedded nul
-before
I'm also wondering if using GIT_EXTERNAL_DIFF would provide a way to work
around this bug in git diff, since GNU diffutils doesn't seem to have any
problems when doing text-mode diffs with embedded NUL:
$ diff -u -a <(git show t1:file) <(git show t2:file) | cat -v
--- /dev/fd/63 2006-11-30 17:00:00.000000000 -0700
+++ /dev/fd/62 2006-11-30 17:00:00.000000000 -0700
@@ -1,3 +1,3 @@
context with^@embedded nul
-before
+after
more context
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
^ permalink raw reply
* Re: bug with .gitattributes diff and embedded NUL
From: Junio C Hamano @ 2007-12-19 6:40 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <4768A70F.8020904@byu.net>
Eric Blake <ebb9@byu.net> writes:
> Looking closer at .dotest/0001, the diff is indeed invalid, containing the
> single line
That is not a bug in diff but actually in bug in non-merge form of
rebase, which reuses "format patch as if we are sending it out in
e-mail, and apply that on top of a different commit as if we are
accepting that e-mail" machinery. That dataflow loses NUL. Fixing
rebase not to reuse the e-mailed patch dataflow is on my to-do list, but
has been slipping.
So, no, I do not think GIT_EXTERNAL_DIFF would help, as the problem is
not diff generation.
I think you can use "rebase -m" to work this issue around.
^ permalink raw reply
* [PATCH 1/2] Avoid update hook during git-rebase --interactive
From: Shawn O. Pearce @ 2007-12-19 6:41 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
If we are rebasing changes that contain potential whitespace
errors that our .git/hooks/pre-commit hook looks for and fails
on then git-commit will fail to commit that change. This causes
git-rebase--interactive to squash commits together, even though it
was not requested to do so by the todo file.
Passing --no-verify to git-commit makes git-rebase -i behave more
like git-rebase normally would in such conditions, providing more
consistent behavior between the different rebase implementations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This bug has bitten me more than once. One could argue that the
pre-commit hook should be running, to prevent you from rebasing a
series that has crappy whitespace, but git-rebase without -m and
without -i will let you rebase such a series without stopping you,
as git-am doesn't execute the pre-commit hook.
git-rebase--interactive.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cd7e43f..b846ea8 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -296,7 +296,7 @@ do_next () {
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
+ $USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT
;;
t)
cp "$MSG" "$GIT_DIR"/MERGE_MSG
@@ -372,7 +372,7 @@ do
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
- git commit -F "$DOTEST"/message -e
+ git commit --no-verify -F "$DOTEST"/message -e
require_clean_work_tree
do_rest
--
1.5.4.rc0.1155.g12ed9
^ permalink raw reply related
* [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive
From: Shawn O. Pearce @ 2007-12-19 6:45 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
If git-commit fails for any reason then git-rebase needs to stop
and not plow through the rest of the series. Its unlikely that
a future git-commit will succeed if the current attempt failed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Comments welcome. This is on top of my 1/2 patch but we could
drop my 1/2 and rewrite this to not use --no-verify, but handle
the git-commit error correctly.
However that would force users to fix whitespace errors in later
patches in a series if they use -i, even though non-i wouldn't
require that sort of fix-up. So I think we should do both patches
in the series.
This has also bitten me a few times. :-\
git-rebase--interactive.sh | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index b846ea8..0f7d939 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -289,22 +289,22 @@ do_next () {
output git reset --soft HEAD^
pick_one -n $sha1 || failed=t
echo "$author_script" > "$DOTEST"/author-script
- case $failed in
- f)
+ if test $failed = f
+ then
# This is like --amend, but with a different message
eval "$author_script"
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT
- ;;
- t)
+ $USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT || failed=t
+ fi
+ if test $failed = t
+ then
cp "$MSG" "$GIT_DIR"/MERGE_MSG
warn
warn "Could not apply $sha1... $rest"
die_with_patch $sha1 ""
- ;;
- esac
+ fi
;;
*)
warn "Unknown command: $command $sha1 $rest"
@@ -372,7 +372,8 @@ do
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
- git commit --no-verify -F "$DOTEST"/message -e
+ git commit --no-verify -F "$DOTEST"/message -e ||
+ die "Could not commit staged changes."
require_clean_work_tree
do_rest
--
1.5.4.rc0.1155.g12ed9
^ permalink raw reply related
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