* Re: 2 questions/nits about commit and config
From: Alan Chandler @ 2006-02-04 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd7evk38.fsf@assigned-by-dhcp.cox.net>
On Saturday 04 February 2006 22:24, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > An example of such semantic change would be: if I am in
> > subdirecotry foo/, commit changes to files in that subdirectory
> > and subdirectory alone. But that is actively _encouraging_
> > partial commits (commits that records a state that never existed
> > in your working tree as a whole) so I personally am not so
> > enthused to buy such a _feature_.
>
> Before people start complaining about it, I take this part
> back. "git commit -a" inside a subdirectory "foo" is not much
> different from "git commit foo/a foo/b foo/c" from the toplevel
> directory to explicitly say "Don't worry about what I told the
> index so far; I want to check in changes only to these paths",
> and making a partial commit out of the current HEAD and the
> specified working tree files using a temporary index (while
> updating the main index at the same time), so I am inclined to
> say we should support it that way, since during the previous
> discussion we have pretty much settled how we would want "git
> commit paths..." and "git commit --include paths..." commands to
> behave.
And I did describe a use case this morning in another thread for this very
thing. For convenience I repeat it here
[Incidentally there is a use case that doesn't seem to have been discussed in
this thread which I use cg-commit all the time for and will now have to see
if there is a use index file equivalence for. That is, I am developing a web
application and in the running version the database framework (iBatis) is
using Tomcats connection pooling. In order to run my JUnit test harness, I
don't have tomcat, so I need to define a different version of iBatis
configuration file to used its own database connection. So I have created a
test branch and edited the configuration file in that branch, and I update
both code and tests in a edit/compile/fix and text loop until I have written
or changed both code and tests. I then do a cg-commit which lists the files
I have changed. I ONLY commit those in the test harness - by deleting the
others from cogito's list of files to commit - and then repeat the commit
commiting the rest]. I then switch back to my master branch and cherry pick
commit that is the code changes - not the text harness]
In this case the tests, and the code that it was testing were in different
subdirectories, so the ability to go into one directory and commit all in
that directory, followed by the ability to go into the other and do the same
would be extremely useful.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Merge problems.
From: Ian Molton @ 2006-02-04 22:50 UTC (permalink / raw)
To: git
Doing the following:
git checkout -b mywork v2.6.12
# work, work, work
git commit -a
git merge "Merging happily." mywork v2.6.15
At theat point I get a merge failure - I assume that means I've
got conflicts. I forgot to not the exact error.
so I can see unmerged files using git ls-files --unmerged which lists a
lot of SHA1 hashes and paths. but most of the files in the list I havent
touched! why would they have any conflicts? surely they would simply
update 2.6.12->2.6.15 ?
The SHA1 hashes are all listed at least twice per file too, eg.
100644 d058e65daf19f4bb8c257e2273f4c935ccee5121 1
Documentation/DocBook/scsidrivers.tmpl
100644 d058e65daf19f4bb8c257e2273f4c935ccee5121 2
Documentation/DocBook/scsidrivers.tmpl
What does this mean?
How do I work out what needs merging byhand?
^ permalink raw reply
* Re: 2 questions/nits about commit and config
From: Junio C Hamano @ 2006-02-04 22:24 UTC (permalink / raw)
To: git
In-Reply-To: <7voe1mvkls.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> An example of such semantic change would be: if I am in
> subdirecotry foo/, commit changes to files in that subdirectory
> and subdirectory alone. But that is actively _encouraging_
> partial commits (commits that records a state that never existed
> in your working tree as a whole) so I personally am not so
> enthused to buy such a _feature_.
Before people start complaining about it, I take this part
back. "git commit -a" inside a subdirectory "foo" is not much
different from "git commit foo/a foo/b foo/c" from the toplevel
directory to explicitly say "Don't worry about what I told the
index so far; I want to check in changes only to these paths",
and making a partial commit out of the current HEAD and the
specified working tree files using a temporary index (while
updating the main index at the same time), so I am inclined to
say we should support it that way, since during the previous
discussion we have pretty much settled how we would want "git
commit paths..." and "git commit --include paths..." commands to
behave.
^ permalink raw reply
* Re: 2 questions/nits about commit and config
From: Junio C Hamano @ 2006-02-04 22:13 UTC (permalink / raw)
To: Michael Fischer; +Cc: git
In-Reply-To: <20060204212337.GA8612@blinkenlights.visv.net>
Michael Fischer <michael@visv.net> writes:
> 1) git commit -m"this is a commit message" doesn't work.
> It has to have a space between -m and the first '"'.
Well that is a minor inconvenience and would be trivial to
accomodate, but please do not send patches in yet. I do not
know if you have been following the list discussion, but it
seems very likely that we will update the way git-commit command
works slightly in other semantic aspects and I do not want to
worry about trivialities. Duly noted and I'll try to remember
that command line parsing issue when we do a rewrite.
> 2) I can descend into subdirectories in my project, and
> git diff, git status both work fine, but git commit
> gets annoyed..
This is more or less deliberate, and I personally do not have a
strong reason to change it (except perhaps making the error
message a bit more helpful) even when we do a rewrite.
Unlike CVS that does version control per file basis, commit in
git is really about the whole tree state, so even if we changed
'git commit' to work from subdirectories that would commit
everything, which would probably be more confusing. That is,
until somebody comes up with a good semantics and rationale why
allowing that semantics is a good change and the code to do so.
An example of such semantic change would be: if I am in
subdirecotry foo/, commit changes to files in that subdirectory
and subdirectory alone. But that is actively _encouraging_
partial commits (commits that records a state that never existed
in your working tree as a whole) so I personally am not so
enthused to buy such a _feature_.
^ permalink raw reply
* Re: [PATCH 3/3] daemon: Support a --user-path option.
From: Junio C Hamano @ 2006-02-04 22:02 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrndu9v7h.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> OK, then: how about putting the user_path logic into enter_repo? Like
> this, perhaps:
I'd like to *REALLY* leave enter_repo alone unless necessary.
The last round to finalize enter_repo() was painful enough to
think its security implications through. And this particular
"public_html" insertion change can be done without touching it.
I think the attached patch would essentially do the same thing.
Only lightly tested, but tested nevertheless ;-). This comes on
top of what I have in 'pu'.
One thing I have not done yet but I consider bould be a good
change is to perhaps change the whitelist logic in path_ok()
after enter_repo() says what canonicalized path it decided to
use, so that it allows any user-relative paths without checking
the whitelist when user_path is in effect (and perhaps not
empty, so giving --user-path="public_git" would allow everybody
while giving --user-path alone or --user-path="" would not).
Otherwise, as the code currently stands (regardless of any of
the patches in the discussion in this thread) I think you need
to list all users on the whitelist line. I think --user-path is
about giving all users ability to export their stuff. What do
you think?
-- >8 --
diff --git a/daemon.c b/daemon.c
index dab8c2c..a1ccda3 100644
--- a/daemon.c
+++ b/daemon.c
@@ -18,7 +18,8 @@ static int reuseaddr;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
-" [--base-path=path] [--reuseaddr] [directory...]";
+" [--base-path=path] [--user-path | --user-path=path]\n"
+" [--reuseaddr] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
@@ -30,6 +31,12 @@ static int export_all_trees = 0;
/* Take all paths relative to this one if non-NULL */
static char *base_path = NULL;
+/* If defined, ~user notation is allowed and the string is inserted
+ * after ~user/. E.g. a request to git://host/~alice/frotz would
+ * go to /home/alice/pub_git/frotz with --user-path=pub_git.
+ */
+static char *user_path = NULL;
+
/* Timeout, and initial timeout */
static unsigned int timeout = 0;
static unsigned int init_timeout = 0;
@@ -137,6 +144,7 @@ static int avoid_alias(char *p)
static char *path_ok(char *dir)
{
+ static char rpath[PATH_MAX];
char *path;
if (avoid_alias(dir)) {
@@ -144,12 +152,31 @@ static char *path_ok(char *dir)
return NULL;
}
- if (base_path) {
- static char rpath[PATH_MAX];
- if (!strict_paths && *dir == '~')
- ; /* allow user relative paths */
- else if (*dir != '/') {
- /* otherwise allow only absolute */
+ if (*dir == '~') {
+ if (!user_path) {
+ logerror("'%s': User-path not allowed", dir);
+ return NULL;
+ }
+ if (*user_path) {
+ /* Got either "~alice" or "~alice/foo";
+ * rewrite them to "~alice/%s" or
+ * "~alice/%s/foo".
+ */
+ int namlen, restlen = strlen(dir);
+ char *slash = strchr(dir, '/');
+ if (!slash)
+ slash = dir + restlen;
+ namlen = slash - dir;
+ restlen -= namlen;
+ loginfo("userpath <%s>, request <%s>, namlen %d, restlen %d, slash <%s>", user_path, dir, namlen, restlen, slash);
+ snprintf(rpath, PATH_MAX, "%.*s/%s%.*s",
+ namlen, dir, user_path, restlen, slash);
+ dir = rpath;
+ }
+ }
+ else if (base_path) {
+ if (*dir != '/') {
+ /* Allow only absolute */
logerror("'%s': Non-absolute path denied (base-path active)", dir);
return NULL;
}
@@ -688,6 +715,14 @@ int main(int argc, char **argv)
reuseaddr = 1;
continue;
}
+ if (!strcmp(arg, "--user-path")) {
+ user_path = "";
+ continue;
+ }
+ if (!strncmp(arg, "--user-path=", 12)) {
+ user_path = arg + 12;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
^ permalink raw reply related
* 2 questions/nits about commit and config
From: Michael Fischer @ 2006-02-04 21:23 UTC (permalink / raw)
To: git
Hi.
Well, I went ahead and put my current project under git. So far so good.
Two nits: (yeah, I'm a "recovering" CVS user)
1) git commit -m"this is a commit message" doesn't work.
It has to have a space between -m and the first '"'.
I *think* this is due to git-commit.sh and how it parses
the args, but I'm not quite sure of how to try to patch
that without mucking up the whole works. Very odd
and hard to figure out what was "wrong" for a CVS user.
2) I can descend into subdirectories in my project, and
git diff, git status both work fine, but git commit
gets annoyed and says "fatal: Not a git repository: '.git'".
Irksome to say the least, and not a little suprising.
Is that something which can be fixed, or is there a
magic incantation (perhaps in .git/config) to make
git commit work anywhere in the source tree?
Incidentally, I groped around my git mailbox, and google,
looking for some definitive list/examples of what can
go in the .git/config file. Seems there must be more
than what is listed in the manpage...
Thanks for all the cool work.
Michael
--
Michael Fischer Happiness is a config option.
michael@visv.net Recompile and be happy.
^ permalink raw reply
* Re: The merge from hell...
From: Linus Torvalds @ 2006-02-04 20:59 UTC (permalink / raw)
To: Paul Mackerras
Cc: Junio C Hamano, Git Mailing List, Marco Costalba, Aneesh Kumar
In-Reply-To: <Pine.LNX.4.64.0602041125440.3854@g5.osdl.org>
On Sat, 4 Feb 2006, Linus Torvalds wrote:
>
> Doing a
>
> git-rev-list --parents HEAD |
> egrep '^.{90}' |
> cut -d' ' -f1 |
> git-diff-tree --pretty --cc --stdin
> | less -S
>
> on the kernel is actually interesting. It's interesting because it shows
> that out of 1391 merges, in the kernel, only _19_ actually had these close
> calls. Some - but certainly not all - of them actually did need manual
> fixup.
There are some doubly interesting lessons when I looked closer.
In particular, some merges that needed manual fixups do _not_ show up. I
found that surprising, at first. I expected that if I had to fix something
manually, it would obviously show up in the "--cc" output.
Not so. In fact, the one I looked closer at didn't show up even in the
"long" version, aka "-c".
The reason? A lot of the manual fixups end up selecting one version or the
other - the clash is because two people fixes the same bug slightly
differently, and the manual merge will end up just selecting one of them.
So then even "-c" won't show it, because it will notice that the whole
file was actually the same as one of the branches merged.
That may be a bit non-intuitive (maybe it shouldn't be, and it was just me
who didn't think about it the right way when I was initially surprised),
but it was definitely the right thing (both from a merge standpoint _and_
from a "what happened" standpoint) in the cases I looked at. The merge may
have been manual, but the end _result_ was trivial, and thus isn't shown.
So even after looking at it more, and searching for "interesting" cases
from the other side, I really like the current git-diff-tree --cc output.
It sometimes shows you things you wouldn't expect, and it sometimes
doesn't show you things you'd expect to show up, but in both cases it
shows/avoids the _right_ things.
However, the point that a "diff" itself isn't totally unambigious is well
taken. You're right that the very first hunk of the 12-way merge is really
not interesting.
However, looking at the other cases, it seems to not really be a huge
problem - that seems to be the only case in the whole kernel - and the
git-diff-tree algorithm may show an unnecessary hunk once in a blue moon,
but that's better than having the heuristics fail the other way around (ie
not showing a hunk).
That's what the gitk problem was, btw (showing too little, not too much).
Current gitk fails on this trivial case:
mkdir test-merge
cd test-merge/
git-init-db
#
# Initial silly contents
#
echo "Hello" > hello
echo "Hi" > hi
git add hello hi
git commit -m "Initial"
#
# Create another branch
#
git branch other
#
# Edit the contents on the master branch,
# commit it.
#
echo "Hello there" > hello
git commit -m "first change" hello
#
# Edit/commit the other differently
#
git checkout other
echo "Hello differently" > hello
git commit -m "second change" hello
#
# Try to merge - this will fail
#
git checkout master
git merge "Clashing merge" HEAD other
#
# Do an evil merge conflict that also edits a
# nonconflicting file
#
echo "Hello third version" > hello
echo "Hidden hi change" > hi
git commit -m "Evil merge conflict" hello hi
At this point, "git-diff-tree --cc HEAD" shows exactly the right thing,
but "gitk" doesn't show anything at all for that merge (it shows the
"hello" file in the file pane, but no diff at all, and certainly not the
"hi" file which it _should_ show).
Linus
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Seth Falcon @ 2006-02-04 19:51 UTC (permalink / raw)
To: git
In-Reply-To: <20060204054056.GB24314@Muzzle>
On 3 Feb 2006, normalperson@yhbt.net wrote:
>> Sam Vilain <sam@vilain.net> wrote:
>> Has anyone done any work on bidirectional access to SVN
>> repositories? ie, tracking and committing.
I think tailor claims to be able to handle this:
http://www.darcs.net/DarcsWiki/Tailor
The README in the devel version seems to indicate that two-way sync
for svn <--> git is implemented (despite the table on the main page).
--
+ seth
^ permalink raw reply
* Re: The merge from hell...
From: Linus Torvalds @ 2006-02-04 19:42 UTC (permalink / raw)
To: Paul Mackerras
Cc: Junio C Hamano, Git Mailing List, Marco Costalba, Aneesh Kumar
In-Reply-To: <17380.34301.584514.520465@cargo.ozlabs.ibm.com>
On Sat, 4 Feb 2006, Paul Mackerras wrote:
>
> > But this is still interesting:
> >
> > @@@@@@@@@@@@@ +308,35 @@@@@@@@@@@@@
> > goto end;
> > }
> > }
> > -- cx->usage++;
> > --
> >
> > +++ #ifdef CONFIG_HOTPLUG_CPU
> > +++ /*
>
> Why is that interesting? It seems to me that two independent changes
> were made that just happened to be within a couple of lines of each
> other, but didn't interact.
Correct. It's "interesting" only because the context of three lines
overlapped. So _technically_ it's not that interesting.
> The reason that one change appears in two branches, and the other in 3,
> is I think just related to where the branches start from. So IMHO this
> hunk isn't interesting.
I actually think that whenever there are edits this close (even if they
aren't strictly overlapping) they actually _are_ interesting. Even if it
merged automatically, you may well want to know that the automated merge
did something like this.
Doing a
git-rev-list --parents HEAD |
egrep '^.{90}' |
cut -d' ' -f1 |
git-diff-tree --pretty --cc --stdin
| less -S
on the kernel is actually interesting. It's interesting because it shows
that out of 1391 merges, in the kernel, only _19_ actually had these close
calls. Some - but certainly not all - of them actually did need manual
fixup.
So I actually prefer the "show close misses" case. But I guess we could
have a "-cN" line to tell how many lines of context to use..
Linus
^ permalink raw reply
* Re: [PATCH 3/3] daemon: Support a --user-path option.
From: Mark Wooding @ 2006-02-04 19:13 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xsrz49e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> In my simplistic view, --base-path serves something like /pub
> hierarchy of an ftp server or /var/www of an http server.
Yes, that's the way I think of it too. I'll probably point it at
/var/www/git or something when I finally get my tuits.
> For ~user/ based paths, it is natural to wish to limit the parts of
> home directories but there currently is not a good way to do so. We
> could probably extend the whitelist to take path glob patterns and say
> "~*/public-git/" or something silly like that, but that still means
> the request must be in the form
> "git://host/~alice/public-git/frotz.git/" (which may not be such a bad
> thing); "git://host/~alice/frotz.git/" might look nicer.
Putting `public-git' in the URLs seems to exposing an unnecessary
detail. Or it's saying something utterly obvious -- of course it's a
public GIT -- otherwise you wouldn't be asking for it.
> Your path munging idea is one way to do so. Another would be for
> alice to have $HOME/frotz.git/git-daemon-export-ok. Personally I do
> not think either would make too much of a difference from usability
> point of view.
The idea of filling my home directory with all my GIT repositories isn't
one I'm particularly keen on. For one thing, I can just tell that I'm
going to get confused between ~/src/foo/.git and ~/foo.git some day; and
besides, I like `ls ~' to be nice and short.
> So I am not dismissing what you are trying to achieve here.
> However, I am not happy about having <pwd.h> there and majorly
> duplicating what enter_repo() does in that part of the code.
OK, then: how about putting the user_path logic into enter_repo? Like
this, perhaps:
Documentation/git-daemon.txt | 11 +++++++++--
cache.h | 2 +-
daemon.c | 16 +++++++++++-----
path.c | 34 ++++++++++++++++++++++++++++------
receive-pack.c | 2 +-
upload-pack.c | 2 +-
6 files changed, 51 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index a20e053..2e48a10 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
- [--base-path=path] [directory...]
+ [--base-path=path] [--user-path=path] [directory...]
DESCRIPTION
-----------
@@ -43,7 +43,7 @@ OPTIONS
'--base-path=/srv/git' on example.com, then if you later try to pull
'git://example.com/hello.git', `git-daemon` will interpret the path
as '/srv/git/hello.git'. Home directories (the '~login' notation)
- access is disabled.
+ access is disabled unless '--user-path' is also given.
--export-all::
Allow pulling from all directories that look like GIT repositories
@@ -70,6 +70,13 @@ OPTIONS
Log to syslog instead of stderr. Note that this option does not imply
--verbose, thus by default only error conditions will be logged.
+--user-path::
+ Rewrite a request for "~user/something" to
+ "home/user-path/something". Useful in conjunction with
+ '--base-path', if you want to restrict the daemon from roaming
+ the entire filesystem without preventing users from publishing
+ their own repositories.
+
--verbose::
Log details about the incoming connections and requested files.
diff --git a/cache.h b/cache.h
index bdbe2d6..b6c9cda 100644
--- a/cache.h
+++ b/cache.h
@@ -191,7 +191,7 @@ int git_mkstemp(char *path, size_t n, co
int adjust_shared_perm(const char *path);
int safe_create_leading_directories(char *path);
char *safe_strncpy(char *, const char *, size_t);
-char *enter_repo(char *path, int strict);
+char *enter_repo(char *path, const char *u_path, int strict);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size);
diff --git a/daemon.c b/daemon.c
index bb014fa..22d133d 100644
--- a/daemon.c
+++ b/daemon.c
@@ -17,7 +17,7 @@ static int verbose;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
-" [--base-path=path] [directory...]";
+" [--base-path=path] [--user-path=path] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
@@ -28,6 +28,7 @@ static int export_all_trees = 0;
/* Take all paths relative to this one if non-NULL */
static char *base_path = NULL;
+static char *user_path = NULL;
/* Timeout, and initial timeout */
static unsigned int timeout = 0;
@@ -137,14 +138,16 @@ static int avoid_alias(char *p)
static char *path_ok(char *dir)
{
char *path;
+ static char rpath[PATH_MAX];
if (avoid_alias(dir)) {
logerror("'%s': aliased", dir);
return NULL;
}
- if (base_path) {
- static char rpath[PATH_MAX];
+ if (user_path && dir[0] == '~')
+ /* okay */;
+ else if (base_path) {
if (*dir != '/') {
/* Forbid possible base-path evasion using ~paths. */
logerror("'%s': Non-absolute path denied (base-path active)");
@@ -154,7 +157,7 @@ static char *path_ok(char *dir)
dir = rpath;
}
- path = enter_repo(dir, strict_paths);
+ path = enter_repo(dir, user_path, strict_paths);
if (!path) {
logerror("'%s': unable to chdir or not a git archive", dir);
@@ -490,7 +493,6 @@ static int socksetup(int port, int **soc
/* Note: error is not fatal */
}
#endif
-
if (bind(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
close(sockfd);
continue; /* not fatal */
@@ -659,6 +661,10 @@ int main(int argc, char **argv)
base_path = arg+12;
continue;
}
+ if (!strncmp(arg, "--user-path=", 12)) {
+ user_path = arg+12;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
diff --git a/path.c b/path.c
index 334b2bd..596e37e 100644
--- a/path.c
+++ b/path.c
@@ -131,7 +131,17 @@ int validate_symref(const char *path)
return -1;
}
-static char *user_path(char *buf, char *path, int sz)
+static void kill_trailing_slashes(char *buf, int *lenp)
+{
+ int len = *lenp;
+ while ((1 < len) && (buf[len-1] == '/')) {
+ buf[len-1] = 0;
+ len--;
+ }
+ *lenp = len;
+}
+
+static char *user_path(char *buf, char *path, const char *u_path, int sz)
{
struct passwd *pw;
char *slash;
@@ -157,9 +167,17 @@ static char *user_path(char *buf, char *
return NULL;
baselen = strlen(pw->pw_dir);
memcpy(buf, pw->pw_dir, baselen);
- while ((1 < baselen) && (buf[baselen-1] == '/')) {
- buf[baselen-1] = 0;
- baselen--;
+ kill_trailing_slashes(buf, &baselen);
+ if (u_path) {
+ while (*u_path == '/')
+ u_path++;
+ len = strlen(u_path);
+ if (sz <= baselen + len + 1)
+ return NULL;
+ buf[baselen++] = '/';
+ memcpy(buf + baselen, u_path, len);
+ baselen += len;
+ kill_trailing_slashes(buf, &baselen);
}
if (slash && slash[1]) {
len = strlen(slash);
@@ -184,6 +202,10 @@ static char *user_path(char *buf, char *
* "%s/.git", "%s.git", "%s" in this order. The first one that exists is
* what we try.
*
+ * If "u_path" is given, and the path we're resolving has the form ~/path
+ * or ~user/path, then we resolve to home/u_path/path (where home is the
+ * appropriate user's home directory).
+ *
* Second, we try chdir() to that. Upon failure, we return NULL.
*
* Then, we try if the current directory is a valid git repository.
@@ -194,7 +216,7 @@ static char *user_path(char *buf, char *
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+char *enter_repo(char *path, const char *u_path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -215,7 +237,7 @@ char *enter_repo(char *path, int strict)
if (PATH_MAX <= len)
return NULL;
if (path[0] == '~') {
- if (!user_path(used_path, path, PATH_MAX))
+ if (!user_path(used_path, path, u_path, PATH_MAX))
return NULL;
strcpy(validated_path, path);
path = used_path;
diff --git a/receive-pack.c b/receive-pack.c
index eae31e3..d411ab2 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -317,7 +317,7 @@ int main(int argc, char **argv)
if (!dir)
usage(receive_pack_usage);
- if(!enter_repo(dir, 0))
+ if(!enter_repo(dir, NULL, 0))
die("'%s': unable to chdir or not a git archive", dir);
write_head_info();
diff --git a/upload-pack.c b/upload-pack.c
index d198055..3468de1 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -276,7 +276,7 @@ int main(int argc, char **argv)
usage(upload_pack_usage);
dir = argv[i];
- if (!enter_repo(dir, strict))
+ if (!enter_repo(dir, NULL, strict))
die("'%s': unable to chdir or not a git archive", dir);
upload_pack();
-- [mdw]
^ permalink raw reply related
* Re: Tracking and committing back to Subversion?
From: Brian Smith @ 2006-02-04 15:27 UTC (permalink / raw)
To: sam; +Cc: git
In-Reply-To: <1138834301.21899.40.camel@wilber.wgtn.cat-it.co.nz>
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
Well..
On Wednesday 01 February 2006 14:51, Sam Vilain wrote:
> Hi all,
>
> Has anyone done any work on bidirectional access to SVN repositories?
> ie, tracking and committing.
>
I'm working on something that does just that, I haven't gotten to the
bidirectional part just yet. (The only reason I didn't use git-svnimport is
that it has a /terrible/ time importing from the KDE svn repo. )
> <prop-dir> is a directory object, with one file in this example;
> called svn:ignore. The contents of this file would be something
> like the .gitignore;
>
> Makefile
> Makefile.old
> blib
> ...etc...
My take on the properties, though I like your thoughts on how to handle at
least svn:ignore, is to basically just let svn deal with them. I will make a
couple tools that will modify them, for interface reasons, but they'll just
be wrappers around the svn commands themselves.
At the moment, the tools are written as bash shell scripts with an interface
I'm trying to keep as intuitive as cogito (even though I use the core-git
tools now.)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] qgit: add some installation instruction
From: Marco Costalba @ 2006-02-04 14:32 UTC (permalink / raw)
To: git mailing list; +Cc: Pavel Roskin, Junio C Hamano
With this I would start to post possible patches for list review.
I am planning to post only a very limited number of patches that could be interesting or
that modify someone else work (like in this case, the new Pavel build system).
Is not my intention to add noise to the list, so I will try to keep the patches to the minimum.
In any case, please, Junio, feel free to express any concern about this and I will stop as soon
as started!
Thanks
Marco
-- >8 --
Document how to strip debug information and better explaing when to reconfigure
the build environment.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
diff --git a/README b/README
index 0869c0c..f32dce4 100644
--- a/README
+++ b/README
@@ -23,10 +23,11 @@ which is used to locate Qt. Version 0.15
also work.
To compile qgit, unpack the tar file (you probably have done it
-already), run "./configure", "make" and "make install". You may need to
-get root permissions for the later. You can run "configure" with full
-path from another empty directory if you want qgit to be compiled in a
-separate directory.
+already), run "./configure", "make" and "make install" or "make install-strip"
+to have debug information removed and install a much smaller bin.
+You may need to get root permissions for the later. You can run "configure"
+with full path from another empty directory if you want qgit to be compiled
+in a separate directory.
If there is another qgit executable in PATH, "make install" will
overwrite it. Otherwise, qgit will be installed in /usr/local/bin. You
@@ -41,6 +42,8 @@ Automake, preferably the latest versions
Only in case you clone the public qgit repository you may need to run
"autoreconf -i" the first time to create the ./configure file. Do not need
to run it on a released tarball.
+You may need to run "autoreconf -i" also when pulling revisions that modify
+some build system file, as "configure.ac".
Command line arguments
---
^ permalink raw reply related
* Re: git-diff-tree --cc on the dodecapus
From: Junio C Hamano @ 2006-02-04 13:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17380.37855.117313.631961@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Junio,
>
> When I use git diff-tree --cc on Len's dodecapus merge (9fdb62af), the
> first diff hunk that it shows is this:
Yeah, I noticed it too, and you described how that happens quite
well. The algorithm is simplistic and improvement patches are
welcome.
^ permalink raw reply
* Re: [PATCH] read-tree --aggressive
From: Junio C Hamano @ 2006-02-04 12:56 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Linus Torvalds, Fredrik Kuivinen
In-Reply-To: <7v8xsr60n2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> This patch would not help recursive strategy, though. Calling
> read-tree with --aggressive flag essentially disables the
> benefit we would expect to get from it -- rename detection.
I think we could fairly easily tweak this by trying at least
half of the rename detection inside read-tree. That would make
it usable by merge-recursive as well.
Instead of doing "aggressive" in the threeway_merge function
first, we can process the stages without it in the first pass,
and run an equivalent of diff-stages -M internally between stage
#2 and stage #3, and keep the matched paths unmerged (we need to
mark these paths somehow). After that, we can do "aggressive"
collapsing to reduce the amount of trivial merges that recursive
does not have to look at for renaming merges.
If we are ambitious, we could go further. We could actually
move the stages around after running the rename detection diff
between stages #2 and #3, along with working tree files as
needed. Then merge-resolve would be able to do the renaming
merge similar to merge-recursive.
^ permalink raw reply
* Re: [PATCH 3/3] daemon: Support a --user-path option.
From: Junio C Hamano @ 2006-02-04 12:40 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrndu8utr.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> This is what I'm after, yes. The above can be achieved
> straightforwardly with --user-path=. if that's what you actually wanted.
> (Indeed, --user-path= works too, but this is harder to explain.)
>
> I think I'd probably either run with --user-path=public-git or
> --user-path=public_html/git -- I've not made my mind up.
I made that conditional to --strict, but come to think of it, an
independent option like --user-path makes more sense, whether
that option does the public_html-like path munging or not.
I think for personal repositories public_html-like limiting may
be simpler to manage than the current approach of using
git-daemon-export-ok flag file (the latter is more flexible but
most people probably do not need that flexibility).
In my simplistic view, --base-path serves something like /pub
hierarchy of an ftp server or /var/www of an http server. It
goes hand-in-hand with the whitelist and everything under it are
exported without having to mark individual directories with
git-daemon-export-ok (or having a name like public_html to mark
it exportable). For ~user/ based paths, it is natural to wish
to limit the parts of home directories but there currently is
not a good way to do so. We could probably extend the whitelist
to take path glob patterns and say "~*/public-git/" or something
silly like that, but that still means the request must be in the
form "git://host/~alice/public-git/frotz.git/" (which may not be
such a bad thing); "git://host/~alice/frotz.git/" might look
nicer. Your path munging idea is one way to do so. Another
would be for alice to have $HOME/frotz.git/git-daemon-export-ok.
Personally I do not think either would make too much of a
difference from usability point of view.
So I am not dismissing what you are trying to achieve here.
However, I am not happy about having <pwd.h> there and majorly
duplicating what enter_repo() does in that part of the code.
^ permalink raw reply
* Re: The merge from hell...
From: Junio C Hamano @ 2006-02-04 12:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17380.34301.584514.520465@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Why is that interesting? It seems to me that two independent changes
> were made that just happened to be within a couple of lines of each
> other, but didn't interact.
I agree th hunk in that particular case is not that interesting.
Things are not black and white but you have to draw a line
somewhere. "Happend to be within a couple of lines" is where we
currently draw that line (it is called "context").
^ permalink raw reply
* Re: [PATCH] config: Rummage through ~/.gitrc as well as the repository's config.
From: Junio C Hamano @ 2006-02-04 12:17 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrndu9042.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> Argh. In every terminal and screen window, restart Emacs, ... Logging
> out looks like the better plan.
So you do mean environment variables? Then what's the aversion
against using GIT_AUTHOR_EMAIL instead of using user.email in
every repository? If you use the same value everywhere, you
can do the environment thing _today_ and re-logging in needs to
be done only once, so I do not find it such a big deal. If you
do _not_ use the same value everywhere, then user.email per
repository is a good thing to have, but ~/.gitrc would not help.
Having said that, there are good uses for per-user configuration
that is used across different repositories. Especially when we
start adding new features, we would not want to invent new
environment variable every time. Under ~/ would be a logical
place to put that information.
If you want to propose a search order of multiple configuration
files and how they interact with each other (what happens if
~/.gitrc and $GIT_DIR/config say different things, especially
for multi-valued configuration items), go wild. I think the
simplest single-value cases should be resolved by taking what
$GIT_DIR/config says and if the configuration is not found there
then look at ~/.gitrc (IOW, $GIT_DIR/config takes precedence),
but I am not sure even if that is true in general. I suspect
that some configuration items are more of personal nature and
some configuration items are more of per-project attribute. For
example, merge resolve strategy would be affected more by the
nature of changes that happen to the project's files than which
strategy the user feels easier to work with; $GIT_DIR/config may
have core.gitproxy and user.email, maybe by historical reasons,
which you may rather want to override with ~/.gitrc (e.g. git
proxy may require proxy authentication which would need to be
supplied per user).
Especially problematic would be user.email. Some people might
want to use different identity depending on what project they
work on, in which case they would want $GIT_DIR/config to take
precedence. But sometimes you may need to go to your colleagues
repository and help him with his work, and when you make a
commit there you would want your name, not user.email in
$GIT_DIR/config that records his identity, to be used for that
commit.
^ permalink raw reply
* Re: [PATCH] read-tree --aggressive
From: Peter Eriksen @ 2006-02-04 11:52 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <7v8xsr60n2.fsf@assigned-by-dhcp.cox.net>
On Fri, Feb 03, 2006 at 11:31:13PM -0800, Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
>
> > In connection with Ian Molton's question about merge have I played a
> > little with 'git merge' on the kernel sources. What I find is that a
> > merge can take quite some time, but I'm not sure where that time exactly
> > goes to. Here are the times I got:
> >
> > Recursive (default): 4m22.282s
> > Resolve (-s resolve): 3m23.548s
>
> In your sample script, you do not disable the post-merge diff,
> which is typically one of the most expensive part in the whole
> merge, and I am wondering how fast a machine you are using to
> get 4 minutes. The post-merge diff is generated by piping the
> output of 'diff-tree -M' to 'apply --stat --summary', and that
> step alone takes about 12 minutes wallclock time on my box X-<.
>
> Since my box is not as fast as yours, I've eliminated the
> post-merge diff step and tried your final merge step like this:
>
> $ time git merge --no-summary -s resolve \
> 'Merging happily' HEAD v2.6.15 >/dev/null
>
> and got this:
>
> real 2m15.737s
> user 1m43.320s
> sys 0m26.690s
I got this:
real 0m51.661s
user 0m28.302s
sys 0m8.949s
> With the attached patch, the most expensive part, which is the
> repeated invocation of git-merge-one-file to remove many deleted
> paths, is eliminated. The result is this.
>
> real 0m20.311s
> user 0m15.780s
> sys 0m4.150s
I got this:
real 0m20.221s
user 0m6.456s
sys 0m1.828s
> This patch would not help recursive strategy, though. Calling
> read-tree with --aggressive flag essentially disables the
> benefit we would expect to get from it -- rename detection.
Aha, so now I better understand where all the time goes. Most of the
time is spend calculating the merge summary. After that the bottleneck
was the large amount of git-merge-one-file invocations.
With the aggressive patch applied it feels like the merge is mostly IO
bound, which might explain why we get similar running times. I did get
one run of 12s, but that was a lucky shot I guess. Repeated runs gave
between 15s and 21s but most where close to 20s.
Thanks,
Peter
^ permalink raw reply
* Re: [Attn - repository browser authors] diff-tree combined format.
From: Marco Costalba @ 2006-02-04 12:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paul Mackerras, Marco Costalba, Aneesh Kumar, Kay Sievers, git
In-Reply-To: <7v1wykceic.fsf@assigned-by-dhcp.cox.net>
On 2/3/06, Junio C Hamano <junkio@cox.net> wrote:
> Marco Costalba <mcostalba@gmail.com> writes:
>
> This reminds me of one thing. One thing I did not like about
> the colouring of gitk on an Octopus was that it repeats the same
> parents in different colors, wasting lines. From diff-tree -c
> output, one thing coloured diff browsers _could_ do is to let
> the user pick one parent and paint the lines to make the
> differences from that parent alone stand out.
>
Both qgit and gitk have the 'diff to selected rev' feature.
What about integrate combined output with exsisting 'diff to selected'
functionality to reach what you are proposing?
Put in other words, an user selects the parent (CTRL + right click in
qgit) and only the
corresponding interesting diffs is shown.
For this to work it is necessary (at least in qgit) something like
git-diff-tree -c -r -m -p <sha1> <sha2>
Marco
^ permalink raw reply
* git-diff-tree --cc on the dodecapus
From: Paul Mackerras @ 2006-02-04 11:45 UTC (permalink / raw)
To: Junio C Hamano, git
Junio,
When I use git diff-tree --cc on Len's dodecapus merge (9fdb62af), the
first diff hunk that it shows is this:
@@@@@@@@@@@@@ -712,17 -711,9 -703,9 -703,9 -703,9 -708,9 -703,9 -703,9 -711,9 -703,9 -711,9 -711,9 +717,17 @@@@@@@@@@@@@
load_ramdisk= [RAM] List of ramdisks to load from floppy
See Documentation/ramdisk.txt.
----------- lockd.udpport= [NFS]
+++++++++++ lockd.nlm_grace_period=P [NFS] Assign grace period.
+++++++++++ Format: <integer>
+++++++++++
+++++++++++ lockd.nlm_tcpport=N [NFS] Assign TCP port.
+++++++++++ Format: <integer>
++++ ++++++
- lockd.tcpport= [NFS]
+++++++++++ lockd.nlm_timeout=T [NFS] Assign timeout value.
+++++++++++ Format: <integer>
+
---- ------ lockd.tcpport= [NFS]
+++++++++++ lockd.nlm_udpport=M [NFS] Assign UDP port.
+++++++++++ Format: <integer>
logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver
Format: <irq>
For some reason, the 6th parent's lines are getting matched
differently from the other parents. Parents 2-12 are actually all the
same in this file AFAICS. All that has happened is that a sequence of
three lines: "lockd.udpport= [NFS]", a blank line, "lockd.tcpport=
[NFS]", have been replaced by 11 lines. For parent 6, the blank line
has been matched with the 6th line of the new stuff, whereas for
parents 2..5 and 7..12 the blank line has been matched with line 9 of
the new stuff. This makes it look like the change from parent 6 is
different when it isn't really, and thus the diff looks interesting
when it shouldn't.
In general, I have found in doing N-way diff displays (both in dirdiff
and in gitk), that one needs to be a bit clever about working out
which lines correspond in the N versions. If you do a series of 2-way
diffs and just believe what diff tells you about which lines
correspond, you will end up with things being shown as different when
they aren't. Where there is ambiguity, some of the 2-way diffs will
resolve it one way and some another, and as a result, something which
is in fact common to all the files can end up being shown as a
difference.
What I do in dirdiff is to do a number of 2-way diffs, but just use
the result as an indication of which parts of the files have some
difference. I then find the matches between all the files in Tcl code
and work out which lines are common and which lines are unique. I
have found it necessary to apply a rule that says that a match across
a larger number of files is preferable to a match across a smaller
number, even if it is a longer match. For a set of lines, I
iteratively pull out the best match (most number of files, then most
number of lines). What's left at the end is the lines that are unique
to one file. This ends up being a bit complicated, but it seems to be
necessary for producing a reasonable result. I can go into more
detail on the algorithm I use if you want.
Paul.
^ permalink raw reply
* Re: [Attn - repository browser authors] diff-tree combined format.
From: Paul Mackerras @ 2006-02-04 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, Aneesh Kumar, Kay Sievers, git
In-Reply-To: <7v1wylkn54.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> (1) keep the index line, but format it like this:
At this stage, I don't think gitk will need the index line.
> (2) match line numbers in the hunk header to normal diff's
> order:
>
> @@@ -1,87 -1,3 +1,93 @@@
I think that will look better.
Paul.
^ permalink raw reply
* Re: The merge from hell...
From: Paul Mackerras @ 2006-02-04 10:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Git Mailing List, Marco Costalba, Aneesh Kumar
In-Reply-To: <7v8xsuuto5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Linus Torvalds <torvalds@osdl.org> writes:
> > That octopus commit has got _twelve_ parents.
Making it a dodecapus, or something? :)
> But this is still interesting:
>
> @@@@@@@@@@@@@ +308,35 @@@@@@@@@@@@@
> goto end;
> }
> }
> -- cx->usage++;
> --
>
> +++ #ifdef CONFIG_HOTPLUG_CPU
> +++ /*
Why is that interesting? It seems to me that two independent changes
were made that just happened to be within a couple of lines of each
other, but didn't interact. The reason that one change appears in two
branches, and the other in 3, is I think just related to where the
branches start from. So IMHO this hunk isn't interesting.
Paul.
^ permalink raw reply
* Re: [PATCH] config: Rummage through ~/.gitrc as well as the repository's config.
From: Mark Wooding @ 2006-02-04 10:22 UTC (permalink / raw)
To: git
In-Reply-To: <7vacd7c4bm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Mark Wooding <mdw@distorted.org.uk> writes:
>
>> I'm fed up of setting user.email in every repository I own.
>
> That is what --template-dir to init-db is for (it works in an
> already initialized git repository, but it does not overwrite
> files).
Except that git-clone has already made a .git/config file, so it won't
be overwritten by git-init-db --template-dir. git-init-db doesn't do
merging of config file lines, and rightly so -- it'd just get too
confusing.
>> I want to put this somewhere central, and I shouldn't have to
>> log in again to make it take effect.
>
> I do not understand about logging in again. If you are talking
> about environment variables, ". ~/.env" would work nicely.
Argh. In every terminal and screen window, restart Emacs, ... Logging
out looks like the better plan.
What's the objection to a ~/.gitrc? (If it's just new-feature
resistance, I can live with that; I'm just interested.)
-- [mdw]
^ permalink raw reply
* Re: [PATCH 2/3] daemon: Set SO_REUSEADDR on listening sockets.
From: Mark Wooding @ 2006-02-04 10:16 UTC (permalink / raw)
To: git
In-Reply-To: <7vfymz33v8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> But with that, you expose yourself to the confusion TIME_WAIT
> was designed to protect you from, so how about making it
> optional like this?
No objections there.
-- [mdw]
^ permalink raw reply
* Re: [PATCH 3/3] daemon: Support a --user-path option.
From: Mark Wooding @ 2006-02-04 10:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vr76kcggx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I am probably slow as usual but I do not see how this is useful.
I don't want the git-daemon roaming all over the file system. Partly,
as a systems administrator, it makes me nervous about security (not for
any particularly good reason, I admit), but mainly because I don't want
to be exposing my local filesystem structure in my git://... namespace
-- it just seems like a bad idea. This is what --base-path is all about.
I do still want users to be able to publish their repositories. But I
also don't want git-daemon wandering all over their home directories --
restriction to sensible places is what --base-path is for, after all.
> Wouldn't loosening the "request must be absolute if you use
> --base-path" check in the area your first patch in the series
> touches to also allow paths that start with a '~' be enough?
> That way ~alice/foo would remain to be /home/alice/foo (with
> /home/alice being alice's $HOME) and ~becky/bar would be
> /home2/becky/bar (with /home2/becky being becky's $HOME).
That would still expose the structure of everyone's home directories in
git://~user URLs, which is rather unfortunate. It's better than
nothing, though.
> I suppose you are doing something similar to ~/public_html, but
> I think that is an independent feature.
This is what I'm after, yes. The above can be achieved
straightforwardly with --user-path=. if that's what you actually wanted.
(Indeed, --user-path= works too, but this is harder to explain.)
I think I'd probably either run with --user-path=public-git or
--user-path=public_html/git -- I've not made my mind up.
-- [mdw]
^ 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