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

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

[Jeff Carr]

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

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

[Junio C Hamano]

Jeff Carr <jcarr@linuxmachines.com> 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

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

[Johannes Schindelin]

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

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

[Jeff Carr]

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

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

[Jeff Carr]

On 08/22/2005 10:15 PM, Junio C Hamano wrote:
> Jeff Carr <jcarr@linuxmachines.com> 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

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

[Junio C Hamano]

Jeff Carr <jcarr@linuxmachines.com> 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.

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

[Jeff Carr]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On 09/06/2005 02:08 PM, Junio C Hamano wrote:
> Jeff Carr <jcarr@linuxmachines.com> 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

[-- Attachment #2: git_restore_mtime --]
[-- Type: text/plain, Size: 1206 bytes --]

#!/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.

[Junio C Hamano]

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.