git-ls-new-files & make patch, pull, etc.

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.

I've also found it useful to start adding things to the Makefile's of the projects I'm putting in git repositories. I think it would be useful to come up with some standard or recommended names. That could start to extend the common "make" "make install" with a few other options for projects that use git as their SCM.

Thanks,
Jeff

patch:
git-diff-files -p

push:
git-send-pack cat .git/branches/origin

pull:
git-pull-script cat .git/branches/origin git-read-tree -m HEAD git-checkout-cache -q -f -u -a

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

add_all:

	./git-ls-new-files |xargs -n 1 git-update-cache --add

#!/usr/bin/perl

# Shows you what files have not been added to your git repository

my %allfiles;

# make a hash of all the files except the .git/ directory

foreach my $file ( `find . -type f` ) {
	chomp $file;
	next if substr($file, 0, 7) eq "./.git/";
	$allfiles{ $file } = "";
}

# now delete all the files from the hash that are already commited

foreach my $file ( split "\n", `git-ls-files` ) {
	chomp $file;
	delete $allfiles{ "./$file" };
}

# print out what's left

foreach my $file ( sort keys %allfiles ) {
	print "$file\n";
}

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

Hi,

"git diff"

"git push origin" (or maybe "git push HEAD:origin")

"git pull origin"

"git commit"

"git add $(git ls-files --others)"

Ciao,
Dscho

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

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;
	}
}

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.

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.

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