* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-29 8:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729081051.GH24895@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Exactly. I want much more freedom in pushing, the only requirement being
> that "the to-be-replaced remote head is ancestor of the to-be-pushed
> local head". I think (am I wrong?) git-send-pack localhead:remotehead
> would work just fine for me, the only thing I need is the support for
> different local and remote head names.
Now I see where you are coming from; I tend to agree why you
might want to have different names on the remote end. I however
still suspect that you might be spreading chaos under the name
of more flexibility. The fact that you can push into it by
definition means you have some control over the other end, and
obviously you are in total control on your end. I do not see
why you cannot rename branches where needed so that whatever you
are pushing match. That would also be one less thing to keep
track of for yourself [*1*].
Yes, I am aware that you brought up the example of pushing to
two separate places, but does it happen in practice that you can
push to two places, and at the same time neither of them
cooperates with you to make it easier for you to work on these
three machines by having the same head names?
Having said that, I do not particulary think allowing push to
write into different ref is an unreasonable thing. As you
pointed out long time ago when send-pack was first done, the
protocol is not so easily extensible, so this may require either
backward incompatible protocol change, or introduction of a new
program pair send-pack-2 / receive-pack-2. I'll take a look
sometime this weekend. Bedtime.
[Footnote]
*1* In a hypothetical situation ``I use branch "b00" in this
repository to do XYZ work but I use branch "b24" in the other
repository for the same XYZ work'', Porcelain can keep track of
mapping between b00:b24 for you, but you still need to keep
track of b00:XYZ and b24:XYZ mapping in your head.
^ permalink raw reply
* Re: cg-restore - restoring modified files
From: Petr Baudis @ 2005-07-29 8:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1118799921.3890.45.camel@dv>
Umm. I just discovered a portion of mailing list I somehow completely
missed. :/ Sorry for the delayed replies.
Dear diary, on Wed, Jun 15, 2005 at 03:45:21AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hello!
Hi,
> I believe the documented behavior of cg-restore is inconsistent.
>
> "Restore given files to their original state. Without any parameters, it
> recovers any files removed locally whose removal was not recorded by
> `cg-rm`."
>
> I interpret it that cg-restore without arguments restores removed files
> but not modified ones.
>
> "If passed a set of file names, it restores those files to their state
> as of the last commit (including bringing files removed with cg-rm back
> to life; FIXME: does not do that part yet)."
>
> I interpret it that cg-restore with arguments restores both removed and
> modified files.
>
> Maybe we need an option whether to restore modified files? Or maybe
> they should always be restored (I think it would more consistent)? Then
> the help text should be more clear about modified files.
>
> The actual behavior is that modified files are never restored. We need
> "-f" option for git-checkout-cache to overwrite existing files, and it's
> not used whether the filenames are specified or not. I wanted to send a
> patch, but after reading help I'm not sure what exactly cg-restore is
> supposed to do.
in the meantime, I actually implemented the -f option. Now I agree that
cg-rm'd files should indeed be restored only when -f is passed. Not a
big deal yet since we don't remove them at all now. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Petr Baudis @ 2005-07-29 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5p2hve1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> In the meantime, the current one is clearly broken as you
> pointed out, so let's replace it with the updated "generic rule
> with the following exceptions" one.
That's fine by me. I would only like to ask the Porcelain authors to
keep their git-ls-files exclude parameters order matching the internal
ordering so that when we indeed change it in the future to follow the
commandline order, the Porcelains won't break.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Git 1.0 Synopis (Draft v3
From: Ryan Anderson @ 2005-07-29 8:29 UTC (permalink / raw)
To: git
In-Reply-To: <20050727100123.GH19290@mythryan2.michonline.com>
Source Code Management with Git
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
Git is a "directory content manager". Git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
Git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o The core Git project considers itself to provide "plumbing" for other
projects, as well as to serve to arbitrate for compatibility between them.
The project built on top of the core Git are referred to as "porcelain".
StGit, Cogito, qgit, gitk and gitweb are all building upon the core Git
tools, and providing an easy to use interface to various pieces of
functionality.
o Some other projects have taken the concepts from the core Git project, and
are either porting an existing toolset to use the Git tools, or
reimplementing the concepts internally, to benefit from the performance
improvements. This includes both Arch 2.0, and Darcs-git.
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves space and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of Git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Deb packages at:
<insert url here>
Or via Git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
(rsync is generally faster for an initial clone, you can switch later
by editing .git/branches/origin and changing the url)
To get the 'Porcelain' tools mentioned above:
SCM Interface layers:
cogito - http://www.kernel.org/pub/software/scm/cogito/
StGIT - http://www.procode.org/stgit/
History Visualization:
gitk - http://ozlabs.org/~paulus/gitk/
gitweb - http://www.kernel.org/pub/software/scm/gitweb/
qgit - http://sourceforge.net/projects/qgit
Git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's Git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
Git development takes place on the Git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v2)
From: Ryan Anderson @ 2005-07-29 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek9jq4n5.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 27, 2005 at 03:13:18PM -0700, Junio C Hamano wrote:
> > Git results from the inspiration and frustration of Linus Torvalds, and
> > the enthusiastic help of over 300 participants on the development
> > mailing list.[1] It is maintained by Junio C Hamano <junkio@cox.net>.
>
> Please drop the e-mail address here; you mention nobody else's.
>
> Well, dropping "the current maintainer" information altogether
> might be even better; the above to a casual reader sounds like
> Linus was frustrated and I wrote it for him, which is definitely
> not what we would like to say. I suspect it still has more code
> by Linus than anybody else (I stopped counting some time ago).
Ok. I was thinking I could add "current" into that description. Or,
something like, "Linus has since returned his focus to the kernel, and
passed maintainership to ...".
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-29 8:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729073644.GE24895@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hmm. What about just excluding the files according to the order of
> parameters on the command line?
>
> Here, the question is whether the GIT Core tools should provide full
> flexibility and friendness to custom use, or rather serve as tighter
> unifying layer for the porcelains, enforcing certain conventions.
While I would in principle prefer to offer more freedom to shoot
yourselves in the foot ;-), the pragmatic side of me says too
much flexibility is just asking for trouble with not much
additional gain. For example, your "generic first, and then
list exceptions" argument convinced me to shelve the "first
match wins" rule, but I _could_ have added an extra option to
allow other Porcelain writers who want to have "most number of
match wins" rule while at it. I didn't. Let's wait and see if
somebody else comes up with a different use scenario that would
be useful in real life.
In the meantime, the current one is clearly broken as you
pointed out, so let's replace it with the updated "generic rule
with the following exceptions" one.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzo6jbme.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 29, 2005 at 09:48:57AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Aha, so it seems our problem is hopefully only in terminology, great.
> >
> > So, what do you mean by "clone" here? And what command should I use for
> > pushing then?
>
> Notice I never used the word "clone" in what I said.
> > However, I happen to think that two repositories
> > you use send-pack (not _CLONE_ which uses completely different
> > protocol)
(emphasis mine ;-)
> Now, A may happen to be on my home machine and B may happen be
> on my notebook, meaning the owner of A and B are both myself.
> But even in that case I would still work by "pulling from A"
> when I am on B, and "pulling from B" when I am on A. In other
> words, "pulling" is the only patch flow mechanism I would use.
I use cg-push on my notebook, given that the notebook might not happen
to have public IP address in some cases, or might be behind some
corporate firewall, or that I'm lazy to ssh to my home machine in order
to pull.
> Pushing is only for publication and I treat it as just a
> GIT-aware rsync/mirror, nothing more. I have a feeling that
> your workflow is different and you plan to use both push and
> pull for normal patch flows. This distinction is probably where
> the disagreement comes from.
Exactly. I want much more freedom in pushing, the only requirement being
that "the to-be-replaced remote head is ancestor of the to-be-pushed
local head". I think (am I wrong?) git-send-pack localhead:remotehead
would work just fine for me, the only thing I need is the support for
different local and remote head names.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Petr Baudis @ 2005-07-29 7:46 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Ryan Anderson, Junio C Hamano, git
In-Reply-To: <20050729073134.GA6507@mars.ravnborg.org>
Dear diary, on Fri, Jul 29, 2005 at 09:31:34AM CEST, I got a letter
where Sam Ravnborg <sam@ravnborg.org> told me that...
> > > While I do not have strong objections to make the build process
> > > go faster, it is somewhat disturbing that the Makefile pieces
> > > maintained in subdirectories need to name things they touch
> > > using paths that include the subdirectory names. I do not have
> > > a better alternative to suggest, though...
>
> If the goal is to speed up the build process the only sane way is to fix
> the dependencies. In kbuild fixdep is used to parse the .c file and it
> locates all references to .h files (recursive) and also detects any
> usage of CONFIG_ symbols.
> This part should be relative straightforward to include in git.
FWIW, I made tiny "build system" (inspired by kconfig) for smaller
projects I work on:
http://pasky.or.cz/~pasky/dev/tunneler/co/Makefile
http://pasky.or.cz/~pasky/dev/tunneler/co/Makefile.lib
http://pasky.or.cz/~pasky/dev/tunneler/co/client/Makefile
Perhaps someone might find that a nice base for further hacking. It
generally appears to work pretty well in practice, although the
automatic dependency tracking might not be perfect.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [PATCH] ls-files: rework exclude patterns.
From: Junio C Hamano @ 2005-07-29 7:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, Linus Torvalds, git, Marco Costalba
In-Reply-To: <7vack6mcd7.fsf@assigned-by-dhcp.cox.net>
Pasky and others raised many valid points on the problems
initial exclude pattern enhancement work had. Based on the
list discussion, rework the exclude logic to use "last match
determines its fate" rule, and order the list by exclude-from
(the fallback default pattern file), exclude-per-directory
(shallower to deeper, so deeper ones can override), and then
command line exclude patterns.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
ls-files.c | 100 +++++++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 72 insertions(+), 28 deletions(-)
a908ed1b0fed52bfdcfc8b3ada366ce05e44c887
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -26,30 +26,45 @@ static const char *tag_other = "";
static const char *tag_killed = "";
static char *exclude_per_dir = NULL;
-static int nr_excludes;
-static int excludes_alloc;
-static struct exclude {
- const char *pattern;
- const char *base;
- int baselen;
-} **excludes;
-static void add_exclude(const char *string, const char *base, int baselen)
+/* We maintain three exclude pattern lists:
+ * EXC_CMDL lists patterns explicitly given on the command line.
+ * EXC_DIRS lists patterns obtained from per-directory ignore files.
+ * EXC_FILE lists patterns from fallback ignore files.
+ */
+#define EXC_CMDL 0
+#define EXC_DIRS 1
+#define EXC_FILE 2
+static struct exclude_list {
+ int nr;
+ int alloc;
+ struct exclude {
+ const char *pattern;
+ const char *base;
+ int baselen;
+ } **excludes;
+} exclude_list[3];
+
+static void add_exclude(const char *string, const char *base,
+ int baselen, struct exclude_list *which)
{
struct exclude *x = xmalloc(sizeof (*x));
x->pattern = string;
x->base = base;
x->baselen = baselen;
- if (nr_excludes == excludes_alloc) {
- excludes_alloc = alloc_nr(excludes_alloc);
- excludes = realloc(excludes, excludes_alloc*sizeof(char *));
+ if (which->nr == which->alloc) {
+ which->alloc = alloc_nr(which->alloc);
+ which->excludes = realloc(which->excludes,
+ which->alloc * sizeof(x));
}
- excludes[nr_excludes++] = x;
+ which->excludes[which->nr++] = x;
}
static int add_excludes_from_file_1(const char *fname,
- const char *base, int baselen)
+ const char *base,
+ int baselen,
+ struct exclude_list *which)
{
int fd, i;
long size;
@@ -76,7 +91,7 @@ static int add_excludes_from_file_1(cons
if (buf[i] == '\n') {
if (entry != buf + i && entry[0] != '#') {
buf[i] = 0;
- add_exclude(entry, base, baselen);
+ add_exclude(entry, base, baselen, which);
}
entry = buf + i + 1;
}
@@ -91,38 +106,45 @@ static int add_excludes_from_file_1(cons
static void add_excludes_from_file(const char *fname)
{
- if (add_excludes_from_file_1(fname, "", 0) < 0)
+ if (add_excludes_from_file_1(fname, "", 0,
+ &exclude_list[EXC_FILE]) < 0)
die("cannot use %s as an exclude file", fname);
}
static int push_exclude_per_directory(const char *base, int baselen)
{
char exclude_file[PATH_MAX];
- int current_nr = nr_excludes;
+ struct exclude_list *el = &exclude_list[EXC_DIRS];
+ int current_nr = el->nr;
if (exclude_per_dir) {
memcpy(exclude_file, base, baselen);
strcpy(exclude_file + baselen, exclude_per_dir);
- add_excludes_from_file_1(exclude_file, base, baselen);
+ add_excludes_from_file_1(exclude_file, base, baselen, el);
}
return current_nr;
}
static void pop_exclude_per_directory(int stk)
{
- while (stk < nr_excludes)
- free(excludes[--nr_excludes]);
+ struct exclude_list *el = &exclude_list[EXC_DIRS];
+
+ while (stk < el->nr)
+ free(el->excludes[--el->nr]);
}
-static int excluded(const char *pathname)
+/* Scan the list and let the last match determines the fate.
+ * Return 1 for exclude, 0 for include and -1 for undecided.
+ */
+static int excluded_1(const char *pathname,
+ int pathlen,
+ struct exclude_list *el)
{
int i;
- if (nr_excludes) {
- int pathlen = strlen(pathname);
-
- for (i = 0; i < nr_excludes; i++) {
- struct exclude *x = excludes[i];
+ if (el->nr) {
+ for (i = el->nr - 1; 0 <= i; i--) {
+ struct exclude *x = el->excludes[i];
const char *exclude = x->pattern;
int to_exclude = 1;
@@ -158,6 +180,22 @@ static int excluded(const char *pathname
}
}
}
+ return -1; /* undecided */
+}
+
+static int excluded(const char *pathname)
+{
+ int pathlen = strlen(pathname);
+ int st;
+
+ for (st = EXC_CMDL; st <= EXC_FILE; st++) {
+ switch (excluded_1(pathname, pathlen, &exclude_list[st])) {
+ case 0:
+ return 0;
+ case 1:
+ return 1;
+ }
+ }
return 0;
}
@@ -371,6 +409,7 @@ static const char *ls_files_usage =
int main(int argc, char **argv)
{
int i;
+ int exc_given = 0;
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -402,20 +441,25 @@ int main(int argc, char **argv)
show_stage = 1;
show_unmerged = 1;
} else if (!strcmp(arg, "-x") && i+1 < argc) {
- add_exclude(argv[++i], "", 0);
+ exc_given = 1;
+ add_exclude(argv[++i], "", 0, &exclude_list[EXC_CMDL]);
} else if (!strncmp(arg, "--exclude=", 10)) {
- add_exclude(arg+10, "", 0);
+ exc_given = 1;
+ add_exclude(arg+10, "", 0, &exclude_list[EXC_CMDL]);
} else if (!strcmp(arg, "-X") && i+1 < argc) {
+ exc_given = 1;
add_excludes_from_file(argv[++i]);
} else if (!strncmp(arg, "--exclude-from=", 15)) {
+ exc_given = 1;
add_excludes_from_file(arg+15);
} else if (!strncmp(arg, "--exclude-per-directory=", 24)) {
+ exc_given = 1;
exclude_per_dir = arg + 24;
} else
usage(ls_files_usage);
}
- if (show_ignored && !nr_excludes) {
+ if (show_ignored && !exc_given) {
fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
argv[0]);
exit(1);
^ permalink raw reply
* [PATCH] Documentation and tests: ls-files exclude pattern.
From: Junio C Hamano @ 2005-07-29 7:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, Linus Torvalds, git, Marco Costalba
In-Reply-To: <7vack6mcd7.fsf@assigned-by-dhcp.cox.net>
Update the tests and documentation to match the new "last one
determines its fate" semantics.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-ls-files.txt | 27 ++++++++++++++-------------
t/t3001-ls-files-others-exclude.sh | 23 ++++++++++++++++++-----
2 files changed, 32 insertions(+), 18 deletions(-)
4ae2315518ee4017c6646a4421cf448297fc6dcc
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -115,14 +115,14 @@ An exclude pattern file used by (2) and
per line. A line that starts with a '#' can be used as comment
for readability.
-The list of patterns that is in effect at a given time is
-built and ordered in the following way:
+There are three lists of patterns that are in effect at a given
+time. They are built and ordered in the following way:
- * --exclude=<pattern> and lines read from --exclude-from=<file>
- come at the beginning of the list of patterns, in the order
- given on the command line. Patterns that come from the file
- specified with --exclude-from are ordered in the same order
- as they appear in the file.
+ * --exclude=<pattern> from the command line; patterns are
+ ordered in the same order as they appear on the command line.
+
+ * lines read from --exclude-from=<file>; patterns are ordered
+ in the same order as they appear in the file.
* When --exclude-per-directory=<name> is specified, upon
entering a directory that has such a file, its contents are
@@ -130,11 +130,12 @@ built and ordered in the following way:
are popped off when leaving the directory.
Each pattern in the pattern list specifies "a match pattern" and
-optionally the fate --- either a file that matches the pattern
-is considered excluded or included. By default, this being
-"exclude" mechanism, the fate is "excluded". A filename is
-examined against the patterns in the list, and the first match
-determines its fate.
+optionally the fate;n either a file that matches the pattern is
+considered excluded or included. A filename is matched against
+the patterns in the three lists; the --exclude-from list is
+checked first, then the --exclude-per-directory list, and then
+finally the --exclude list. The last match determines its fate.
+If there is no match in the three lists, the fate is "included".
A pattern specified on the command line with --exclude or read
from the file specified with --exclude-from is relative to the
@@ -168,9 +169,9 @@ An example:
*.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
+ *.html
# except foo.html which is maintained by hand
!foo.html
- *.html
$ git-ls-files --ignored \
--exclude='Documentation/*.[0-9]' \
--exclude-from=.git/ignore \
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -14,7 +14,7 @@ rm -fr one three
for dir in . one one/two three
do
mkdir -p $dir &&
- for i in 1 2 3 4 5
+ for i in 1 2 3 4 5 6 7 8
do
>$dir/a.$i
done
@@ -24,31 +24,44 @@ cat >expect <<EOF
a.2
a.4
a.5
+a.8
one/a.3
one/a.4
one/a.5
+one/a.7
+one/two/a.2
one/two/a.3
one/two/a.5
+one/two/a.7
+one/two/a.8
three/a.2
three/a.3
three/a.4
three/a.5
+three/a.8
EOF
echo '.gitignore
output
expect
.gitignore
-' >.git/ignore
+*.7
+!*.8' >.git/ignore
echo '*.1
-/*.3' >.gitignore
+/*.3
+!*.6' >.gitignore
echo '*.2
-two/*.4' >one/.gitignore
+two/*.4
+!*.7
+*.8' >one/.gitignore
+echo '!*.2
+!*.8' >one/two/.gitignore
test_expect_success \
- 'git-ls-files --others --exclude.' \
+ 'git-ls-files --others with various exclude options.' \
'git-ls-files --others \
+ --exclude=\*.6 \
--exclude-per-directory=.gitignore \
--exclude-from=.git/ignore \
>output &&
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-29 7:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729070628.GA24895@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Aha, so it seems our problem is hopefully only in terminology, great.
>
> So, what do you mean by "clone" here? And what command should I use for
> pushing then?
Notice I never used the word "clone" in what I said.
What I mean by "a semantically equivalent two repositories,
potentially one being a strict subset of the other" is you can
pull head A from one or head A from the other and can get the
same result (although one may and the other may not have head
B). And naturally you use send-pack for pushing.
If I "clone" from repository A to create a repository B, I would
never "push back" from B to A. Instead I would ask a person who
owns A to "pull from B". My impression is the patch flow in the
kernel circle works like that (although I have never been in
that circle).
Now, A may happen to be on my home machine and B may happen be
on my notebook, meaning the owner of A and B are both myself.
But even in that case I would still work by "pulling from A"
when I am on B, and "pulling from B" when I am on A. In other
words, "pulling" is the only patch flow mechanism I would use.
Pushing is only for publication and I treat it as just a
GIT-aware rsync/mirror, nothing more. I have a feeling that
your workflow is different and you plan to use both push and
pull for normal patch flows. This distinction is probably where
the disagreement comes from.
And I strongly suspect that the primary reason that I "simply do
not get it" after reading your messages is because my mental
model is strongly molded into what Linus taught us. I have to
unlearn things...
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Matthias Urlichs @ 2005-07-29 7:37 UTC (permalink / raw)
To: git
In-Reply-To: <20050729072157.GD24895@pasky.ji.cz>
Hi,
Petr Baudis:
> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
> where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> > Hi, A Large Angry SCM wrote:
> >
> > > So you're arguing for "last match wins" versus "first match wins". I,
> > > personally, find the former more natural and easier to debug by hand.
> >
> > You know, up until five minutes ago, I thought so too.
>
> So is the Large Angry SCM agreeing with me or not? I wrote long reply to
> his mail, then reread what he wrote again, and decided that he is
> _agreeing_ with me and you that "last match wins" is better. :-)
>
Bah, I misparsed his sentence (I read "former" as "first wins"), otherwise
my reply would have been worded slightly differently.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"All these black people are screwing up my democracy." - Ian Smith
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Petr Baudis @ 2005-07-29 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, Linus Torvalds, git, Marco Costalba
In-Reply-To: <7vack6mcd7.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> * When checking a file to see if it is excluded, we first look
> at "exclude-from patterns" list, then "per directory
> patterns" list, and then "command line patterns list", in
> that order. The last match wins [*1*].
Hmm. What about just excluding the files according to the order of
parameters on the command line?
Here, the question is whether the GIT Core tools should provide full
flexibility and friendness to custom use, or rather serve as tighter
unifying layer for the porcelains, enforcing certain conventions. That's
up to you to decide, obviously, but perhaps someone will want to use the
exclude mechanisms for something else than the "classic" other files
ignoring stuff, and generally more flexibility might be better. So I'd
argue for codifying those conventions at the level of the porcelain
users and not enforcing them in git-ls-files itself.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Sam Ravnborg @ 2005-07-29 7:31 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20050729065335.GA32263@mythryan2.michonline.com>
> > While I do not have strong objections to make the build process
> > go faster, it is somewhat disturbing that the Makefile pieces
> > maintained in subdirectories need to name things they touch
> > using paths that include the subdirectory names. I do not have
> > a better alternative to suggest, though...
If the goal is to speed up the build process the only sane way is to fix
the dependencies. In kbuild fixdep is used to parse the .c file and it
locates all references to .h files (recursive) and also detects any
usage of CONFIG_ symbols.
This part should be relative straightforward to include in git.
> I think I'm going to rethink this, a bit more. I'm unhappy with how I
> had to edit the sub-dir Makefiles to include directory names. Sam, if
> you happen to be reading this, feel free to help out!
>
> I'm almost thinking that something like:
>
> PROGS :=
> SCRIPTS :=
> include x/Makefile.inc
> PROGRAMS += $(addprefix x/,$PROGS)
> ALL_SCRIPTS += $(addprefix x/,$SCRIPTS)
That is doable for sure. But it hits you hard when you have to create
some special rules in a subdirectory - then you need to know in what
directory you are placed. You could assing sub := x before including
x/Makefile.inc.
On the other hand. The recursive make considered harmful is IMHO a bit
overaggregated. See the kernel where it is used extensively. And it
works with no hassle. For a small project like git it should be possible
to keep the dependencies in proper shape so there is no cross directory
boundaries to worry about - or at least only a few.
Sam
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Petr Baudis @ 2005-07-29 7:21 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.28.19.25.39.562903@smurf.noris.de>
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> Hi, A Large Angry SCM wrote:
>
> > So you're arguing for "last match wins" versus "first match wins". I,
> > personally, find the former more natural and easier to debug by hand.
>
> You know, up until five minutes ago, I thought so too.
So is the Large Angry SCM agreeing with me or not? I wrote long reply to
his mail, then reread what he wrote again, and decided that he is
_agreeing_ with me and you that "last match wins" is better. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29 7:14 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.28.21.13.35.458701@smurf.noris.de>
Dear diary, on Thu, Jul 28, 2005 at 11:13:38PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> Then, you'd kill porcelain writers who don't verify that the old head is
> a(n indirect) parent of the new one. ;-)
send-pack.c:
if (!ref_newer(new_sha1, ref->old_sha1)) {
error("remote '%s' isn't a strict parent of local", name);
continue;
}
"git-core: Making life nice for Porcelains."
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29 7:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.58.0507282201110.3005@wgmdd8.biozentrum.uni-wuerzburg.de>
Dear diary, on Thu, Jul 28, 2005 at 10:14:35PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,
Hello,
> Naming the remote HEAD differently than the local HEAD is just *wrong*
> when you want to push back to them.
But you might not know that in advance. That's one of they key points of
the distributed systems, after all - when you are cloning, you needn't
know in advance that you will want to do local commits, and don't need
upstream approval. You also might not know in advance that you will want
to push them back. Sure, distributed systems are more complicated. If
you don't like complicated things, there's always RCS. ;-)
> The only sane way if you have to have different local and remote HEADs
> that I can think of, would be to allow only the current local active HEAD
> to be pushed to a certain remote HEAD (preferably identified by a file in
> .git/branches).
Well, but (if I understand you correctly) that was always the _point_.
It's what I was talking about all the time. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Josef Weidendorfer, git
In-Reply-To: <7v4qaeqrh3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 29, 2005 at 04:24:40AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > One of the Cogito design bits is that branch name is something local to
> > the repository. When you are adding a branch, the local name you assign
> > it is your private thing repository-wise, and doesn't have to have any
> > correlation to other repositories you might interact width.
>
> I do not disagree with that. I think branch name is mostly a
> local matter. However, I happen to think that two repositories
> you use send-pack (not clone which uses completely different
> protocol) to sync one from the other are semantically equivalent
> ones, except that the destination may be a strict subset. I
> think of it as "a copy I throw at a public place to show what I
> have in my private repository I work in", so,...
Aha, so it seems our problem is hopefully only in terminology, great.
So, what do you mean by "clone" here? And what command should I use for
pushing then?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Ryan Anderson @ 2005-07-29 6:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4qafrk8w.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 27, 2005 at 02:50:55PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > 003afd3ed1f83b4533b628182fa16c9ab0dc0467
> > diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/Makefile.inc
> > @@ -0,0 +1,50 @@
> > +MAN1_TXT=$(wildcard Documentation/git-*.txt)
> > +MAN7_TXT=Documentation/git.txt
> > +
> >...
>
> While I do not have strong objections to make the build process
> go faster, it is somewhat disturbing that the Makefile pieces
> maintained in subdirectories need to name things they touch
> using paths that include the subdirectory names. I do not have
> a better alternative to suggest, though...
>
> I'd keep it in the proposed updates branch for now and wait for
> a bit until discussions on the list die out.
Sorry for taking so long to respond here - I've probably got 2 or 3
general replies to make on this thread, but basically, I truly intended
it as a RFC.
I think the best justification for the end goal of the process I was
thinking of starting is this:
$ git clone -l git-linus git-example
defaulting to local storage area
0 blocks
$ cd git-example
$ git checkout
$ ls | wc -l
154
I've been spending some time trying to think out what qualifies as a
"tool" and what is "core", etc. I think it wouldn't be a bad idea to
think about restructuring things a bit so that all the little "helper"
scripts we keep adding don't fill up the top level directory.
I think I'm going to rethink this, a bit more. I'm unhappy with how I
had to edit the sub-dir Makefiles to include directory names. Sam, if
you happen to be reading this, feel free to help out!
I'm almost thinking that something like:
PROGS :=
SCRIPTS :=
include x/Makefile.inc
PROGRAMS += $(addprefix x/,$PROGS)
ALL_SCRIPTS += $(addprefix x/,$SCRIPTS)
in the top-level Makefile might be the cleanest way to keep the
subdirectory ones simpler - but that's still somewhat distasteful, and
only fixes up one part of the problem.
Anyway, I'll come back to this later when I've got some of the follow-up
issues sorted out, like what to do with the directory structure.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Tutorial problem a/a a/b
From: Junio C Hamano @ 2005-07-29 5:35 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git, torvalds
In-Reply-To: <1122582005.12374.6.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> In the tutorial the user is instructed to create two files: a and b.
>
> Then when the user diffs the files, they see this:
>
> diff --git a/a b/a
>
> That really confused somebody and I had to untangle their brain. :-)
Yes I was confused when I read it for the first time.
How does this look?
------------
[PATCH] Tutorial: use a bit longer sample filenames.
Darrin Thompson noticed when he was showing off GIT to others
that the use of filenames "a" and "b" in the tutorial example
was unnecessarily confusing, especially with our "patch -p1"
prefix a/ and b/, without giving us any patch. I was very
tempted to change them back to l/ and k/ prefixes, but decided
to restrain myself and update the tutorial instead ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Linus CC'ed for a historical amusement value.
Documentation/tutorial.txt | 80 ++++++++++++++++++++++----------------------
1 files changed, 40 insertions(+), 40 deletions(-)
0f6aa6e8db2321678645a979aa3777ed9f852a43
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -104,8 +104,8 @@ Start off with just creating any random
in your git archive. We'll start off with a few bad examples, just to
get a feel for how this works:
- echo "Hello World" > a
- echo "Silly example" > b
+ echo "Hello World" >hello
+ echo "Silly example" >example
you have now created two files in your working directory, but to
actually check in your hard work, you will have to go through two steps:
@@ -125,7 +125,7 @@ adding a new entry with the "--add" flag
So to populate the index with the two files you just created, you can do
- git-update-cache --add a b
+ git-update-cache --add hello example
and you have now told git to track those two files.
@@ -155,11 +155,11 @@ regular file), and you can see the conte
git-cat-file "blob" 557db03de997c86a4a028e1ebd3a1ceb225be238
which will print out "Hello World". The object 557db... is nothing
-more than the contents of your file "a".
+more than the contents of your file "hello".
-[ Digression: don't confuse that object with the file "a" itself. The
+[ Digression: don't confuse that object with the file "hello" itself. The
object is literally just those specific _contents_ of the file, and
- however much you later change the contents in file "a", the object we
+ however much you later change the contents in file "hello", the object we
just looked at will never change. Objects are immutable. ]
Anyway, as we mentioned previously, you normally never actually take a
@@ -180,11 +180,11 @@ However, since git knows about them, you
most basic git commands to manipulate the files or look at their status.
In particular, let's not even check in the two files into git yet, we'll
-start off by adding another line to "a" first:
+start off by adding another line to "hello" first:
- echo "It's a new day for git" >> a
+ echo "It's a new day for git" >>hello
-and you can now, since you told git about the previous state of "a", ask
+and you can now, since you told git about the previous state of "hello", ask
git what has changed in the tree compared to your old index, using the
"git-diff-files" command:
@@ -192,7 +192,7 @@ git what has changed in the tree compare
oops. That wasn't very readable. It just spit out its own internal
version of a "diff", but that internal version really just tells you
-that it has noticed that "a" has been modified, and that the old object
+that it has noticed that "hello" has been modified, and that the old object
contents it had have been replaced with something else.
To make it readable, we can tell git-diff-files to output the
@@ -202,14 +202,14 @@ differences as a patch, using the "-p" f
which will spit out
- diff --git a/a b/a
- --- a/a
- +++ b/a
+ diff --git a/hello b/hello
+ --- a/hello
+ +++ b/hello
@@ -1 +1,2 @@
Hello World
+It's a new day for git
-ie the diff of the change we caused by adding another line to "a".
+ie the diff of the change we caused by adding another line to "hello".
In other words, git-diff-files always shows us the difference between
what is recorded in the index, and what is currently in the working
@@ -243,10 +243,10 @@ creating the equivalent of a git "direct
and this will just output the name of the resulting tree, in this case
(if you have does exactly as I've described) it should be
- 3ede4ed7e895432c0a247f09d71a76db53bd0fa4
+ 8988da15d077d4829fc51d8544c097def6644dbb
which is another incomprehensible object name. Again, if you want to,
-you can use "git-cat-file -t 3ede4.." to see that this time the object
+you can use "git-cat-file -t 8988d.." to see that this time the object
is not a "blob" object, but a "tree" object (you can also use
git-cat-file to actually output the raw object contents, but you'll see
mainly a binary mess, so that's less interesting).
@@ -273,7 +273,7 @@ shell pipeline:
which will say:
- Committing initial tree 3ede4ed7e895432c0a247f09d71a76db53bd0fa4
+ Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
just to warn you about the fact that it created a totally new commit
that is not related to anything else. Normally you do this only _once_
@@ -293,13 +293,13 @@ instead, and it would have done the abov
Making a change
---------------
-Remember how we did the "git-update-cache" on file "a" and then we
-changed "a" afterward, and could compare the new state of "a" with the
+Remember how we did the "git-update-cache" on file "hello" and then we
+changed "hello" afterward, and could compare the new state of "hello" with the
state we saved in the index file?
Further, remember how I said that "git-write-tree" writes the contents
of the _index_ file to the tree, and thus what we just committed was in
-fact the _original_ contents of the file "a", not the new ones. We did
+fact the _original_ contents of the file "hello", not the new ones. We did
that on purpose, to show the difference between the index state, and the
state in the working directory, and how they don't have to match, even
when we commit things.
@@ -362,19 +362,19 @@ in the working directory that we want to
work through the index file, so the first thing we need to do is to
update the index cache:
- git-update-cache a
+ git-update-cache hello
(note how we didn't need the "--add" flag this time, since git knew
about the file already).
Note what happens to the different git-diff-xxx versions here. After
-we've updated "a" in the index, "git-diff-files -p" now shows no
+we've updated "hello" in the index, "git-diff-files -p" now shows no
differences, but "git-diff-cache -p HEAD" still _does_ show that the
current state is different from the state we committed. In fact, now
"git-diff-cache" shows the same difference whether we use the "--cached"
flag or not, since now the index is coherent with the working directory.
-Now, since we've updated "a" in the index, we can commit the new
+Now, since we've updated "hello" in the index, we can commit the new
version. We could do it by writing the tree by hand again, and
committing the tree (this time we'd have to use the "-p HEAD" flag to
tell commit that the HEAD was the _parent_ of the new commit, and that
@@ -585,7 +585,7 @@ create your own copy of the git reposito
mkdir my-git
cd my-git
- rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git .git
+ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
followed by
@@ -683,12 +683,12 @@ being the same as the original "master"
that branch, and do some work there.
git checkout mybranch
- echo "Work, work, work" >> a
- git commit a
+ echo "Work, work, work" >>hello
+ git commit hello
-Here, we just added another line to "a", and we used a shorthand for
-both going a "git-update-cache a" and "git commit" by just giving the
-filename directly to "git commit".
+Here, we just added another line to "hello", and we used a shorthand for
+both going a "git-update-cache hello" and "git commit" by just giving the
+filename directly to "git commit".
Now, to make it a bit more interesting, let's assume that somebody else
does some work in the original branch, and simulate that by going back
@@ -696,13 +696,13 @@ to the master branch, and editing the sa
git checkout master
-Here, take a moment to look at the contents of "a", and notice how they
+Here, take a moment to look at the contents of "hello", and notice how they
don't contain the work we just did in "mybranch" - because that work
hasn't happened in the "master" branch at all. Then do
- echo "Play, play, play" >> a
- echo "Lots of fun" >> b
- git commit a b
+ echo "Play, play, play" >>hello
+ echo "Lots of fun" >>example
+ git commit hello example
since the master branch is obviously in a much better mood.
@@ -734,20 +734,20 @@ of it as it can automatically (which in
file, which had no differences in the "mybranch" branch), and say:
Simple merge failed, trying Automatic merge
- Auto-merging a.
+ Auto-merging hello.
merge: warning: conflicts during merge
- ERROR: Merge conflict in a.
+ ERROR: Merge conflict in hello.
fatal: merge program failed
Automatic merge failed, fix up by hand
which is way too verbose, but it basically tells you that it failed the
really trivial merge ("Simple merge") and did an "Automatic merge"
-instead, but that too failed due to conflicts in "a".
+instead, but that too failed due to conflicts in "hello".
-Not to worry. It left the (trivial) conflict in "a" in the same form you
+Not to worry. It left the (trivial) conflict in "hello" in the same form you
should already be well used to if you've ever used CVS, so let's just
-open "a" in our editor (whatever that may be), and fix it up somehow.
-I'd suggest just making it so that "a" contains all four lines:
+open "hello" in our editor (whatever that may be), and fix it up somehow.
+I'd suggest just making it so that "hello" contains all four lines:
Hello World
It's a new day for git
@@ -756,7 +756,7 @@ I'd suggest just making it so that "a" c
and once you're happy with your manual merge, just do a
- git commit a
+ git commit hello
which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-29 5:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, Linus Torvalds, git, Marco Costalba
In-Reply-To: <20050728155210.GA17952@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> You generally don't say "I never want this ignored, but I want
> the rest of that ignored", but "I want that ignored, except
> this".
OK.
> But more importantly,
>
> .gitignore: *.txt
> Documentation/.gitignore: !*.txt
>
> will not work, which was the whole _point_ of the exclusion.
I agree that this is a bigger issue.
My updated proposal is as follows:
* We collect --exclude patterns in "command line patterns"
list, in the same order as given on the command line.
* We collect patterns read from the files specified with
--exclude-from in "exclude-from patterns" list, in the same
order as given on the command line and the same order
patterns appear in the file.
* While we descend the directories, files named by EPD flag, if
found, are read from top to bottom and concatenated into the
"per directory patterns" list. When leaving the directory,
the patterns read from that directory's EPD file are popped
off.
* When checking a file to see if it is excluded, we first look
at "exclude-from patterns" list, then "per directory
patterns" list, and then "command line patterns list", in
that order. The last match wins [*1*].
An example:
You have three files in your git source tree and your $HOME:
git/.gitignore lists patterns A and B
git/Documentation/.gitignore lists patterns C and D
git/.git/info/ignore lists patterns E and F
$HOME/.gitrc/ignore lists patterns G and H
You say:
git-ls-files --others \
--exclude=I --exclude=J \
--exclude-from=.git/info/ignore \
--exclude-from=~/.gitrc/ignore \
--exclude-per-directory=.gitignore \
While in git/ directory itself, the following patterns are
checked and the last match wins:
E F G H A B I J
When we descend into git/Documentation, the list of patterns
used becomes the following, still the last match wins:
E F G H A B C D I J
The reason --exclude-from comes first (i.e. having the least say
in the outcome) and --exclude comes last (i.e. having the most
say) is because the former is to give the overall fallback
default, and the latter is the ultimate end user preference.
Does this sound reasonable?
[Footnote]
*1* In real implementation, I would probably scan in reverse
from the end and stop at the first match, but that is an
implementation detail.
^ permalink raw reply
* [PATCH] Make git-apply --stat less butt-ugly with long filenames
From: Linus Torvalds @ 2005-07-29 3:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
When git-apply was printing out long filenames, it used to just truncate
them to show the last "max_len" characters of the filename. Which can be
really quite ugly (note the two filenames that have just been silently
truncated from the beginning - it looks even worse when there are lots
of them, like there were in the current v2.6.13-rc4 cris arch update):
Documentation/video4linux/README.saa7134 | 9
Documentation/video4linux/bttv/Cards | 74
umentation/video4linux/hauppauge-wintv-cx88-ir.txt | 54
Documentation/video4linux/lifeview.txt | 42
mentation/video4linux/not-in-cx2388x-datasheet.txt | 41
Documentation/w1/w1.generic | 107
With this patch it now looks like so:
Documentation/video4linux/README.saa7134 | 9
Documentation/video4linux/bttv/Cards | 74
.../video4linux/hauppauge-wintv-cx88-ir.txt | 54
Documentation/video4linux/lifeview.txt | 42
.../video4linux/not-in-cx2388x-datasheet.txt | 41
Documentation/w1/w1.generic | 107
ie we've made it clear with an ellipsis that we've cut off something from
the beginning, and it also tries to do it cleanly at a subdirectory level.
Signed-off-by: Linus "good taste" Torvalds <torvalds@osdl.org>
---
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -737,6 +737,7 @@ static const char minuses[]= "----------
static void show_stats(struct patch *patch)
{
+ const char *prefix = "";
char *name = patch->new_name;
int len, max, add, del, total;
@@ -750,8 +751,15 @@ static void show_stats(struct patch *pat
max = max_len;
if (max > 50)
max = 50;
- if (len > max)
+ if (len > max) {
+ char *slash;
+ prefix = "...";
+ max -= 3;
name += len - max;
+ slash = strchr(name, '/');
+ if (slash)
+ name = slash;
+ }
len = max;
/*
@@ -770,7 +778,7 @@ static void show_stats(struct patch *pat
add = (add * max + max_change / 2) / max_change;
del = total - add;
}
- printf(" %-*s |%5d %.*s%.*s\n",
+ printf(" %s%-*s |%5d %.*s%.*s\n", prefix,
len, name, patch->lines_added + patch->lines_deleted,
add, pluses, del, minuses);
}
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Linus Torvalds @ 2005-07-29 2:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, Catalin Marinas, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <7vack6qrhd.fsf@assigned-by-dhcp.cox.net>
On Thu, 28 Jul 2005, Junio C Hamano wrote:
>
> I do not want to get involved in policy decisions, but for the
> record I always hated your commit log for that "identifies the
> committer physically" approach.
Well, I have to say that I find it quite useful myself. I try to commit
x86 patches to the kernel on an x86 machine (I had better had tested them
there), so they usually say "torvalds@evo.osdl.org" or "torvalds@yonah..",
while my normal patches tend to say "torvalds@g5.." since that's my main
machine.
So I tend to not override it, even though none of those are really valid
email addresses.
Linus
^ permalink raw reply
* Re: [PATCH] add "-f" option to git-commit-script to force commit withoutchanges
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507281646340.25783@wgmdd8.biozentrum.uni-wuerzburg.de>
While I agree there should be a graceful way to go back to the
original head from a failed merge situation, I do not think
"committing the current HEAD" is the right model for the end
user to think about it.
Wouldn't using "checkout -f" to revert to the version you would
want to go back work as expected?
^ permalink raw reply
* Re: Dump http servers still slow?
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1122584423.12374.11.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> I just ran git clone against the mainline git repository using both http
> and rsync. http was still quite slow compared to rsync. I expected that
> the http time would be much faster than in the past due to the pack
> file.
>
> Is there something simple I'm missing?
No, the only thing you missed was that I did not write it to
make it fast, but just to make it work ;-). The commit walker
simply does not work against a dumb http server repository that
is packed and prune-packed, which is already the case for both
kernel and git repositories.
The thing is, the base pack for the git repository is 1.8MB
currently containing 4500+ objects, while we accumulated 600+
unpacked objects since then which is about ~5MB. The commit
walker needs to fetched the latter one by one in the old way.
When packed incrementally on top of the base pack, these 600+
unpacked objects compress down to something like 400KB, and I
was hoping we could wait until we accumulate enough to produce
an incremental about a meg or so ...
^ 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