* Re: several quick questions
From: Keith Packard @ 2006-02-14 18:55 UTC (permalink / raw)
To: Carl Worth; +Cc: keithp, Linus Torvalds, Nicolas Vilz 'niv', git
In-Reply-To: <87k6bxvmj6.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Tue, 2006-02-14 at 10:10 -0800, Carl Worth wrote:
> I don't know if it's the original poster's question or not, but an
> operation I don't see in the above is "put the working files into the
> state of a given revision".
I was using:
rm -r *
rm -f .cvsignore .gitignore
git-reset --hard <tag>
to get to a specific tag. Of course, I cloned the repository and did
this in a separate directory; I wanted to make sure nothing 'bad'
happened to my working directory.
Creating a fake branch seemed like a lot more bother.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Handling large files with GIT
From: Johannes Schindelin @ 2006-02-14 18:56 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <43F113A5.2080506@f2s.com>
Hi,
On Mon, 13 Feb 2006, Ian Molton wrote:
> Im curious as to why anyone would want to use a SCM tool on a mail dir
> anyway - surely no-one edits their pasnt mails and needs to keep logs?
>
> surely incremental backups would be a better way to manage something
> like this?
Point is, if you want to read your email on different computers (like one
desktop and one laptop), you are quite well off managing them with git. Of
course, you could rsync them from/to the other computer. But rsync is slow
once you accumulated enough files, since it has to compare the hashes of
tons of files (or file chunks). Git knows if they have changed.
Hth,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 19:00 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <87irrhvkyl.wl%cworth@cworth.org>
On Tue, 14 Feb 2006, Carl Worth wrote:
>
> Oh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for
> mentioning it elsewhere in the thread). So now I've at least got the
> recipe I was after:
>
> git-read-tree <revision>
> git-update-index --replace
> git-checkout-index -a -f -u
This is very very inefficient, because it will replace the old
index without using the (valid) information that is there from before.
Resulting in a lot of unnecessary IO..
You may not care for a small project, but for bigger stuff, you're better
off using more subtle approaches.
Explore using "git-read-tree --reset <revision>" or, perhaps even more
interesting is "git-read-tree -u -m <oldrev> <newrev>"
> And I think that would make for a dandy command to have in git. Any
> suggestions for a name?
I'd suggest "git reset" as a cool way to say that it "resets" the tree to
another version ;)
Linus
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 19:04 UTC (permalink / raw)
To: Keith Packard; +Cc: Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <1139943349.4341.66.camel@evo.keithp.com>
On Tue, 14 Feb 2006, Keith Packard wrote:
>
> I was using:
>
> rm -r *
> rm -f .cvsignore .gitignore
> git-reset --hard <tag>
Ooh.
Try doing that on a big project, and it will just kill you. You've also
lost the "top-of-branch" info, but if you're just tracking some other
tree, that's likely not an issue.
(actually, under Linux, with enough memory, and the git stuff all cached,
it will perform pretty well, but that's just because the OS does a _lot_
to try to hide how expensive it is to re-write everything. And even under
Linux it will suck in the cold-cache case).
> Creating a fake branch seemed like a lot more bother.
You'll find that if cairo ever grows bigger, it has huge advantages to
switch between branches (or any random state, for that matter) without
having to rewrite it all is a _major_ performance impact.
Linus
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 19:13 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87k6bxvmj6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> 2) Ensure that bogus-branch exists somewhere (don't care where), then
> move it:
>
> # Create the branch (if it doesn't exist)
> git checkout -b bogus-branch >& /dev/null
> # Switch to it (which doesn't happen above if it already existed)
> git checkout bogus-branch
> # Move the branch to the revision of interest
> git reset --hard <revision>
For moving around in history (like cg-seek if I understand
correctly), the above is the right and probably most efficient
way to do with the core-git tools.
# setup
$ git branch -f temp ;# make sure it exists
$ git checkout temp ;# and switch to it
# repeatedly...
$ git reset --hard <revision1>
# do interesting things
$ git reset --hard <revision2>
# do interesting things
$ git reset --hard <revision3>
# ...
$ git reset --hard <revisionn>
# do interesting things
# once you are done
$ git checkout master
$ git branch -D temp
^ permalink raw reply
* Re: several quick questions
From: Andreas Ericsson @ 2006-02-14 19:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141056170.3691@g5.osdl.org>
Linus Torvalds wrote:
>
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to
> another version ;)
>
OTOH, it would be nifty (and I imagine not particularly hard) to teach
"git checkout" to check out any revision, and not just a branch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: several quick questions
From: Keith Packard @ 2006-02-14 19:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141101110.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Tue, 2006-02-14 at 11:04 -0800, Linus Torvalds wrote:
> Try doing that on a big project, and it will just kill you. You've also
> lost the "top-of-branch" info, but if you're just tracking some other
> tree, that's likely not an issue.
I was validating the cvs import by comparing every tagged version. Trust
me, the git tree-rewriting stage was somewhat faster than the CVS
checkout of the same content. And, as an egg, one often prefers BFI to
finesse. I had trouble figuring out precisely what sequence of commands
were needed to make git-reset --hard happy with existing bits in the
directory.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 19:46 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43F20532.5000609@iaglans.de>
Hi,
now from the simple Cogito's point of view. I will swap the two parts
of your mail.
Dear diary, on Tue, Feb 14, 2006 at 05:28:34PM CET, I got a letter
where Nicolas Vilz 'niv' <niv@iaglans.de> said that...
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
>
> do you have to make a new private branch out of the tag 1.1.6?
>
> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.
The simple answer is cg-seek, which is meant for temporary ventures to
the commit history - e.g. you want to go back to git version 1.1.6, but
intend to do no development on top of it and to return back to the top
later. cg-seek will remember "where you came from" and by doing either
cg-reset or simply calling cg-seek without any parameters, it will
return back to the top.
If you want to permanently change your branch to point to the 1.1.6
tag, the command to use is cg-switch -f. There is also a simpler but
less powerful variant of this command available as cg-admin-uncommit.
> i wonder, how i revoke a straight forward merge of two trees... I
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
>
> do you have to make a new private branch out of the tag 1.1.6?
>
> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.
>
> I like git very much and every new day I like it more.
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
>
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
>
> maybe that was because i didn't do anything in my master tree in the
> meantime.
So I assume that it made a fast-forward merge and you want to undo it.
Unfortunately, there is no facility to automatically remember what your
previous last commit was, so you either:
* Remember the "fast-forwarding" message cg-merge gave you. ;-)
* Fire up cg-log and find the commit you want to go back to.
Now, when you have the commit id, this is the time for cg-switch -f -
what you want to do is to "repoint" your current branch (let's assume it
is master) to the commit id you've just found:
cg-switch -f -r commit_id master
(The same thing could be done using cg-admin-uncommit, but it is a
little confusing in this particular usage; you would have to rather
choose the commit id of the last commit to uncommit, and it does not
cope well with merges.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-14 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ian Molton, git
In-Reply-To: <Pine.LNX.4.63.0602141953000.22451@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 14 Feb 2006, Johannes Schindelin wrote:
>
> Point is, if you want to read your email on different computers (like one
> desktop and one laptop), you are quite well off managing them with git. Of
> course, you could rsync them from/to the other computer. But rsync is slow
> once you accumulated enough files, since it has to compare the hashes of
> tons of files (or file chunks). Git knows if they have changed.
Yes. I actually think that git would be a _wonderful_ email tracking tool,
but that may not mean that it's a wonderful tool for tracking all
particular email layout possibilities. It clearly is _not_ a wonderful
tool for tracking mbox-style email setups, for example ;)
I suspect we actually could make the "one linear directory" setup perform
pretty well. It wouldn't be the best possible layout (by far), but I think
our problems there are just because of some decisions we've (me, mostly)
made that didn't take that layout into account. I don't think the problems
are in any way fundamental.
That said, I think git could do much better if the layout was optimized
for git. For example, in the maildir thing, there's two issues: the flat
directory structure is sub-optimal, but the other thing seems to be that
maildir apparently saves metadata in the filename.
Saving meta-data in the filename should actually work wonderfully well
with git, but both merging and git-diff-tree consider the filename to be
the "index", so they optimize for that. You could do indexing the other
way around, and consider the contents to be the index (and the filename is
the "status"), but that's obviously not sane for a sw project, even if it
might be exactly what you want to do for mail handling.
Linus
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141026570.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]
On Tue, 14 Feb 2006 10:34:35 -0800 (PST), Linus Torvalds wrote:
> On Tue, 14 Feb 2006, Carl Worth wrote:
> >
> > I don't know if it's the original poster's question or not, but an
> > operation I don't see in the above is "put the working files into the
> > state of a given revision".
>
> What a strange thing to ask for.
It's pretty common in other tools. For example, many tools have a way
to examine the files from a previous state in a "no current branch"
state. Any attempt to commit from that state would prompt the user to
create a new branch name at that point.
In fact, this is the natural operation for the basis of something like
git-bisect.
> It's actually as efficient as anything else, and there's much less room
> for confusion. When you want to go back, you can just do a simple
>
> git checkout -f master
OK, the efficiency arguments made elsewhere in the thread make it
clear that these are the operations that need to happen.
But I'd still like to be able to do this without having to invent a
fake branch name, without the ability to accidentally commit on the
fake branch, and without the possibility of accidentally leaving those
commits dangling the next time I seek somewhere else.
So I looked, and git-bisect does use this approach with a fake branch
of "bisect" and by saving the original head ref in $GIT_DIR/head-name
for the sake of the final "git bisect reset".
Also, git-bisect does take advantage of the $GIT_DIR/head-name state
to prevent nested calls to "git bisect start", ("won't bisect on
seeked tree").
That gives a very natural name, "seek", for the operation I'd like.
How about "git seek" for doing the operations above, and using some
reserved branch name, (say "seek"). Then, git-bisect could easily be
built on that, and git-commit could respect the "seek" name and refuse
to commit to it, (could tell the user how to create the branch
necessary to commit from the current point).
There could also be a "git seek reset" to return to the HEAD saved by
the first in a chain of "git seek" operations.
That looks like I minor generalization of existing behavior in
git-bisect, but it would provide an operation that I would find
useful.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141056170.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
On Tue, 14 Feb 2006 11:00:44 -0800 (PST), Linus Torvalds wrote:
> > And I think that would make for a dandy command to have in git. Any
> > suggestions for a name?
>
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to
> another version ;)
Heh. It also moves a branch name though, and that's the part I don't
want. See my suggestion elsewhere of "git seek". [*]
-Carl
[*] Yes, I appear doomed to be reinventing cogito piecemeal. I got
"seek" from the error message in git-bisect, before I heard about
cg-seek, (as Junio pointed out elsewhere in the thread).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 20:27 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Nicolas Vilz 'niv', git
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>
Dear diary, on Tue, Feb 14, 2006 at 09:10:28PM CET, I got a letter
where Carl Worth <cworth@cworth.org> said that...
> That gives a very natural name, "seek", for the operation I'd like.
>
> How about "git seek" for doing the operations above, and using some
> reserved branch name, (say "seek"). Then, git-bisect could easily be
> built on that, and git-commit could respect the "seek" name and refuse
> to commit to it, (could tell the user how to create the branch
> necessary to commit from the current point).
>
> There could also be a "git seek reset" to return to the HEAD saved by
> the first in a chain of "git seek" operations.
>
> That looks like I minor generalization of existing behavior in
> git-bisect, but it would provide an operation that I would find
> useful.
Well, this is exactly what cg-seek does (and it's one of pretty old
Cogito commands) - it even has the same name. ;-) See my other mail in
this thread.
It works by creating a new branch cg-seek-point and storing the seeked
point there; if HEAD is already on the branch, it merely changes the
seek point and resets the working tree appropriately. cg-seek without
any arguments will then return to your original head, whose name was
stored in .git/head-name.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: several quick questions
From: Johannes Schindelin @ 2006-02-14 20:34 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F231C5.5010205@op5.se>
Hi,
On Tue, 14 Feb 2006, Andreas Ericsson wrote:
> [...] it would be nifty (and I imagine not particularly hard) to teach
> "git checkout" to check out any revision, and not just a branch.
You have to have a valid HEAD. So, you can create a throw-away branch
easily:
git-checkout -f throw HEAD~56
Hth,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Johannes Schindelin @ 2006-02-14 20:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git
In-Reply-To: <20060214202728.GE31278@pasky.or.cz>
Hi,
On Tue, 14 Feb 2006, Petr Baudis wrote:
> [...]
>
> It works by creating a new branch cg-seek-point and storing the seeked
> point there; if HEAD is already on the branch, it merely changes the
> seek point and resets the working tree appropriately. cg-seek without
> any arguments will then return to your original head, whose name was
> stored in .git/head-name.
And if you want to prevent accidental commit, just "chmod a-w
$GIT_DIR/index".
Ciao,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 20:40 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>
On Tue, 14 Feb 2006, Carl Worth wrote:
> >
> > What a strange thing to ask for.
>
> It's pretty common in other tools.
Well, it's pretty common in git too. But in git, the notion of "branch"
really has been made so cheap that it's basically a no-op.
The "overhead" of creating a branch is literally the cost of writing one
(small) file.
> In fact, this is the natural operation for the basis of something like
> git-bisect.
Right. And "git bisect" very much does exactly that. It creates a
temporary branch for bisection (the branch is called "bisect", one of the
less confusing naming decisions in git ;)
That's really my point. It all boils down to the same three operations:
"git branch", "git checkout" and "git reset".
In fact, if you look into git-bisect, you'll notice that it doesn't even
use "git reset" internally. It _literally_ creates a new branch (which it
does by hand for some strange reason, but never mind) called "new-bisect",
and then does "git checkout new-bisect" followed by renaming the branch
back to "bisect" (which it again does by hand).
So "git bisect" may actually get its hands dirty by knowing a bit too much
about the internal workings of git branches, but conceptually, it really
does just
git checkout -b new-bisect <newrev>
to switch its state around.
> But I'd still like to be able to do this without having to invent a
> fake branch name, without the ability to accidentally commit on the
> fake branch, and without the possibility of accidentally leaving those
> commits dangling the next time I seek somewhere else.
Pasky did this before the "multi-branch" thing was common, and calls it
"cg-seek".
I think that does exactly what you ask for, I just don't really see the
point. The downside of cg-seek is that you're really really limited to
what you can do with it.
For example, it may be "overhead" to have a dummy branch for bisection,
but it means (for example) that you can actually do real work on the point
that "git bisect" points you to.
For example, if you hit a compile error, you can _literally_ fix that
compile error AND COMMIT that state, and when you then mark that commit
"good" or "bad" when you continue to bisect, bisection will actually do
the right thing. Something that would be impossible in a "seek"
environment, where you don't have a branch that you can do development on.
I realize that when you come from an environment where branches are big
things, this is kind of strange. But in git, a branch is literally a
single file that is 41 bytes in size. That's it. No more, no less.
Linus
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 20:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 14 Feb 2006, Petr Baudis wrote:
>
>> [...]
>>
>> It works by creating a new branch cg-seek-point and storing the seeked
>> point there; if HEAD is already on the branch, it merely changes the
>> seek point and resets the working tree appropriately. cg-seek without
>> any arguments will then return to your original head, whose name was
>> stored in .git/head-name.
>
> And if you want to prevent accidental commit, just "chmod a-w
> $GIT_DIR/index".
That is a wrong answer. It is perfectly sane to modify index
without an intention to commit that change (you can always say
"git reset").
^ permalink raw reply
* [PATCH] commit: detect misspelled pathspec while making a partial commit.
From: Junio C Hamano @ 2006-02-14 20:46 UTC (permalink / raw)
To: pasky; +Cc: git
When you say "git commit Documentaiton" to make partial commit
for the files only in that directory, we did not detect that as
a misspelled pathname and attempted to commit index without
change. If nothing matched, there is no harm done, but if the
index gets modified otherwise by having another valid pathspec
or after an explicit update-index, a user will not notice
without paying attention to the "git status" preview.
This introduces --error-unmatch option to ls-files, and uses it
to detect this common user error.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Pasky, does this address the issue you mentioned earlier on
the #git channnel?
git-commit.sh | 16 +++++++++-------
ls-files.c | 51 ++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 53 insertions(+), 14 deletions(-)
c49ee6e0bba6c800f2c36df819973f3caac20fa4
diff --git a/git-commit.sh b/git-commit.sh
index ab5e6bc..f7ee1aa 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -180,6 +180,7 @@ verify=t
verbose=
signoff=
force_author=
+only_include_assumed=
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -340,12 +341,8 @@ case "$#,$also$only" in
0,)
;;
*,)
- echo >&2 "assuming --only paths..."
+ only_include_assumed="# Explicit paths specified without -i nor -o; assuming --only paths..."
also=
-
- # If we are going to launch an editor, the message won't be
- # shown without this...
- test -z "$log_given$status_only" && sleep 1
;;
esac
unset only
@@ -380,6 +377,8 @@ t,)
;;
,t)
save_index &&
+ git-ls-files --error-unmatch -- "$@" >/dev/null || exit
+
git-diff-files --name-only -z -- "$@" |
(
cd "$TOP"
@@ -408,7 +407,7 @@ t,)
refuse_partial "Different in index and the last commit:
$dirty_in_index"
fi
- commit_only=`git-ls-files -- "$@"`
+ commit_only=`git-ls-files --error-unmatch -- "$@"` || exit
# Build the temporary index and update the real index
# the same way.
@@ -569,7 +568,10 @@ else
PARENTS=""
fi
-run_status >>"$GIT_DIR"/COMMIT_EDITMSG
+{
+ test -z "$only_include_assumed" || echo "$only_include_assumed"
+ run_status
+} >>"$GIT_DIR"/COMMIT_EDITMSG
if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" ]
then
rm -f "$GIT_DIR/COMMIT_EDITMSG"
diff --git a/ls-files.c b/ls-files.c
index 7024cf1..a716e5f 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -25,6 +25,8 @@ static int line_terminator = '\n';
static int prefix_len = 0, prefix_offset = 0;
static const char *prefix = NULL;
static const char **pathspec = NULL;
+static int error_unmatch = 0;
+static char *ps_matched = NULL;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -325,7 +327,8 @@ static int cmp_name(const void *p1, cons
* Match a pathspec against a filename. The first "len" characters
* are the common prefix
*/
-static int match(const char **spec, const char *filename, int len)
+static int match(const char **spec, char *ps_matched,
+ const char *filename, int len)
{
const char *m;
@@ -333,17 +336,24 @@ static int match(const char **spec, cons
int matchlen = strlen(m + len);
if (!matchlen)
- return 1;
+ goto matched;
if (!strncmp(m + len, filename + len, matchlen)) {
if (m[len + matchlen - 1] == '/')
- return 1;
+ goto matched;
switch (filename[len + matchlen]) {
case '/': case '\0':
- return 1;
+ goto matched;
}
}
if (!fnmatch(m + len, filename + len, 0))
- return 1;
+ goto matched;
+ if (ps_matched)
+ ps_matched++;
+ continue;
+ matched:
+ if (ps_matched)
+ *ps_matched = 1;
+ return 1;
}
return 0;
}
@@ -356,7 +366,7 @@ static void show_dir_entry(const char *t
if (len >= ent->len)
die("git-ls-files: internal error - directory entry not superset of prefix");
- if (pathspec && !match(pathspec, ent->name, len))
+ if (pathspec && !match(pathspec, ps_matched, ent->name, len))
return;
fputs(tag, stdout);
@@ -444,7 +454,7 @@ static void show_ce_entry(const char *ta
if (len >= ce_namelen(ce))
die("git-ls-files: internal error - cache entry not superset of prefix");
- if (pathspec && !match(pathspec, ce->name, len))
+ if (pathspec && !match(pathspec, ps_matched, ce->name, len))
return;
if (!show_stage) {
@@ -699,6 +709,10 @@ int main(int argc, const char **argv)
prefix_offset = 0;
continue;
}
+ if (!strcmp(arg, "--error-unmatch")) {
+ error_unmatch = 1;
+ continue;
+ }
if (*arg == '-')
usage(ls_files_usage);
break;
@@ -710,6 +724,14 @@ int main(int argc, const char **argv)
if (pathspec)
verify_pathspec();
+ /* Treat unmatching pathspec elements as errors */
+ if (pathspec && error_unmatch) {
+ int num;
+ for (num = 0; pathspec[num]; num++)
+ ;
+ ps_matched = xcalloc(1, num);
+ }
+
if (show_ignored && !exc_given) {
fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
argv[0]);
@@ -725,5 +747,20 @@ int main(int argc, const char **argv)
if (prefix)
prune_cache();
show_files();
+
+ if (ps_matched) {
+ /* We need to make sure all pathspec matched otherwise
+ * it is an error.
+ */
+ int num, errors = 0;
+ for (num = 0; pathspec[num]; num++) {
+ if (ps_matched[num])
+ continue;
+ error("pathspec '%s' did not match any.",
+ pathspec[num] + prefix_len);
+ }
+ return errors ? 1 : 0;
+ }
+
return 0;
}
--
1.2.0.g6552
^ permalink raw reply related
* Re: several quick questions
From: Johannes Schindelin @ 2006-02-14 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgtr7u2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 14 Feb 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Tue, 14 Feb 2006, Petr Baudis wrote:
> >
> >> [...]
> >>
> >> It works by creating a new branch cg-seek-point and storing the seeked
> >> point there; if HEAD is already on the branch, it merely changes the
> >> seek point and resets the working tree appropriately. cg-seek without
> >> any arguments will then return to your original head, whose name was
> >> stored in .git/head-name.
> >
> > And if you want to prevent accidental commit, just "chmod a-w
> > $GIT_DIR/index".
>
> That is a wrong answer. It is perfectly sane to modify index
> without an intention to commit that change (you can always say
> "git reset").
Okay, I was not being completely truthful. If I did not get the original
idea of git-seek wrong, then it was kind of an excursion, just taking a
peek. And if you want to return from that excursion, I thought maybe it
would make sense to disallow index operations *at all* until returning to
the HEAD.
But I agree it is nasty. And Linus mentioned that the benefits of being
able to commit into a temporary branch outweigh the shortcoming easily.
(The shortcoming being that you have to keep in mind that you are in
another branch. Which does not come easily to a fresh CVS convert.)
Ciao,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 20:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Tue, Feb 14, 2006 at 09:37:39PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Tue, 14 Feb 2006, Petr Baudis wrote:
>
> > [...]
> >
> > It works by creating a new branch cg-seek-point and storing the seeked
> > point there; if HEAD is already on the branch, it merely changes the
> > seek point and resets the working tree appropriately. cg-seek without
> > any arguments will then return to your original head, whose name was
> > stored in .git/head-name.
>
> And if you want to prevent accidental commit, just "chmod a-w
> $GIT_DIR/index".
currently, Cogito has a generic "blocking" mechanism which will
prevent you to do operations mutating the history (mostly committing and
mergnign) - seeking is the only user now.
Note that this is not very flexible and I consider this legacy stuff;
I will replace that by a specific check for a seek when I have some time
(which will also make it compatible with the git-bisect-using-headname).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Chuck Lever @ 2006-02-14 20:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20060214160747.GA6350@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]
Karl Hasselström wrote:
> On 2006-02-14 10:22:51 -0500, Chuck Lever wrote:
>
>
>>Karl Hasselström wrote:
>>
>>
>>>One thing I would like to see in stgit is the opposite of "stg
>>>commit"; instead of converting patches to regular commits, take
>>>the topmost regular commits and convert them to patches.
>>>
>>>For example, "stg uncommit foo bar baz" would -- regardless of any
>>>existing patches, applied or not -- convert the top three regular
>>>commits, with comments and all, to stgit patches called foo, bar,
>>>and baz. These would be already applied, at the bottom of the
>>>stack. I imagine all one would have to do is to modify some stgit
>>>metadata, so the operation could be really cheap.
>>>
>>>Of course, "stg uncommit" is allowed to reject any commit with
>>>more than one parent, since those can't be represented as stgit
>>>patches.
>>>
>>>This would perhaps not add much power to an all-stgit workflow,
>>>but it would be a really convenient way to edit recent git
>>>history. Sort of like a more convenient rebase. And a great way to
>>>lure new users. :-)
>>
>>i think you want "stg pick --reverse" ?
>
>
> No, I literally want the opposite of "stg commit", so that the
> sequence "stg commit; stg uncommit" has zero net effect.
gotcha.
well, that would work OK for maintainers, but would be kind of strange
for folks who are pulling from such a repository. how would that work?
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 21:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141224110.3691@g5.osdl.org>
Dear diary, on Tue, Feb 14, 2006 at 09:40:24PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 14 Feb 2006, Carl Worth wrote:
> > But I'd still like to be able to do this without having to invent a
> > fake branch name, without the ability to accidentally commit on the
> > fake branch, and without the possibility of accidentally leaving those
> > commits dangling the next time I seek somewhere else.
>
> Pasky did this before the "multi-branch" thing was common, and calls it
> "cg-seek".
>
> I think that does exactly what you ask for, I just don't really see the
> point. The downside of cg-seek is that you're really really limited to
> what you can do with it.
>
> For example, it may be "overhead" to have a dummy branch for bisection,
> but it means (for example) that you can actually do real work on the point
> that "git bisect" points you to.
>
> For example, if you hit a compile error, you can _literally_ fix that
> compile error AND COMMIT that state, and when you then mark that commit
> "good" or "bad" when you continue to bisect, bisection will actually do
> the right thing. Something that would be impossible in a "seek"
> environment, where you don't have a branch that you can do development on.
That's a neat idea - I like this. I just tweaked cg-commit -f so that it
will now override the cg-seek block, with a warning that you should be
content about your commit being thrown away.
Really, except this blocking restriction (which is really a check for a
non-empty .git/blocked file), cg-seek does exactly the fake branch
thing, as you actually persuaded me to do. So you are on a dedicated
seeking branch and theoretically you can do development on it - it's
only too easy to lose the commits.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Handling large files with GIT
From: Sam Vilain @ 2006-02-14 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Ian Molton, git
In-Reply-To: <Pine.LNX.4.64.0602141108050.3691@g5.osdl.org>
Linus Torvalds wrote:
> That said, I think git could do much better if the layout was optimized
> for git. For example, in the maildir thing, there's two issues: the flat
> directory structure is sub-optimal, but the other thing seems to be that
> maildir apparently saves metadata in the filename.
>
> Saving meta-data in the filename should actually work wonderfully well
> with git, but both merging and git-diff-tree consider the filename to be
> the "index", so they optimize for that. You could do indexing the other
> way around, and consider the contents to be the index (and the filename is
> the "status"), but that's obviously not sane for a sw project, even if it
> might be exactly what you want to do for mail handling.
This seems to me to be another use case where git could gain orders of
magnitude speed improvement by either explicit ("forensic") history
objects, or a history analysis cache.
Sam.
^ permalink raw reply
* Re: [PATCH] commit: detect misspelled pathspec while making a partial commit.
From: Petr Baudis @ 2006-02-14 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfymlr7n8.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Feb 14, 2006 at 09:46:03PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When you say "git commit Documentaiton" to make partial commit
> for the files only in that directory, we did not detect that as
> a misspelled pathname and attempted to commit index without
> change. If nothing matched, there is no harm done, but if the
> index gets modified otherwise by having another valid pathspec
> or after an explicit update-index, a user will not notice
> without paying attention to the "git status" preview.
>
> This introduces --error-unmatch option to ls-files, and uses it
> to detect this common user error.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * Pasky, does this address the issue you mentioned earlier on
> the #git channnel?
Yes, this is what I meant. I actually have no practical experience with
this since I'm not a git-commit user, I merely expressed horror ;) on
what you mentioned during the night. BUT it turns out that this affects
Cogito as well, albeit in a milder version - only when you pass multiple
explicit paths to cg-commit and some of them are misspelled, they are
ignored quietly (unless all of them are misspelled).
So, thanks for the fix on behalf of Cogito users as well. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: several quick questions
From: Josef Weidendorfer @ 2006-02-14 21:30 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Linus Torvalds
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>
On Tuesday 14 February 2006 21:10, you wrote:
> How about "git seek" for doing the operations above, and using some
> reserved branch name, (say "seek"). Then, git-bisect could easily be
> built on that, and git-commit could respect the "seek" name and refuse
> to commit to it, (could tell the user how to create the branch
> necessary to commit from the current point).
Why not allow something like
git-checkout master~5
which implicitly does create a read-only branch "seek-point"?
I do not think that it is important to remember the branch name you seek
from.
A branch could be marked readonly by above command with
chmod a-w .git/refs/heads/seek
And git-commit should refuse to commit on a readonly ref, telling
the user to create a writable branch before with "git-branch new".
This would also help "cg-seek" to prohibit the user to commit on
"cg-seek-point" via "git-commit" (by setting cg-seek-point read-only).
BTW, "origin" (and any local branch that tracks a remote one) should
be set to readonly this way to signal that these are not developer
branches.
Josef
^ permalink raw reply
* Re: several quick questions
From: Nicolas Vilz 'niv' @ 2006-02-14 21:30 UTC (permalink / raw)
To: git
In-Reply-To: <43F20D4B.3060606@op5.se>
Andreas Ericsson wrote:
>
> git will recognize the merge-base as being the current HEAD and simply
> sets HEAD to point to that of topic-branch. This is why it's called a
> fast-forward, since no heavy computing needs to be done to combine the
> two development tracks.
well finaly, if nothing happened in one of the lines, then the two lines
become the same, when merging back into one line. and the two lines
overlay each other. That is what i saw during playing with git-merge,
git-pull and git-reset.. ok.
>
>> do you have to make a new private branch out of the tag 1.1.6?
>>
>
> No, you don't, but you can if you wish. It's nifty if you want to fork
> the development from a particular branch. In your case, if you really,
> really *want* the arrows pointing to one line, you can do
>
> $ git branch topic-branch HEAD^
> # work, work, work
> $ git checkout master
> $ git pull . topic-branch
>
> That would create one pretty arrow. When multiple tracks of development
> (rather than just two) are combined into one it's called an octopus
> merge. Unless you really know what you're doing, you should try to avoid
> those for small projects, and doing it just for the pretty arrows is....
> well, let's call it "interesting from the behaviour science scholars
> point of view".
its just the thought "cool, it looks like there at the git repo"... just
to realize "ok, that happens, when i merge two trees.
>> i used svn and there i could go back some revisions. I haven't found
>> such a feature in git, yet... but i think i am blind all the time.
>>
>
> Most likely. I believe at least the reset command is mentioned in the
> tutorial. I trust you've read it before asking, so something is amiss
> either with your eyesight or the tutorial.
well the namespace of the references confused me, before i realized,
that HEAD finally points to an sha1sum (which symbolizes a certain commit)
mh.. I use pull if i want to get an external development tree, right? I
still search for a possibility to replace the svn:externals, which were
quite handy some times.
lets imagine, i want to reuse work i did in another repository, then I
can easily pull from that repository, which my work i want to reuse is
stored at... i see... i just will have to pull frequently.... and hope
there is no conflict between some files.
once more... thank you all and good work.
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