* Re: Diff-tree does not work for initial commit
From: Jeff King @ 2008-09-15 22:34 UTC (permalink / raw)
To: sverre; +Cc: Michael J Gruber, Anatol Pomozov, Git Mailing List
In-Reply-To: <bd6139dc0809151411p49f5adeaq4beff452574ca980@mail.gmail.com>
On Mon, Sep 15, 2008 at 11:11:30PM +0200, Sverre Rabbelier wrote:
> Some of my code uses "git rev-parse" on "HEAD^" to see if a commit has
> a parent; I wouldn't be surprised if someone else has a script that
> uses "git diff-tree" or such for that purpose, or at least assumes
> that for a root commit it will complain. Anyway, as Junio said, for
> "diff-tree" you can use the "--root" option. A better RFE would
> perhaps be that "--root" be supported in more places.
I posted this a week or so ago, but I am sure it is incomplete. If there
is interest I can clean it up and do a proper submission.
---
diff --git a/builtin-diff.c b/builtin-diff.c
index 76651bd..4151900 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -332,8 +332,11 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
break;
else if (!strcmp(arg, "--cached")) {
add_head_to_pending(&rev);
- if (!rev.pending.nr)
- die("No HEAD commit to compare with (yet)");
+ if (!rev.pending.nr) {
+ if (!rev.show_root_diff)
+ die("No HEAD commit to compare with (yet)");
+ add_empty_to_pending(&rev);
+ }
break;
}
}
diff --git a/revision.c b/revision.c
index 2f646de..7ec3990 100644
--- a/revision.c
+++ b/revision.c
@@ -145,16 +145,27 @@ void add_pending_object(struct rev_info *revs, struct object *obj, const char *n
add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
}
-void add_head_to_pending(struct rev_info *revs)
+static void add_to_pending_by_name(struct rev_info *revs, const char *name)
{
unsigned char sha1[20];
struct object *obj;
- if (get_sha1("HEAD", sha1))
+ if (get_sha1(name, sha1))
return;
obj = parse_object(sha1);
if (!obj)
return;
- add_pending_object(revs, obj, "HEAD");
+ add_pending_object(revs, obj, name);
+}
+
+void add_head_to_pending(struct rev_info *revs)
+{
+ add_to_pending_by_name(revs, "HEAD");
+}
+
+void add_empty_to_pending(struct rev_info *revs)
+{
+ add_to_pending_by_name(revs,
+ "4b825dc642cb6eb9a060e54bf8d69288fbee4904");
}
static struct object *get_reference(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags)
diff --git a/revision.h b/revision.h
index 2fdb2dd..8c990d5 100644
--- a/revision.h
+++ b/revision.h
@@ -152,6 +152,7 @@ extern void add_object(struct object *obj,
extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
extern void add_head_to_pending(struct rev_info *);
+extern void add_empty_to_pending(struct rev_info *);
enum commit_action {
commit_ignore,
^ permalink raw reply related
* Re: CGit and repository list
From: Lars Hjemli @ 2008-09-15 22:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johan Herland, git, Jakub Narebski, Kristian Høgsberg
In-Reply-To: <20080913194938.GI10360@machine.or.cz>
On Sat, Sep 13, 2008 at 9:49 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Sep 13, 2008 at 01:20:50AM +0200, Lars Hjemli wrote:
>> I guess I could add support for something like
>>
>> scan-paths=/pub/git
>>
>> in cgitrc (and optionally store the result of the scan as another
>> cgitrc-file in the cache directory). Would that improve things for
>> you?
>
> Yes, certainly.
Ok, for now I've added a --scan-tree=<path> commandline option which
will make cgit print a sorted list of the repositories found to
stdout. If/when this does a reasonable job on repo.or.cz I can look
into some form of automatic rescanning (enabled from cgitrc).
>> > Unfortunately, the recommended RewriteRule is not working - it does not
>> > play well together with query parameters cgit is using, so e.g. browsing
>> > past commits does not work.
I've also pushed support for PATH_INFO. This allows you to drop the
rewriterules from httpd.conf and the 'virtual-url' option from cgitrc
and still get the 'nice' urls.
> I wonder why
>
> http://repo.or.cz/c/libc.git/
>
> has such a funny-looking summary page.
It's due to cgits terrible functions for parsing commits and tags.
I've pushed a reworked patch which should make the parsing more robust
and thus also render glibc.git correctly.
Finally, and probably more interesting for freedesktop.org than
repo.or.cz, is the support for repolist filtering by url prefix
(compare http://hjemli.net/git and http://hjemli.net/git/xorg for a
minimal example).
This is all available from the master branch in
git://hjemli.net/pub/git/cgit, enjoy!
--
larsh
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Anatol Pomozov @ 2008-09-15 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <7vprn59lkd.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 15, 2008 at 1:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> The initial commit has no parent, so diff-tree does not know which tree
>> to compare to.
>
> --root?
Oops my bad.
I overlooked this part of the manual. Thanks Junio.
Taking back my words about bug.
--
anatol
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Dmitry Potapov @ 2008-09-15 21:47 UTC (permalink / raw)
To: Michael J Gruber; +Cc: sverre, Pico Geyer, git
In-Reply-To: <48CED08F.5040602@drmicha.warpmail.net>
On Mon, Sep 15, 2008 at 11:15:59PM +0200, Michael J Gruber wrote:
> Sverre Rabbelier venit, vidit, dixit 15.09.2008 22:59:
> >
> > I thought this was fixed in a more recent version of git-svn? Didn't
> > it even work both ways?
>
> Kind of. You can't fake a different author when committing to svn.
This is not exactly correct as you can fake author if you have the right
to change the svn:author property (or what is its name?), but by default
this is not allowed to anyone, and git-svn does not support this method
anyway.
> But
> "--add-author-from" makes dcommit embed the author in the svn commit
> message (if there's no from nor sob), and "--use-log-author" makes fetch
> look for that info and use it.
Yes, it works. And it is very useful especially you are going eventually
convert your SVN repository in Git (so all authorship information will
be retain). Probably, I should have mentioned this possibility.
Thanks,
Dmitry
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Michael J Gruber @ 2008-09-15 21:15 UTC (permalink / raw)
To: sverre; +Cc: Dmitry Potapov, Pico Geyer, git
In-Reply-To: <bd6139dc0809151359i357987c5vb2544b1b5c99802f@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 15.09.2008 22:59:
> On Mon, Sep 15, 2008 at 21:55, Dmitry Potapov <dpotapov@gmail.com> wrote:
>> [...] Another problem with
>> this approach is that the author is not preserved. In SVN, all commits will
>> look like all changes are done by the person who run "git svn dcommit".
>
> I thought this was fixed in a more recent version of git-svn? Didn't
> it even work both ways?
Kind of. You can't fake a different author when committing to svn. But
"--add-author-from" makes dcommit embed the author in the svn commit
message (if there's no from nor sob), and "--use-log-author" makes fetch
look for that info and use it.
Michael
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Sverre Rabbelier @ 2008-09-15 21:11 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Anatol Pomozov, Git Mailing List
In-Reply-To: <48CECA42.1050209@drmicha.warpmail.net>
On Mon, Sep 15, 2008 at 22:49, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> diff-tree is plumbing. Would this change break anything?
Some of my code uses "git rev-parse" on "HEAD^" to see if a commit has
a parent; I wouldn't be surprised if someone else has a script that
uses "git diff-tree" or such for that purpose, or at least assumes
that for a root commit it will complain. Anyway, as Junio said, for
"diff-tree" you can use the "--root" option. A better RFE would
perhaps be that "--root" be supported in more places.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Michael J Gruber @ 2008-09-15 21:09 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: Git Mailing List
In-Reply-To: <48CECA42.1050209@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 15.09.2008 22:49:
> Anatol Pomozov venit, vidit, dixit 15.09.2008 22:01:
>> Hi, It looks like I found a bug in git.
>>
>> The problem: In my script I need to know what files were modified by
>> given commit. I use diff-tree for it. Although it works for most
>> cases, for initial commit it does not. Here is a sequence of actions.
>>
>>
>> anatol:~ $ mkdir mkdir initialcommitissue anatol:~ $ cd
>> initialcommitissue/ anatol:initialcommitissue $ git init Initialized
>> empty Git repository in /home/anatol/initialcommitissue/.git/
>> anatol:initialcommitissue $ echo "First commit" > 1.txt
>> anatol:initialcommitissue $ git add 1.txt anatol:initialcommitissue $
>> git commit -m "First commit" Created initial commit 31ccc6a: First
>> commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode
>> 100644 1.txt anatol:initialcommitissue $ git diff-tree HEAD <<<<<
>> PROBLEM IS HERE
>
> From the man page:
>
> Compares the content and mode of the blobs found via two tree
> objects.
>
> If there is only one <tree-ish> given, the commit is compared
> with its parents (see --stdin below).
>
> Note that git-diff-tree can use the tree encapsulated in a commit
> object.
>
>
> The initial commit has no parent, so diff-tree does not know which tree
> to compare to.
>
> You can do
>
> git diff-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 HEAD
>
> but I guess you suggest that diff-tree should do that automatically for
> a single parentless treeish: bug -> RFE
>
> diff-tree is plumbing. Would this change break anything?
>
> Michael
Ooops, that man page is just too long. Scrolling way down:
"git commit-tree --root" treats the root as a commit with an empty tree.
So this does what you want.
But you may want to look into porcelain like
git show --pretty=format: --name-only
Michael
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Sverre Rabbelier @ 2008-09-15 20:59 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Pico Geyer, git
In-Reply-To: <37fcd2780809151255q278b1786ub4caec9022d7b082@mail.gmail.com>
On Mon, Sep 15, 2008 at 21:55, Dmitry Potapov <dpotapov@gmail.com> wrote:
> [...] Another problem with
> this approach is that the author is not preserved. In SVN, all commits will
> look like all changes are done by the person who run "git svn dcommit".
I thought this was fixed in a more recent version of git-svn? Didn't
it even work both ways?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Junio C Hamano @ 2008-09-15 20:54 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Anatol Pomozov, Git Mailing List
In-Reply-To: <48CECA42.1050209@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Anatol Pomozov venit, vidit, dixit 15.09.2008 22:01:
>> Hi, It looks like I found a bug in git.
>>
>> The problem: In my script I need to know what files were modified by
>> given commit. I use diff-tree for it. Although it works for most
>> cases, for initial commit it does not. Here is a sequence of actions.
>>
>>
>> anatol:~ $ mkdir mkdir initialcommitissue anatol:~ $ cd
>> initialcommitissue/ anatol:initialcommitissue $ git init Initialized
>> empty Git repository in /home/anatol/initialcommitissue/.git/
>> anatol:initialcommitissue $ echo "First commit" > 1.txt
>> anatol:initialcommitissue $ git add 1.txt anatol:initialcommitissue $
>> git commit -m "First commit" Created initial commit 31ccc6a: First
>> commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode
>> 100644 1.txt anatol:initialcommitissue $ git diff-tree HEAD <<<<<
>> PROBLEM IS HERE
>
> From the man page:
>
> Compares the content and mode of the blobs found via two tree
> objects.
>
> If there is only one <tree-ish> given, the commit is compared
> with its parents (see --stdin below).
>
> Note that git-diff-tree can use the tree encapsulated in a commit
> object.
>
> The initial commit has no parent, so diff-tree does not know which tree
> to compare to.
--root?
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Michael J Gruber @ 2008-09-15 20:49 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: Git Mailing List
In-Reply-To: <3665a1a00809151301p7d8e6387g3cacfb879b45da2f@mail.gmail.com>
Anatol Pomozov venit, vidit, dixit 15.09.2008 22:01:
> Hi, It looks like I found a bug in git.
>
> The problem: In my script I need to know what files were modified by
> given commit. I use diff-tree for it. Although it works for most
> cases, for initial commit it does not. Here is a sequence of actions.
>
>
> anatol:~ $ mkdir mkdir initialcommitissue anatol:~ $ cd
> initialcommitissue/ anatol:initialcommitissue $ git init Initialized
> empty Git repository in /home/anatol/initialcommitissue/.git/
> anatol:initialcommitissue $ echo "First commit" > 1.txt
> anatol:initialcommitissue $ git add 1.txt anatol:initialcommitissue $
> git commit -m "First commit" Created initial commit 31ccc6a: First
> commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode
> 100644 1.txt anatol:initialcommitissue $ git diff-tree HEAD <<<<<
> PROBLEM IS HERE
>From the man page:
Compares the content and mode of the blobs found via two tree
objects.
If there is only one <tree-ish> given, the commit is compared
with its parents (see --stdin below).
Note that git-diff-tree can use the tree encapsulated in a commit
object.
The initial commit has no parent, so diff-tree does not know which tree
to compare to.
You can do
git diff-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 HEAD
but I guess you suggest that diff-tree should do that automatically for
a single parentless treeish: bug -> RFE
diff-tree is plumbing. Would this change break anything?
Michael
^ permalink raw reply
* Re: [PATCH 14/16] clone: support narrow checkout with --path option
From: Junio C Hamano @ 2008-09-15 20:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <m3r67mmu0v.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Second, how `--path=<narrow_spec>` interacts with `-n' (no checkout).
> Does it even have any sense? Perhaps those options should be mutually
> incompatibile (and --bare and this option too)?
Technically you could mark the index entries with no-checkout bits even
with -n, so that later checkout or branch switching would honor that, but
the branch switching would make paths that do not exist in the remote HEAD
branch but do exist in the switched-to branch appear, which would be
confusing. So instead of supporting:
$ git clone -n --path=Documentation/ $there work
$ cd work
$ git checkout next
we can support:
$ git clone -n $there work
$ cd work
$ git checkout --path=Documentation/ next
which is much easier to explain and understand.
^ permalink raw reply
* Re: [PATCH] help git-upload-pack find git
From: Michael J Gruber @ 2008-09-15 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlm9b3v4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 15.09.2008 21:34:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> The corresponding bug was reported by Paul Johnston who wondered why
>> "git clone" failed when specifying --upload-pack for an out-of-$PATH
>> installation of git. I'm not sure whether we should encourage this, but
>> the --upload-pack option clearly gives the impression that
>> git-upload-pack is all that is needed.
>
> Another possibility would be to teach exec_cmd.c:setup_path() to add the
> directory specified by $(bindir) to PATH after we add GIT_EXEC_PATH to
> it. That should cover the case David Miller reported, shouldn't it?
Probably. I read that thread only after submitting my patch for
upload-pack but suspected that other server side incarnations may suffer
from the same problem.
I was actually surprised that setup_path() uses argv0_path without
setting it, same as with argv_exec_path. I assumed this is for a good
reason, I'm lacking the code base overview to judge this myself.
In any case, git.c sets argv0_path early, messes a bit with argv[0] and
calls setup_path afterwards anyways. So adding the path in setup_path()
should not hurt any "git foo" command.
One could construe situations where even that wouldn't help, because
git-upload-pack can't pass --exec-dir to git and they can be in
different locations - but I think that's crazy.
git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.
setup_path() needs to get a parameter. If shell.c should profit from the
change then it needs to be taught how to pass an absolute path to
do_{generic,cvs}_cmd().
So, I guess the general approach (change setup() path and have every
caller profit) is OK. OK with you?
Michael
^ permalink raw reply
* Re: [PATCH 05/16] ls-files: add --narrow-checkout option to "will checkout" entries
From: Junio C Hamano @ 2008-09-15 20:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <m34p4io8vt.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> @@ -72,6 +73,11 @@ OPTIONS
>> to file/directory conflicts for checkout-index to
>> succeed.
>>
>> +--narrow-checkout::
>> + When narrow checkout is being used, this option together with other
>> + index-based selection options like --cached or --stage, only narrowed
>> + portion will be printed out.
>> +
>
> I would rather say, that if git-ls-files is requested to show index
> content (by using selection options like --cached or --stage), then
> by default it shows all entries, also those marked "no checkout".
> With this option git-ls-files would show only files that would get
> checked out.
ls-files is a very low-level interrogator, and I have this queasy feeling
in the stomach if it suddenly stopped showing half of the index without
explicitly asked to with an option like this. If somebody iterates over
ls-files output (with or without pathspecs), most often it would be to do
something interesting on the work tree files that correspond to these
paths, and for that use case it would make sense to have a mode that shows
only the paths marked for checkout. But unless you can prove that "most
often" above is "100%", you risk breaking somebody's script. Maybe you
are doing something similar [*1*] to the index-filter feature of
filter-branch, starting from the current index that has no-checkout marks
in its entries, and it wants to know all the paths in the index. Who
knows?
[Footnote]
*1* filter-branch happens to start with an empty index and does not know
about the new 'narrow checkout' feature, so it is Ok, but it is plausible
as an optimization for it to prime the initial index from the current
"real" index, which may have the no-checkout marks.
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Jakub Narebski @ 2008-09-15 20:05 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0809150701j1161f87gcedef0013a244610@mail.gmail.com>
On Mon, 15 Sep 2008 16:01, Nguyen Thai Ngoc Duy wrote:
> On 9/15/08, Jakub Narebski <jnareb@gmail.com> wrote:
>> [I don't see mails I am replying to on GMane interface to git mailing
>> list, so threads might be broken. Strange... Perhaps too long lines
>> were cause of rejection by anti-SPAM vger filter?]
>
> It was because I used zenbe.com (limited choices at work) to send
> mails and did not realize until too late that zenbe.com did not encode
> UTF-8 properly in mail headers. It made vger.k.o nervous and refuse to
> accept my mails.
Yes, vger anti-SPAM filter is quite "trigger happy"...
>> On Mon, 15 Sep 2008, Duy Nguyen wrote:
>>> On 09/15/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
>>>>> +Narrow spec will be used to specify how you want to narrow your
>>>>> +checkout. It is a list of pathspecs separated by colons. Each
>>>>> +patchspec specifies what files should be checked out on working
>>>>> +directory. Pathspec can contain wildcards and is relative to
>>>>> +current working directory. Usually asterisk (*) does not match
>>>>> +slashes. If a pathspec is prefixed by a plus sign (+), then
>>>>> +any asterisk will match anything, even slashes.
>>>>
>>>> First, does this mean that you can specify paths containing colons
>>>> (':') only using --add-path and --remove-path, or does it mean that
>>>> you cannot specify paths containg colon ':' (which should be rare)
>>>> at all as checkout limiter / checkout narrowing rule?
>>>
>>> You cannot do othat explicitly unfortunately. You can work-around using
>>> wildcard though.
>>
>> Couldn't you simply escape ':', i.e. write for example Git\:\:Tag.3pm,
>> or Eichten_PRD21\:313,1980_erratum.tex, or \:0.log, or perhaps
>> kmail/jnareb@gmail.com\:@pop.gmail.com\:995, or even something like
>> Mail/inbox/cur/1194202360.32296.mprnq\:2,S, in the same way like you
>> can escape other special characters, for example wildcard characters
>> like '\*' for '*' and '\?' for '?', and of course '\\' for '\'?
>
> Sure. Somehow I forgot that.
Well, if it is possible, it should be stated in documentation.
Even if it is obvious.
> [...] how about this? Note that document changes that also require code
> change like narrow spec escape or '**' do not get in. I will change it
> when I update code.
> --<--
> Narrow checkout
> ---------------
>
> Normally when you do checkout a branch, your working directory
> will be fully populated. In some situations, you just need to
> work on certain files, no full checkout is needed. Narrow
> checkout is a mode that limits checkout area according to your
> needs.
You have decided then on the term 'narrow checkout', and not
'partial checkout' or 'sparse checkout', then?
It would be nice if git mailing list came with examples of usage for
this feature. It was quite frequently requested. I can think off-hand
about two reasons one might want to use 'narrow checkout':
1.) when you are not interested in files outside some selected
set, and you don't want to mess files outside this set, even
by accident. For example for end-user documentation writers
it would be Documentation/* (non-recursive).
2.) when you work on some large monolithic repository which doesn't
use submodules, and you have limited and small quota (or disk size).
Usually repository size is smaller or comparable to checkout size,
and even if it isn't you can use alternates to reduce size of
repository (assuming that reference repository is hosted outside
user quota).
> Because narrow checkout uses new index format, it will be
> incompatible with git prior to 1.6.0 regarding worktree operations.
> Repository-only operations such as clone, push, pull... should not be
s/pull/fetch/. pull affects working repository, and it can affect
narrow checkout unexpectedly by conflicts during merge part of pull.
> affected by narrow checkout. In order to make your working directory
> work again with those versions, you can use `git checkout --full` to
> return to normal mode (and compatible index format).
By the way, you have made "git checkout <file>" get file and mark
it "wanted", i.e. clear/zero "no-checkout" bit. Wouldn't then
"git checkout ." be shorter equivalent to "git checkout --full"?
I'm not saying that '--full' option should be abandoned...
>
> In narrow checkout mode, checkout status of every files in your
> working directory will be recorded in index. If a file is marked
> "no-checkout", it means that file is not needed to be present in
> working directory by user or any git command. When a new file is added
> to index, it will be marked "checkout" unless narrow spec is applied.
> Unmerged files are always "checkout". linkgit:git-update-index[1] can
> be used to update "checkout/no-checkout" status in index. When you
> checkout new files using "git checkout <file>" they will be
> automatically marked "checkout". Other commands such as "git apply"
> can also checkout new files if they are needed.
>
> "No-checkout" status is very similar to "assume-unchanged bit"
> (see linkgit:git-update-index[1]). The main difference between them
> is "assume unchanged" bit just ignores corresponding files in working
> directory while narrow checkout goes a bit farther, remove those files
> when it is safe to do so.
Good description (although probably could be improved even further).
>
> Narrow spec
> -----------
>
> Narrow spec is used to easily specify how do you want to form your
> checkout area. It is a list of pathspecs separated by colons. Each
> patchspec specifies what files should or should not be checked out on
> working directory. Pathspec can contain wildcards and is relative to
> current working directory. Usually asterisk (*) does not match
> slashes. If a pathspec is prefixed by a plus sign (+), then any
> asterisk will match anything, even slashes.
Here I think you should give some examples, perhaps together with
wildcard escaping, escape (backslash) escaping and colon escaping.
>
> When you apply new narrow spec to your working directory using either
> --path, --add-path or --remove-path, it will update "checkout" status
> in index accordingly. Moreover, if a file is marked "no-checkout" and
> is present in working directory, it will be removed. If a file is
> turned from "no-checkout" to "checkout", then it will be added again
> to working directory. Modified and unmerged entries can't bear
> "no-checkout" status, if narrow spec applies to them, "git checkout"
> will refuse to update working directory.
Do I understand correctly, that if one uses --path=<colon separated list>
_only_ filenames matching one of patterns specified would be checked out,
--add-path=<path> would additionally checkout given path and mark "wanted",
and --remove-path=<path> would additionally mark "no-checkout" and remove
path?
What --add-path starts from, i.e. does
$ git checkout --add-path=.gitignore
starts from empty set if --add-path is first, or from full set as without
--add-path?
And is <pathspec> matched against full pathname, or like .gitignore
rules, i.e. as full pathname if it has at least one '/' in it?
>
> Narrow spec is not saved by "git checkout". You can form your checkout
> area on one go with --path option, or do it incrementally
> with --add-path and --remove-path.
> --<--
I would probably say that specification used to select which paths to
check out is not saved anywhere, and used only to mark paths in index
as "no-checkout" or not. Or somehing like that.
Thank you very much for your continued work on this feature!
--
Jakub Narebski
Poland
^ permalink raw reply
* Diff-tree does not work for initial commit
From: Anatol Pomozov @ 2008-09-15 20:01 UTC (permalink / raw)
To: Git Mailing List
Hi, It looks like I found a bug in git.
The problem: In my script I need to know what files were modified by
given commit. I use diff-tree for it. Although it works for most
cases, for initial commit it does not. Here is a sequence of actions.
anatol:~ $ mkdir mkdir initialcommitissue
anatol:~ $ cd initialcommitissue/
anatol:initialcommitissue $ git init
Initialized empty Git repository in /home/anatol/initialcommitissue/.git/
anatol:initialcommitissue $ echo "First commit" > 1.txt
anatol:initialcommitissue $ git add 1.txt
anatol:initialcommitissue $ git commit -m "First commit"
Created initial commit 31ccc6a: First commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 1.txt
anatol:initialcommitissue $ git diff-tree HEAD <<<<< PROBLEM IS HERE
anatol:initialcommitissue $ echo "Second commit" > 2.txt
anatol:initialcommitissue $ git add 2.txt
anatol:initialcommitissue $ git commit -m "Second commit"
Created commit 51e8bcb: Second commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 2.txt
anatol:initialcommitissue $ git diff-tree HEAD
51e8bcbb739fc8329fc092db7a84b02bbc64feb2
:000000 100644 0000000000000000000000000000000000000000
c133ee6afb86d836ae607cc12e7b7b42242aa5fa A 2.txt
so git diff-tree HEAD works fine but git diff-tree HEAD~1 does not. I
guess in sake of consistency it should show all changed files in
initial commit.
--
anatol
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Dmitry Potapov @ 2008-09-15 19:55 UTC (permalink / raw)
To: Pico Geyer; +Cc: git
In-Reply-To: <aa2b76740809150550q724ab0f4x99a27fa21d90c0fb@mail.gmail.com>
On Mon, Sep 15, 2008 at 4:50 PM, Pico Geyer <picogeyer@gmail.com> wrote:
>
> At the head office, we are (still) using a Subversion server to host
> our source code.
> At the branch office, we would like to do the following:
> * Fetch the latest code from the subversion server.
> * Push changes that we have made at the remote office back to upstream
> SVN server.
> * Be able to share source code changes locally (at the branch office)
> between developers.
I used Git in somewhat similar situation where almost all development
was done in Git mirror of SVN, and then the work was propagated to SVN.
There are some limitations with this approach. The most important is
that SVN does not support merges, so you have to linerialize all history
that you want to commit in SVN. That means that you are going to use git
rebase a lot to rewrite history, which is a PITA. Another problem with
this approach is that the author is not preserved. In SVN, all commits will
look like all changes are done by the person who run "git svn dcommit".
Yet, despite of all these limitations caused by using SVN as backend,
it was far more pleasant to work with Git than with SVN (you can save
your work in progress, you can easily organize the review process,
and many other features such as "git bisect" or "git log -S" just to
name a few...).
>
> The solution that I imagined is that we would setup a server (lets
> call it A) at the branch office with a Git repository, that all the
> developers can access.
> Developers would then clone the server repository A, make mods and
> then push changes back to A.
> It would be nice if git users could commit to a subversion branch.
> A merge master would then (as necessary) use svn dcommit to push the
> changes up to the svn server.
> Is this scenario possible?
Each user has its own copy of the whole repository and they always
commit to their _local_ branches. Then they can push their changes to
the Git repo on your server, but it is a bad idea to push changes to
a local branch of a non-bare repository especially if that branch is
checked out, because push does not (and should not!) update the working
tree and that leads to the situation where all pushed changes are
looked undo in the working tree of that repository. Therefore, you
will probably have a separately integration branch to which users
will push. Oftentimes, users will have to rebase their work on top the
integration branch to be able to push on it (only fast-forward push
should be allowed).
The merge master will merge this branch to the local branch assotiated
with subversion (it will be fast-forward, not a real merge) and then
run git svn dcommit to propagate to subversion.
If there were some conflicting changes in subversion repo, the merge
master will have to resolve them. After that update the merge base
should be updated (using git branch -f) to point out to the top of
the subversion branch.
If users have some changes that were based on the old integration
branches they will have to rebase them to the new position of the
integration branch. As I said above, git rebase is going to be very
often operation in this workflow.
NOTE: branches in git differs from what they are in subversion. In
essence, they are no more than pointers to where to add the next
commit. When I learned Git, I found very useful the article called
"Git for computer scientists" to understand basic ideas of how Git
works: http://eagain.net/articles/git-for-computer-scientists/
>
> From the git-svn man page: "git-clone does not clone branches under
> the refs/remotes/ hierarchy or any git-svn metadata, or config. So
> repositories created and managed with using git-svn should use rsync
> for cloning, if cloning is to be done at all."
> Does that mean that one should not push changes to a repository that
> was created with "git svn clone ..."?
No, what the above description says is that SVN specific information is
not cloned when you clone a repo created by svn. It means that users who
cloned from you will not be able to use git-svn to push their changes in
the original subversion repository. Yet, they can push to your repository
as to any other Git repository.
Dmitry
^ permalink raw reply
* Re: [PATCH 09/16] ls-files: apply --deleted on narrow area only
From: Junio C Hamano @ 2008-09-15 19:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-10-git-send-email-pclouds@gmail.com>
I think this should be part of [05/16], not a separate patch.
^ permalink raw reply
* Re: [PATCH 16/16] ls-files: add --overlay option
From: Junio C Hamano @ 2008-09-15 19:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-17-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The same situation happens for "assume unchanged" bit, but I would
> expect narrow checkout to be more user-friendly and should notify users
> these cases so users will not be confused. On this first step, users
> may check by themselves with "git ls-files --overlay",...
Could you explain how the earlier --narrow-checkout option introduced in
[05/16] interacts with this one?
The user has X inside narrow area and Y outside. ls-files reports both X
and Y. 'ls-files --narrow-checkout' reports only X. Y is tracked but not
really, so 'ls-files --narrow-checkout -o' shouldn't say Y is untracked;
there is no cue to tell between X and Y.
But with a half of your patch to 'ls-files -t', you already can show these
potentially stale (leftover from an ancient checkout un-updated because of
narrowness) files. Could a simpler alternative be to do this processing
not inside "if (show_deleted/modified)" part of show_files(), but inside
"if (show_cached/stage)" part of it? Instead of saying tag_cached
unconditionally, if the entry is marked no_checkout, then you would
lstat(2) it there and report that the path is "marked not to be checked
out but somehow something exists there".
By the way, I do not see an easy way to review what paths are marked with
no-checkout easily from your command set. It might be worthwhile to add a
new option that iterates over the index, finds a set of common prefixes to
no-checkout entries and reports that set.
^ permalink raw reply
* Re: [PATCH 11/16] unpack_trees(): add support for narrow checkout
From: Junio C Hamano @ 2008-09-15 19:34 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-12-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/cache.h b/cache.h
> index 2b2c90f..1fc0f83 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -167,6 +167,9 @@ struct cache_entry {
> #define CE_HASHED (0x100000)
> #define CE_UNHASHED (0x200000)
>
> +/* Only remove in work directory, not index */
> +#define CE_WD_REMOVE (0x400000)
> +
> /*
> * Extended on-disk flags
> */
> diff --git a/unpack-trees.c b/unpack-trees.c
> index e59d144..968cc98 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -96,6 +96,15 @@ static int check_updates(struct unpack_trees_options *o)
> if (o->update && o->verbose_update) {
> for (total = cnt = 0; cnt < index->cache_nr; cnt++) {
> struct cache_entry *ce = index->cache[cnt];
> +
> + if (ce->ce_flags & CE_WD_REMOVE) {
> + total++;
> + continue;
> + }
> +
> + if (ce_no_checkout(ce))
> + continue;
> +
> if (ce->ce_flags & (CE_UPDATE | CE_REMOVE))
> total++;
> }
This check for ce_no_checkout() before the existing check to see if
CE_UPDATE and/or CE_REMOVE are on puzzles me (you have the same check
sequence in later loop that does the actualy worktree updates). If
apply_narrow_checkout() check is working correctly, would we ever give
CE_UPDATE and/or CE_REMOVE bits to a cache entry with CE_NO_CHECKOUT set?
IOW, I think this extra check is Ok as it is expected to be no-op when
combined with the existing check, but it leaves me wondering if it is
hiding some codepath that incorrectly sets CE_UPDATE/CE_REMOVE to an entry
outside the narrow checkout area.
I have two more messages but other than these the series is nicely done
and a pleasure to read.
^ permalink raw reply
* Re: [PATCH] help git-upload-pack find git
From: Junio C Hamano @ 2008-09-15 19:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <1221495891-12600-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> The corresponding bug was reported by Paul Johnston who wondered why
> "git clone" failed when specifying --upload-pack for an out-of-$PATH
> installation of git. I'm not sure whether we should encourage this, but
> the --upload-pack option clearly gives the impression that
> git-upload-pack is all that is needed.
Another possibility would be to teach exec_cmd.c:setup_path() to add the
directory specified by $(bindir) to PATH after we add GIT_EXEC_PATH to
it. That should cover the case David Miller reported, shouldn't it?
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Daniel Barkalow @ 2008-09-15 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Brown, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <7vy71tetvt.fsf@gitster.siamese.dyndns.org>
On Mon, 15 Sep 2008, Junio C Hamano wrote:
> David Brown <git@davidb.org> writes:
>
> > ... As far as I can tell, P4 completely
> > ignores whatever the $Id: ...$ headers happen to be expanded to at the
> > time of checking. You can put garbage there, and it check in fine.
> > ...
> > I guess it isn't a problem to make this optional in git-p4, but I
> > don't think this patch is solving the right problem.
>
> Hmm. I do not do p4, but what I am guessing is that there probably is a
> configuration switch on the p4 side that lets you check in files with
> "$Id: garbage $" in them, while dhruva hasn't turned that switch on.
Actually, the problem seems to be that git-p4 tries to create the modified
file by applying the git-generated diff to the p4-provided file, and this
fails if the context for the git-generated diff contains a keyword, since
the p4-provided file has it expanded and git has it collapsed.
I think the right solution is for git-p4 to check that p4 thinks the file
is the correct file and then simply replace it rather than trying to
generate the right result by patching. To be a bit more careful, git-p4
could check that the contents it's replacing actually would exactly match
the git contents if the keywords were callapsed (if the p4 setting is to
use keywords in this file).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [ANNOUNCE] tig-0.12
From: Jonas Fonseca @ 2008-09-15 19:07 UTC (permalink / raw)
To: git
Hello,
Here goes tig version 0.12 after several bug fixes and improvements have
accumulated. This is the first release with a proper NEWS file from
which the notes for this release is included below. The rendering code
has been cleaned up and simplified so if you notice any regressions,
such as slow downs, please report them. Enjoy!
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Improvements:
- F5 also refreshes the current view.
- Allow line graphics to be disabled with new line-graphics option.
- Main view: also include the reference names when searching.
- Main view: support for refreshing.
- Main view: disable boundary commits by default. Use --boundary when
they should be shown. (Debian bug 498628)
- Stage view: add stage-next action to jump to next diff chunk that can
be staged. By default bound to '@'.
- Configure: check for the ncurses header files.
- Add author-width option to costumize the width of the author column.
For example, put the following in ~/.tigrc: set author-width = 10
Bug fixes:
- Fix regression when staging all diff chunks in a section.
- Bind the maximize view action to 'O'; it conflicted with the
keybinding to launch the merge tool in the status view.
- Fix problem with $(cmd) usage in shell code. Some shells (jsh)
installed as /bin/sh does not support it.
- Do not show incomplete boundary commits when --no-walk is used.
- Documentation: Rename gitlink macro to support AsciiDoc 8.2.3.
- Ignore pipe reads with errno "Success" reported after a signals,
for example when refreshing doing background loading.
Change summary
--------------
The diffstat and shortlog summary for changes made in this release.
3 Dominik Vogt
1 Jeff King
33 Jonas Fonseca
1 Rodolfo Borges
INSTALL | 4 +
Makefile | 10 +-
NEWS | 164 +++++++++++
TODO | 3 +
VERSION | 2 +-
asciidoc.conf | 7 +-
configure.ac | 26 +-
manual.txt | 5 +-
tig.1.txt | 4 +-
tig.c | 733 ++++++++++++++++++++++++++++---------------------
tigrc.5.txt | 14 +-
11 files changed, 641 insertions(+), 331 deletions(-)
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 3/3] t9700/test.pl: remove File::Temp requirement
From: Tom G. Christensen @ 2008-09-15 18:27 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <dQSOPLs4uHkUBp4B1ZT4QbBf2xm6SluHuVl0M4fikzSgHUtgDcJXiQ@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> The object oriented version of File::Temp is a rather new incarnation it
> seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
> the 'Objects' section. Instead of creating a file with a unique name in
> the system TMPDIR, we can create our own temporary file with a static
> name and use that instead.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
I applied all three patches and ran the testsuite with perl 5.8.0
(RHEL3). It now passes t9700 and runs to completion as expected.
-tgc
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.0-rc2
From: David Miller @ 2008-09-15 18:25 UTC (permalink / raw)
To: bulb; +Cc: gitster, peterz, git, linux-kernel
In-Reply-To: <20080915171240.GB4787@efreet.light.src>
From: Jan Hudec <bulb@ucw.cz>
Date: Mon, 15 Sep 2008 19:12:40 +0200
> On Sat, Sep 13, 2008 at 01:33:30 -0700, David Miller wrote:
> > Wouldn't it make sense to put the bindir into PATH when we try to do
> > execv_git_cmd()? The code has already put the gitexecdir into the
> > PATH at this point.
>
> I don't think it gets to execv_git_cmd(). Git on local side will run
> ssh <host> git upload-pack
> and it's ssh that can't find git in ~/bin (or maybe it's still using the
> dashed form for backward compatibility; the argument stands either way).
That's not the case I'm running into. The initial GIT execution
works, it's when GIT forks up sub processes and tries to execute other
things that problem show up.
I added tracing and on the ssh remote system, and my PATH had the
GIT exec dir in my path when the problem triggers.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.0-rc2
From: Jan Hudec @ 2008-09-15 17:12 UTC (permalink / raw)
To: David Miller; +Cc: gitster, peterz, git, linux-kernel
In-Reply-To: <20080913.013330.29519747.davem@davemloft.net>
On Sat, Sep 13, 2008 at 01:33:30 -0700, David Miller wrote:
> As a followup this turned out to be the classic "PATH when doing GIT over
> SSH" problem.
>
> I have to say this is very unfun to debug, and even less fun to "fix"
> even once you know this is the problem. And what's more I know this is
> the second time I've had to spend a night debugging this very problem.
>
> I ended up having to make a ~/.ssh/environment file and then restart my
> SSH server with "PermitUserEnvironment yes" added to sshd_config.
>
> But I can't believe this is what I have to do just to pull from a machine
> where I have GIT only installed in my home directory. What if I were just
> a normal user and couldn't change the SSHD config? What hoops would I
> need to jump through to get my PATH setup correctly? :)
>
> It doesn't even work to put ~/bin into the PATH listed in the system wide
> /etc/environment, because that does not do tilde expansion, SSHD just takes
> it as-is.
>
> Wouldn't it make sense to put the bindir into PATH when we try to do
> execv_git_cmd()? The code has already put the gitexecdir into the
> PATH at this point.
I don't think it gets to execv_git_cmd(). Git on local side will run
ssh <host> git upload-pack
and it's ssh that can't find git in ~/bin (or maybe it's still using the
dashed form for backward compatibility; the argument stands either way).
There are two possible solutions (besides the .ssh/environment one):
1. Without hacking git: Use a separate key pair for git access and configure
that key on the server with 'command="/home/you/bin/git-shell"' option in
.ssh/authorized_keys. Git shell should run the command from exec-dir
properly.
2. Hack git to support some variable to set the remote command for ssh
protocol.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ 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