* Re: unseeking?
From: Zack Brown @ 2005-04-24 21:38 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504241418190.30848-100000@iabervon.org>
On Sun, Apr 24, 2005 at 02:47:30PM -0400, Daniel Barkalow wrote:
> On Sun, 24 Apr 2005, Zack Brown wrote:
> > 4) In normal work-flow, when would forks be created, as opposed to other ways
> > of getting a tree?
>
> I have a tree that I want to modify, but I want to keep the original, and
> I may want to update the original from an upstream source (and then sync
> my work with it).
So why not just do 'git init URL' to get the upstream sources, make your edits,
do 'git pull' to track the upstream sources every once in awhile, and do 'git
diff' when you're ready to send your changes to the upstream maintainer.
I think I've understood your explanation of what's actually happening, but I
still don't see its significance. What do you get from a fork that you don't get
from a regular old init and pull?
Be well,
Zack
> I start with the original:
>
> cd original
> git init URL
> git addremote remote-source URL
> git track remote-source
>
> I make my own working directory:
>
> git fork my-changes ../my-changes
> cd ../my-changes
>
> Then I do my changes, and commit whenever I feel like I've gotten
> somewhere (or when I think I'm about to mess something up and might want
> to undo changes). Periodically, I check on the mainline:
>
> cd ../original
> git pull
>
> I also merge changes from the mainline:
>
> cd ../my-changes
> git merge remote-source
>
> When I'm done, I make a patch for my work:
>
> cd ../my-changes
> git patch remote-source
>
> I generally then fork the original again, split the patch, apply each
> section in the new fork, committing after each one, generate patches for
> each of these commits, and send those out. Then I discard my old branch
> and continue from the new one. If, at some point, all of the changes I
> want to keep have been put into the mainline, I discard all my branches
> and fork again from the mainline.
>
> (My personal style is to discard the history of how the changes got made
> in favor of the history of how the changes got into the mainline, since I
> don't really need to keep all of my debugged mistakes that nobody else
> saw.)
>
> -Daniel
> *This .sig left intentionally blank*
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] git rm -- recursive directories
From: Junio C Hamano @ 2005-04-24 21:34 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: git
In-Reply-To: <200504241709.05689.jcorbin@wunjo.org>
Why not also make add non recursive by default and give -r
option when you want recursive?
^ permalink raw reply
* Re: Hash collision count
From: Imre Simon @ 2005-04-24 21:24 UTC (permalink / raw)
To: Jeff Garzik
Cc: Petr Baudis, Ray Heasman, Git Mailing List, Linus Torvalds,
Imre Simon
In-Reply-To: <426AEBAE.1060402@pobox.com>
On 4/23/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> Petr Baudis wrote:
> > -DCOLLISION_CHECK
>
> Cool. I am happy, then :)
>
> Make sure that's enabled by default...
>
> Thanks,
>
> Jeff
I would like to second the suggestion that this should be enabled by default.
First, I do think it is highly unlikely that a collision will ever be
found. Actually because of this if one is found it would be an
important byproduct of git and it would probably influence future
system designs. Hence, I believe that it is worth loosing some
efficiency in order to illuminate better this question of the
collision.
I would like to add a reciepe by which one would surely produce a
collision with two files of the same length and quite similar to each
other. I believe that there is a popular belief that this is pretty
much impossible. Of course, we do not have time to execute this
algorithm, but I believe that it convinces everyone that similar files
*do* exist (actually in abundance) with the same hash.
1. Take your favorite text file, at least 160 characters long.
2. Choose 160 positions in this file.
3. For each position choose your favorite mispelling of that character.
4. Produce all 2^160 text files, all of the same length, choosing for
each position either the original or the alternate character
5. Add an arbitrary file of the same length, different from the above
Two of these files have the same sha1 hash. Or, for that matter, for
any 160 bit hash the same is true.
Cheers, Imre Simon
^ permalink raw reply
* Re: [FILE] Docs update
From: Junio C Hamano @ 2005-04-24 21:23 UTC (permalink / raw)
To: David Greaves; +Cc: Petr Baudis, Linus Torvalds, GIT Mailing Lists
In-Reply-To: <426BF790.9070406@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
Looking much better than before.
DG> ################################################################
DG> commit-tree
DG> commit-tree <tree> [-p <parent tree>]* < changelog
DG> Options
DG> ...
DG> -p <parent tree>
DG> Each -p indicates a the id of a parent commit object.
Just for consistency:
commit-tree <tree> [-p <parent commit>]* < changelog
-p <parent commit>
DG> ################################################################
DG> git-export
DG> git-export top [base]
DG> probably deprecated:
DG> ...
DG> Although in Linus' distribution show-diff is not part of 'core' git.
Perhaps:
Although in Linus' distribution, git-export is not part of 'core' git.
DG> ################################################################
DG> merge-base
DG> merge-base <commit> <commit>
DG> ...
DG> It essentially returns either A or B randomly.
You may want to check this with Daniel Barkalow; the commit ID
0345fb64d68ba9e1e853c0ee9526fa93c45a67f9 is the latest one that
touches merge-base.c which has an extensive rework [*1*].
DG> ################################################################
DG> merge-cache
DG> merge-cache <merge-program> (-a | -- | <file>*)
DG> Typically this is run with the a script calling the merge command from
DG> the RCS package.
DG> Example script:
Drop example script and refer the reader to git-merge-one-file-script.
The one you attached is already old and missing the last three
parameter.
Addition before rev-tree:
rev-list <commit>
Lists commit objects in reverse chronological order starting
at the given commit, taking ancestry relationship into
account. This is useful to produce human-readable log output.
DG> ################################################################
DG> show-diff
DG> show-diff [-R] [-q] [-s] [-z] [paths...]
DG> Shows the difference between the version of the specified file on disk
DG> and the file in the cache.
DG> -R
DG> Reverse the diff
DG> -q
DG> Reduce verbosity
This flag means "Do not complain on non-existent files (i.e. a
dircache entry is found but corresponding file is not in the
working tree).
DG> -s
DG> Remain silent even on nonexisting files (forces -q)
This flag means "Do not show the diff text. Just output SHA1
and name for changed paths." You are correct that this implies -q.
DG> -z
DG> Machine readable (including \0 line termination on output)
This flag changes the behaviour of the program in number of
subtle ways for script consumption:
-z
Machine readable.
. Each output record has the path name at the end of the
record, instead of the front.
. Each record is terminated with a NUL '\0' character.
. For unchanged files, nothing is output.
. For an unmerged file, the following is output:
U name
. For a deleted file, the following is output:
X name
. For a modified file, the following is output:
SHA1 name
where SHA1 is from the dircache entry.
DG> Although in Linus' distribution show-diff is not part of 'core' git.
Perhaps:
Although in Linus' distribution, show-diff is not part of 'core' git.
[Footnotes]
*1* Here is the jit-trackdown script to help you find out this
kind of thing. Sample usage:
$ jit-trackdown $(cat .git/heads/linus) merge-base.c
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cat >jit-trackdown <<\EOF
#!/bin/sh
# Usage: jit-trackdown <commit> paths...
tmp=.jit-trackdown.$$
hits=$tmp-hits
trap 'rm -f $tmp-*' 0 1 2 3 15
tty -s || to_tty=:
head="$1"
shift
rev-list "$head" |
while read commit
do
for p in $(cat-file commit "$commit" | sed -ne 's/^parent //p;/^$/q')
do
$to_tty echo >&2 -n .
diff-tree -r -z "$p" "$commit" "$@" | jit-diff-tree-helper "$@" >$hits
test -s "$hits" || continue;
{
$to_tty echo >&2
echo "commit $commit"
cat-file commit "$commit"
echo
cat "$hits"
} | ${PAGER-less}
case "$to_tty" in
'')
echo >&2 -n "Dig further [Y/n]? "
read next </dev/tty
case "$next" in
[nN]) exit 0 ;;
esac
esac
done
done
$to_tty echo >&2
EOF
cat >jit-diff-tree-helper <<\EOF
#!/usr/bin/perl -w
use strict;
use File::Temp qw(mkstemp);
use Getopt::Long;
my $reverse_diff;
GetOptions('reverse' => \$reverse_diff)
or die "usage: $0 [ --reverse ] [paths...]";
sub cat_file {
my ($sha1, $file) = @_;
unless (defined $sha1) {
return (0, "/dev/null");
}
if ($sha1 =~ /^0{40}$/) {
return (0, $file);
}
local $/; # slurp mode
open I, "-|", "cat-file", "blob", $sha1
or die "$0: cannot read $sha1";
my ($o, $filename) = mkstemp(",,jit-diff-tree-helperXXXXXX");
print $o join("",<I>);
close I
or die "$0: closing cat-file pipe from $sha1";
close $o
or die "$0: closing write fd to $filename";
return (1, $filename);
}
$/ = "\0";
my $rM = "[0-7]+";
my $rI = "[0-9a-f]{40}";
while (<STDIN>) {
my ($old, $new, $file, $o_is_temp, $n_is_temp);
chomp;
if (/^\+$rM\tblob\t($rI)\t(.*)$/os) {
($old, $new, $file) = (undef, $1, $2);
}
elsif (/^-$rM\tblob\t($rI)\t(.*)$/os) {
($old, $new, $file) = ($1, undef, $2);
}
elsif (/^\*$rM->$rM\tblob\t($rI)->($rI)\t(.*)$/os) {
($old, $new, $file) = ($1, $2, $3);
}
else {
chomp;
print STDERR "warning: $0: ignoring $_\n";
next;
}
if (@ARGV) {
my $matches = 0;
for (@ARGV) {
my $l = length($_);
if ($file eq $_ ||
(substr($file, 0, $l) eq $_ &&
substr($file, $l, 1) eq "/")) {
$matches = 1;
last;
}
}
next unless $matches;
}
($o_is_temp, $old) = cat_file $old, $file;
($n_is_temp, $new) = cat_file $new, $file;
my @a = ($reverse_diff) ? ($new, $old) : ($old, $new);
system "diff", "-L", "k/$file", "-L", "l/$file", "-pu", @a;
unlink $old if ($o_is_temp);
unlink $new if ($n_is_temp);
}
EOF
chmod +x jit-trackdown jit-diff-tree-helper
^ permalink raw reply
* Re: fsck-cache problem
From: Linus Torvalds @ 2005-04-24 21:24 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc0504231855145c10a5@mail.gmail.com>
On Sat, 23 Apr 2005, Morten Welinder wrote:
>
> That "(null)" is not from git, but from glibc in response to NULL
> passed for %s.
Fixed.
The object library set the types for tree/commit objects only when they
_parsed_ them, resulting in objects that were never parsed (because they
weren't found - because you hadn't gotten them downloaded yet) never
having their type set.
Linus
^ permalink raw reply
* Re: [RFC] Design of name-addressed data portion
From: Daniel Barkalow @ 2005-04-24 21:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Linus Torvalds
In-Reply-To: <20050424205438.GN1507@pasky.ji.cz>
On Sun, 24 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > I'd propose the following structure:
> >
> > objects/ the content-addressed repository portion
> > references/ the name-addressed repository portion
>
> references/ is just too long for my taste. ;-) What about just refs/ ?
Fine with me. I guess you can't just hit tab when writing a script. :)
> > heads/ the heads that are being used out of this repository
> > DEFAULT the head that people pulling this repository mean by default
> > ... other heads, by name, that fsck-cache should mark reachable
> > tags/ the tags
> > ... files with the symbolic name of the tags, containing the hash
> > info/ other per-repository information
> > remotes URLs of remote repositories
> > complete hashes that the repository contains all references from
> > missing hashes that the repository lacks but wants
> > excluded hashes that the repository doesn't want
> > ... other files are per .git directory, not shared on push/pull
> > index
> > HEAD symlink to the head that is the local default
> > tracked remote that this working directory tracks
>
> I will probably throw the local stuff to local/.
That seems to encourage confusion with the local/remote repository
contrast. I think branch/ or fork/ would be more clear. Putting it in a
directory doesn't seem so important to me, since it won't be shared
anyway. (The reason I want info/ is so that you just symlink info/ to the
master info/, and you don't have to remember to make a link for each
file).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git rm -- recursive directories
From: Joshua T. Corbin @ 2005-04-24 21:09 UTC (permalink / raw)
To: git
After posting the previous patch, I realized it made sense, to me at least ;),
to have git rm work the same way. Same idea as my previous patch except this
time the recursion is off by default, must pass -r.
Signed-off-by: Joshua T. Corbin <jcorbin@wunjo.org>
Index: git
===================================================================
--- be4029f0225729bd52a08ac39214264247e1d319/git (mode:100755
sha1:24d8c30383fa11d049aafcd659cefe700afe1cf1)
+++ e925e99aef139d50acc11d906be86809f3a08bcb/git (mode:100755
sha1:3928887f010454a41853b8a836e1b87eeb0aaf51)
@@ -42,7 +42,7 @@
merge [-c] [-b BASE_ID] FROM_ID
patch [COMMIT_ID | COMMIT_ID:COMMIT_ID]
pull [RNAME]
- rm FILE...
+ rm [-r] FILE...
seek [COMMIT_ID]
status
tag TNAME [COMMIT_ID]
Index: gitrm.sh
===================================================================
--- be4029f0225729bd52a08ac39214264247e1d319/gitrm.sh (mode:100755
sha1:3cc50fb9f12d2bf93a285ea18daadca7d3f5b549)
+++ e925e99aef139d50acc11d906be86809f3a08bcb/gitrm.sh (mode:100755
sha1:236261a53fdce287d32b40b8baf46c338515e555)
@@ -5,11 +5,36 @@
#
# Takes a list of file names at the command line, and schedules them
# for removal from the GIT repository at the next commit.
+# Optional "-r" parameter specifies that you don't want to remove directories
+# recursively.
if [ ! "$1" ]; then
echo "gitrm.sh: usage: git rm FILE..." >&2
exit 1;
fi
-rm -f "$@"
-update-cache --remove -- "$@"
+recur=
+if [ "$1" = "-r" ]; then
+ shift
+ recur=1
+fi
+
+if [ $recur ]; then
+ RMFILE=$(mktemp -t gitrm.XXXXXX)
+ RMDIRS=
+ while [ "$1" ]; do
+ if [ -d "$1" ]; then
+ RMDIRS="$DIRS $1"
+ find $1 -type f -and -not -name '.*'
+ else
+ echo "$1"
+ fi
+ shift
+ done > $RMFILE
+ rm -f $(cat $RMFILE)
+ rmdir $(find $RMDIRS -depth -type d)
+ update-cache --remove -- $(cat $RMFILE)
+else
+ rm -f "$@"
+ update-cache --remove -- "$@"
+fi
^ permalink raw reply
* Re: [RFC] Design of name-addressed data portion
From: Petr Baudis @ 2005-04-24 20:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0504241336250.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> It would be useful to have a bit more structure to the repository, such
> that there are a fixed number of paths that hold all of the information
> about the state of the repository, while the rest of the directory has
> information that is particular to a working directory's state (e.g.,
> index).
Agreed.
>
>
> I'd propose the following structure:
>
> objects/ the content-addressed repository portion
> references/ the name-addressed repository portion
references/ is just too long for my taste. ;-) What about just refs/ ?
> heads/ the heads that are being used out of this repository
> DEFAULT the head that people pulling this repository mean by default
> ... other heads, by name, that fsck-cache should mark reachable
> tags/ the tags
> ... files with the symbolic name of the tags, containing the hash
> info/ other per-repository information
> remotes URLs of remote repositories
> complete hashes that the repository contains all references from
> missing hashes that the repository lacks but wants
> excluded hashes that the repository doesn't want
> ... other files are per .git directory, not shared on push/pull
> index
> HEAD symlink to the head that is the local default
> tracked remote that this working directory tracks
I will probably throw the local stuff to local/.
I think I like this otherwise.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH] git add - recursive directories
From: Joshua T. Corbin @ 2005-04-24 20:51 UTC (permalink / raw)
To: git
This patch does two things:
1) git add will now by default recursively add any directories given to it.
2) this can be disabled and the old behavior used instead with the new -n
switch.
Signed-off-by: Joshua T. Corbin <jcorbin@wunjo.org>
Index: git
===================================================================
--- 2aaf94eae20acc451553766f3c063bc46cfa75c6/git (mode:100755
sha1:f8f5e0e4e5c50102415cd479619dd7598d3c42e1)
+++ 58dd789846677d8d0848b608e365e9742d2db642/git (mode:100755
sha1:24d8c30383fa11d049aafcd659cefe700afe1cf1)
@@ -25,7 +25,7 @@
Usage: git COMMAND [ARG]...
Available commands:
- add FILE...
+ add [-n] FILE...
addremote RNAME RSYNC_URL
apply < patch on stdin
cancel
Index: gitadd.sh
===================================================================
--- 2aaf94eae20acc451553766f3c063bc46cfa75c6/gitadd.sh (mode:100755
sha1:fa77d96198dd7d5ebf47bdedb296995ab7e77cf3)
+++ 58dd789846677d8d0848b608e365e9742d2db642/gitadd.sh (mode:100755
sha1:f0b030e1b4d770d96dabd5350e25f2e8fad5e59d)
@@ -5,10 +5,31 @@
#
# Takes a list of file names at the command line, and schedules them
# for addition to the GIT repository at the next commit.
+# Optional "-n" parameter specifies that you don't want to add directories
+# recursively.
if [ ! "$1" ]; then
- echo "gitadd.sh: usage: git add FILE..." >&2
+ echo "gitadd.sh: usage: git add [-n] FILE..." >&2
exit 1;
fi
-update-cache --add -- "$@"
+recur=1
+if [ "$1" = "-n" ]; then
+ shift
+ recur=
+fi
+
+if [ $recur ]; then
+ ADDFILE=$(mktemp -t gitadd.XXXXXX)
+ while [ "$1" ]; do
+ if [ -d "$1" ]; then
+ find $1 -type f -and -not -name '.*'
+ else
+ echo "$1"
+ fi
+ shift
+ done > $ADDFILE
+ update-cache --add -- $(cat $ADDFILE)
+else
+ update-cache --add -- "$@"
+fi
^ permalink raw reply
* Re: Humble request of 'git' developers
From: Petr Baudis @ 2005-04-24 20:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <426AA8E2.60403@pobox.com>
Dear diary, on Sat, Apr 23, 2005 at 09:58:26PM CEST, I got a letter
where Jeff Garzik <jgarzik@pobox.com> told me that...
> Please stop filling up my /usr/local/bin :)
>
> Just have one 'git' script, which looks in /usr/local/libexec/git for
> further scripts and backends programs like write-tree and diff-cache.
Ad core git, yes, one of the reasons why I decided for the Cogito rename
was to free the "git namesace" for the git programs. :-)
> Also, please don't assume that "." is in PATH. I think there is at
> least one invocation of commit-id with that assumption, in git-pasky-0.6.3.
Yes, sorry, fixed and pushed out.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] updates for git-pull-script
From: James Bottomley @ 2005-04-24 19:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504241045260.15879@ppc970.osdl.org>
On Sun, 2005-04-24 at 10:49 -0700, Linus Torvalds wrote:
> I don't think anybody preferes the original behaviour - the reason
> git-pull-script punted with any non-trivial merge was that when I wrote
> the damn thing, I was still just testing out the merges, and I definitely
> didn't trust the automated script.
Well ... I kept checking it against BK for a while ... however it seems
to do the right thing, so I've been happy ...
> However, when you remove the "checkout-cache -f -a" thing, it means that
> you are leaving all teh checked-out files in a state where it's _very_
> easy to mess up later, and doign so silently really is very bad.
Yes ... I really want the BK behaviour back where it would abort the
update if a change has to be made to a file that I've already touched.
I'm still thinking about how best to do this
> So at the _very_ least you should do an "update-cache --refresh", and
> _tell_ the user about the files that are checked-out but not up-to-date.
>
> And it really sounds like the whole and only reason you don't like
> checkout-cache is that you normally work with an empty tree, so I actually
> think that the _right_ answer for you is to add a new flag to
> "checkout-cache" that only updates files that already exist. Something
> like "-n" for "don't create new files".
OK, look over the attached. I added the -n option to checkout-cache and
an --ignore-missing to update-cache. Now if I add
checkout-cache -n -f -a && update-cache --ignore-missing --refresh
it should do the right thing.
James
checkout-cache.c: f65be62b4abad184bd755884fb72681fc28c8b3b
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -34,7 +34,7 @@
*/
#include "cache.h"
-static int force = 0, quiet = 0;
+static int force = 0, quiet = 0, not_new = 0;
static void create_directories(const char *path)
{
@@ -118,7 +118,8 @@ static int checkout_entry(struct cache_e
* just do the right thing)
*/
unlink(path);
- }
+ } else if (not_new)
+ return 0;
return write_entry(ce, path);
}
@@ -182,6 +183,10 @@ int main(int argc, char **argv)
quiet = 1;
continue;
}
+ if (!strcmp(arg, "-n")) {
+ not_new = 1;
+ continue;
+ }
if (!memcmp(arg, "--prefix=", 9)) {
base_dir = arg+9;
continue;
update-cache.c: 4353b80890ba2afbe22248a4dc25060aa4a429b2
--- a/update-cache.c
+++ b/update-cache.c
@@ -12,7 +12,23 @@
* like "update-cache *" and suddenly having all the object
* files be revision controlled.
*/
-static int allow_add = 0, allow_remove = 0;
+static int allow_add = 0, allow_remove = 0, not_new = 0;
+
+/* Three functions to allow overloaded pointer return; see linux/err.h */
+static inline void *ERR_PTR(long error)
+{
+ return (void *) error;
+}
+
+static inline long PTR_ERR(const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline long IS_ERR(const void *ptr)
+{
+ return (unsigned long)ptr > (unsigned long)-1000L;
+}
static int index_fd(unsigned char *sha1, int fd, struct stat *st)
{
@@ -172,7 +188,7 @@ static struct cache_entry *refresh_entry
int changed, size;
if (stat(ce->name, &st) < 0)
- return NULL;
+ return ERR_PTR(-errno);
changed = cache_match_stat(ce, &st);
if (!changed)
@@ -183,10 +199,10 @@ static struct cache_entry *refresh_entry
* to refresh the entry - it's not going to match
*/
if (changed & MODE_CHANGED)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (compare_data(ce, st.st_size))
- return NULL;
+ return ERR_PTR(-EINVAL);
size = ce_size(ce);
updated = malloc(size);
@@ -212,8 +228,9 @@ static void refresh_cache(void)
}
new = refresh_entry(ce);
- if (!new) {
- printf("%s: needs update\n", ce->name);
+ if (IS_ERR(new)) {
+ if (!(not_new && PTR_ERR(new) == -ENOENT))
+ printf("%s: needs update\n", ce->name);
continue;
}
active_cache[i] = new;
@@ -328,6 +345,10 @@ int main(int argc, char **argv)
i += 3;
continue;
}
+ if (!strcmp(path, "--ignore-missing")) {
+ not_new = 1;
+ continue;
+ }
die("unknown option %s", path);
}
if (!verify_path(path)) {
^ permalink raw reply
* Re: Old "sparse" archive converted..
From: Linus Torvalds @ 2005-04-24 19:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: sparse mailing list, Git Mailing List
In-Reply-To: <426B2D82.5000906@pobox.com>
On Sun, 24 Apr 2005, Jeff Garzik wrote:
>
> Any chance you could copy it to
>
> /pub/scm/linux/kernel/git/torvalds/sparse.git
Done.
Linus
^ permalink raw reply
* [FILE] Docs update
From: David Greaves @ 2005-04-24 19:46 UTC (permalink / raw)
To: Petr Baudis, Linus Torvalds; +Cc: GIT Mailing Lists
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Now contains strawman reference documentation for all the core git commands
It would probably be a good idea for people who know what's going on to
validate these docs lest the partially sighted author unwittingly leads
too many potential gitters over conceptual cliffs...
And I've attached this as a file rather than a patch to make it easier
for people to read.
Signed-off-by: David Greaves <david@dgreaves.com>
---
[-- Attachment #2: README.reference --]
[-- Type: text/plain, Size: 31282 bytes --]
This file contains reference information for the core git commands.
It is actually based on the source from Petr Baudis' tree and may
therefore contain a few 'extras' that may or may not make it upstream.
The README contains much useful definition and clarification info -
read that first. And of the commands, I suggest reading
'update-cache' and 'read-tree' first - I wish I had!
David Greaves - 24/4/05
Identifier terminology used:
<object>
Indicates any object sha1 identifier
<blob>
Indicates a blob object sha1 identifier
<tree>
Indicates a tree object sha1 identifier
<commit>
Indicates a commit object sha1 identifier
<tree/commit>
Indicates a tree or commit object sha1 identifier (usually
because the command can read the <tree> a <commit> contains).
[Eventually may be replaced with <tree> if <tree> means
<tree/commit> in all commands]
<type>
Indicates that an object type is required.
Currently one of: blob/tree/commit
<file>
Indicates a filename - often includes leading path
<path>
Indicates the path of a file (is this ever useful?)
################################################################
cat-file
cat-file (-t | <type>) <object>
Provide contents or type of objects in the repository. The type is
required if -t is not being used to find the object type.
<object>
The sha1 identifier of the object.
-t
show the object type identified by <object>
<type>
One of: blob/tree/commit
Output
If -t is specified, one of:
blob/tree/commit
Otherwise the raw (though uncompressed) contents of the <object> will
be returned.
################################################################
check-files
check-files <file>...
Check that a list of files are up-to-date between the filesystem and
the cache. Used to verify a patch target before doing a patch.
Files that do not exist on the filesystem are considered up-to-date
(whether or not they are in the cache).
Emits an error message on failure.
preparing to update existing file <file> not in cache
<file> exists but is not in the cache
preparing to update file <file> not uptodate in cache
<file> on disk is not up-to-date with the cache
exits with a status code indicating success if all files are
up-to-date.
see also: update-cache
################################################################
checkout-cache
checkout-cache [-q] [-a] [-f] [--prefix=<string>] [--] <file>...
Will copy all files listed from the cache to the working directory
(not overwriting existing files). Note that the file contents are
restored - NOT the file permissions.
-q
be quiet if files exist or are not in the cache
-f
forces overwrite of existing files
-a
checks out all files in the cache (will then continue to
process listed files).
--prefix=<string>
When creating files, prepend <string> (usually a directory
including a trailing /)
--
Do not interpret any more arguments as options.
Note that the order of the flags matters:
checkout-cache -a -f file.c
will first check out all files listed in the cache (but not overwrite
any old ones), and then force-checkout file.c a second time (ie that
one _will_ overwrite any old contents with the same filename).
Also, just doing "checkout-cache" does nothing. You probably meant
"checkout-cache -a". And if you want to force it, you want
"checkout-cache -f -a".
Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" thing is that from scripts you are
supposed to be able to do things like
find . -name '*.h' -print0 | xargs -0 checkout-cache -f --
which will force all existing *.h files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the cache, which was not the point.
Oh, and the "--" is just a good idea when you know the rest will be
filenames. Just so that you wouldn't have a filename of "-a" causing
problems (not possible in the above example, but get used to it in
scripting!).
The prefix ability basically makes it trivial to use checkout-cache as
a "export as tree" function. Just read the desired tree into the
index, and do a
checkout-cache --prefix=export-dir/ -a
and checkout-cache will "export" the cache into the specified
directory.
NOTE! The final "/" is important. The exported name is literally just
prefixed with the specified string, so you can also do something like
checkout-cache --prefix=.merged- Makefile
to check out the currently cached copy of "Makefile" into the file
".merged-Makefile".
################################################################
commit-tree
commit-tree <tree> [-p <parent tree>]* < changelog
Creates a new commit object based on the provided tree object and
emits the new commit object id on stdout. If no parent is given then
it is considered to be an initial tree.
A commit object usually has 1 parent (a commit after a change) or up
to 16 parents. More than one parent represents merge of branches that
led to them.
While a tree represents a particular directory state of a working
directory, a commit represents that state in "time", and explains how
to get there.
Normally a commit would identify a new "HEAD" state, and while git
doesn't care where you save the note about that state, in practice we
tend to just write the result to the file ".git/HEAD", so that we can
always see what the last committed state was.
Options
<tree>
An existing tree object
-p <parent tree>
Each -p indicates a the id of a parent commit object.
Commit Information
A commit encapsulates:
all parent object ids
author name, email and date
committer name and email and the commit time.
If not provided, commit-tree uses your name, hostname and domain to
provide author and committer info. This can be overridden using the
following environment variables.
AUTHOR_NAME
AUTHOR_EMAIL
AUTHOR_DATE
COMMIT_AUTHOR_NAME
COMMIT_AUTHOR_EMAIL
(nb <,> and '\n's are stripped)
A commit comment is read from stdin (max 999 chars). If a changelog
entry is not provided via '<' redirection, commit-tree will just wait
for one to be entered and terminated with ^D
see also: write-tree
################################################################
diff-cache
diff-cache [-r] [-z] [--cached] <tree/commit>
Compares the content and mode of the blobs found via a tree object
with the content of the current cache and, optionally ignoring the
stat state of the file on disk.
(This is basically a special case of diff-tree that works with the
current cache as the first tree.)
<tree/commit>
The id of a tree or commit object to diff against.
-r
recurse
-z
\0 line termination on output
--cached
do not consider the on-disk file at all
Output format:
For files in the tree but not in the cache
-<mode>\t <type>\t <object>\t <path><file>
For files in the cache but not in the tree
+<mode>\t <type>\t <object>\t <path><file>
For files that differ:
*<tree-mode>-><cache-mode>\t <type>\t <tree-sha1>-><cache-sha1>\t <path><file>
In the special case of the file being changed on disk and out of sync
with the cache, the sha1 is all 0's. Example:
*100644->100660 blob 5be4a414b32cf4204f889469942986d3d783da84->0000000000000000000000000000000000000000 file.c
Operating Modes
You can choose whether you want to trust the index file entirely
(using the "--cached" flag) or ask the diff logic to show any files
that don't match the stat state as being "tentatively changed". Both
of these operations are very useful indeed.
Cached Mode
If --cached is specified, it allows you to ask:
show me the differences between HEAD and the current index
contents (the ones I'd write with a "write-tree")
For example, let's say that you have worked on your index file, and are
ready to commit. You want to see eactly _what_ you are going to commit is
without having to write a new tree object and compare it that way, and to
do that, you just do
diff-cache --cached $(cat .git/HEAD)
Example: let's say I had renamed "commit.c" to "git-commit.c", and I had
done an "upate-cache" to make that effective in the index file.
"show-diff" wouldn't show anything at all, since the index file matches
my working directory. But doing a diff-cache does:
torvalds@ppc970:~/git> diff-cache --cached $(cat .git/HEAD)
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
And as you can see, the output matches "diff-tree -r" output (we
always do "-r", since the index is always fully populated
??CHECK??).
You can trivially see that the above is a rename.
In fact, "diff-cache --cached" _should_ always be entirely equivalent to
actually doing a "write-tree" and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
So doing a "diff-cache --cached" is basically very useful when you are
asking yourself "what have I already marked for being committed, and
what's the difference to a previous tree".
Non-cached Mode
The "non-cached" mode takes a different approach, and is potentially
the even more useful of the two in that what it does can't be emulated
with a "write-tree + diff-tree". Thus that's the default mode. The
non-cached version asks the question
"show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date"
which is obviously a very useful question too, since that tells you what
you _could_ commit. Again, the output matches the "diff-tree -r" output to
a tee, but with a twist.
The twist is that if some file doesn't match the cache, we don't have a
backing store thing for it, and we use the magic "all-zero" sha1 to show
that. So let's say that you have edited "kernel/sched.c", but have not
actually done an update-cache on it yet - there is no "object" associated
with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> diff-cache $(cat .git/HEAD )
*100644->100664 blob 7476bbcfe5ef5a1dd87d745f298b831143e4d77e->0000000000000000000000000000000000000000 kernel/sched.c
ie it shows that the tree has changed, and that "kernel/sched.c" has is
not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
NOTE! As with other commands of this type, "diff-cache" does not actually
look at the contents of the file at all. So maybe "kernel/sched.c" hasn't
actually changed, and it's just that you touched it. In either case, it's
a note that you need to upate-cache it to make the cache be in sync.
NOTE 2! You can have a mixture of files show up as "has been updated" and
"is still dirty in the working directory" together. You can always tell
which file is in which state, since the "has been updated" ones show a
valid sha1, and the "not in sync with the index" ones will always have the
special all-zero sha1.
################################################################
diff-tree
diff-tree [-r] [-z] <tree/commit> <tree/commit>
Compares the content and mode of the blobs found via two tree objects.
Note that diff-tree can use the tree encapsulated in a commit object.
<tree sha1>
The id of a tree or commit object.
-r
recurse
-z
\0 line termination on output
Output format:
For files in tree1 but not in tree2
-<mode>\t <type>\t <object>\t <path><file>
For files not in tree1 but in tree2
+<mode>\t <type>\t <object>\t <path><file>
For files that differ:
*<tree1-mode>-><tree2-mode>\t <type>\t <tree1 sha1>-><tree2 sha1>\t <path><file>
An example of normal usage is:
torvalds@ppc970:~/git> diff-tree 5319e4d609cdd282069cc4dce33c1db559539b03 b4e628ea30d5ab3606119d2ea5caeab141d38df7
*100664->100664 blob ac348b7d5278e9d04e3a1cd417389379c32b014f->a01513ed4d4d565911a60981bfb4173311ba3688 fsck-cache.c
which tells you that the last commit changed just one file (it's from
this one:
commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
tree 5319e4d609cdd282069cc4dce33c1db559539b03
parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
Make "fsck-cache" print out all the root commits it finds.
Once I do the reference tracking, I'll also make it print out all the
HEAD commits it finds, which is even more interesting.
in case you care).
################################################################
fsck-cache
fsck-cache [[--unreachable] <commit>*]
Verifies the connectivity and validity of the objects in the database.
<commit>
A commit object to treat as the head of an unreachability
trace
--unreachable
print out objects that exist but that aren't readable from any
of the specified root nodes
It tests SHA1 and general object sanity, but it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
"--unreachable" flag it will also print out objects that exist but
that aren't readable from any of the specified root nodes.
So for example
fsck-cache --unreachable $(cat .git/HEAD)
or, for Cogito users:
fsck-cache --unreachable $(cat .git/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
sorted properly etc), but on the whole if "fsck-cache" is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
(ie you can just remove them and do an "rsync" with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
evil person, and the end result might be crap. Git is a revision
tracking system, not a quality assurance system ;)
Extracted Diagnostics
expect dangling commits - potential heads - due to lack of head information
You haven't specified any nodes as heads so it won't be
possible to differentiate between un-parented commits and
root nodes.
missing sha1 directory '<dir>'
The directory holding the sha1 objects is missing.
unreachable <type> <object>
The <type> object <object>, isn't actually referred to directly
or indirectly in any of the trees or commits seen. This can
mean that there's another root na SHA1_ode that you're not specifying
or that the tree is corrupt. If you haven't missed a root node
then you might as well delete unreachable nodes since they
can't be used.
missing <type> <object>
The <type> object <object>, is referred to but isn't present in
the database.
dangling <type> <object>
The <type> object <object>, is present in the database but never
_directly_ used. A dangling commit could be a root node.
warning: fsck-cache: tree <tree> has full pathnames in it
And it shouldn't...
sha1 mismatch <object>
The database has an object who's sha1 doesn't match the
database value.
This indicates a ??serious?? data integrity problem.
(note: this error occured during early git development when
the database format changed.)
Environment Variables
SHA1_FILE_DIRECTORY
used to specify the object database root (usually .git/objects)
################################################################
git-export
git-export top [base]
probably deprecated:
On Wed, 20 Apr 2005, Petr Baudis wrote:
>> I will probably not buy git-export, though. (That is, it is merged, but
>> I won't make git frontend for it.) My "git export" already does
>> something different, but more importantly, "git patch" of mine already
>> does effectively the same thing as you do, just for a single patch; so I
>> will probably just extend it to do it for an (a,b] range of patches.
That's fine. It was a quick hack, just to show that if somebody wants to,
the data is trivially exportable.
Linus
Although in Linus' distribution show-diff is not part of 'core' git.
################################################################
init-db
init-db
This simply creates an empty git object database - basically a .git
directory.
If the object storage directory is specified via the
SHA1_FILE_DIRECTORY environment variable then the sha1 directories are
created underneath - otherwise the default .git/objects directory is
used.
init-db won't hurt an existing repository.
################################################################
ls-tree
ls-tree [-r] [-z] <tree/commit>
convert the tree object to a human readable (and script
processable) form.
<tree/commit>
Id of a tree or commit object.
-r
recurse into sub-trees
-z
\0 line termination on output
Output Format
<mode>\t <type>\t <object>\t <path><file>
################################################################
merge-base
merge-base <commit> <commit>
merge-base finds one of the best common ancestors of a pair of commits. In
particular, it finds one of the ones which is fewest commits away from the
further of the heads.
When it has a tree with equally likely common ancestors like this:
A -- C
\/ \
/\ /
B -- D
It essentially returns either A or B randomly.
The merge-base algorithm is still in flux.
################################################################
merge-cache
merge-cache <merge-program> (-a | -- | <file>*)
This looks up the <file>(s) in the cache and, if there are any merge
entries, unpacks all of them (which may be just one file, of course)
into up to three separate temporary files, and then executes the
supplied <merge-program> with those three files as arguments 1,2,3
(empty argument if no file), and <file> as argument 4.
--
Interpret all future arguments as filenames
-a
Run merge against all files in the cache that need merging.
If merge-cache is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
Typically this is run with the a script calling the merge command from
the RCS package.
Example script:
#!/bin/sh
#
# This is the git merge script, called with
#
# $1 - original file (or empty string)
# $2 - file in branch1 (or empty string)
# $3 - file in branch2 (or empty string)
# $4 - pathname in repository
#
#
# Case 1: file removed in both
#
if [ -z "$2" && -z "$3" ]; then
rm -- "$4"
update-cache --remove -- "$4"
exit 0
fi
#
# Case 2: file exists in just one
#
if [ -z "$2" || -z "$3" ] then
cat "$2""$3" > "$4"
update-cache --add -- "$4"
exit 0
fi
#
# Case 3: file exists in both
#
src="$1"
if [ -z "$1" ]; then
src=/den/null
fi
merge "$3" "$src" "$2" && cp "$3" "$4" && update-cache --add -- "$4"
ALERT ALERT ALERT! The git "merge object order" is different from the
RCS "merge" program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
"merge" is to have the original in the middle. Don't ask me why.
Examples:
torvalds@ppc970:~/merge-test> merge-cache cat MM
This is MM from the original tree. # original
This is modified MM in the branch A. # merge1
This is modified MM in the branch B. # merge2
This is modified MM in the branch B. # current contents
or
torvalds@ppc970:~/merge-test> merge-cache cat AA MM
cat: : No such file or directory
This is added AA in the branch A.
This is added AA in the branch B.
This is added AA in the branch B.
fatal: merge program failed
where the latter example shows how "merge-cache" will stop trying to
merge once anything has returned an error (ie "cat" returned an error
for the AA file, because it didn't exist in the original, and thus
"merge-cache" didn't even try to merge the MM thing).
################################################################
read-tree
read-tree (<tree> | -m <tree1> [<tree2> <tree3>])"
Reads the tree information given by <tree> into the directory cache,
but does not actually _update_ any of the files it "caches". (see:
checkout-cache)
Optionally, it can merge a tree into the cache or perform a 3-way
merge.
Trivial merges are done by read-tree itself. Only conflicting paths
will be in unmerged state when read-tree returns.
-m
Perform a merge, not just a read
<tree#>
The id of the tree object(s) to be read/merged.
Merging
If -m is specified, read-tree performs 2 kinds of merge, a single tree
merge if only 1 tree is given or a 3-way merge if 3 trees are
provided.
Single Tree Merge
If only 1 tree is specified, read-tree operates as if the user did not
specify "-m", except that if the original cache has an entry for a
given pathname; and the contents of the path matches with the tree
being read, the stat info from the cache is used. (In other words, the
cache's stat()s take precedence over the merged tree's)
That means that if you do a "read-tree -m <newtree>" followed by a
"checkout-cache -f -a", the checkout-cache only checks out the stuff
that really changed.
This is used to avoid unnecessary false hits when show-diff is
run after read-tree.
3-Way Merge
Each "index" entry has two bits worth of "stage" state. stage 0 is the
normal one, and is the only one you'd see in any kind of normal use.
However, when you do "read-tree" with multiple trees, the "stage"
starts out at 0, but increments for each tree you read. And in
particular, the "-m" flag means "start at stage 1" instead.
This means that you can do
read-tree -m <tree1> <tree2> <tree3>
and you will end up with an index with all of the <tree1> entries in
"stage1", all of the <tree2> entries in "stage2" and all of the
<tree3> entries in "stage3".
Furthermore, "read-tree" has special-case logic that says: if you see
a file that matches in all respects in the following states, it
"collapses" back to "stage0":
- stage 2 and 3 are the same; take one or the other (it makes no
difference - the same work has been done on stage 2 and 3)
- stage 1 and stage 2 are the same and stage 3 is different; take
stage 3 (some work has been done on stage 3)
- stage 1 and stage 3 are the same and stage 2 is different take
stage 2 (some work has been done on stage 2)
Write-tree refuses to write a nonsensical tree, so write-tree will
complain about unmerged entries if it sees a single entry that is not
stage 0".
Ok, this all sounds like a collection of totally nonsensical rules,
but it's actually exactly what you want in order to do a fast
merge. The different stages represent the "result tree" (stage 0, aka
"merged"), the original tree (stage 1, aka "orig"), and the two trees
you are trying to merge (stage 2 and 3 respectively).
In fact, the way "read-tree" works, it's entirely agnostic about how
you assign the stages, and you could really assign them any which way,
and the above is just a suggested way to do it (except since
"write-tree" refuses to write anything but stage0 entries, it makes
sense to always consider stage 0 to be the "full merge" state).
So what happens? Try it out. Select the original tree, and two trees
to merge, and look how it works:
- if a file exists in identical format in all three trees, it will
automatically collapse to "merged" state by the new read-tree.
- a file that has _any_ difference what-so-ever in the three trees
will stay as separate entries in the index. It's up to "script
policy" to determine how to remove the non-0 stages, and insert a
merged version. But since the index is always sorted, they're easy
to find: they'll be clustered together.
- the index file saves and restores with all this information, so you
can merge things incrementally, but as long as it has entries in
stages 1/2/3 (ie "unmerged entries") you can't write the result.
So now the merge algorithm ends up being really simple:
- you walk the index in order, and ignore all entries of stage 0,
since they've already been done.
- if you find a "stage1", but no matching "stage2" or "stage3", you
know it's been removed from both trees (it only existed in the
original tree), and you remove that entry. - if you find a
matching "stage2" and "stage3" tree, you remove one of them, and
turn the other into a "stage0" entry. Remove any matching "stage1"
entry if it exists too. .. all the normal trivial rules ..
Incidentally - it also means that you don't even have to have a separate
subdirectory for this. All the information literally is in the index file,
which is a temporary thing anyway. There is no need to worry about what is in
the working directory, since it is never shown and never used.
see also:
write-tree
show-files
################################################################
rev-tree
rev-tree [--edges] [--cache <cache-file>] [^]<commit> [[^]<commit>]
Provides the revision tree for one or more commits.
--edges
Show edges (ie places where the marking changes between parent
and child)
--cache <cache-file>
Use the specified file as a cache. [Not implemented yet]
[^]<commit>
The commit id to trace (a leading caret means to ignore this
commit-id and below)
Output:
<date> <commit>:<flags> [<parent-commit>:<flags> ]*
<date>
Date in 'seconds since epoch'
<commit>
id of commit object
<parent-commit>
id of each parent commit object (>1 indicates a merge)
<flags>
The flags are read as a bitmask representing each commit
provided on the commandline. eg: given the command:
$ rev-tree <com1> <com2> <com3>
The output:
<date> <commit>:5
means that <commit> is reachable from <com1>(1) and <com3>(4)
A revtree can get quite large. rev-tree will eventually allow you to
cache previous state so that you don't have to follow the whole thing
down.
So the change difference between two commits is literally
rev-tree [commit-id1] > commit1-revtree
rev-tree [commit-id2] > commit2-revtree
join -t : commit1-revtree commit2-revtree > common-revisions
(this is also how to find the most common parent - you'd look at just
the head revisions - the ones that aren't referred to by other
revisions - in "common-revision", and figure out the best one. I
think.)
################################################################
show-diff
show-diff [-R] [-q] [-s] [-z] [paths...]
Shows the difference between the version of the specified file on disk
and the file in the cache.
-R
Reverse the diff
-q
Reduce verbosity
-s
Remain silent even on nonexisting files (forces -q)
-z
Machine readable (including \0 line termination on output)
Environment variables
GIT_DIFF_CMD Default="diff -L 'a/%s' -L 'b/%s'"
Command used to generate diff
GIT_DIFF_OPTS Default="-p -u"
Options passed to diff command
Although in Linus' distribution show-diff is not part of 'core' git.
################################################################
show-files
show-files [-z] [-t] (--[cached|deleted|others|ignored|stage|unmerged])*
This merges the file listing in the directory cache index with the
actual working directory list, and shows different combinations of the
two.
One or more of the options below may be used to determine the files
shown:
--cached
Show cached files in the output (default)
--deleted
Show deleted files in the output
--others
Show other files in the output
--ignored
Show ignored files in the output
--stage
Show stage files in the output
--unmerged
Show unmerged files in the output (forces --staged)
-t
Show the following tags (followed by a space) at the start of
each line:
H cached
M unmerged
R removed/deleted
? other
-z
\0 line termination on output
Output
show files just outputs the filename unless --stage is specified in
which case it outputs:
[<tag> ]<mode> <object> <stage> <file>
show-files --unmerged" and "show-files --stage " can be used to examine
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
the dircache records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
the user (or Cogito) to see what should eventually be recorded at the
path. (see read-cache for more information on state)
see also:
read-cache
################################################################
unpack-file
unpack-file <blob>
Creates a file holding the contents of the blob specified by sha1. It
returns the name of the temporary file in the following format:
.merge_file_XXXXX
<blob>
Must be a blob id
################################################################
update-cache
update-cache [--add] [--remove] [--refresh] [--cacheinfo <mode> <object> <path>]* [--] [<file>]*
Modifies the index or directory cache. Each file mentioned is updated
into the cache and any 'unmerged' or 'needs updating' state is
cleared.
The way update-cache handles files it is told about can be modified
using the various options:
--add
If a specified file isn't in the cache already then it's
added.
Default behaviour is to ignore new files.
--remove
If a specified file is in the cache but is missing then it's
removed.
Default behaviour is to ignore removed file.
--refresh
Looks at the current cache and checks to see if merges or
updates are needed by checking stat() information.
--cacheinfo <mode> <object> <path>
Directly insert the specified info into the cache.
--
Do not interpret any more arguments as options.
<file>
Files to act on.
Note that files begining with '.' are discarded. This includes
"./file" and "dir/./file". If you don't want this, then use
cleaner names.
The same applies to directories ending '/' and paths with '//'
Using --refresh
--refresh" does not calculate a new sha1 file or bring the cache
up-to-date for mode/content changes. But what it _does_ do is to
"re-match" the stat information of a file with the cache, so that you
can refresh the cache for a file that hasn't been changed but where
the stat entry is out of date.
For example, you'd want to do this after doing a "read-tree", to link
up the stat cache details with the proper files.
Using --cacheinfo
--cacheinfo is used to register a file that is not in the current
working directory. This is useful for minimum-checkout merging.
To pretend you have a file with mode and sha1 at path, say:
$ update-cache --cacheinfo mode sha1 path
################################################################
write-tree
write-tree
Creates a tree object using the current cache.
The cache must be merged.
Conceptually, write-tree sync()s the current directory cache contents
into a set of tree files.
In order to have that match what is actually in your directory right
now, you need to have done a "update-cache" phase before you did the
"write-tree".
################################################################
Terminology: - see README for description
Each line contains terms used interchangeably
object database, .git directory
directory cache, index
id, sha1, sha1-id, sha1 hash
type, tag
blob, blob object
tree, tree object
commit, commit object
parent
root object
changeset
git Environment Variables
AUTHOR_NAME
AUTHOR_EMAIL
AUTHOR_DATE
COMMIT_AUTHOR_NAME
COMMIT_AUTHOR_EMAIL
GIT_DIFF_CMD
GIT_DIFF_OPTS
GIT_INDEX_FILE
SHA1_FILE_DIRECTORY
^ permalink raw reply
* Re: unseeking?
From: Daniel Barkalow @ 2005-04-24 18:47 UTC (permalink / raw)
To: Zack Brown; +Cc: Petr Baudis, git
In-Reply-To: <20050424180116.GC11094@tumblerings.org>
On Sun, 24 Apr 2005, Zack Brown wrote:
> That works a little better for me, but neither really works. If I do
>
> git fork currdir newdir
>
> I get
>
> cat: .git/HEAD: No such file or directory
> Invalid id:
> grep: .git/remotes: No such file or directory
> /home/zbrown/git/git-pasky-0.6.2/gitfork.sh: line 41: .git/heads/mygitdir: No
> such file or directory
> cat: .git/HEAD: No such file or directory
> Invalid id:
> error: no access to SHA1 file directory
> fatal: invalid cache
> error: no access to SHA1 file directory
> fatal: cache corrupted
> Branch mygitdir ready in mygitdir3 with head
I think your "mygitdir" directory has lost its idea of what's in it, so
the fork doesn't know what should be there, either. If it's tracking a
remote repository, you should be able to do a "git pull" there to both
bring it up to date and fix this. Then things should work better.
> I'm sure this is all accurate information, but I'm still unclear about several
> points:
>
> 1) when I fork directory A into directory B, is A at all different from B
> when the fork completes, and if so, how?
They should be the same, but now independant as far as commits into them.
> 2) Are A and B altered by the forking process? i.e., is this an event that is
> recorded in the repo, or is it just the equivalent of 'checking out' the repo?
The repo contains the latest commit on each side in .git/heads/<name>
> 3) What is the significance of a branch 'name'? Is this like a tag?
It's orthogonal to a tag; it's what stays the same when you do more
commits on something. E.g., linux-scsi or linux-stable would be branch
names. (Tags, on the other hand, stick where you put them.)
> 4) In normal work-flow, when would forks be created, as opposed to other ways
> of getting a tree?
I have a tree that I want to modify, but I want to keep the original, and
I may want to update the original from an upstream source (and then sync
my work with it). I start with the original:
cd original
git init URL
git addremote remote-source URL
git track remote-source
I make my own working directory:
git fork my-changes ../my-changes
cd ../my-changes
Then I do my changes, and commit whenever I feel like I've gotten
somewhere (or when I think I'm about to mess something up and might want
to undo changes). Periodically, I check on the mainline:
cd ../original
git pull
I also merge changes from the mainline:
cd ../my-changes
git merge remote-source
When I'm done, I make a patch for my work:
cd ../my-changes
git patch remote-source
I generally then fork the original again, split the patch, apply each
section in the new fork, committing after each one, generate patches for
each of these commits, and send those out. Then I discard my old branch
and continue from the new one. If, at some point, all of the changes I
want to keep have been put into the mainline, I discard all my branches
and fork again from the mainline.
(My personal style is to discard the history of how the changes got made
in favor of the history of how the changes got into the mainline, since I
don't really need to keep all of my debugged mistakes that nobody else
saw.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [RFC] Design of name-addressed data portion
From: Daniel Barkalow @ 2005-04-24 18:17 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Petr Baudis
I think it has gotten to be time to have a standard mechanism for
name-addressed data in the .git directory. We currently have one
agreed-upon item, HEAD, as well as a number of items in cogito: heads,
tags, and, to a certain extent, remotes. (Even in core git, when we
support tags, we'll want a mapping from tag names to tag objects, even if
this mapping doesn't get transferred by push and pull operations; nobody's
going to want to cut and paste a hash from email every time they want to
refer to the tag, and fsck-cache could stand to know which tags you mean
to have so that it can report the rest to git-prune-script)
It would be useful to have a bit more structure to the repository, such
that there are a fixed number of paths that hold all of the information
about the state of the repository, while the rest of the directory has
information that is particular to a working directory's state (e.g.,
index).
I'd propose the following structure:
objects/ the content-addressed repository portion
references/ the name-addressed repository portion
heads/ the heads that are being used out of this repository
DEFAULT the head that people pulling this repository mean by default
... other heads, by name, that fsck-cache should mark reachable
tags/ the tags
... files with the symbolic name of the tags, containing the hash
info/ other per-repository information
remotes URLs of remote repositories
complete hashes that the repository contains all references from
missing hashes that the repository lacks but wants
excluded hashes that the repository doesn't want
... other files are per .git directory, not shared on push/pull
index
HEAD symlink to the head that is the local default
tracked remote that this working directory tracks
All of the files in references/*/* contain hex for objects in the
database, and are not synced between repositories in situ (but some sync
operations will read some of them and write them under different
names). fsck-cache would use as its reachability starting point $(cat
references/*/*).
In info/ are, generically, other files that relate to operations which
work on the repository rather than a working directory. Transfer programs
would use and maintain this information.
I think we'd still eventually want some way of getting from a commit-id to
any tags about it (I think git log would do well to mention any tags you
have when it shows a commit), but I don't want to design this quite
yet. It should also work for going from the real history to cached delta
info, when we have comparison tools that are sufficiently smart,
expensive, and intermediate-dependant to want to cache this.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* NULL check for malloc?
From: Christopher Li @ 2005-04-24 14:03 UTC (permalink / raw)
To: git mailing list
I notice that there are lots of malloc call without
checking the return NULL pointer.
Should we just have some wrapper function for malloc
just die if malloc fails?
Chris
^ permalink raw reply
* Re: unseeking?
From: Zack Brown @ 2005-04-24 18:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504241305370.30848-100000@iabervon.org>
On Sun, Apr 24, 2005 at 01:25:35PM -0400, Daniel Barkalow wrote:
> On Sun, 24 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> told me that...
>
> > git fork seconddeveloper ../mygitdir
>
> Doesn't that have to be from the first one to the second one (rather than
> the other way)?
That works a little better for me, but neither really works. If I do
git fork currdir newdir
I get
cat: .git/HEAD: No such file or directory
Invalid id:
grep: .git/remotes: No such file or directory
/home/zbrown/git/git-pasky-0.6.2/gitfork.sh: line 41: .git/heads/mygitdir: No
such file or directory
cat: .git/HEAD: No such file or directory
Invalid id:
error: no access to SHA1 file directory
fatal: invalid cache
error: no access to SHA1 file directory
fatal: cache corrupted
Branch mygitdir ready in mygitdir3 with head
If I cd into mygitdir3, I see a .git directory, but no files. If I do a 'git
pull', it asks me where to pull from, and I don't know what to tell it.
> > > 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> > > these things do in general, but the specifics are confusing, and the README is a
> > > little vague.
> >
> > Try head git*.sh. ;-)
>
> Which is to say, there are useful comments at the beginnings of the
> scripts. I.e., you really want "head `which gitfork.sh`"
I've looked at the scripts, but I don't find the comments specific enough. For
instance, for gitfork.sh:
# Create a branch sharing the objects database.
# Copyright (c) Petr Baudis, 2005
#
# This script creates a new branch (or revives an unused old branch)
# in a given directory, sharing the same objects database with the
# branch in the current directory, and forking from it at the latest
# commit (in the case of a new branch). You can use the name
# of the branch as an ID in all the other branches sharing the
# objects database.
#
# The new directory has a fresh checkout of the branch.
#
# Takes the desired branch name, its directory name, and potentially
# the head commit ID (for new branch).
I'm sure this is all accurate information, but I'm still unclear about several
points:
1) when I fork directory A into directory B, is A at all different from B
when the fork completes, and if so, how?
2) Are A and B altered by the forking process? i.e., is this an event that is
recorded in the repo, or is it just the equivalent of 'checking out' the repo?
3) What is the significance of a branch 'name'? Is this like a tag?
4) In normal work-flow, when would forks be created, as opposed to other ways
of getting a tree?
Thanks,
Zack
>
> -Daniel
> *This .sig left intentionally blank*
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: [RFC] updates for git-pull-script
From: Linus Torvalds @ 2005-04-24 17:49 UTC (permalink / raw)
To: James Bottomley; +Cc: git
In-Reply-To: <1114352069.4997.24.camel@mulgrave>
On Sun, 24 Apr 2005, James Bottomley wrote:
>
> The attached addresses all these points. It's what I use, but since
> others may prefer the original behaviour, I'm sending it as a straw
> horse.
I don't think anybody preferes the original behaviour - the reason
git-pull-script punted with any non-trivial merge was that when I wrote
the damn thing, I was still just testing out the merges, and I definitely
didn't trust the automated script.
However, when you remove the "checkout-cache -f -a" thing, it means that
you are leaving all teh checked-out files in a state where it's _very_
easy to mess up later, and doign so silently really is very bad.
So at the _very_ least you should do an "update-cache --refresh", and
_tell_ the user about the files that are checked-out but not up-to-date.
And it really sounds like the whole and only reason you don't like
checkout-cache is that you normally work with an empty tree, so I actually
think that the _right_ answer for you is to add a new flag to
"checkout-cache" that only updates files that already exist. Something
like "-n" for "don't create new files".
Linus
^ permalink raw reply
* Rename tracking, revisited (was: unseeking?)
From: Kevin Smith @ 2005-04-24 17:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Zack Brown, git
In-Reply-To: <20050424160514.GI1507@pasky.ji.cz>
Petr Baudis wrote:
> Git does not record renames, and neither does Cogito (for now).
Here's one message in the git list archives where Linus proposes a way
to track renames without tracking renames:
http://permalink.gmane.org/gmane.comp.version-control.git/217
I figure this will be an FAQ as more folks join the git community.
Kevin
^ permalink raw reply
* Re: [PATCH] make git-prune-script actually work
From: Linus Torvalds @ 2005-04-24 17:35 UTC (permalink / raw)
To: James Bottomley; +Cc: git
In-Reply-To: <1114351135.4997.18.camel@mulgrave>
On Sun, 24 Apr 2005, James Bottomley wrote:
>
> I find this script very useful to get back to where I started from after
> test merges, and also for cloning trees from a non-current base. The
> functionality is altered so it now takes an optional commit argument
> (and a -q flag to make it be quiet).
Hmm.. You should probably rename it to "git-reset-script" or something,
and any time you reset the head, you should also amke sure to reset the
index, because otherwise your index file may actually be referencing
objects that no longer even exist, and that's going to be very very
painful.
So
> +echo $head > .git/HEAD
should probably be followed by
read-tree -m $head
update-cache --refresh
which will also tell the user what files he has that are now "dirty" (and
he can decide whether he wants to commit his changes, or whether he wants
to do a "checkout-cache -f -a" to just get rid of it all).
Linus
^ permalink raw reply
* Re: unseeking?
From: Daniel Barkalow @ 2005-04-24 17:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Zack Brown, git
In-Reply-To: <20050424160514.GI1507@pasky.ji.cz>
On Sun, 24 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > Hi,
>
> Hi,
> > How can I seek back to the most recent state of the dir?
>
> git seek, without any arguments.
>
> Perhaps we should prohibit absence of arguments and add 'unseek'?
Have both; I think that it ought to accept anything where it's obvious
what the user means.
> Actually, this _would_ work:
>
> git init ../mygitdir/.git
>
> Then, you would need to git pull to get the latest changes.
It's worth pointing out that the reason for this (and why the rsync
version below didn't work) is that the conventional URLs are for .git
directories, not the directories that contain them: .../cogito/cogito.git
mirrors a cogito/.git directory. Or, phrasing it the other way, when it's
public, it's cogito.git; if it's in a working directory, it gets hidden by
making it just .git.
> git fork seconddeveloper ../mygitdir
Doesn't that have to be from the first one to the second one (rather than
the other way)?
> Git does not record renames, and neither does Cogito (for now).
And, in general, future history-browsing tools will work based on clever
analysis of the files, not explicit information in the database. They
ought to recognize when some content disappears from one place and
something very similar appears elsewhere, regardless of whether it is a
complete file or not.
I'm fairly certain that the most common rename-type events are moving code
within a file, not renaming files, and these would be a major pain to get
people to explicitly mark.
> > 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> > these things do in general, but the specifics are confusing, and the README is a
> > little vague.
>
> Try head git*.sh. ;-)
Which is to say, there are useful comments at the beginnings of the
scripts. I.e., you really want "head `which gitfork.sh`"
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [GIT PATCH] Selective diff-tree
From: Linus Torvalds @ 2005-04-24 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, Git Mailing List
In-Reply-To: <7vbr84tyfd.fsf@assigned-by-dhcp.cox.net>
On Sun, 24 Apr 2005, Junio C Hamano wrote:
>
> Is either of you planning to do the same for diff-cache?
I wasn't. I don't think it's nearly as relevant for diff-cache, since
diff-cache is never run thousands of times.
IOW, with diff-cache you can just do
diff-cache <tree> | grep "interesting"
and you're done.
Diff-tree is different, simply because diff-tree is the way you find out
which files changed between two revisions, so if you search for "when did
this file change" you may well have to do _thousands_ of different
diff-tree's. That's why pruning the diff-tree output is important: it
makes diff-tree _much_ cheaper.
diff-cache usually doesn't make sense to do against more than one or two
threes (the parent, and after a merge but before you commit maybe the
parent_s_).
Linus
^ permalink raw reply
* Re: [GIT PATCH] Selective diff-tree
From: Linus Torvalds @ 2005-04-24 17:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1114323914.3419.70.camel@localhost.localdomain>
On Sun, 24 Apr 2005, David Woodhouse wrote:
>
> On the other hand, my gitfilelog.sh is fairly fundamentally flawed and
> probably needs rewriting in C based on rev-tree.
Yeah, I think I'll make the "tree-diff" functions be available to others,
since they are actually _very_ cheap, and it's a bit sad to have to
execute a whole new process just to get a tree-diff. Then writing some
rev-list thing that just does tree-diff between different versions should
be trivial and quite efficient for finding things like "when did this set
of files/subdirectory last change".
Which definitely is very useful information.
Linus
^ permalink raw reply
* Re: unseeking?
From: Zack Brown @ 2005-04-24 16:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050424160514.GI1507@pasky.ji.cz>
On Sun, Apr 24, 2005 at 06:05:14PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > Hi,
>
> Hi,
>
> > I've been pulling cogito and the kernel, and just fumbling around trying to
> > learn the tool. My latest cogito is version 0.7, tracking
> >
> > pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> > linus rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git
> >
> > I have many questions.
> >
> > 1) I saw some discussion of 'seek' as a way to get to an earlier version of a
> > tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
> > it worked - but now all I have is that very early version of my test directory.
> > All subsequent changes are apparently gone. How can I seek back to the most
> > recent state of the dir?
>
> git seek, without any arguments.
This didn't work. I did a 'git seek' and I still see only the early version of
my directory. However, see the next point for more on this.
>
> Perhaps we should prohibit absence of arguments and add 'unseek'?
>
> > 2) How can I 'check out' my local repository? i.e. I want to pretend to be
> > two developers, one of whom wants to grab a copy of the project leader's work. I
> > tried things like:
> >
> > mkdir mygitdir2
> > git init ../mygitdir
> >
> > where mydir is my test git repository. This didn't work. I tried rephrasing the
>
> Actually, this _would_ work:
>
> git init ../mygitdir/.git
>
> Then, you would need to git pull to get the latest changes.
OK, I did 'git init ../mygitdir/.git', and it worked, I didn't even need to do a
pull. It's a little unintuitive that I would have to specifically identify the
.git subdirectory in that command. But it worked.
So, regarding my first point. When I did the init from the original repo, the
new repo got the latest snapshot of the tree. So I did a 'git log' in the new
directory to obtain the latest d394a1e71504c6f032a484bbd5e8ecbe4c3de05e thingy.
Then I went back to my main directory (the one I'd seeked back to the
beginning), and did
git seek d394a1e71504c6f032a484bbd5e8ecbe4c3de05e
but it didn't work. The directory is still stuck at the beginning of its history.
>
> > command with an rsync url:
> >
> > git init rsync://home/zbrown/site/gitstuff/mygitdir
> >
> > but that didn't work either. It just said:
> >
> > defaulting to local storage area
> > rsync: getaddrinfo: home 873: Name or service not known
> > rsync error: error in socket IO (code 10) at clientserver.c(94)
> > gitpull.sh: unable to get the head pointer of branch master
> > gitinit.sh: pull failed
>
> git fork seconddeveloper ../mygitdir
Can you say what this does? Is it the same as the init+pull you described above?
Hmm... I tried it, and got:
09:24:06 [zbrown] ~/site/gitstuff/mygit3$ git fork seconddeveloper ../mygitdir
cat: .git/HEAD: No such file or directory
Invalid id:
grep: .git/remotes: No such file or directory
gitfork.sh: ../mygitdir already exists
09:24:07 [zbrown] ~/site/gitstuff/mygit3$
>
> > 3) How can I do a rename with cogito? There doesn't seem to be a rename command,
> > and if I manually do a mv and 'git add', I can commit the result, but what
> > actually happened? Did I really do a rename? Is the file's history preserved?
> > How can I verify these things?
>
> Git does not record renames, and neither does Cogito (for now).
OK
>
> > 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> > these things do in general, but the specifics are confusing, and the README is a
> > little vague.
>
> Try head git*.sh. ;-)
heh. This is not more clear ;-)
>
> > 5) I'm a little confused about how to use a git repository to follow along with
> > a project. I have no problem pulling the latest version, but I'm interested in
> > generating changelogs for specific releases like 2.6.12-rc3. How can I
> >
> > a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
> > represents the release I'm interested in
>
> Assuming that it is tagged, just do
>
> commit-id linux-2.6.12-rc3
>
> or whatever the tag name is. From Cogito perspective, you can use the
> symbolic name anywhere you would use the proper string.
>
> There is also tree-id and parent-id, with same usage.
OK, I still have questions on this, but I see tagging is getting some heavy
work today. I think I'll wait till that shakes out.
>
> > b) generate the changelog between that version and the previous one,
> > once I've solved (a)
>
> git log previous that
>
> Any ideas how to improve the user interface further are deeply
> appreciated. (However please note that it is going to undergo a big
> change in an hour or two, so you might want to postpone them until
> that.)
Be well,
Zack
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: unseeking?
From: Petr Baudis @ 2005-04-24 16:05 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050424154754.GA11094@tumblerings.org>
Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Hi,
Hi,
> I've been pulling cogito and the kernel, and just fumbling around trying to
> learn the tool. My latest cogito is version 0.7, tracking
>
> pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> linus rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git
>
> I have many questions.
>
> 1) I saw some discussion of 'seek' as a way to get to an earlier version of a
> tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
> it worked - but now all I have is that very early version of my test directory.
> All subsequent changes are apparently gone. How can I seek back to the most
> recent state of the dir?
git seek, without any arguments.
Perhaps we should prohibit absence of arguments and add 'unseek'?
> 2) How can I 'check out' my local repository? i.e. I want to pretend to be
> two developers, one of whom wants to grab a copy of the project leader's work. I
> tried things like:
>
> mkdir mygitdir2
> git init ../mygitdir
>
> where mydir is my test git repository. This didn't work. I tried rephrasing the
Actually, this _would_ work:
git init ../mygitdir/.git
Then, you would need to git pull to get the latest changes.
> command with an rsync url:
>
> git init rsync://home/zbrown/site/gitstuff/mygitdir
>
> but that didn't work either. It just said:
>
> defaulting to local storage area
> rsync: getaddrinfo: home 873: Name or service not known
> rsync error: error in socket IO (code 10) at clientserver.c(94)
> gitpull.sh: unable to get the head pointer of branch master
> gitinit.sh: pull failed
git fork seconddeveloper ../mygitdir
> 3) How can I do a rename with cogito? There doesn't seem to be a rename command,
> and if I manually do a mv and 'git add', I can commit the result, but what
> actually happened? Did I really do a rename? Is the file's history preserved?
> How can I verify these things?
Git does not record renames, and neither does Cogito (for now).
> 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> these things do in general, but the specifics are confusing, and the README is a
> little vague.
Try head git*.sh. ;-)
> 5) I'm a little confused about how to use a git repository to follow along with
> a project. I have no problem pulling the latest version, but I'm interested in
> generating changelogs for specific releases like 2.6.12-rc3. How can I
>
> a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
> represents the release I'm interested in
Assuming that it is tagged, just do
commit-id linux-2.6.12-rc3
or whatever the tag name is. From Cogito perspective, you can use the
symbolic name anywhere you would use the proper string.
There is also tree-id and parent-id, with same usage.
> b) generate the changelog between that version and the previous one,
> once I've solved (a)
git log previous that
Any ideas how to improve the user interface further are deeply
appreciated. (However please note that it is going to undergo a big
change in an hour or two, so you might want to postpone them until
that.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox