* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Jakub Narebski @ 2006-05-17 19:13 UTC (permalink / raw)
To: git
In-Reply-To: <7viro4ecao.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> In 'Documentation/glossary.txt' we have:
>> ----
>> branch::
>> A non-cyclical graph of revisions, i.e. the complete history of
>> a particular revision, which is called the branch head. The
>> branch heads are stored in `$GIT_DIR/refs/heads/`.
>> ----
>
> While technically it might be correct, the above description for
> "branch" completely misses the point in the context of other
> entries. I do not recall when this entry was first written, but
> I suspect it probably predates other entries that talk about the
> same thing.
[cut long description]
The description you gave is nice, but it belongs in Tutorial rather than in
Glossary. Additionally it mainly deals with branches fron the 'revision
history' point of view, although the 'commit' point of view can also be
seen.
Glossary entry should be short, up to the point, and encompass al three
points of view:
a.) conceptual point of view, i.e. "branch is separate line of
development" (be it stable or development direction, introducing new
feature aka. 'topic', or following aka. 'tracking' changes in other
repository),
b) revision history point of view, i.e. "on branch means, roughly,
reachable from branch head aka. tip", or "branch is lineage of history of
project" (somewhat mudded by merges[*1*], fork points[*2*] and multiple
roots). This is what current glossary entry tries to present,
c) commit point of view, i.e. "branch tip is where we do commit
changes" (branch tip is [one of] parent(s) of current commit, and branch
tip is advanced to new commit).
[*1*] Problem with merges:
---.---.---A-\--.---.---.---B-- branch1
\
---.---.---C---*D---.---.---E-- branch2
Does A belong to branch2? It is one of parents of commit D. We can assume
that only first parent in merges continues branch. But what if we have the
following history:
---.---.---A-\ <---- there was branch1 here
\
---.---.---C---*D---.---.---E-- branch2
To which branch belongs A then?
[*2*] Problem with fork point
/--1---2---3-- maintenance/stable/fixes branch
/
---A---B----C---D---E-- master/development branch
Following the ancestry chain we get that commit A is on branch 'maint' (it
is also on branch 'master'); git does not record fork points. Perhaps the
branch logging and/or per branch configuration could be used to resolve
this issue.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-17 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsln8cwn6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Importing a quilt patch series into git is not very difficult
>> but parsing the patch descriptions and all of the other
>> minutia take a bit of effort to get right, so this automates it.
>>
>> Since git and quilt complement each other it makes sense
>> to make it easy to go back and forth between the two.
>>
>> If a patch is encountered that it cannot derive the author
>> from the user is asked.
>
> What's the expected workflow for you to work on a 1300 patch
> series you get from Andrew in the next installment to deal with
> 88 unattributed patches? Answer the question 88 times and make
> sure you get the answers right every time? Or abort and
> hand-edit them to help mailinfo to notice the correct
> attribution and re-run?
For the internal consumption case it isn't a big deal. I
can specify --author with something bogus and it works.
There are a few tweaks that can be made to git-mailinfo to
make it better at parsing information out of patches. I
cut the list down to about 49 that way. I had it all of the
way down to 1. But then I realized that the first Singed-off-by
really doesn't accurately reflect the author. I suspect a
few of my other teaks are equally suspicious.
> I know I am guilty of suggesting "going interactive", but I have
> a feeling that having an optional file that maps patch-name to
> author might be easier to work with. If the old patches are
> recycled in the updated -mm set, you probably can reuse the
> mapping for them, adding entries for newly introduced "unnamed"
> patches as needed.
Short of getting the script where it has a sane restart in the
middle mode going interactive and asking questions makes a lot
of sense. Especially with smaller trees.
For Andrews tree before I play anymore with technical solutions I
need to talk to Andrew and see if we can improve the situation
upstream. Possibly with a quilt-audit script that finds problem
patches.
Eric
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Pavel Roskin @ 2006-05-17 19:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4f9eo$b60$1@sea.gmane.org>
On Wed, 2006-05-17 at 15:46 +0200, Jakub Narebski wrote:
> Santi wrote:
>
> > In the other way, now I find the value of being able to say:
> >
> > $ git add t*
> >
> > and be sure that it does not add an ignored file. Unfortunately
> > git-add cannot distinguish between both.
>
> Well, it could. If 'git add <filespec>' would result in NO files
> added, take <filespec> as literate <file> (filename), regardless
> of ignores.
Can we apply the ignore rules to the directories but not the files?
This way, "git-add *" would add all files (rarely a good idea), whereas
"git-add ." would respect the ignore rules.
Kludgy as it is, this approach would generally produce more expected
results than others. If you let the shell expand the pattern, expect
all junk to be added. If you let git expand the pattern, expect it to
adhere to the ignore rules.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: 1.3.2 git-clone segfaults
From: Bill Yoder @ 2006-05-17 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Wolfgang Denk
In-Reply-To: <7vwtckcwve.fsf@assigned-by-dhcp.cox.net>
Dear Junio (and Fernando):
> Could you try 1.3.3?
Here are the last few lines of output from 1.3.3, cooked with gcc 3.2.3:
Getting alternates list for http://www.denx.de/git/linux-2.6-denx.git/
got b603ba9e9b5482d3e80fc8e0fa96bb9a943502ff
got 1635ee25918fc19ea613d1e8dbcb672075220efb
got dd7d627bf66f306b4ee9401f06ed4fb574896a85
got c771a7db9871bfa3f3c76b78c1369111c4be767b
got 374e20ad8b0d02f15fbcaa5315e272eabd6c4f76
got a8bef1d1371cc999ce6882d355c7554ca7738173
got ab08f35cbc355f4b2058d88ff289552f202ea5b4
Getting pack list for http://www.denx.de/git/linux-2.6-denx.git/
got 92297ff24e8525de2617dff728b3420a4649f66a
got 93dcbe1abb4c83b65cc6af59fb84c3c5e16effbb
got 41ecbb847f32f301a7ecd30b6438fea702886a33
got 94f557fa46369ec94ec718d25616ceb0b73fd2d2
got 09e00433c78e267b37b3f485c0d877de780a0674
got da7c09e4ede6e83198bf1ab5f16c571b0cc214ee
got 85533ec5aaa17f4146452a16ef61ca40fc601c80
got 50e338d2ffda9cb5a835d67849e38ae0ceba1647
/usr/local/downloads/git-1.3.3/git-clone: line 323: 1124
Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
Regards,
Bill
^ permalink raw reply
* Re: 1.3.2 git-clone segfaults
From: Pavel Roskin @ 2006-05-17 19:29 UTC (permalink / raw)
To: Bill Yoder; +Cc: git, Wolfgang Denk
In-Reply-To: <879BAFDD-87DB-4041-8753-5D63630076B5@cs.utexas.edu>
On Wed, 2006-05-17 at 13:32 -0500, Bill Yoder wrote:
> /usr/local/downloads/git-1.3.2/git-clone: line 323: 25972
> Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
I've seen git-http-fetch segfaults many times when cloning qgit, but
it's hard to reproduce on demand.
I think you should compile git without optimizations and allow coredumps
(ulimit -c unlimited), then load git-http-fetch in gdb with the core
(gdb --core=core git-http-fetch) and run bt to see the backtrace.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Linus Torvalds @ 2006-05-17 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodxwcwa1.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> This makes -c misbehave in a subtle way.
>
> git grep -c -e no-such-string-anywhere | head -n 1
>
> But I do not think we care.
Ahh, yes. That appears to be unfixable without using special GNU
extensions.
I agree that we probably don't care, though.
Linus
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Sean @ 2006-05-17 19:39 UTC (permalink / raw)
To: Pavel Roskin; +Cc: jnareb, git
In-Reply-To: <1147893786.16654.5.camel@dv>
On Wed, 17 May 2006 15:23:06 -0400
Pavel Roskin <proski@gnu.org> wrote:
> Can we apply the ignore rules to the directories but not the files?
>
> This way, "git-add *" would add all files (rarely a good idea), whereas
> "git-add ." would respect the ignore rules.
>
> Kludgy as it is, this approach would generally produce more expected
> results than others. If you let the shell expand the pattern, expect
> all junk to be added. If you let git expand the pattern, expect it to
> adhere to the ignore rules.
Shouldn't git just always respect the ignore rules? Forcing someone to
remove a file from the .gitignore or employ the other work around
mentioned earlier doesn't seem too bad. How often are people adding
files that are explicitly ignored?
Sean
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Jakub Narebski @ 2006-05-17 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP12920BE00C27B0CF31CB9FAEA10@CEZ.ICE>
Sean wrote:
> Shouldn't git just always respect the ignore rules? Forcing someone to
> remove a file from the .gitignore [...]
Or adding exclude rule (!filename) for specific file to .gitignore.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Pavel Roskin @ 2006-05-17 19:56 UTC (permalink / raw)
To: Sean; +Cc: jnareb, git
In-Reply-To: <20060517153903.6b896fdd.seanlkml@sympatico.ca>
On Wed, 2006-05-17 at 15:39 -0400, Sean wrote:
> On Wed, 17 May 2006 15:23:06 -0400
> Pavel Roskin <proski@gnu.org> wrote:
>
> Shouldn't git just always respect the ignore rules? Forcing someone to
> remove a file from the .gitignore or employ the other work around
> mentioned earlier doesn't seem too bad. How often are people adding
> files that are explicitly ignored?
That's a good idea! And the implementation should be easy - if the file
is present, but git-ls-file doesn't show it, tell the user to
adjust .gitignore or to use some flag like --force.
Libification of git-ls-files would allow even more precise messages.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Junio C Hamano @ 2006-05-17 19:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4fsla$oth$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> [cut long description]
>
> The description you gave is nice, but it belongs in Tutorial rather than in
> Glossary.
I suspect I was not clear enough for you when I said:
I cannot easily do a glossary entry to describe that specific
term, but maybe somebody else can split the following up and
paraphrase.
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Jakub Narebski @ 2006-05-17 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xp0ctlf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> [cut long description]
>>
>> The description you gave is nice, but it belongs in Tutorial rather than
>> in the Glossary.
>
> I suspect I was not clear enough for you when I said:
>
> I cannot easily do a glossary entry to describe that specific
> term, but maybe somebody else can split the following up and
> paraphrase.
Maybe I should say that the description you gave is a nice source for
eventual glossary entry, but I feel that as the whole is worth preserving
in some tutorial text.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] Implement a --dry-run option to git-quiltimport
From: Eric W. Biederman @ 2006-05-17 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsln8cwn6.fsf@assigned-by-dhcp.cox.net>
Since large quilt trees like -mm can easily have patches
without clear authorship information, add a --dry-run
option to make the problem patches easy to find.
---
This patch should make it easy to communicate to Andrew
and others exactly which patches there are problems
with, and should make it possible to easily edit
those patches before they are imported.
Documentation/git-quiltimport.txt | 8 +++++++-
git-quiltimport.sh | 24 ++++++++++++++++++------
2 files changed, 25 insertions(+), 7 deletions(-)
cb0ff8090e1492f177a521b01cf987c16b125d81
diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt
index e694537..97f4071 100644
--- a/Documentation/git-quiltimport.txt
+++ b/Documentation/git-quiltimport.txt
@@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchs
SYNOPSIS
--------
[verse]
-'git-quiltimport' [--author <author>] [--patches <dir>]
+'git-quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
DESCRIPTION
@@ -29,6 +29,12 @@ preserved as the 1 line subject in the g
OPTIONS
-------
+--dry-run::
+ Walk through the patches in the series and warn
+ if we cannot find all of the necessary information to commit
+ a patch. At the time of this writing only missing author
+ information is warned about.
+
--author Author Name <Author Email>::
The author name and email address to use when no author
information can be found in the patch description.
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index be43f9d..476e078 100644
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -1,8 +1,9 @@
#!/bin/sh
-USAGE='--author <author> --patches </path/to/quilt/patch/directory>'
+USAGE='--dry-run --author <author> --patches </path/to/quilt/patch/directory>'
SUBDIRECTORY_ON=Yes
. git-sh-setup
+dry_run=""
quilt_author=""
while case "$#" in 0) break;; esac
do
@@ -19,6 +20,11 @@ do
shift
;;
+ --dry-run)
+ shift
+ dry_run=1
+ ;;
+
--pa=*|--pat=*|--patc=*|--patch=*|--patche=*|--patches=*)
QUILT_PATCHES=$(expr "$1" : '-[^=]*\(.*\)')
shift
@@ -75,8 +81,12 @@ for patch_name in $(cat "$QUILT_PATCHES/
if [ -n "$quilt_author" ] ; then
GIT_AUTHOR_NAME="$quilt_author_name";
GIT_AUTHOR_EMAIL="$quilt_author_email";
+ elif [ -n "$dry_run" ]; then
+ echo "No author found in $patch_name" >&2;
+ GIT_AUTHOR_NAME="dry-run-not-found";
+ GIT_AUTHOR_EMAIL="dry-run-not-found";
else
- echo "No author found in $patch_name";
+ echo "No author found in $patch_name" >&2;
echo "---"
cat $tmp_msg
echo -n "Author: ";
@@ -98,9 +108,11 @@ for patch_name in $(cat "$QUILT_PATCHES/
SUBJECT=$(echo $patch_name | sed -e 's/.patch$//')
fi
- git-apply --index -C1 "$tmp_patch" &&
- tree=$(git-write-tree) &&
- commit=$((echo "$SUBJECT"; echo; cat "$tmp_msg") | git-commit-tree $tree -p $commit) &&
- git-update-ref HEAD $commit || exit 4
+ if [ -z "$dry_run" ] ; then
+ git-apply --index -C1 "$tmp_patch" &&
+ tree=$(git-write-tree) &&
+ commit=$((echo "$SUBJECT"; echo; cat "$tmp_msg") | git-commit-tree $tree -p $commit) &&
+ git-update-ref HEAD $commit || exit 4
+ fi
done
rm -rf $tmp_dir || exit 5
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* Re: Do "git add" as a builtin
From: Linus Torvalds @ 2006-05-17 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd3ocvyy.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> By "not seeing the point", do you mean you do not agree with
> what bba319b5 and 45e48120 tried to do to help users?
Naah, I just didn't see why, and didn't bother to go exploring.
How about this patch on top of the previous one?
Linus
----
diff --git a/builtin-add.c b/builtin-add.c
index e815b3d..82e8f44 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -44,50 +44,89 @@ static int common_prefix(const char **pa
return prefix;
}
-static int match(const char **pathspec, const char *name, int namelen, int prefix)
+static int match_one(const char *match, const char *name, int namelen)
{
+ int matchlen;
+
+ /* If the match was just the prefix, we matched */
+ matchlen = strlen(match);
+ if (!matchlen)
+ return 1;
+
+ /*
+ * If we don't match the matchstring exactly,
+ * we need to match by fnmatch
+ */
+ if (strncmp(match, name, matchlen))
+ return !fnmatch(match, name, 0);
+
+ /*
+ * If we did match the string exactly, we still
+ * need to make sure that it happened on a path
+ * component boundary (ie either the last character
+ * of the match was '/', or the next character of
+ * the name was '/' or the terminating NUL.
+ */
+ return match[matchlen-1] == '/' ||
+ name[matchlen] == '/' ||
+ !name[matchlen];
+}
+
+static int match(const char **pathspec, const char *name, int namelen, int prefix, char *seen)
+{
+ int retval;
const char *match;
name += prefix;
namelen -= prefix;
- while ((match = *pathspec++) != NULL) {
- int matchlen;
-
+ for (retval = 0; (match = *pathspec++) != NULL; seen++) {
+ if (retval & *seen)
+ continue;
match += prefix;
- matchlen = strlen(match);
- if (!matchlen)
- return 1;
- if (!strncmp(match, name, matchlen)) {
- if (match[matchlen-1] == '/')
- return 1;
- switch (name[matchlen]) {
- case '/': case '\0':
- return 1;
- }
+ if (match_one(match, name, namelen)) {
+ retval = 1;
+ *seen = 1;
}
- if (!fnmatch(match, name, 0))
- return 1;
}
- return 0;
+ return retval;
}
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
- int i;
+ char *seen;
+ int i, specs;
struct dir_entry **src, **dst;
+ for (specs = 0; pathspec[specs]; specs++)
+ /* nothing */;
+ seen = xmalloc(specs);
+ memset(seen, 0, specs);
+
src = dst = dir->entries;
i = dir->nr;
while (--i >= 0) {
struct dir_entry *entry = *src++;
- if (!match(pathspec, entry->name, entry->len, prefix)) {
+ if (!match(pathspec, entry->name, entry->len, prefix, seen)) {
free(entry);
continue;
}
*dst++ = entry;
}
dir->nr = dst - dir->entries;
+
+ for (i = 0; i < specs; i++) {
+ struct stat st;
+ const char *match;
+ if (seen[i])
+ continue;
+
+ /* Existing file? We must have ignored it */
+ match = pathspec[i];
+ if (!lstat(match, &st))
+ continue;
+ die("pathspec '%s' did not match any files", match);
+ }
}
static void fill_directory(struct dir_struct *dir, const char **pathspec)
^ permalink raw reply related
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 20:26 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Sean, jnareb, git
In-Reply-To: <1147895816.30618.6.camel@dv>
On Wed, 17 May 2006, Pavel Roskin wrote:
> On Wed, 2006-05-17 at 15:39 -0400, Sean wrote:
> > On Wed, 17 May 2006 15:23:06 -0400
> > Pavel Roskin <proski@gnu.org> wrote:
> >
> > Shouldn't git just always respect the ignore rules? Forcing someone to
> > remove a file from the .gitignore or employ the other work around
> > mentioned earlier doesn't seem too bad. How often are people adding
> > files that are explicitly ignored?
>
> That's a good idea! And the implementation should be easy - if the file
> is present, but git-ls-file doesn't show it, tell the user to
> adjust .gitignore or to use some flag like --force.
Umm. That's exactly the semantics for "git add" right now. We _always_
respect the ignore rules.
That was what people were complaining about.
Although I think Santi realized why we do it, and isn't even complaining
any more.
So we're all good again.
Linus
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Jakub Narebski @ 2006-05-17 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605171325200.10823@g5.osdl.org>
Linus Torvalds wrote:
> On Wed, 17 May 2006, Pavel Roskin wrote:
>> [...] implementation should be easy - if the file
>> is present, but git-ls-file doesn't show it, tell the user to
>> adjust .gitignore or to use some flag like --force.
>
> Umm. That's exactly the semantics for "git add" right now. We _always_
> respect the ignore rules.
>
> That was what people were complaining about.
>
> Although I think Santi realized why we do it, and isn't even complaining
> any more.
>
> So we're all good again.
The changes in docummentation are nice and dandy, but it would be even nicer
if "git add" told us about "git update-index --add" when it adds no files,
as it is certainly the case when something is wrong (perhaps user
expectations, but still...).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 20:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4g1f4$anv$1@sea.gmane.org>
On Wed, 17 May 2006, Jakub Narebski wrote:
>
> The changes in docummentation are nice and dandy, but it would be even nicer
> if "git add" told us about "git update-index --add" when it adds no files,
> as it is certainly the case when something is wrong (perhaps user
> expectations, but still...).
Well, with the new-and-improved builtin "git add", you could probably do
something like the appended (on top of my most recent patch).
It says
No added files - did you perhaps mean to do a 'git update-index'?
whenever it finds that "git add" has ignored a file and not actually added
anything. That, btw, can happen either because it refused to see the file
in the first place (ie it was ignored), or because all the files listed
were already added.
In both cases the warning may or may not be sensible.
Anyway, I dunno. I don't have any strong opinions on this.
Linus
---
diff --git a/builtin-add.c b/builtin-add.c
index 82e8f44..8641137 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -12,6 +12,8 @@ #include "dir.h"
static const char builtin_add_usage[] =
"git-add [-n] [-v] <filepattern>...";
+static int ignored;
+
static int common_prefix(const char **pathspec)
{
const char *path, *slash, *next;
@@ -123,8 +125,10 @@ static void prune_directory(struct dir_s
/* Existing file? We must have ignored it */
match = pathspec[i];
- if (!lstat(match, &st))
+ if (!lstat(match, &st)) {
+ ignored = 1;
continue;
+ }
die("pathspec '%s' did not match any files", match);
}
}
@@ -257,6 +261,9 @@ int cmd_add(int argc, const char **argv,
for (i = 0; i < dir.nr; i++)
add_file_to_index(dir.entries[i]->name, verbose);
+ if (ignored && !active_cache_changed)
+ fprintf(stderr, "No added files - did you perhaps mean to do a 'git update-index'?\n");
+
if (active_cache_changed) {
if (write_cache(newfd, active_cache, active_nr) ||
commit_index_file(&cache_file))
^ permalink raw reply related
* Re: git-add + git-reset --hard = Arrrggh!
From: Shawn Pearce @ 2006-05-17 21:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0605170722u15702301p2565e8ac29a5a0da@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/17/06, Shawn Pearce <spearce@spearce.org> wrote:
> >All I can say is I'm very happy that update-index does a lot more
> >than just update the index. I was easily able to find the deleted
> >test by finding the most recently modified object in my .git/objects
> >directory and pulling it back out with git cat-file. :-)
> >
>
> Maybe git-lost-found would help here?
Thanks! I did that the hard way with git fsck-objects only to find
I actually had a lot of dangling objects. Luckily the most recent
one was the one I was looking for so a quick pipe through perl and
ls -t found it quite quickly.
What would have really helped me was just using GIT properly
rather than slamming something in fast with `git reset --hard`.
Somehow that option has become part of my finger feel when using
reset and that's just not right. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Shawn Pearce @ 2006-05-17 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v7j4kec3h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Wed, 17 May 2006, Junio C Hamano wrote:
> >>
> >> This does not allow '2006-05-17 00:00:00' as the timespec, and
> >> the documentation carefully avoids giving that example, but I
> >> think it is better to spell that limitation out.
> >
> > It doesn't? The "approxidate()" function should handle any reasonable date
> > specifier, and the above is certainly more than reasonable.
> >
> > Why doesn't approxidate handle it?
>
> The way I read the code is that get_sha1() would first do its
> magic at the first colon and feeds get_sha1_1() with prefix up
> to the first colon. This gets passed down to get_sha1_basic()
> and what approxidate() is fed is the suffix of that prefix. It
> ends up seeing stuff between '@' and ':'. I.e.
>
> "master@2006-05-17 00:00:00:cache.h"
>
> would ask for "00:00:cache.h" file in the "master" branch as of
> timestamp "2006-05-17 00".
Good catch. I'll see if I can deal with it later; probably early
tomorrow morning before work. It may just come down to documenting
this particular case as ambiguous and sure to parse the way you
did not mean it to. :-)
I tested a bunch of other date formats but not the basic ISO. Argh.
I'll send a test case soon for the expression parsing here, to be
sure we pull stuff from the log as expected as well as parse the
expression in a consistent way between releases. :-)
--
Shawn.
^ permalink raw reply
* Make git-rev-list understand --tags/--branches/--remotes
From: Linus Torvalds @ 2006-05-17 21:44 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
We shouldn't add stuff to git-rev-parse without teaching git-rev-list and
all the other tools to do the same.
In fact, these days there is much less reason for git-rev-parse in the
first place: it's usually used to verify a particular reference, or to
just split the different argument types up from each other. Most tools
don't need or use it any more (eg "gitk" will just pass its arguments
directly to git-rev-list).
With this, you can now do (for example)
gitk HEAD --not --tags
to see all the work on all the main branch that hasn't been included in a
tagged version (replace HEAD with "--branches" to show all branches, of
course).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index 2294b16..1fc6725 100644
--- a/revision.c
+++ b/revision.c
@@ -470,11 +470,13 @@ static int handle_one_ref(const char *pa
return 0;
}
-static void handle_all(struct rev_info *revs, unsigned flags)
+typedef int (*ref_fn_t)(int (*)(const char *, const unsigned char *));
+
+static void handle_ref(ref_fn_t fn, struct rev_info *revs, unsigned flags)
{
all_revs = revs;
all_flags = flags;
- for_each_ref(handle_one_ref);
+ fn(handle_one_ref);
}
static int add_parents_only(struct rev_info *revs, const char *arg, int flags)
@@ -614,7 +616,19 @@ int setup_revisions(int argc, const char
continue;
}
if (!strcmp(arg, "--all")) {
- handle_all(revs, flags);
+ handle_ref(for_each_ref, revs, flags);
+ continue;
+ }
+ if (!strcmp(arg, "--branches")) {
+ handle_ref(for_each_branch_ref, revs, flags);
+ continue;
+ }
+ if (!strcmp(arg, "--tags")) {
+ handle_ref(for_each_tag_ref, revs, flags);
+ continue;
+ }
+ if (!strcmp(arg, "--remotes")) {
+ handle_ref(for_each_remote_ref, revs, flags);
continue;
}
if (!strcmp(arg, "--not")) {
^ permalink raw reply related
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Shawn Pearce @ 2006-05-17 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqtwhpum.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> + fprintf(stderr, "warning: Log %s only goes back to %s.\n",
> + logfile, show_rfc2822_date(date, tz));
> + return 0;
>
> I am not sure about this part. If the oldest log entry was 3
> hours ago, the second oldest 2 hours ago, we can tell during
> that one hour period the ref was at that point. If the user
> asked "ref as of four hours ago", and if the oldest log entry
> had old SHA1 that is not 0{40} (because the log was not enabled
> before that record), it might make more sense to give that back.
If I understand my own code here what I'm doing is walking back
in the log file, realizing I fell off the first line of it, then
loading the old ref from the first line. This is the oldest ref
I can find so I return it as a valid ref to the caller but I'm
printing out this warning to tell the user that the oldest point
in time I found in the log is effectively the update date as I have
no idea when that old sha1 first became the value of the ref.
So I think I'm doing what you are expecting here. The log will start
with the value in the ref at the time the log started, not 0{40}
and that value is what gets returned when we have this warning
come out.. That's the best anyone can expect...
> Also I wonder how much complexity would we suffer and how much
> efficiency would we gain if we binary search the logdata (the
> committer info is variable length, so you would need to resync
> in each step).
I thought about doing this but did not think it would be worth the
effort (either developer to code or CPU to execute) at this point
in time. I don't think users will be pulling refs from the log very
often and if they are they will probably be pulling from recent time,
not very far back. Thus starting at the end and walking back is
probably "good enough".
But if it proves to be too slow in practice I'm sure I can come up
with a faster way to walk through the log. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Shawn Pearce @ 2006-05-17 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060517220613.GC30313@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> >
> > Also I wonder how much complexity would we suffer and how much
> > efficiency would we gain if we binary search the logdata (the
> > committer info is variable length, so you would need to resync
> > in each step).
>
> I thought about doing this but did not think it would be worth the
> effort (either developer to code or CPU to execute) at this point
> in time. I don't think users will be pulling refs from the log very
> often and if they are they will probably be pulling from recent time,
> not very far back. Thus starting at the end and walking back is
> probably "good enough".
>
> But if it proves to be too slow in practice I'm sure I can come up
> with a faster way to walk through the log. :-)
I just ran a test on my PowerBook: walking a 10,000 line log file and
extracting the very oldest commit along. Each hit on git-rev-parse
seems to took about 100 ms. Hardly worth worrying about for casual
use. Further git-rev-parse is taking 73 ms just to run '--verify
HEAD' so an extra 30 ms to read the 10k log is pretty much nothing.
[spearce@pb15 trash]$ wc -l .git/logs/refs/heads/master
10000 .git/logs/refs/heads/master
[spearce@pb15 trash]$ head -n 1 .git/logs/refs/heads/master
b943559a305bdd6bdee2cef6e5df2413c3d30a00 0000000000000000000000000000000000000000 A U Thor <example@example.com> 1136091600 -0500
[spearce@pb15 trash]$ perl -e 'print scalar(localtime shift),"\n"' 1136091600
Sun Jan 1 00:00:00 2006
[spearce@pb15 trash]$ time ../../git-rev-parse --verify HEAD@'300 days'
warning: Log .git/logs/refs/heads/master only goes back to Thu, 1 Jan 1970 00:00:00 +0000.
b943559a305bdd6bdee2cef6e5df2413c3d30a00
real 0m0.112s
user 0m0.029s
sys 0m0.023s
[spearce@pb15 trash]$ time ../../git-rev-parse --verify HEAD@'300 days'
warning: Log .git/logs/refs/heads/master only goes back to Thu, 1 Jan 1970 00:00:00 +0000.
b943559a305bdd6bdee2cef6e5df2413c3d30a00
real 0m0.105s
user 0m0.029s
sys 0m0.023s
--
Shawn.
^ permalink raw reply
* [RFC 6/5] Fix ref log parsing so it works properly.
From: Shawn Pearce @ 2006-05-17 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The log parser was only ever matching the last log record due to
calling strtoul on "> 1136091609" rather than " 1136091609". Also
once a match for '@' has been found after the name of the ref there
is no point in looking for another '@' within the remaining text.
---
Uh yea, I found a couple of bugs. :-)
This applies on top of the other 5 patches (hence the 6/5).
refs.c | 2 +-
sha1_name.c | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
fbc7bf049255370f1611a5772c39d35422a81e24
diff --git a/refs.c b/refs.c
index 4c99e37..ae9825d 100644
--- a/refs.c
+++ b/refs.c
@@ -459,7 +459,7 @@ int read_ref_at(const char *ref, unsigne
c++;
if (c == logend || *c == '\n')
die("Log %s is corrupt.", logfile);
- date = strtoul(c, NULL, 10);
+ date = strtoul(c + 1, NULL, 10);
if (date <= at_time) {
if (get_sha1_hex(rec + 41, sha1))
die("Log %s is corrupt.", logfile);
diff --git a/sha1_name.c b/sha1_name.c
index 3ac3ab4..4376cb3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -267,6 +267,7 @@ static int get_sha1_basic(const char *st
at_time = approxidate(date_spec);
free(date_spec);
len = at_mark;
+ break;
}
}
--
1.3.2.g7278
^ permalink raw reply related
* Re: "git add $ignored_file" fail
From: Junio C Hamano @ 2006-05-17 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605171342370.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, with the new-and-improved builtin "git add", you could probably do
> something like the appended (on top of my most recent patch).
>
> It says
>
> No added files - did you perhaps mean to do a 'git update-index'?
>
> whenever it finds that "git add" has ignored a file and not actually added
> anything. That, btw, can happen either because it refused to see the file
> in the first place (ie it was ignored), or because all the files listed
> were already added.
>
> In both cases the warning may or may not be sensible.
>
> Anyway, I dunno. I don't have any strong opinions on this.
If you give a pattern that would match two files but one of them
were hidden by .gitignore, this approach would not help you
much.
Even if we wanted to say something like "if the user explicitly
tells us to add etc/mtab~ by spelling it out, we should ignore
*~ entry in .gitignore", the shell expansion bites us because it
is done before we get to what the user give us. We cannot
distinguish that with the user typing etc/?tab* for example.
If somebody (Jakub, perhaps?) cares strong enough, we could show
by default "matched the pathspec but ignored by .gitignore"
paths with fprintf(stderr, "ignoring '%s'\n"), and have an
option -q to squelch it.
I do not have strong feeling on this, so I'll see if somebody
comes up with a better implementation.
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ecb688.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> If you give a pattern that would match two files but one of them
> were hidden by .gitignore, this approach would not help you
> much.
Correct. On the other hand, what could you do?
I think that the common case for that is literally something like
git add dirname/
or
git add file*
and it turns out that there are object files under the directory, or that
there's a file.c, file.h _and_ a already-compiled file.o file.
Under both of those circumstances (one pattern that matches multiple files
but ignores others - or several different patterns where _some_ of the
patterns are ignored), we actually do what I think is the only sane thing.
Namely to just silently add everything that makes sense to add.
> Even if we wanted to say something like "if the user explicitly
> tells us to add etc/mtab~ by spelling it out, we should ignore
> *~ entry in .gitignore", the shell expansion bites us because it
> is done before we get to what the user give us. We cannot
> distinguish that with the user typing etc/?tab* for example.
Right.
The only case that we cando anything at all about is really the case where
we didn't add anything at all, and then we might reasonably ask "do you
know what the heck you're doing".
That's kind of what my last patch did. It's a total special case, but it's
the _only_ special case that I can see that is at all relevant (ie in all
other cases it would just be annoying as _hell_ if we started talking
about how we're ignoring object files. Of _course_ we're ignoring them,
and that's why they are listed in .gitignore).
So I'd love to have the built-in "git add", but quite frankly, if you drop
that last patch as "too ugly to live", I certainly won't complain. I sent
it out more as a "we -could- do this" thing rather than anything more
serious.
Linus
^ permalink raw reply
* Re: [RFC] qgit with tabs
From: Pavel Roskin @ 2006-05-17 23:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550605131538u63b87002o3e9b5542c0e15bf7@mail.gmail.com>
Hi, Marco!
On Sun, 2006-05-14 at 00:38 +0200, Marco Costalba wrote:
> Hi Pavel,
>
> >
> > Sure, but I often want to see what changed in a particular file.
> >
> > And of course I only mean the subwindow dislaying the files affected by the
> > patch. The file tree should still have file annotation bound to the double
> > click.
> >
>
> I understand your reasons, but I have some doubts about this change:
>
> 1) The context menu is currently shared between the tree and the file
> list, splitting in two subcases adds some crap to the code (ok, this
> is not the real doubt ;-) )
Actually, "Get revision/patch" and "External diff" shouldn't be in the
popup used in the tree, or at least they should only appear for the
files affected by the currently selected patch.
"External diff" may be a good candidate for the toolbar if you find out
how to feed a multi-file patch to kompare (I guess you'll need two
temporary directories populated with differing files).
> 2) The context menu is currently shared between the file list in main
> view and the file list in patch view. The file list in patch view, of
> course, does not need a double click, a single click is enough to
> select corresponding file's diff. In main view you currently need a
> single click _plus_ a 'p' key press to change the view. So we should
> add another subcase here.
Yes. It should be perfectly OK to have different menus for different
contexts.
> 3) It is true that double clicking on a revision switch to the patch
> view at top position (if no file is selected), but it's also true that
> you can select the file's related diff directly in patch view with a
> single click on the right column file list.
That's true. But I still find myself double clicking on the file in the
file list and expecting to see the patch for the file. It's very
natural.
If I see the list of the recent patches, I see the descriptions and the
affected files. If I'm interested to see what changed in the file, it's
only natural for me to double-click the corresponding entry in the list.
Full history of a file is a much more advanced operation, and it's not
something I need to do often while browsing recently merged changes.
> 4) Once a file is selected, as example with a single click, you can
> browse through rev list and the selection is preserved, it means that
> anytime you switch to patch view page the content will be _already_
> centered on the correct diff.
That's useful, but irrelevant.
> 5) Double clicking on a file name is currently the only way (without
> opening the menu) to show the file content tab, with your suggested
> change we will have two ways to switch to patch view and no one to
> switch to file view.
That's a good thing. That's called consistency. git is about patches,
so showing the patches should be the default whenever practical.
The file viewer is a great feature, and it should be discoverable, but
it doesn't mean it should pop up when users expect something else.
>
> 6) Selecting from the tree view is very slow if you have to search for
> the correct file, it is fast only if the file is already selected, but
> in this case is faster to press 'p' key ;-)
That's true, but we are talking about double click behavior. Every
reasonable person can learn shortcuts, but the software should work
predictably even if operated by the mouse.
--
Regards,
Pavel Roskin
^ 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