Re: git-ls-new-files & make patch, pull, etc.
In my opinion, setting the file timestamp to the commit time (or any other time other than the time of checkout) tends to screw you up more than help you. Suppose you have the latest checked out in your working tree, you build and test, and find regressions. You'd want to check out from an older commit, rebuild and make sure things used to work correctly. If the checkout used the timestamp of the older commit, however, all the things you built from the latest would have timestamps newer than the source, so you would end up always having to run "make clean" before rebuilding. - 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
Re: git-ls-new-files & make patch, pull, etc.
On 09/06/2005 02:08 PM, Junio C Hamano wrote:
> Jeff Carr <[EMAIL PROTECTED]> writes:
>
>
>>... If I remember
>>correctly, there was some threads at the beginning of git about how
>>datestamps were not accurate so there was no point in setting them(?) Or
>>maybe I mis-understood.
>
>
> The point of those thread was that clocks on machines tend to be
> not so accurate and we should not take the timestamps *too*
> seriously. We do record the time as accurately as the clock is
> maintained on the machine the commit is made, provided if the
> user does not override it with the GIT_COMMIT_DATE environment
> variable with a bogus value.
>
> The way you use it to show changes made in a certain timeperiod
> is a good example that the information is useful. The argument
> against relying on timestamp too much in that thread you are
> remembering was that it should not be used to see which commit
> came before which other commit when there is no parent-child
> ancestry between them. It is still a useful hint, and we do use
> it as such, but as the recent merge-base fixes show it is just a
> hint and relying on it too much tends to screw things up.
OK, I understand better now. I was just setting the mtime via the last
time the file showed up in the git-whatchanged output. When I check out
a repository I do:
git-read-tree -m HEAD && git-checkout-cache -q -f -u -a
git-restore-mtime
This is probably also a really bad reimplementation of something. :)
All and all, really enjoying using git. It's better.
Jeff
#!/usr/bin/perl
# parses git-whatchanged output and then
# sets the mtime for all the files # copyleft GPL
use strict;
use HTTP::Date;
# my $string = time2str($time);# Format as GMT ASCII time
# my $now = str2time($string);# convert ASCII date to machine time
my $oldest = localtime();
my %allfiles;
my $time;
# make a hash of all the files
foreach my $file ( split "\n", `git-ls-files` ) {
chomp $file;
$allfiles{ $file } = 0;
}
# get the newest mtime for each one
foreach my $line ( `git-whatchanged` ) {
chomp $line;
my @parts = split " ", $line;
if( $parts[0] eq "Date:" ) {
shift @parts;
pop @parts;
$time = str2time( join " ", @parts );
next;
}
if( $line =~ /^:/ ) {
my $name = pop @parts;
if( $allfiles{ $name } lt $time ) {
# print "$name was $allfiles{ $name } now: $time\n";
$allfiles{ $name } = $time;
}
if( $time lt $oldest ) {
$oldest = $time;
}
}
}
# set the mtime for each one
foreach my $name ( sort keys %allfiles ) {
if ( $allfiles{$name} eq 0 ) {
# print "$name mtime $allfiles{$name}\n";
utime $oldest, $oldest, $name;
} else {
# print "$name mtime $allfiles{$name}\n";
utime $allfiles{$name}, $allfiles{$name}, $name;
}
}
Re: git-ls-new-files & make patch, pull, etc.
Jeff Carr <[EMAIL PROTECTED]> writes: > ... If I remember > correctly, there was some threads at the beginning of git about how > datestamps were not accurate so there was no point in setting them(?) Or > maybe I mis-understood. The point of those thread was that clocks on machines tend to be not so accurate and we should not take the timestamps *too* seriously. We do record the time as accurately as the clock is maintained on the machine the commit is made, provided if the user does not override it with the GIT_COMMIT_DATE environment variable with a bogus value. The way you use it to show changes made in a certain timeperiod is a good example that the information is useful. The argument against relying on timestamp too much in that thread you are remembering was that it should not be used to see which commit came before which other commit when there is no parent-child ancestry between them. It is still a useful hint, and we do use it as such, but as the recent merge-base fixes show it is just a hint and relying on it too much tends to screw things up. - 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
Re: git-ls-new-files & make patch, pull, etc.
On 08/22/2005 10:15 PM, Junio C Hamano wrote: > Jeff Carr <[EMAIL PROTECTED]> writes: > > >>Something simple like the perl script at the bottom would be useful for >>showing files that haven't been added via git-update-cache --add already. > > > If I am not mistaken, you just reinvented: > > $ git ls-files --others > > in a very expensive way. Notice your `find . -type f` that does > not prune .git directory upfront. > > Also you may want to take a look at: > > $ git ls-files --others --exclude-from=.git/info/exclude Yes, you are right -- I did reinvent the above poorly :) I also was using a perl script to parse the output of git-whatchanged to set the datestamps on the files to the last modified time. If I remember correctly, there was some threads at the beginning of git about how datestamps were not accurate so there was no point in setting them(?) Or maybe I mis-understood. In any case, sometimes it is useful for me because I just want to look at what files I changed today or yesterday or something to that effect. Sometimes in the kernel/Documentation directories it is useful because you can see what documentation was done/changed this year. Sometimes that's nice if you are looking for new things you might not know much about; recently I was digging around in the I2C stuff to try to figure out if I could read the right temperature sensor on the smbus on a machine. Anyway, I'll just use that but perhaps there is also a "correct" way to keep timestamps? BTW, for what it's worth, you can't package git under debian sarge because asciidoc doesn't support "-b xhtml11". I pulled it from sid and it packaged it fine. Just an FYI. I emailed the asciidoc maintainer for what it's worth. Thanks a lot, Jeff - 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
Re: git-ls-new-files & make patch, pull, etc.
On 08/22/2005 11:48 PM, Johannes Schindelin wrote: > >>patch: > > "git diff" > > >>push: > > "git push origin" (or maybe "git push HEAD:origin") > > >>pull: > > "git pull origin" > > >>commit: >> vi changelog.txt >> GIT_AUTHOR_NAME="$(GIT_AUTHOR_NAME)" \ >> GIT_AUTHOR_EMAIL="$(GIT_AUTHOR_EMAIL)" \ >> git-commit-tree `git-write-tree` -p $(HEAD) < changelog.txt > .git/HEAD >> rm changelog.txt > > > "git commit" Well, I did that by hand so at the end I could have it append the changes to a changelog file in the archive itself. >>add_all: >> ./git-ls-new-files |xargs -n 1 git-update-cache --add > > > "git add $(git ls-files --others)" I was using the version of git that was in debian sarge; it was too old and didn't do the commands. I've updated and everything is working now. Thanks for the help! Jeff - 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
Re: git-ls-new-files & make patch, pull, etc.
Hi, On Mon, 22 Aug 2005, Jeff Carr wrote: > patch: > git-diff-files -p "git diff" > push: > git-send-pack `cat .git/branches/origin` "git push origin" (or maybe "git push HEAD:origin") > pull: > git-pull-script `cat .git/branches/origin` > git-read-tree -m HEAD > git-checkout-cache -q -f -u -a "git pull origin" > commit: > vi changelog.txt > GIT_AUTHOR_NAME="$(GIT_AUTHOR_NAME)" \ > GIT_AUTHOR_EMAIL="$(GIT_AUTHOR_EMAIL)" \ > git-commit-tree `git-write-tree` -p $(HEAD) < changelog.txt > .git/HEAD > rm changelog.txt "git commit" > add_all: > ./git-ls-new-files |xargs -n 1 git-update-cache --add "git add $(git ls-files --others)" Ciao, Dscho - 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
Re: git-ls-new-files & make patch, pull, etc.
Jeff Carr <[EMAIL PROTECTED]> writes: > Something simple like the perl script at the bottom would be useful for > showing files that haven't been added via git-update-cache --add already. If I am not mistaken, you just reinvented: $ git ls-files --others in a very expensive way. Notice your `find . -type f` that does not prune .git directory upfront. Also you may want to take a look at: $ git ls-files --others --exclude-from=.git/info/exclude - 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
