Query about status of http-pull
Hi, Recently cogito again say that the rsync method will be deprecated in future (due to http-pull now supporting pack objects I suppose), but it seems to me that it still have other issues: - lycan linux-2.6 # git pull origin Fetching HEAD using http Getting pack list error: Couldn't get 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf: not separate or in any pack error: Tried http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/05/72e3da3ff5c3744b2f606ecf296d5f89a4bbdf Cannot obtain needed object 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf while processing commit . lycan linux-2.6 # cg-update 17:50:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master [41/41] -> "refs/heads/.origin-pulling" [1] FINISHED --17:50:09-- Downloaded: 11,949 bytes in 5 files Missing object of tag v2.6.13-rc7... unable to retrieve Up to date. Applying changes... Branch already fully merged. lycan linux-2.6 # - If you switch it however to rsync again, it works just fine. Other branches like that of KLIBC and one or two others do not even pull via http-pull. So basically the question is if this is known issues (had mail issues, so missed the last week or so's mail) ? Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [patch] fixup GECOS handling
On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote: > Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > Meaning, if they use a ',' in one of the fields (and it is a linux > > system with the chfn most probably from the shadow package), then they > > are looking for trouble. The only reason I added the ';' was because > > somebody said whatever OS used it instead of a ','. > > What about just swapping the two tests so that ; is cut off and , only > when no ; is around? > Actually, maybe just leave it. Its not a train smash, and in theory on linux ';' is a valid char in the gecos. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re:
On Fri, 2005-04-22 at 15:19 -0700, atani wrote: > Martin Schlemmer, I ran "emerge sync" today and found git has been > added to portage, version 0.5. Also note that there are now two "git" > entries within portage app-misc/git and dev-util/git. app-misc/git is > GNU Interactive Tools > Yeah, I know - that is actually why I complained to r3pek, as most of the guys interested in doing patches, etc will prob pull and build themselfs, but the user that just want to get the latest kernel, will rather want cogito (or git-pasky). So basically the git I mentioned that I wanted added (or maybe replace the current one in the tree depending on what r3pek do), was Petr's stuff ... Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [3/5] Add http-pull
On Fri, 2005-04-22 at 19:12 -0400, Daniel Barkalow wrote: > On Sat, 23 Apr 2005, Petr Baudis wrote: > > > Dear diary, on Sat, Apr 23, 2005 at 01:00:33AM CEST, I got a letter > > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > > On Sat, 23 Apr 2005, Petr Baudis wrote: > > > > > > > Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter > > > > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > > > > > > > Huh. Why? You just go back to history until you find a commit you > > > > already have. If you did it the way as Tony described, if you have that > > > > commit, you can be sure that you have everything it depends on too. > > > > > > But if you download 1000 files of the 1010 you need, and then your network > > > goes down, you will need to download those 1000 again when it comes back, > > > because you can't save them unless you have the full history. > > > > Why can't I? I think I can do that perfectly fine. The worst thing that > > can happen is that fsck-cache will complain a bit. > > Not if you're using the fact that you don't have them to tell you that you > still need the other 10, which is what tony's scheme would do. > Any way (like maybe extending one of the web interfaces already around) to first get a list of all the sha1's you need, and then starting from the bottom like Tony/Petr wants you to do? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[pasky] tags issue on mirrors
Hi, Just check, you currently have: rsync://rsync.kernel.org/pub/scm/cogito/cogito.git/tags/tags Both with the same tag files. Cheers, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [git pasky] tarball question
On Sat, 2005-04-23 at 00:42 +0200, Petr Baudis wrote: > Dear diary, on Fri, Apr 22, 2005 at 04:31:43PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > Hi, > > Hi, > > > I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with > > the .git database included as well (btw, great stuff renaming it to > > something more distributable), but its going to be a pita for users of > > source based distro's like us (Gentoo), as well as our mirrors if it > > gets much bigger. (Already asked r3pek to add it to portage). > > yes; that was actually the plan, it's just that my memory is so > volatile... > Yep, saw before you posted about the change in URL, thanks. > > How about ripping the .git directory from the next release, and just > > have a un-numbered tarball (like you used to) that have the latest > > snapshot of the .git directory for those that want to do git-pasky > > development? Should even make things easier your side, as you could > > just do a cron to update it one a day/whatever. > > Does it actually make sense to keep a tarball with history? Just build > git-pasky and do git init. (Or rsync it manually.) > Well, I did not know about kernel.org hosting it, so I thought it might help due to your reasons for initially tarballing the whole thing =) Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[git pasky] tarball question
Hi, I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with the .git database included as well (btw, great stuff renaming it to something more distributable), but its going to be a pita for users of source based distro's like us (Gentoo), as well as our mirrors if it gets much bigger. (Already asked r3pek to add it to portage). How about ripping the .git directory from the next release, and just have a un-numbered tarball (like you used to) that have the latest snapshot of the .git directory for those that want to do git-pasky development? Should even make things easier your side, as you could just do a cron to update it one a day/whatever. Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[patch] fixup GECOS handling
Hi,
This still applies - any reason for not doing this?
Thanks,
The GECOS is delimited by ',' or ';', so we should only use whatever is
before the first ',' or ';' for the full name, rather than just
stripping those.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
-* Go back, and remove crud from the end: some people
-* have commas etc in their gecos field
-*/
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
signature.asc
Description: This is a digitally signed message part
Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote: > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote: > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote: > > > Hey there, > > > > > > I am trying to pull the latest repository of the linux-2.6 git from > > > Linus' rsync mirror. > > > > > > Here is the shell: > > > > > > === > > > > > > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ gitinit.sh > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git > > > defaulting to local storage area > > > gitpull.sh: unknown remote > > > gitinit.sh: pull failed > > > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ rm -r .git > > > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ gitinit.sh > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git > > > defaulting to local storage area > > > gitpull.sh: unknown remote > > > gitinit.sh: pull failed > > > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ > > > > > > = > > > > > > Any idea why this is not working? > > > > Try: > > > > $ git init > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git > > Exactly the same, sorry. > With latest git-pasky, after blowing the .git directory? I am not sure (and have not checked) that git will do the right thing if you retry without clearing. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote: > Hey there, > > I am trying to pull the latest repository of the linux-2.6 git from Linus' > rsync mirror. > > Here is the shell: > > === > > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ gitinit.sh > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git > defaulting to local storage area > gitpull.sh: unknown remote > gitinit.sh: pull failed > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ rm -r .git > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ gitinit.sh > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git > defaulting to local storage area > gitpull.sh: unknown remote > gitinit.sh: pull failed > [EMAIL PROTECTED]:~/repo/linux-2.6.repo$ > > = > > Any idea why this is not working? > Try: $ git init rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Pasky problem with 'git init URL'
On Thu, 2005-04-21 at 22:29 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Hi,
>
> Hi,
>
> > Just pulled linux-2.6.git, and got this:
> >
> >
> > New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > Tracked branch, applying changes...
> > Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 ->
> > 3a6fd752a50af92765853879f4a11cc0cfcd0320
> > to a2755a80f40e5794ddc20e00f781af9d6320fafb...
> >
> > Enter commit message, terminated by ctrl-D on a separate line:
> > Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
> >
> >
> > Weird thing was that I made no changes.
>
> did you compensate for the renamed hashes? Didn't you before update from
> some very old git-pasky version?
>
> Actually, did you do that git init _after_ the unsuccessful pull, or
> before?
>
I re-pulled it from scratch after the sha1 changes, so not that. Just
the next pull that went wonky.
> > Digging a bit deeper, I saw that .git/HEAD was a symlink
> > to .git/heads/master, and the tracked branch was 'origin'. Due to the
> > fact that Linus only have a .git/heads/master on his rsync, and this
> > thus updated to the new sha1, but the 'origin' (and tracked) head is
> > still pointing to an older sha1 caused this confusion.
>
> Duh. The remote branch always grabs the HEAD over there; you don't need
> to care about the various branches over there, and you really do not
> *want* to care. Actually I might add some ^branchname to the rsync URL,
> to be able to refer to particular branches inside of the repository.
>
Well, I just did a quick peek. I thought it just changed the local head
to the sha1 of the remote, and then updated the local files - haven't
yet looked at gitmerge.sh.
> > I replicated the linux tree via:
> >
> >
> > git init URL
> >
> >
> > So I had a look at gitinit.sh, which first creates the .git/heads/master
> > and symlinks HEAD to it, then on seeing a URL was supplied, creates
> > a .git/heads/origin, track it, but do *not* change the .git/HEAD
> > symlink ... Is this intended? I see also that gittrack.sh do not update
> > the HEAD symlink ... Is this also intended?
>
> Yes.
>
> You never work directly on the remote branch. Ever. That's what this
> tracking stuff is for; you set up a local branch which follows the
> remote one.
>
Ok, but for some weird reason it wanted to commit the merge between
remote and local.
> Otherwise, you fork to two trees, one is remote branch, second is local
> branch, and you do git pull remotebranch in the second. You are in
> trouble now. Also, if you do some local commit on the remote branch,
> what would happen? This kind of stuff is why I decided that you just
> cannot work on remote branches directly.
>
> > The last option however brings a problem or two. First, how do you do
> > the multi-head thing? Maybe add a command 'git lsheads' (and while at
> > it, also add 'git lstags'?)? Secondly, if there was more than one head,
>
> Perhaps it would be useful to have some "command classes" (with at least
> cg-*-(add|ls|rm)), like:
>
> cg-branch-ls
> cg-remote-rm
> cg-tag-add
>
Might make things more sane.
> > the local copy needs to be checked out ... don't know if 'git cancel' is
> > the logical thing the user will think to do ('git clone' perhaps?) ...
>
> I don't know what do you mean here.
>
Don't worry, no biggy.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Pasky problem with 'git init URL'
Hi,
Just pulled linux-2.6.git, and got this:
New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
Tracked branch, applying changes...
Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 ->
3a6fd752a50af92765853879f4a11cc0cfcd0320
to a2755a80f40e5794ddc20e00f781af9d6320fafb...
Enter commit message, terminated by ctrl-D on a separate line:
Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
Weird thing was that I made no changes.
Digging a bit deeper, I saw that .git/HEAD was a symlink
to .git/heads/master, and the tracked branch was 'origin'. Due to the
fact that Linus only have a .git/heads/master on his rsync, and this
thus updated to the new sha1, but the 'origin' (and tracked) head is
still pointing to an older sha1 caused this confusion.
I replicated the linux tree via:
git init URL
So I had a look at gitinit.sh, which first creates the .git/heads/master
and symlinks HEAD to it, then on seeing a URL was supplied, creates
a .git/heads/origin, track it, but do *not* change the .git/HEAD
symlink ... Is this intended? I see also that gittrack.sh do not update
the HEAD symlink ... Is this also intended?
I guess a solution is to either just use 'master', and do not do the
'origin' head, or to update the HEAD symlink. I however do not think
this is very generic, especially if the remote repo do not call their
main head 'master' - so it might be better to check what it have
in .git/heads, and if only one, use that as the main and tracked head,
else do nothing and tell the user to decide what head to track, etc.
The last option however brings a problem or two. First, how do you do
the multi-head thing? Maybe add a command 'git lsheads' (and while at
it, also add 'git lstags'?)? Secondly, if there was more than one head,
the local copy needs to be checked out ... don't know if 'git cancel' is
the logical thing the user will think to do ('git clone' perhaps?) ...
I think it might be a good time to start thinking and putting to text
what commands is really needed, what they should be called, and how
exactly they should behave before it gets much later in the game.
Anyhow, suggestions/comments welcome.
Thanks,
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 2005-04-19 at 15:43 -0700, Linus Torvalds wrote: > > On Wed, 20 Apr 2005, Martin Schlemmer wrote: > > > > Correct me if I am wrong, but the right way to do this is to set the > > hostname to just that - the hostname, and add 'domain foo.com' > > to /etc/resolv.conf. > > I'll correct you. > > The fact is, that's not what people do. Not me, not kernel.org, not _any_ > of the machines I've got access to. They put the fully qualified name in > the hostname, and just do "search foo.com" in /etc/resolv.conf. > > So clearly, expecting that people work the way you claim is being > extremely optimistic. I'm sure some people do that too, but I suspect I'm > in the majority. Both Fedora Core and YellowDog act the way I described, > not the way you do.. > The interesting bit you snipped was the part where you said you do not know how to get dnsdomainname to work properly, and that I answered. Why this other crap about how 90% of the world does it? PS: If you have later tools, setting hostname to the FQDN and then still adding 'domain' to resolv.conf seems to do the right thing, although it did not some time back (and was why I said the bit about hostname only containing the hostname, else you got something like 'hostname -f' returning 'www1.foo.com.foo.com) ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 2005-04-19 at 15:00 -0700, Linus Torvalds wrote: > > On Tue, 19 Apr 2005, Greg KH wrote: > > > > It looks like your domain name isn't set up properly for your box (which > > is why it worked for you, but not me before, causing that patch). > > No, I think it's a bug in your domainname changes. I don't think you > should do the domainname at all if the hostname has a dot in it. > > Most machines I have access to (and that includes machines that are > professionally maintained, not just my own cruddy setup) says "(none)" to > domainname and have the full hostname in hostname. > > And even the ones that use domainname tend to not have a fully qualified > DNS domain there. You need to use dnsdomainname to get that, and I don't > even know how to do it with standard libc. > Correct me if I am wrong, but the right way to do this is to set the hostname to just that - the hostname, and add 'domain foo.com' to /etc/resolv.conf. Then you should get something like (for say www1.foo.com): $ hostname www1 $ dnsdomainname foo.com $ hostname -f www1.foo.com I know for some buggy software the workaround was to set the hostname to the FQDN, but that is really just a kludge, and the software should rather be fixed (had to patch postfix some time back for instance). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Change "pull" to _only_ download, and "git update"=pull+merge?
On Tue, 2005-04-19 at 12:50 +0200, Petr Baudis wrote: > Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote: > > > Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter > > > where David Greaves <[EMAIL PROTECTED]> told me that... > > > > > > Dunno. I do it personally all the time, with git at least. > > > > > > What do others think? :-) > > > > > > > I think pull is pull. If you are doing lots of local stuff and do not > > want it overwritten, it should have been in a forked branch. > > I disagree. This already forces you to have two branches (one to pull > from to get the data, mirroring the remote branch, one for your real > work) uselessly and needlessly. > > I think there is just no good name for what pull is doing now, and > update seems like a great name for what pull-and-merge really is. Pull > really is pull - it _pulls_ the data, while update also updates the > given tree. No surprises. > > (We should obviously have also update-without-pull but that is probably > not going to be so common so a parameter for update (like -n) should be > fine for that.) > > These naming issues may appear silly but I think they matter big time > for usability, intuitiveness, and learning curve (I don't want git-pasky > become another GNU arch). > Ok, so 'pull' do the bk thing, and 'update' do the cvs thing. I think however you should do either do one or the other. Maybe drop the 'update', and rather add 'checkout' (or 'co' for short) which will update the tree (or merge with local changes if needed). Then you have two distinct separate things (ok, so pretty much how bk do things). This will also enable you to make 'fork', 'export', etc just do the right thing with the database, but leave 'checkout' up to the user if he wants to do so. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Change "pull" to _only_ download, and "git update"=pull+merge?
On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote: > Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter > where David Greaves <[EMAIL PROTECTED]> told me that... > > Dunno. I do it personally all the time, with git at least. > > What do others think? :-) > I think pull is pull. If you are doing lots of local stuff and do not want it overwritten, it should have been in a forked branch. > I start to like the pull/update distinction, and I think I'll go for it. > -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [patch] fixup GECOS handling
On Mon, 2005-04-18 at 22:35 +1000, David Woodhouse wrote:
> On Mon, 2005-04-18 at 12:36 +0200, Martin Schlemmer wrote:
> > realgecos[strchr(realgecos, ',') - realgecos] = '\0';
>
> Er, *strchr(realgecos, ',') = 0; surely? Even if the compiler is clever
> enough to optimise out the gratuitous addition and subtraction, that's
> no real excuse for it.
>
Err, right. Updated patch.
The gecos is delimited by ',' or ';', so we should only use whatever
before the first ',' or ';' for the full name, and not just strip those.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
-* Go back, and remove crud from the end: some people
-* have commas etc in their gecos field
-*/
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
signature.asc
Description: This is a digitally signed message part
Re: Re-done kernel archive - real one?
On Sun, 2005-04-17 at 19:20 +0100, Russell King wrote: > On Sun, Apr 17, 2005 at 02:13:59PM -0400, David A. Wheeler wrote: > > On Sun, 17 Apr 2005, Russell King wrote: > > >>BTW, there appears to be "errors" in the history committed thus far. > > >>I'm not sure where this came from though. Some of them could be > > >>UTF8 vs ASCII issues, > > > ... > > >>One thing which definitely needs to be considered is - what character > > >>encoding are the comments to be stored as? > > > > Linus Torvalds replied: > > > To git, it's just a byte stream, and you can have binary comments if you > > > want to. I personally would prefer to move towards UTF eventually, but I > > > really don't think it matters a whole lot as long as 99.9% of everything > > > we'd see there is still 7-bit ascii. > > > > I would _heartily_ recommend moving towards UTF-8 as the > > internal charset for all comments. Alternatives are possible > > (e.g., recording the charset in the header), but they're > > incredibly messy. Even if you don't normally work in UTF-8, > > it's pretty easy to set most editors up to read & write UTF-8. > > Having the data stored as a constant charset eliminates > > a raft of error-prone code. > > Except, I believe, MicroEMACS, which both Linus and myself use. As > far as I know, there aren't any patches to make it UTF-8 compliant. > > The alternative is, I suppose, iconv. However, iconv in _my_ glibc > seems buggy (segfaults) and my efforts for building glibc 2.3.2 for > ARM have failed. Effectively that means iconv is inaccessible to > me. > OT, and probably not much help, but glibc-2.3.5 is out ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Re-done kernel archive - real one?
On Mon, 2005-04-18 at 10:23 +0100, Russell King wrote: > On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote: > > On Sun, 17 Apr 2005, Russell King wrote: > > > I pulled it tonight into a pristine tree (which of course worked.) > > > > Goodie. > > Note the "pristine". Now comes the real test... > > > > In doing so, I noticed that I'd messed up one of the commits - there's > > > a missing new file. Grr. I'll put that down to being a newbie git. > > > > Actually, you should put that down to horribly bad interface tools. With > > BK, we had these nice tools that pointed out that there were files that > > you might want to commit (ie "bk citool"), and made this very obvious. > > > > Tools absolutely matter. And it will take time for us to build up that > > kind of helper infrastructure. So being newbie might be part of it, but > > it's the smaller part, I say. Rough interfaces is a big issue. > > Ok, I just tried pulling your tree into the tree you pulled from, and > got this: > > Tree change: e7905b2f22eb5d5308c9122b9c06c2d02473dd4f > ee423ea56280512778a5961ee58a785a73acb7d1 > ... > *100644->100644 blob > 46f0a3caae02b4bb8f903d7ac86456aa0c37954b->ba4afd7956173b6f89eb6b0b9ad23b392d5c0aee > arch/arm/kernel/process.c > *100644->100644 blob > 4a36fa7192e11df36f5e0928b064239dabe1e305->ec0bc8f315ab5d78a4220e176e7aee76d52d1c74 > arch/arm/kernel/traps.c > *100644->100644 blob > 311d19ee00208faf02359f9e7c5394577a40f253->bf923a953703c6ca0c88eac3b2850cf07b838996 > arch/arm/lib/changebit.S > *100644->100644 blob > c07afa31695654e6489ec59c3f837183b325e9da->41f89b3a393d5af939f04f63c5bf4991b2bf6599 > arch/arm/lib/clearbit.S > ... > Tracked branch, applying changes... > Merging e7905b2f22eb5d5308c9122b9c06c2d02473dd4f -> > ee423ea56280512778a5961ee58a785a73acb7d1 > to df4449813c900973841d0fa5a9e9bc7186956e1e... > COPYING: needs update > CREDITS: needs update > Documentation/00-INDEX: needs update > Documentation/BK-usage/00-INDEX: needs update > ... > patching file arch/arm/kernel/process.c > Reversed (or previously applied) patch detected! Skipping patch. > 2 out of 2 hunks ignored -- saving rejects to file > arch/arm/kernel/process.c.rejpatching file arch/arm/kernel/traps.c > Reversed (or previously applied) patch detected! Skipping patch. > 3 out of 3 hunks ignored -- saving rejects to file arch/arm/kernel/traps.c.rej > patching file arch/arm/lib/changebit.S > Reversed (or previously applied) patch detected! Skipping patch. > 2 out of 2 hunks ignored -- saving rejects to file > arch/arm/lib/changebit.S.rej > patching file arch/arm/lib/clearbit.S > Reversed (or previously applied) patch detected! Skipping patch. > 2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/clearbit.S.rej > > so obviously git pull isn't able to indentify what's already in the > local repository. > > Interestingly, the files listed above as having rejects are excluded > from the list of "needs update". And I don't know why git is staying > that these files need updating, because they haven't changed since > they were initially checked out. > > This was with some random version of git-pasky-0.04. Unfortunately, > this version doesn't have the sha1 ID appended, so I couldn't say > definitively that it's the latest and greatest. It might be a day > old. > gitmerge.sh does not yet have support for the new merge stuff as far as I know, and if it does, then its a very recent version (ie, one that have the sha1 ID appended). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [pasky] recent changes to gitdiff.sh
On Mon, 2005-04-18 at 12:40 +0200, Petr Baudis wrote: > Dear diary, on Mon, Apr 18, 2005 at 12:40:08PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > Hi, > > Hello, > > > I see the recent changes to gitdiff.sh requires you to pass -r (git diff > > -r local:$tracking) even if you separate the branches via ':'. Is this > > intended (seems like it)? > > yes. This brings the usage style in sync with the rest of the world. :-) > > > If so, then gittrack.sh, gitpull.sh and gitmerge.sh needs to be > > updated ... > > I hopes I updated all the places. If I missed anything, please say what. > Update calls to gitdiff.sh to include the '-r' switch. Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]> gitmerge.sh: 7ea441e584d603463fb1b83991b88f63a3895cff --- 1/gitmerge.sh +++ 2/gitmerge.sh 2005-04-18 12:55:34.0 +0200 @@ -67,7 +67,7 @@ fi update-cache --refresh -gitdiff.sh "$base":"$branch" | gitapply.sh +gitdiff.sh -r "$base":"$branch" | gitapply.sh cat >&2 <<__END__ Please inspect the merge in the ,,merge/ subdirectory. Commit from that gitpull.sh: 9bda6555a1dafc1db762bc46db60d2a9485dc523 --- 1/gitpull.sh +++ 2/gitpull.sh2005-04-18 12:55:34.0 +0200 @@ -73,7 +73,7 @@ gitmerge.sh -b "$orig_head" "$new_head" else - gitdiff.sh "$orig_head":"$new_head" | gitapply.sh + gitdiff.sh -r "$orig_head":"$new_head" | gitapply.sh read-tree $(tree-id $new_head) echo $new_head >.git/HEAD gittrack.sh: 30654380c10edde32def8e5fa2e2c956fbff3d58 --- 1/gittrack.sh +++ 2/gittrack.sh 2005-04-18 12:55:34.0 +0200 @@ -50,7 +50,7 @@ echo $name >.git/tracking read-tree $(tree-id "$name") - gitdiff.sh local:"$name" | gitapply.sh + gitdiff.sh -r local:"$name" | gitapply.sh update-cache --refresh else @@ -60,7 +60,7 @@ die "tracked \"$tracking\" branch missing!" if [ -s ".git/HEAD.local" ]; then - gitdiff.sh "$tracking":local | gitapply.sh + gitdiff.sh -r "$tracking":local | gitapply.sh read-tree $(tree-id local) update-cache --refresh -- Martin Schlemmer gitmerge.sh: 7ea441e584d603463fb1b83991b88f63a3895cff --- 1/gitmerge.sh +++ 2/gitmerge.sh 2005-04-18 12:55:34.0 +0200 @@ -67,7 +67,7 @@ fi update-cache --refresh -gitdiff.sh "$base":"$branch" | gitapply.sh +gitdiff.sh -r "$base":"$branch" | gitapply.sh cat >&2 <<__END__ Please inspect the merge in the ,,merge/ subdirectory. Commit from that gitpull.sh: 9bda6555a1dafc1db762bc46db60d2a9485dc523 --- 1/gitpull.sh +++ 2/gitpull.sh 2005-04-18 12:55:34.0 +0200 @@ -73,7 +73,7 @@ gitmerge.sh -b "$orig_head" "$new_head" else - gitdiff.sh "$orig_head":"$new_head" | gitapply.sh + gitdiff.sh -r "$orig_head":"$new_head" | gitapply.sh read-tree $(tree-id $new_head) echo $new_head >.git/HEAD gittrack.sh: 30654380c10edde32def8e5fa2e2c956fbff3d58 --- 1/gittrack.sh +++ 2/gittrack.sh 2005-04-18 12:55:34.0 +0200 @@ -50,7 +50,7 @@ echo $name >.git/tracking read-tree $(tree-id "$name") - gitdiff.sh local:"$name" | gitapply.sh + gitdiff.sh -r local:"$name" | gitapply.sh update-cache --refresh else @@ -60,7 +60,7 @@ die "tracked \"$tracking\" branch missing!" if [ -s ".git/HEAD.local" ]; then - gitdiff.sh "$tracking":local | gitapply.sh + gitdiff.sh -r "$tracking":local | gitapply.sh read-tree $(tree-id local) update-cache --refresh signature.asc Description: This is a digitally signed message part
Re: [patch] fork optional branch point normazilation
On Sun, 2005-04-17 at 16:39 -0700, Linus Torvalds wrote: > > On Sun, 17 Apr 2005, Brad Roberts wrote: > > > > braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash > > > > All gecos entries on all my debian boxes are of the form: > > > >fullname, office number, office extension, and home number > > Ahh, ok. > > I'll make the "cleanup" thing just remove strange characters from the end, > that should fix this kind of thing for now. > > I'd just remove everything after the first strange number, but I can also > see people using the "lastname, firstname" format, and I'd hate to just > ignore firstname in that case. > If we get the info from /etc/passwd, then we should just use whatever before the first [,;] (see patch I posted earlier). If not, then I think AUTHOR_* should be sane). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[pasky] recent changes to gitdiff.sh
Hi, I see the recent changes to gitdiff.sh requires you to pass -r (git diff -r local:$tracking) even if you separate the branches via ':'. Is this intended (seems like it)? If so, then gittrack.sh, gitpull.sh and gitmerge.sh needs to be updated ... (I did not want to add a patch as I am not sure which it is) Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[patch] fixup GECOS handling
Hi,
The gecos is delimited by ',' or ';', so we should only use whatever
before the first ',' or ';' for the full name, and not just strip those.
Also, a '.' may be valid in the full name (Foo B. Zooman) or email
([EMAIL PROTECTED]).
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
-* Go back, and remove crud from the end: some people
-* have commas etc in their gecos field
-*/
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ realgecos[strchr(realgecos, ',') - realgecos] = '\0';
+ else if (strchr(realgecos, ';'))
+ realgecos[strchr(realgecos, ';') - realgecos] = '\0';
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.0 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ realgecos[strchr(realgecos, ',') - realgecos] = '\0';
+ else if (strchr(realgecos, ';'))
+ realgecos[strchr(realgecos, ';') - realgecos] = '\0';
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
signature.asc
Description: This is a digitally signed message part
Re: Plug memory leak in update-cache.c
On Sat, 2005-04-16 at 01:48 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 14, 2005 at 10:53:50AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Hi,
> >
> > Might not be that an big an issue as it should be freed on exit, but
> > might cause problems with big trees.
> >
> >
> >
> > Plug memory leak in update-cache.c.
> >
> > Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
> >
> > update-cache.c: 22f3ccd47db4f0888901109a8cbf883d272d1cba
> > --- 22f3ccd47db4f0888901109a8cbf883d272d1cba/update-cache.c
> > +++ uncommitted/update-cache.c
> > @@ -202,6 +202,7 @@
> > printf("%s: needs update\n", ce->name);
> > continue;
> > }
> > + free(active_cache[i]);
> > active_cache[i] = new;
> > }
> > }
>
> FYI, new could've contained active_cache[i] at that time, so you needed
> to check for that. Fixed though, thanks for pointing it out.
>
Urk, no, please drop. As Ingo pointed out, the memory was obtained via
mmap ...
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: fix various issues in gitapply.sh (basically did not handle add/del/cm at all)
On Fri, 2005-04-15 at 20:15 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 11:28:38AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Hi,
> >
> > The egrep regex should not escape the '{' and '}', and also add a check
> > for ' \t' so that we do not pickup stuff like '+', etc. Fix typo in
> > assignment. Check if file exists in new tree before adding/removing
> > (might add support for this lowlevel to increase speed?). Fix typo in
> > line removing temp files.
> >
> > Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
>
> Thanks for the merge and typo fixes. I can't imagine how, but it really
> appeared to work for me that time!
>
> I'm confused however what does the exits_in_cache() (what exits? exists?)
> gives us, apart of horribly-looking code. What bug does it fix?
>
My typo it seems - should be exists. Basically (especially for
gittrack.sh) it will add all files changed between the trees to either
the add or remove queue if this is not done. This is because it will
just add (say git track linus; git track pasky) the git*.sh files that
is missing in the linus tree (or gitrm.sh if in reverse) although they
are already present there. So we need to check if the file exists in
the destination tree before we git{add,rm}.sh it - if it do exists, then
its ok to gitrm.sh it, if it does not, it is ok to gitadd.sh it.
The other problem is also that if you keep switching, it will add each
file multiple times to the add/rm queue. This is a bug with
git{add,rm}.sh which do not check the queue if the file is already
there, and it also add a file even if it is already in the cache - so it
probably need the same type of fix. I will send a patch when we get how
we check if a file is already in the cache resolved.
Like I said in the patch, it might be better to add support low-level
side (don't know if we can have ls-tree return true/false on file basis,
else add a new tool?).
Thanks,
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [patch pasky 1/2] fix various issues in gitapply.sh (basically did not handle add/del/cm at all)
PS: forget the '1/2' in the topic, i did it slightly different which
required changes to gettrack.sh, etc, but to got getmerge.sh, and saw my
short sightedness.
On Fri, 2005-04-15 at 11:28 +0200, Martin Schlemmer wrote:
> Hi,
>
> The egrep regex should not escape the '{' and '}', and also add a check
> for ' \t' so that we do not pickup stuff like '+', etc. Fix typo in
> assignment. Check if file exists in new tree before adding/removing
> (might add support for this lowlevel to increase speed?). Fix typo in
> line removing temp files.
>
> Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
>
> gitapply.sh: 47b9346d2679b1bf34220fe4502f15c7d0737b0c
> --- 47b9346d2679b1bf34220fe4502f15c7d0737b0c/gitapply.sh
> +++ uncommitted/gitapply.sh
> @@ -19,15 +19,22 @@
> # just handle it all ourselves.
> patch -p1 -N <$patchfifo &
>
> -tee $patchfifo | egrep '^[+-]\{3\}' | {
> +exits_in_cache() {
> + for x in $(ls-tree "$1"); do
> + [ "$x" = "$2" ] && return 0
> + done
> + return 1
> +}
> +
> +tee $patchfifo | egrep '^[+-]{3}[ \t]' | {
> victim=
> origmode=
>
> while read sign file attrs; do
> - echo $sign $file $attrs ... >&2
> +# echo $sign $file $attrs ... >&2
> case $sign in
> "---")
> - victim=file
> + victim=$file
> mode=$(echo $attrs | sed
> 's/.*mode:[0-7]*\([0-7]\{3\}\).*/\1/')
> origmode=
> [ "$mode" != "$attrs" ] && origmode=$mode
> @@ -35,14 +42,19 @@
> "+++")
> if [ "$file" = "/dev/null" ]; then
> torm=$(echo "$victim" | sed 's/[^\/]*\///')
> #-p1
> - echo -ne "rm\0$torm\0"
> + tree=$(echo $attrs | sed
> 's/.*tree:\([0-9a-f]\{40\}\).*/\1/')
> + exits_in_cache "$tree" "$torm" && echo -ne
> "rm\0$torm\0"
> continue
> elif [ "$victim" = "/dev/null" ]; then
> - echo -ne "add\0$file\0"
> + toadd=$(echo "$file" | sed 's/[^\/]*\///')
> #-p1
> + tree=$(echo "$file" | sed -e
> 's/\([^\/]*\)\/.*/\1/')
> + exits_in_cache "$tree" "$toadd" || echo -ne
> "add\0$toadd\0"
> fi
> mode=$(echo $attrs | sed
> 's/.*mode:[0-7]*\([0-7]\{3\}\).*/\1/')
> if [ "$mode" ] && [ "$mode" != "$attrs" ] && [
> "$origmode" != "$mode" ]; then
> - echo -ne "cm\0$mode\0$file\0"
> + tochmod=$(echo "$file" | sed 's/[^\/]*\///')
> #-p1
> + # need a space else numbers gets converted
> + echo -ne "cm\0 $mode\0$tochmod\0"
> fi
> ;;
> *)
> @@ -74,4 +86,4 @@
> done
> ' padding
>
> -rm $pathfifo $todo $gonefile
> +rm $patchfifo $todo $gonefile
>
>
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
[patch pasky 1/2] fix various issues in gitapply.sh (basically did not handle add/del/cm at all)
Hi,
The egrep regex should not escape the '{' and '}', and also add a check
for ' \t' so that we do not pickup stuff like '+', etc. Fix typo in
assignment. Check if file exists in new tree before adding/removing
(might add support for this lowlevel to increase speed?). Fix typo in
line removing temp files.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
gitapply.sh: 47b9346d2679b1bf34220fe4502f15c7d0737b0c
--- 47b9346d2679b1bf34220fe4502f15c7d0737b0c/gitapply.sh
+++ uncommitted/gitapply.sh
@@ -19,15 +19,22 @@
# just handle it all ourselves.
patch -p1 -N <$patchfifo &
-tee $patchfifo | egrep '^[+-]\{3\}' | {
+exits_in_cache() {
+ for x in $(ls-tree "$1"); do
+ [ "$x" = "$2" ] && return 0
+ done
+ return 1
+}
+
+tee $patchfifo | egrep '^[+-]{3}[ \t]' | {
victim=
origmode=
while read sign file attrs; do
- echo $sign $file $attrs ... >&2
+# echo $sign $file $attrs ... >&2
case $sign in
"---")
- victim=file
+ victim=$file
mode=$(echo $attrs | sed
's/.*mode:[0-7]*\([0-7]\{3\}\).*/\1/')
origmode=
[ "$mode" != "$attrs" ] && origmode=$mode
@@ -35,14 +42,19 @@
"+++")
if [ "$file" = "/dev/null" ]; then
torm=$(echo "$victim" | sed 's/[^\/]*\///') #-p1
- echo -ne "rm\0$torm\0"
+ tree=$(echo $attrs | sed
's/.*tree:\([0-9a-f]\{40\}\).*/\1/')
+ exits_in_cache "$tree" "$torm" && echo -ne
"rm\0$torm\0"
continue
elif [ "$victim" = "/dev/null" ]; then
- echo -ne "add\0$file\0"
+ toadd=$(echo "$file" | sed 's/[^\/]*\///') #-p1
+ tree=$(echo "$file" | sed -e
's/\([^\/]*\)\/.*/\1/')
+ exits_in_cache "$tree" "$toadd" || echo -ne
"add\0$toadd\0"
fi
mode=$(echo $attrs | sed
's/.*mode:[0-7]*\([0-7]\{3\}\).*/\1/')
if [ "$mode" ] && [ "$mode" != "$attrs" ] && [
"$origmode" != "$mode" ]; then
- echo -ne "cm\0$mode\0$file\0"
+ tochmod=$(echo "$file" | sed 's/[^\/]*\///')
#-p1
+ # need a space else numbers gets converted
+ echo -ne "cm\0 $mode\0$tochmod\0"
fi
;;
*)
@@ -74,4 +86,4 @@
done
' padding
-rm $pathfifo $todo $gonefile
+rm $patchfifo $todo $gonefile
--
Martin Schlemmer
gitapply.sh: 47b9346d2679b1bf34220fe4502f15c7d0737b0c
--- 47b9346d2679b1bf34220fe4502f15c7d0737b0c/gitapply.sh
+++ uncommitted/gitapply.sh
@@ -19,15 +19,22 @@
# just handle it all ourselves.
patch -p1 -N <$patchfifo &
-tee $patchfifo | egrep '^[+-]\{3\}' | {
+exits_in_cache() {
+ for x in $(ls-tree "$1"); do
+ [ "$x" = "$2" ] && return 0
+ done
+ return 1
+}
+
+tee $patchfifo | egrep '^[+-]{3}[ \t]' | {
victim=
origmode=
while read sign file attrs; do
- echo $sign $file $attrs ... >&2
+# echo $sign $file $attrs ... >&2
case $sign in
"---")
- victim=file
+ victim=$file
mode=$(echo $attrs | sed 's/.*mode:[0-7]*\([0-7]\{3\}\).*/\1/')
origmode=
[ "$mode" != "$attrs" ] && origmode=$mode
@@ -35,14 +42,19 @@
"+++")
if [ "$file" = "/dev/null" ]; then
torm=$(echo "$victim" | sed 's/[^\/]*\///') #-p1
-echo -ne "rm\0$torm\0"
+tree=$(echo $attrs | sed 's/.*tree:\([0-9a-f]\{40\}\).*/\1/')
+exits_in_cache "$tree" "$torm" && echo -ne "rm\0$torm\0"
continue
elif [ "$victim" = "/dev/null" ]; then
-echo -ne "add\0$file\0"
+toadd=$(echo "$file" | sed 's/[^\/]*\///') #-p1
+tree=$(echo "$file" | sed -e 's/\([^\/]*\)\/.*/\1/')
+exits_in_cache "$tree" "$toadd" || echo -ne "add\0$toadd\0"
fi
mode=$(echo $attrs | sed 's/.*mode:[0-7]*\([0-7]\{3\}\).*/\1/')
if [ "$mode" ] && [ "$mode" != "$attrs" ] && [ "$origmode" != "$mode" ]; then
-echo -ne "cm\0$mode\0$file\0"
+tochmod=$(echo "$file" | sed 's/[^\/]*\///') #-p1
+# need a space else numbers gets converted
+echo -ne "cm\0 $mode\0$tochmod\0"
fi
;;
*)
@@ -74,4 +86,4 @@
done
' padding
-rm $pathfifo $todo $gonefile
+rm $patchfifo $todo $gonefile
signature.asc
Description: This is a digitally signed message part
Re: Re: Re: Re: Remove need to untrack before tracking new branch
On Fri, 2005-04-15 at 00:35 +0200, Alex Riesen wrote:
> On 4/14/05, Martin Schlemmer <[EMAIL PROTECTED]> wrote:
> > + if (update_mode && changed & MODE_CHANGED)
> > + chmod(ce->name, ce->st_mode);
>
> it's "if ((update_mode && changed) & MODE_CHANGED)"
> Did you really mean that?
>
No, '&' have a higher priority (weight?) than '&&'. Although, yes, it
might be better style to add brackets.
But just to make you happy, let me prove it:
-
$ cat foo1.c
int main() {
int foo, bar;
if (foo && bar & 1)
return 1;
return 0;
}
$ cat foo2.c
int main() {
int foo, bar;
if (foo && (bar & 1))
return 1;
return 0;
}
$ cat foo3.c
int main() {
int foo, bar;
if ((foo && bar) & 1)
return 1;
return 0;
}
$ gcc -c -S foo1.c -o foo1.S
$ gcc -c -S foo2.c -o foo2.S
$ gcc -c -S foo3.c -o foo3.S
$ diff -u foo1.S foo2.S
--- foo1.S 2005-04-15 07:42:27.0 +0200
+++ foo2.S 2005-04-15 07:42:32.0 +0200
@@ -1,4 +1,4 @@
- .file "foo1.c"
+ .file "foo2.c"
.text
.globl main
.type main, @function
$ diff -u foo1.S foo3.S
--- foo1.S 2005-04-15 07:42:27.0 +0200
+++ foo3.S 2005-04-15 07:42:35.0 +0200
@@ -1,4 +1,4 @@
- .file "foo1.c"
+ .file "foo3.c"
.text
.globl main
.type main, @function
@@ -9,9 +9,14 @@
andl$-16, %esp
movl$0, %eax
subl%eax, %esp
+ movl$0, -16(%ebp)
cmpl$0, -4(%ebp)
- je .L2
- movl-8(%ebp), %eax
+ je .L3
+ cmpl $0, -8(%ebp)
+ je .L3
+ movl$1, -16(%ebp)
+.L3:
+ movl-16(%ebp), %eax
andl$1, %eax
testl %eax, %eax
je .L2
-
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: Re: [patch pasky] update gitcancel.sh to handle modes as well
On Fri, 2005-04-15 at 01:15 +0200, Petr Baudis wrote: > Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > Rather use checkout-cache to sync our tree, as should do the right thing > > instead of diffing (cancel imply just blow away everything). > > > > Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]> > > > > gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114 > > --- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh > > +++ uncommitted/gitcancel.sh > > @@ -10,9 +10,8 @@ > > # > > # Takes no arguments. Takes the evil changes from the tree. > > > > -# FIXME: Does not revert mode changes! > > > > -show-diff | patch -p0 -R > > rm -f .git/add-queue .git/rm-queue > > +checkout-cache -q -f -a > > > > update-cache --refresh > PS, shouldn't we add a read-tree $(tree-id) before the checkout-cache? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Remove need to untrack before tracking new branch
On Fri, 2005-04-15 at 01:09 +0200, Martin Schlemmer wrote: > On Fri, 2005-04-15 at 01:00 +0200, Petr Baudis wrote: > > Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote: > > > > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter > > > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > > > > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", > > > > > > > name, name); > > > > > > > + for (n = 0; n < 20; n++) > > > > > > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]); > > > > > > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L > > > > > > > uncommitted/%s -u -N - %s", > > > > > > > + sha1, ce->name, ce->name, ce->name); > > > > > > > > > > > > The "directory" sha1 is the sha1 of the tree, not of the particular > > > > > > file - that one is in the "attributes" list (parentheses after the > > > > > > filename), together with mode. > > > > > > > > > > > > > > > > Does it really matter? It is more just to get the patch prefix right, > > > > > and I did it as it went nicely with the printed: > > > > > > > > > > > > > > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96 > > > > > > > > > > > > > > > for example ... > > > > > > > > Yes, it matters, and I don't care how nicely it wents with what you > > > > print before. > > > > > > > > > > hah ;p > > > > > > > Either print there some nonsense which is clear not to be a tree ID, or > > > > (much more preferably) print the real tree ID there. If some tool ever > > > > uses it (e.g. to help resolve conflicts, perhaps even actually doing a > > > > real merge based on the patch), you just confused it. > > > > > > > > > > Ok, understood. Do you think it will be scripted? If not I guess we > > > can just do labels like: > > > > > > --- committed/ > > > +++ uncommitted/ > > > > > > ? > > > > Heh. Well, of course this could do. But is there any technical reason > > why not just carry the sha1 id of the tree around and stuff it there? > > > > Not at all. Just wanted to know if anybody saw the possible use before > adding possible cruft that could be done shorter - will do a patch > shortly. > Ho hum - none of the lowlevel tools know or work with the tree-id, and I am not too sure if Linus will like adding something to get it ... any ideas? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Re: [patch pasky] update gitcancel.sh to handle modes as well
On Fri, 2005-04-15 at 01:07 +0200, Petr Baudis wrote: > Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > Rather use checkout-cache to sync our tree, as should do the right thing > > instead of diffing (cancel imply just blow away everything). > > > > Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]> > > > > gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114 > > --- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh > > +++ uncommitted/gitcancel.sh > > @@ -10,9 +10,8 @@ > > # > > # Takes no arguments. Takes the evil changes from the tree. > > > > -# FIXME: Does not revert mode changes! > > > > -show-diff | patch -p0 -R > > rm -f .git/add-queue .git/rm-queue > > +checkout-cache -q -f -a > > > > update-cache --refresh > > Why -q? > > Never make things silent unless you really know what are you doing and > why. The same goes for popular throwing of -f to rm's of files which > should always exist or 2>/dev/null for cats. > Uhm, no particular reason (other than perhaps working usually on stuff where too much info just confuses the user). If its fine in spirit, the -q can go. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Remove need to untrack before tracking new branch
On Fri, 2005-04-15 at 01:00 +0200, Petr Baudis wrote: > Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote: > > > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter > > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > > > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, > > > > > > name); > > > > > > + for (n = 0; n < 20; n++) > > > > > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]); > > > > > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s > > > > > > -u -N - %s", > > > > > > + sha1, ce->name, ce->name, ce->name); > > > > > > > > > > The "directory" sha1 is the sha1 of the tree, not of the particular > > > > > file - that one is in the "attributes" list (parentheses after the > > > > > filename), together with mode. > > > > > > > > > > > > > Does it really matter? It is more just to get the patch prefix right, > > > > and I did it as it went nicely with the printed: > > > > > > > > > > > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96 > > > > > > > > > > > > for example ... > > > > > > Yes, it matters, and I don't care how nicely it wents with what you > > > print before. > > > > > > > hah ;p > > > > > Either print there some nonsense which is clear not to be a tree ID, or > > > (much more preferably) print the real tree ID there. If some tool ever > > > uses it (e.g. to help resolve conflicts, perhaps even actually doing a > > > real merge based on the patch), you just confused it. > > > > > > > Ok, understood. Do you think it will be scripted? If not I guess we > > can just do labels like: > > > > --- committed/ > > +++ uncommitted/ > > > > ? > > Heh. Well, of course this could do. But is there any technical reason > why not just carry the sha1 id of the tree around and stuff it there? > Not at all. Just wanted to know if anybody saw the possible use before adding possible cruft that could be done shorter - will do a patch shortly. Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [patch pasky] update gitcancel.sh to handle modes as well
On Fri, 2005-04-15 at 00:57 +0200, Martin Schlemmer wrote: > Hi, > > gitcancel.sh do not handle mode changes: > > > $ chmod -x Makefile > $ git cancel > patch: Only garbage was found in the patch input. > > > Rather use checkout-cache to sync our tree, as should do the right thing > instead of diffing (cancel imply just blow away everything). > > Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]> > > gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808 > --- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh > +++ uncommitted/gittrack.sh > @@ -51,6 +51,7 @@ > > read-tree $(tree-id "$name") > gitdiff.sh local "$name" | gitapply.sh > + update-cache --refresh > > else > [ "$tracking" ] || \ > @@ -61,6 +62,7 @@ > if [ -s ".git/HEAD.local" ]; then > gitdiff.sh "$tracking" local | gitapply.sh > read-tree $(tree-id local) > + update-cache --refresh > > head=$(cat .git/HEAD) > branchhead=$(cat .git/heads/$tracking) Yes, I am an idiot, and its past 1am already here. Rather use checkout-cache to sync our tree, as should do the right thing instead of diffing (cancel imply just blow away everything). Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]> gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114 --- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh +++ uncommitted/gitcancel.sh @@ -10,9 +10,8 @@ # # Takes no arguments. Takes the evil changes from the tree. -# FIXME: Does not revert mode changes! -show-diff | patch -p0 -R rm -f .git/add-queue .git/rm-queue +checkout-cache -q -f -a update-cache --refresh -- Martin Schlemmer gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114 --- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh +++ uncommitted/gitcancel.sh @@ -10,9 +10,8 @@ # # Takes no arguments. Takes the evil changes from the tree. -# FIXME: Does not revert mode changes! -show-diff | patch -p0 -R rm -f .git/add-queue .git/rm-queue +checkout-cache -q -f -a update-cache --refresh signature.asc Description: This is a digitally signed message part
Re: Remove need to untrack before tracking new branch
On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > (PS, can you check the fact that your mail client keeps on adding a 'Re:
> > ' ...)
>
> Hmm. I guess my ancient reply_regexp
> "^((\\[|\\()([^B]|B([^u]|u([^g]|g([^ ]|AnTiMaTcH[^]]+(\\]|\\)))?[
> \t]*((re([\\[0-9\\]+])*|aw):[ \t]*)?" is broken... ;-)
>
> > On Thu, 2005-04-14 at 11:11 +0200, Petr Baudis wrote:
> > > I'm lost. Why do you do --update-modes? That makes no sense to me.
> > > You introduce them to the cache out-of-order w.r.t. commits, that means
> > > in the normal git usage they are already unrevertable.
> > >
> >
> > Right, afterwards I thought I did add it to the wrong place.
>
> So, could you please do something with it? :-)
>
> > > What are you trying to do? Mode changes _are_ real changes. You _don't_
> > > want to silence them. What you want is to even show them more explicitly
> > > in show-diff.
> > >
> >
> > No, you do not understand. If you actually change the mode, it will
> > show. What now happens, is that say I track the 'linus' branch, then
> > untrack, and then track 'pasky' again, the Patches will be applied, but
> > not the mode changes which are stored in the cache ... Let me show you:
> >
> > -
> > $ ls -l $(./show-diff -s | cut -d: -f1)
> ..directroy listing with no 'x' bit..
> > -
> >
> > (Note no 'x' bit ...)
> >
> > And that is _after_ doing:
> >
> > $ git track linus; git track
> >
> > So basically the modes that are stored in the cache are not applied ...
> > Although, yes, I prob should add the relevant code to checkout-cache.
>
> This should be fixed now, BTW. git apply didn't correctly apply the
> mode changes, but now it should. Several bugs prevented it to, in fact.
> ;-)
>
Yep, I saw - thought you scrapped this, so mailed a new patch (or was
busy doing the touch ups to the email when this came in.
> > > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > > > --- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
> > > > +++ uncommitted/show-diff.c
> > > > @@ -5,13 +5,18 @@
> > > > */
> > > > #include "cache.h"
> > > >
> > > > -static void show_differences(char *name,
> > > > +static void show_differences(struct cache_entry *ce,
> > > > void *old_contents, unsigned long long old_size)
> > > > {
> > > > static char cmd[1000];
> > > > + static char sha1[41];
> > > > + int n;
> > > > FILE *f;
> > > >
> > > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name,
> > > > name);
> > > > + for (n = 0; n < 20; n++)
> > > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> > > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u
> > > > -N - %s",
> > > > + sha1, ce->name, ce->name, ce->name);
> > >
> > > The "directory" sha1 is the sha1 of the tree, not of the particular
> > > file - that one is in the "attributes" list (parentheses after the
> > > filename), together with mode.
> > >
> >
> > Does it really matter? It is more just to get the patch prefix right,
> > and I did it as it went nicely with the printed:
> >
> >
> > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> >
> >
> > for example ...
>
> Yes, it matters, and I don't care how nicely it wents with what you
> print before.
>
hah ;p
> Either print there some nonsense which is clear not to be a tree ID, or
> (much more preferably) print the real tree ID there. If some tool ever
> uses it (e.g. to help resolve conflicts, perhaps even actually doing a
> real merge based on the patch), you just confused it.
>
Ok, understood. Do you think it will be scripted? If not I guess we
can just do labels like:
--- committed/
+++ uncommitted/
?
> Also, do you think you could separate this patch from the other
> (--update-modes) patch? (If we actually still need the --update-modes
> patch after git apply was fixed.)
>
Yeah, already split it out locally, just waiting on above response ...
Thanks,
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: Re: [PATCH] Git pasky include commit-id in Makefile
On Fri, 2005-04-15 at 00:35 +0200, Petr Baudis wrote: > Dear diary, on Fri, Apr 15, 2005 at 12:37:25AM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote: > > > Currently the commit-id script is not install with > > > make install, this patches includes it in the SCRIPT > > > target. This patch is against git-pasky-0.4 > > > > > > > Hmm, this is still not fixed ... > > Come on people, give me a while. I just started walking through the > queued bugfixes. ;-) > Sorry, thought you missed it as you had in later patches =) -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[patch pasky] update gitcancel.sh to handle modes as well
Hi,
gitcancel.sh do not handle mode changes:
$ chmod -x Makefile
$ git cancel
patch: Only garbage was found in the patch input.
Rather use checkout-cache to sync our tree, as should do the right thing
instead of diffing (cancel imply just blow away everything).
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
--
Martin Schlemmer
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
signature.asc
Description: This is a digitally signed message part
[patch pasky] refresh cache after changing tracked tree
Hi,
I see the latest gitdiff-do does the right thing regarding modes, but we
still need to refresh the cache.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
--
Martin Schlemmer
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Git pasky include commit-id in Makefile
On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote: > Currently the commit-id script is not install with > make install, this patches includes it in the SCRIPT > target. This patch is against git-pasky-0.4 > Hmm, this is still not fixed ... > Signed-off-by Darren Williams <[EMAIL PROTECTED]> > > COPYING: fe2a4177a760fd110e78788734f167bd633be8de > Makefile: ca50293c4f211452d999b81f122e99babb9f2987 > --- Makefile > +++ Makefile2005-04-14 23:52:35.701915203 +1000 > @@ -19,7 +19,7 @@ > SCRIPT=parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh > \ > gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \ > gitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \ > - gitapply.sh gitcancel.sh gitlntree.sh > + gitapply.sh gitcancel.sh gitlntree.sh commit-id > > GEN_SCRIPT= gitversion.sh > > README: ded1a3b20e9bbe1f40e487ba5f9361719a1b6b85 > VERSION: c27bd67cd632cc15dd520fbfbf807d482efa2dcf > cache.h: 4d382549041d3281f8d44aa2e52f9f8ec47dd420 > cat-file.c: 45be1badaa8517d4e3a69e0bf1cac2e90191e475 > check-files.c: 927b0b9aca742183fc8e7ccd73d73d8d5427e98f > checkout-cache.c: f06871cdbc1b18ea93bdf4e17126aeb4cca1373e > commit-id: 65c81756c8f10d513d073ecbd741a3244663c4c9 > commit-tree.c: 12196c79f31d004dff0df1f50dda67d8204f5568 > diff-tree.c: 7dcc9eb7782fa176e27f1677b161ce78ac1d2070 > fsck-cache.c: 9c900fe458cecd2bdb4c4571a584115b5cf24f22 > git: 2c557dcf2032325acc265b577ee104e605fdaede > gitXnormid.sh: a5d7a9f4a6e8d4860f35f69500965c2a493d80de > gitadd.sh: 3ed93ea0fcb995673ba9ee1982e0e7abdbe35982 > gitaddremote.sh: bf1f28823da5b5270aa8fa05b321faa514a57a11 > gitapply.sh: d0e3c46e2ce1ee74e1a87ee6137955fa9b35c27b > gitcancel.sh: ec58f7444a42cd3cbaae919fc68c70a3866420c0 > gitcommit.sh: 3629f67bbd3f171d091552814908b67af7537f4d > gitdiff-do: d6174abceab34d22010c36a8453a6c3f3f184fe0 > gitdiff.sh: 5e47c4779d73c3f2f39f6be714c0145175933197 > gitexport.sh: dad00bf251b38ce522c593ea9631f842d8ccc934 > gitlntree.sh: 17c4966ea64aeced96ae4f1b00f3775c1904b0f1 > gitlog.sh: 177c6d12dd9fa4b4920b08451ffe4badde544a39 > gitls.sh: b6f15d82f16c1e9982c5031f3be22eb5430273af > gitlsobj.sh: 128461d3de6a42cfaaa989fc6401bebdfa885b3f > gitmerge.sh: 23e4a3ff342c6005928ceea598a2f52de6fb9817 > gitpull.sh: 0883898dda579e3fa44944b7b1d909257f6dc63e > gitrm.sh: 5c18c38a890c9fd9ad2b866ee7b529539d2f3f8f > gittag.sh: c8cb31385d5a9622e95a4e0b2d6a4198038a659c > gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808 > init-db.c: aa00fbb1b95624f6c30090a17354c9c08a6ac596 > ls-tree.c: 3e2a6c7d183a42e41f1073dfec6794e8f8a5e75c > parent-id: 1801c6fe426592832e7250f8b760fb9d2e65220f > read-cache.c: 7a6ae8b9b489f6b67c82e065dedd5716a6bfc0ef > read-tree.c: eb548148aa6d212f05c2c622ffbe62a06cd072f9 > rev-tree.c: 395b0b3bfadb0537ae0c62744b25ead4b487f3f6 > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96 > show-files.c: a9fa6767a418f870a34b39379f417bf37b17ee18 > tree-id: cb70e2c508a18107abe305633612ed702aa3ee4f > update-cache.c: 62d0a6c41560d40863c44599355af10d9e089312 > write-tree.c: 1534477c91169ebddcf953e3f4d2872495477f6b > > --- > Darren Williams > [EMAIL PROTECTED] > ------ > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [patch] git: fix memory leak #2 in read-cache.c
On Thu, 2005-04-14 at 15:25 +0200, Ingo Molnar wrote: > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > this patch fixes a memory leak in read-cache.c: when there's cache > > entry collision we should free the previous one. > > > + free(active_cache[pos]); > > active_cache[pos] = ce; > > i'm having second thoughs about this one: active_cache entries are not > always malloc()-ed - e.g. read_cache() will construct them from the > mmap() of the index file. Which must not be free()d! > > one safe solution would be to malloc() all these entries and copy them > over from the index file? Slightly slower but safer and free()-able when > update-cache.c notices a collision. The (tested) patch below does this. > > this would also make Martin Schlemmer's update-cache.c fix safe. > Ok, bad me it seems - assumed it was malloc'd. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Re: Re: Re: Remove need to untrack before tracking new branch
On Thu, 2005-04-14 at 11:40 +0200, Martin Schlemmer wrote:
> On Thu, 2005-04-14 at 11:11 +0200, Petr Baudis wrote:
> > Please trim the replied mails a bit, snipping old and irrelevant parts.
> > This is insane. :-)
> >
> > Dear diary, on Thu, Apr 14, 2005 at 10:38:25AM CEST, I got a letter
> > where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > ..snip..
> > > Normalize show-diff output, add --update-modes target to update-cache,
> > > and make sure we only show real changes after changing the tracked
> > > branch, as well as update the file modes according to the cache.
> >
> > I'm lost. Why do you do --update-modes? That makes no sense to me.
> > You introduce them to the cache out-of-order w.r.t. commits, that means
> > in the normal git usage they are already unrevertable.
> >
>
> Right, afterwards I thought I did add it to the wrong place.
>
>
> > What are you trying to do? Mode changes _are_ real changes. You _don't_
> > want to silence them. What you want is to even show them more explicitly
> > in show-diff.
> >
>
> No, you do not understand. If you actually change the mode, it will
> show. What now happens, is that say I track the 'linus' branch, then
> untrack, and then track 'pasky' again, the Patches will be applied, but
> not the mode changes which are stored in the cache ...
>
> So basically the modes that are stored in the cache are not applied ...
> Although, yes, I prob should add the relevant code to checkout-cache.
>
Ok, this should be a better one I think.
Normalize show-diff output, add --update-modes target to update-cache,
and make sure we only show real changes after changing the tracked
branch, as well as update the file modes according to the cache.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
checkout-cache.c: f06871cdbc1b18ea93bdf4e17126aeb4cca1373e
--- f06871cdbc1b18ea93bdf4e17126aeb4cca1373e/checkout-cache.c
+++ uncommitted/checkout-cache.c
@@ -34,7 +34,7 @@
*/
#include "cache.h"
-static int force = 0, quiet = 0;
+static int force = 0, quiet = 0, update_mode = 0;
static void create_directories(const char *path)
{
@@ -99,6 +99,8 @@
unsigned changed = cache_match_stat(ce, &st);
if (!changed)
return 0;
+ if (update_mode && changed & MODE_CHANGED)
+ chmod(ce->name, ce->st_mode);
if (!force) {
if (!quiet)
fprintf(stderr, "checkout-cache: %s already
exists\n", ce->name);
@@ -158,6 +160,10 @@
quiet = 1;
continue;
}
+ if (!strcmp(arg, "-m")) {
+ update_mode = 1;
+ continue;
+ }
}
checkout_file(arg);
}
gitcancel.sh: ec58f7444a42cd3cbaae919fc68c70a3866420c0
--- ec58f7444a42cd3cbaae919fc68c70a3866420c0/gitcancel.sh
+++ uncommitted/gitcancel.sh
@@ -12,7 +12,8 @@
# FIXME: Does not revert mode changes!
-show-diff | patch -p0 -R
+show-diff | patch -p1 -R
rm -f .git/add-queue .git/rm-queue .git/merged
+checkout-cache -q -m -a
update-cache --refresh
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,8 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ checkout-cache -q -m -a
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +63,8 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ checkout-cache -q -m -a
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
--- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
+++ uncommitted/show-diff.c
@@ -5,13 +5,18 @@
*/
#include "cache.h"
-static void show_differences(char *name,
+static void show_differences(struct cache_entry *ce,
void *old_contents, unsigned long long old_size)
{
static char cmd[1000];
+ static char sha1[41];
+ int n;
FILE *f;
- snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
+ for (n = 0; n < 20; n++)
+ snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
+ snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N -
%s",
+
Re: Re: Re: Re: Remove need to untrack before tracking new branch
(PS, can you check the fact that your mail client keeps on adding a 'Re:
' ...)
On Thu, 2005-04-14 at 11:11 +0200, Petr Baudis wrote:
> Please trim the replied mails a bit, snipping old and irrelevant parts.
> This is insane. :-)
>
> Dear diary, on Thu, Apr 14, 2005 at 10:38:25AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> ..snip..
> > Normalize show-diff output, add --update-modes target to update-cache,
> > and make sure we only show real changes after changing the tracked
> > branch, as well as update the file modes according to the cache.
>
> I'm lost. Why do you do --update-modes? That makes no sense to me.
> You introduce them to the cache out-of-order w.r.t. commits, that means
> in the normal git usage they are already unrevertable.
>
Right, afterwards I thought I did add it to the wrong place.
> What are you trying to do? Mode changes _are_ real changes. You _don't_
> want to silence them. What you want is to even show them more explicitly
> in show-diff.
>
No, you do not understand. If you actually change the mode, it will
show. What now happens, is that say I track the 'linus' branch, then
untrack, and then track 'pasky' again, the Patches will be applied, but
not the mode changes which are stored in the cache ... Let me show you:
-
$ ls -l $(./show-diff -s | cut -d: -f1)
-rw-r--r-- 1 root root 168 Apr 14 11:33 commit-id
-rw-r--r-- 1 root root 2213 Apr 14 11:33 git
-rw-r--r-- 1 root root 1168 Apr 14 11:33 gitXnormid.sh
-rw-r--r-- 1 root root 403 Apr 14 11:33 gitadd.sh
-rw-r--r-- 1 root root 844 Apr 14 11:33 gitaddremote.sh
-rw-r--r-- 1 root root 1899 Apr 14 11:33 gitapply.sh
-rw-r--r-- 1 root root 479 Apr 14 11:33 gitcancel.sh
-rw-r--r-- 1 root root 2512 Apr 14 11:33 gitcommit.sh
-rw-r--r-- 1 root root 2152 Apr 14 11:33 gitdiff-do
-rw-r--r-- 1 root root 819 Apr 14 11:33 gitdiff.sh
-rw-r--r-- 1 root root 717 Apr 14 11:33 gitexport.sh
-rw-r--r-- 1 root root 524 Apr 14 11:33 gitlog.sh
-rw-r--r-- 1 root root 228 Apr 14 11:33 gitls.sh
-rw-r--r-- 1 root root 904 Apr 14 11:33 gitlsobj.sh
-rw-r--r-- 1 root root 665 Apr 14 11:33 gitmerge.sh
-rw-r--r-- 1 root root 2044 Apr 14 11:33 gitpull.sh
-rw-r--r-- 1 root root 433 Apr 14 11:33 gitrm.sh
-rw-r--r-- 1 root root 614 Apr 14 11:33 gittag.sh
-rw-r--r-- 1 root root 2272 Apr 14 11:33 gittrack.sh
-rw-r--r-- 1 root root 284 Apr 14 11:33 parent-id
-rw-r--r-- 1 root root 177 Apr 14 11:33 tree-id
-
(Note no 'x' bit ...)
And that is _after_ doing:
$ git track linus; git track
So basically the modes that are stored in the cache are not applied ...
Although, yes, I prob should add the relevant code to checkout-cache.
> The --refreshes are fine.
>
> > Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
> >
> > gitcancel.sh: ec58f7444a42cd3cbaae919fc68c70a3866420c0
> > --- ec58f7444a42cd3cbaae919fc68c70a3866420c0/gitcancel.sh
> > +++ uncommitted/gitcancel.sh
> > @@ -12,7 +12,8 @@
> >
> > # FIXME: Does not revert mode changes!
> >
> > -show-diff | patch -p0 -R
> > +show-diff | patch -p1 -R
> > rm -f .git/add-queue .git/rm-queue .git/merged
> >
> > -update-cache --refresh
> > +# --update-modes need to be before --refresh
> > +update-cache --update-modes --refresh
>
> Here, e.g., you should do the very opposite - change the modes back to
> how are they in the cache.
>
Uhm, that is what it did ... Like I said above, the wrong place though
to add the code to update-cache.
> > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > --- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
> > +++ uncommitted/show-diff.c
> > @@ -5,13 +5,18 @@
> > */
> > #include "cache.h"
> >
> > -static void show_differences(char *name,
> > +static void show_differences(struct cache_entry *ce,
> > void *old_contents, unsigned long long old_size)
> > {
> > static char cmd[1000];
> > + static char sha1[41];
> > + int n;
> > FILE *f;
> >
> > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
> > + for (n = 0; n < 20; n++)
> > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N
> > - %s",
> > + sha1, ce->name, ce->name, ce->name);
>
> The "directory" sha1 is the sha1 of the tree, not of the particular
> file - that one is in the "attributes" list (parentheses after the
> filename), together with mode.
>
Does it really matter? It is more just to
Plug memory leak in update-cache.c
Hi,
Might not be that an big an issue as it should be freed on exit, but
might cause problems with big trees.
Plug memory leak in update-cache.c.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
update-cache.c: 22f3ccd47db4f0888901109a8cbf883d272d1cba
--- 22f3ccd47db4f0888901109a8cbf883d272d1cba/update-cache.c
+++ uncommitted/update-cache.c
@@ -202,6 +202,7 @@
printf("%s: needs update\n", ce->name);
continue;
}
+ free(active_cache[i]);
active_cache[i] = new;
}
}
--
Martin Schlemmer
update-cache.c: 22f3ccd47db4f0888901109a8cbf883d272d1cba
--- 22f3ccd47db4f0888901109a8cbf883d272d1cba/update-cache.c
+++ uncommitted/update-cache.c
@@ -202,6 +202,7 @@
printf("%s: needs update\n", ce->name);
continue;
}
+ free(active_cache[i]);
active_cache[i] = new;
}
}
signature.asc
Description: This is a digitally signed message part
Re: Re: Re: Remove need to untrack before tracking new branch
On Thu, 2005-04-14 at 10:28 +0200, Martin Schlemmer wrote: > On Thu, 2005-04-14 at 08:55 +0200, Martin Schlemmer wrote: > > On Thu, 2005-04-14 at 00:19 +0200, Petr Baudis wrote: > > > Dear diary, on Wed, Apr 13, 2005 at 02:15:37PM CEST, I got a letter > > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > > On Wed, 2005-04-13 at 11:26 +0200, Petr Baudis wrote: > > > >> > Dear diary, on Wed, Apr 13, 2005 at 10:41:12AM CEST, I got a letter > > > > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > > > > On Wed, 2005-04-13 at 09:54 +0200, Petr Baudis wrote: > > > > > > PS: not having looked deeper yet, why does fsck-cache always find > > > > > > unreferenced blobs/commits (no matter what tree is tracked, they > > > > > > stay > > > > > > the same) ? And trying to remove them leads to more, which leads > > > > > > to an > > > > > > empty .git/opjects/ =) Also, leading to this, will adding an > > > > > > option to > > > > > > remove disconnected commits/blobs from local commits (that was > > > > > > disconnected with a pull) be a viable option to add? > > > > > > > > > > fsck-cache is concerned only by the objects database, so all the HEADs > > > > > are unreferenced commits too. This is a right thing, the HEAD tracking > > > > > should stay purely in the scripts - if we want to make fsck-cache > > > > > smarter about that, we should implement git fsck or something. > > > > > > > > > > Killing unreferenced blobs should be safe, I think. > > > > > > > > > > > First, about the 'git diff' thing I asked yesterday .. what I > > > > > > meant, was > > > > > > should it actually output this: > > > > > > > > > > > > > > > > > > COPYING: fe2a4177a760fd110e78788734f167bd633be8de 33 > > > > > > Makefile: 929aa49a3dbe683ad52094099797bc636a7949a6 33 > > > > > > README: 46c6a9ea48ddd1dda45ca585f49975a6869ffe51 33 > > > > > > ... > > > > > > > > > > > > > > > > > > Shouldn't it just show actual changes? > > > > > > > > > > This is an actual change. It's just that it's a change to metadata > > > > > (somewhat esotherically described by the "33"), not the file contents. > > > > > > > > > > BTW, git diff does actually something completely different from git > > > > > diff > > > > > with any arguments. It diffs to the directory cache, not to any tree! > > > > > It > > > > > just wraps show-diff, which has also a different output format (not > > > > > outputting "git diffs"). The worst thing is that it requires a > > > > > different > > > > > -p option to apply. Someone should purge this wart, I think. > > > > > > > > > > > > > Check applied patch (also in the new output). > > > > > > Please send patches inline and properly signed off. > > > > > > > The new evo have a bad habit of screwing the tabs, but sure. > > > > > > > > Also on the same note .. should 'git ci' without listed files to be > > > > > > committed, really add a reference to all files as it currently do > > > > > > in the > > > > > > commit/blob/whatever info, instead of just the changed/added files > > > > > > (see > > > > > > the git-seperate-dir.patch you have not yet commented on for > > > > > > reference)? > > > > > > > > > > ... > > > > > > > > > > > > > Patch will also resolve this. > > > > > > Your patch is bad - it removes the pure metadata changes, but you > > > definitively do not want to do that! If you are annoyed by meaningless > > > time changes etc, do update-cache --refresh. Ignoring mode changes is a > > > pure disaster. > > > > > > > Ahh - and there was light. I do not have a problem with the mode > > changes - its just _all_ files was shown after tracked branch was > > changed. How about below patch? > > > > > > > > I know its in its infancy,
Re: Re: Re: Remove need to untrack before tracking new branch
On Thu, 2005-04-14 at 08:55 +0200, Martin Schlemmer wrote: > On Thu, 2005-04-14 at 00:19 +0200, Petr Baudis wrote: > > Dear diary, on Wed, Apr 13, 2005 at 02:15:37PM CEST, I got a letter > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > On Wed, 2005-04-13 at 11:26 +0200, Petr Baudis wrote: > > >> > Dear diary, on Wed, Apr 13, 2005 at 10:41:12AM CEST, I got a letter > > > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > > > On Wed, 2005-04-13 at 09:54 +0200, Petr Baudis wrote: > > > > > PS: not having looked deeper yet, why does fsck-cache always find > > > > > unreferenced blobs/commits (no matter what tree is tracked, they stay > > > > > the same) ? And trying to remove them leads to more, which leads to > > > > > an > > > > > empty .git/opjects/ =) Also, leading to this, will adding an option > > > > > to > > > > > remove disconnected commits/blobs from local commits (that was > > > > > disconnected with a pull) be a viable option to add? > > > > > > > > fsck-cache is concerned only by the objects database, so all the HEADs > > > > are unreferenced commits too. This is a right thing, the HEAD tracking > > > > should stay purely in the scripts - if we want to make fsck-cache > > > > smarter about that, we should implement git fsck or something. > > > > > > > > Killing unreferenced blobs should be safe, I think. > > > > > > > > > First, about the 'git diff' thing I asked yesterday .. what I meant, > > > > > was > > > > > should it actually output this: > > > > > > > > > > > > > > > COPYING: fe2a4177a760fd110e78788734f167bd633be8de 33 > > > > > Makefile: 929aa49a3dbe683ad52094099797bc636a7949a6 33 > > > > > README: 46c6a9ea48ddd1dda45ca585f49975a6869ffe51 33 > > > > > ... > > > > > > > > > > > > > > > Shouldn't it just show actual changes? > > > > > > > > This is an actual change. It's just that it's a change to metadata > > > > (somewhat esotherically described by the "33"), not the file contents. > > > > > > > > BTW, git diff does actually something completely different from git diff > > > > with any arguments. It diffs to the directory cache, not to any tree! It > > > > just wraps show-diff, which has also a different output format (not > > > > outputting "git diffs"). The worst thing is that it requires a different > > > > -p option to apply. Someone should purge this wart, I think. > > > > > > > > > > Check applied patch (also in the new output). > > > > Please send patches inline and properly signed off. > > > > The new evo have a bad habit of screwing the tabs, but sure. > > > > > > Also on the same note .. should 'git ci' without listed files to be > > > > > committed, really add a reference to all files as it currently do in > > > > > the > > > > > commit/blob/whatever info, instead of just the changed/added files > > > > > (see > > > > > the git-seperate-dir.patch you have not yet commented on for > > > > > reference)? > > > > > > > > ... > > > > > > > > > > Patch will also resolve this. > > > > Your patch is bad - it removes the pure metadata changes, but you > > definitively do not want to do that! If you are annoyed by meaningless > > time changes etc, do update-cache --refresh. Ignoring mode changes is a > > pure disaster. > > > > Ahh - and there was light. I do not have a problem with the mode > changes - its just _all_ files was shown after tracked branch was > changed. How about below patch? > > > > > > I know its in its infancy, but I am not sure on what scm you are > > > > > basing > > > > > it, so not sure how things should behave. > > > > > > > > I'm trying to base it on common sense and principle of least surprise. > > > > :-) > > > > > > > > > > Ok, I'll just bug you then if I am not sure on how you want something ;p > > > > Or do it somehow and I'll bug you back if I don't like it. ;-) > > > > Ditto > > > > > Normalize show-diff o
Re: Re: Re: Remove need to untrack before tracking new branch
On Thu, 2005-04-14 at 00:19 +0200, Petr Baudis wrote: > Dear diary, on Wed, Apr 13, 2005 at 02:15:37PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > On Wed, 2005-04-13 at 11:26 +0200, Petr Baudis wrote: > >> > Dear diary, on Wed, Apr 13, 2005 at 10:41:12AM CEST, I got a letter > > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > > On Wed, 2005-04-13 at 09:54 +0200, Petr Baudis wrote: > > > > PS: not having looked deeper yet, why does fsck-cache always find > > > > unreferenced blobs/commits (no matter what tree is tracked, they stay > > > > the same) ? And trying to remove them leads to more, which leads to an > > > > empty .git/opjects/ =) Also, leading to this, will adding an option to > > > > remove disconnected commits/blobs from local commits (that was > > > > disconnected with a pull) be a viable option to add? > > > > > > fsck-cache is concerned only by the objects database, so all the HEADs > > > are unreferenced commits too. This is a right thing, the HEAD tracking > > > should stay purely in the scripts - if we want to make fsck-cache > > > smarter about that, we should implement git fsck or something. > > > > > > Killing unreferenced blobs should be safe, I think. > > > > > > > First, about the 'git diff' thing I asked yesterday .. what I meant, was > > > > should it actually output this: > > > > > > > > > > > > COPYING: fe2a4177a760fd110e78788734f167bd633be8de 33 > > > > Makefile: 929aa49a3dbe683ad52094099797bc636a7949a6 33 > > > > README: 46c6a9ea48ddd1dda45ca585f49975a6869ffe51 33 > > > > ... > > > > > > > > > > > > Shouldn't it just show actual changes? > > > > > > This is an actual change. It's just that it's a change to metadata > > > (somewhat esotherically described by the "33"), not the file contents. > > > > > > BTW, git diff does actually something completely different from git diff > > > with any arguments. It diffs to the directory cache, not to any tree! It > > > just wraps show-diff, which has also a different output format (not > > > outputting "git diffs"). The worst thing is that it requires a different > > > -p option to apply. Someone should purge this wart, I think. > > > > > > > Check applied patch (also in the new output). > > Please send patches inline and properly signed off. > The new evo have a bad habit of screwing the tabs, but sure. > > > > Also on the same note .. should 'git ci' without listed files to be > > > > committed, really add a reference to all files as it currently do in the > > > > commit/blob/whatever info, instead of just the changed/added files (see > > > > the git-seperate-dir.patch you have not yet commented on for reference)? > > > > > > ... > > > > > > > Patch will also resolve this. > > Your patch is bad - it removes the pure metadata changes, but you > definitively do not want to do that! If you are annoyed by meaningless > time changes etc, do update-cache --refresh. Ignoring mode changes is a > pure disaster. > Ahh - and there was light. I do not have a problem with the mode changes - its just _all_ files was shown after tracked branch was changed. How about below patch? > > > > I know its in its infancy, but I am not sure on what scm you are basing > > > > it, so not sure how things should behave. > > > > > > I'm trying to base it on common sense and principle of least surprise. > > > :-) > > > > > > > Ok, I'll just bug you then if I am not sure on how you want something ;p > > Or do it somehow and I'll bug you back if I don't like it. ;-) > Ditto Normalize show-diff output and make sure we only show real changes after changing the tracked branch. Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]> gittrack.sh: a9d7c3d117390787e562a0450deb14c7cbf4b565 33 --- a9d7c3d117390787e562a0450deb14c7cbf4b565/gittrack.sh +++ uncommitted/gittrack.sh @@ -49,6 +49,7 @@ read-tree $(tree-id "$name") gitdiff.sh local "$name" | gitapply.sh + update-cache --refresh else [ "$tracking" ] || \ @@ -59,6 +60,7 @@ if [ -s ".git/HEAD.local" ]; then gitdiff.sh "$tracking" local | gitapply.sh read-tree $(tree-id local) + upd
