Dana How wrote: > Most commands accept relative paths,

Hi, NACK. The "?" thing is highly unintuitive, and I still do not think that it is worth the confusion to make Git behave funny on <tree>:<file-name>. Think of the "todo" branch, for example. And this is not even far fetched. In many repositories I have to have separate related, but non-branch HEADs. For example, I track some projects with custom scripts. These scripts do _not_ belong into that branch. However, they are related, so I store them in the same repository. Pl...

Double ACK. I'm in complete agreement with every point Dscho has made in this thread, even if I haven't quoted it. ;-) I *really* do not want to see "<tree-ish>:<path>" to mean include the current prefix, *especially* when a bare repository is involved. I often either do ad-hoc git-show lines against bare repositories, or have scripts that depend on this existing absolute path behavior. I'd like to see those not break. ;-) Since "." and ".." should not be valid names in any tre...

>

Hmm, most of the work I do in the parts of our perforce repository I want to convert to git is far enough down that the paths have 6 in-repo path components. I don't want to type all those when I want to fetch an older version with git-show. Everything I do is relative. In fact, I think perforce supports typing absolute paths, (using an 8-character prefix!) but I have never used it, nor would I if it were shorter. -- Dana L. How danahow@gmail.com +1 650 804 5991 cell -

I think the consensus is to use <tree-ish>:./<relative-path> for relative paths, and <tree-ish>:<path> for absolute (well, in the meaning that it counts from top of _tree-ish_, and tree-ish needs not to be top tree / commit tree). And I think 6 in-repo path components means not very well thought directory hierarchy, I think... -- Jakub Narebski Poland -

Signed-off-by: Yann Dirson <ydirson@altern.org> --- Well, it looks like the voices we heard on this naming issue were quite equally cast towards each of the 2 name. Let my vote be to get back to "sink", so the user can easily pair the command with "float". I expect that any previously-silent majoity prefering "bury" will talk now, before Catalin decides if he wants this patch in the next release :) Oh, this patch reminds me we still have to activate rename detection... Documentat...

Check if a line of the header has enough characters to possibly contain the requested prefix. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> --- Noticed by debugging git-log crash in broken repos with missing packs. It happened to be up in backtrace. At the moment the optimization is actually a slow down: no line in the header is shorter than the only key this function is ever asked for: encoding. But, in case the function ever gets asked for something longer, the old condition is just ...

I think these feel more or less natural (except that we do not say ":/fullpath" and instead say ":fullpath" which is unfortunate). In the hindsight, if we had the perfect vision into the future, we would have made <path> relative to where you are when we initially did "<something>:<path>", with obvious semantics for things like "<something>:../<path>" and "<something>:/<path>". We didn't. Further, we made a mistake to make :/ to mean something complet...

Hi, FWIW I still find that unintuitive. I know "<something>:<path>" from ssh, and there it does not change meaning depending on where I am. IMHO in most cases you want to use git-diff anyway, which _does_ honour the current relative path. Ciao, Dscho -

Hi, No, it is relative to where I am _at the other end_. If I "cd /tmp", it still is relative to $HOME. Now, what you want to do is changing the meaning of v1.5.1:Makefile, depending if you "cd Documentation/"ed or not. For me, "v1.5.1:" means something similar to ssh: it is a distant revision. It is not a complete filesystem. I think of revisions as something more general than a directory, but less general than a filesystem. And thus, it makes perfect sense to me that "v1.5.1:Makefile"...

Hi, Actually, no. I expect "git diff HEAD@{yesterday} git.txt" to work fine, and "git show HEAD@{yesterday}:git.c" also, both when in Documentation/, because I expect "git show HEAD@{yesterday}:git.c" to work _also_ when I set GIT_DIR=/path/to/my/bare-repo.git/ before that, while I do not expect the call to git-diff to work (for obvious reasons). Ciao, Dscho -

In the history? Yes. With svn cp you actually create this "blame" history: * -- * -- G -- B \ ----- G* -- 1 -- 2 -- 3 where G* is a new revision, but since it is otherwise identical to G, it does not introduce new blame-able lines. -- Hannes -

Change (undocumented) git commit -f option from a synonym for git-commit -F to "Take the commit message from the given file, and remove the file upon successful commit". git-revert and git-cherry-pick should make use of this to properly cleanup the automatically created ./.msg file. Signed-off-by: Gerrit Pape <pape@smarden.org> --- Documentation/git-commit.txt | 7 ++++--- git-commit.sh | 25 +++++++++++++++++++++++-- 2 files changed, 27 insertions(+), 5 deletions(-) ...

I'm actually sort of against changing the behavior of git-commit -f to mean "delete the file". We never did that before. Users might get surprised when their file goes away! What about this change instead? We make cherry-pick/revert use the same temporary file as merge, which is under .git/ (something Alex mentioned he wanted). I think the use of ".msg" in cherry-pick/revert has always just been a bug, and not a feature, so I'm really not against changing things around like this. diff --...

Petr Baudis <pasky <at> suse.cz> writes: well, my example above was exagerated, noone ever reindented the whole ffmpeg or checked in a old version over HEAD. what did and does occasionally happen is that people check in several things at once (like a 100k reindenton mixed with various functional changes) for these we currently copy the last good version of the affected files over the current one with svn cp and then apply the changes in nicely split manner. (possibly without the reinden...

Hi we have a nice svn policy which explains that, also people wont receive write access without having submitted a few clean patches first so i dont know if more education would really help, the problems are IMHO rather caused by a mix of lazyness, arrogance and plain oversight but please dont missunderstand, these problems are not that common, its yes i think so too, the added push after commit wont stop a bad commit yes, id like to switch ffmpeg to git or mercurial as that seems like a goo...

A big difference between git and svn is that git allows you to commit your changes individually to your local repository before pushing them out to the world. With svn you make your changes visible to the world as soon as you commit something, including the commit screwups. With Git you always have the opportunity to look at your commits and test them all together before pushing which should make commit mistakes obvious before they leave your machine. If a mistake happened in one of those...

From: Sven Verdoolaege <skimo@kotnet.org> This patch series implements a mechanism for cloning submodules. Each submodule is specified by a 'submodule.<submodule>.url' configuration option, e.g., bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url' submodule.cloog.url /home/sverdool/public_html/cloog.git submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git git-clone will use the first url that works. E.g., a git clone -...

From: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> --- Makefile | 6 +++++- config.c | 14 ++++++++++++++ http.c | 10 ++++++++-- http_config.h | 1 + http_config_curl.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ http_config_none.c | 6 ++++++ 6 files changed, 83 insertions(+), 3 deletions(-) create mode 100644 http_config.h create mode 100644 http_config_curl.c create mod...

From: Sven Verdoolaege <skimo@kotnet.org> This command dumps the config of a repository and will be used to read config options from a remote site. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> --- .gitignore | 1 + Documentation/cmd-list.perl | 1 + Documentation/git-dump-config.txt | 37 +++++++++++++++++++++++++++++++++++++ Makefile | 1 + daemon.c | 7 +++++++ dump-config.c ...

One thing I haven't figured out, although I haven't looked at the code much, is this: When does git-svn do a merge rather than a rebase? How can there ever be a diff? Is this perhaps something that can happen if you use set-tree, because I don't see how it happens with dcommit. -- David Kågedal -

The plumbing part looks very good, although I sensed a slight slop toward the end (will comment on individual patches later). I do not like the Porcelain part very much, though. I do not think we would want to add anything new to git-clone. We should lose as much code from git-clone that is common with git-fetch as we can first, and add new features to git-fetch, with possibly passthru options added to git-clone as needed (e.g. a new --submodule option). If you --submodule cloned a remote repo...

From: Sven Verdoolaege <skimo@kotnet.org> This command dumps the config of a repository and will be used to read config options from a remote site. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> --- .gitignore | 1 + Documentation/cmd-list.perl | 1 + Documentation/git-dump-config.txt | 37 +++++++++++++++++++++++++++++++++++++ Makefile | 1 + daemon.c | 7 +++++++ dump-config.c ...

From: Sven Verdoolaege <skimo@kotnet.org> When the --submodules option is specified, git-clone will search for submodule.<submodule>.url options in the remote configuration and clone each submodule using the first url that it can use from the local site. The submodules are currently not checked out. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> --- Documentation/config.txt | 3 ++ Documentation/git-clone.txt | 6 +++- git-clone.sh | 68 ++++++...