* Re: [PATCH] checkout-cache fix
From: Petr Baudis @ 2005-05-12 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voebhnwey.fsf_-_@assigned-by-dhcp.cox.net>
Dear diary, on Thu, May 12, 2005 at 02:02:45AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Commit cc01b05f0a3dfdf5ed114e429a7bec1ad549ab1c
> Author Junio C Hamano <junkio@cox.net>, Wed May 11 17:00:16 2005 -0700
> Committer Junio C Hamano <junkio@cox.net>, Wed May 11 17:00:16 2005 -0700
>
> Fix checkout-cache when existing work tree interferes with the checkout.
Thanks, applied. A nit about the commit message, though - I'd prefer you
to put this metadata stuff belong the --- separator, since they really
do not belong to the log message. I've already seen something like this
in one commit merged from git-jc (IIRC some of the Ingo Molnar's leak
fixes), and it was a little PITA there since the first line was some
Date: header but we tend to use the first line as the commit's caption
at some places.
Thanks,
--
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: [PATCH] Test suite
From: Junio C Hamano @ 2005-05-12 19:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050512192941.GC324@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>> --- /dev/null
>> +++ b/t/test-lib.sh
>> +# For repeatability, reset the environment to known value.
>> +export LANG C
>> +export TZ UTC
These are just "Duh". Sorry.
>> +
>> +test_description () {
>> + while case "$#" in 0) break;; esac
PB> Duh. This looks mysterious - why not a simple test?
Because I am old fashioned and am used to this kind of Bourne
shell idioms.
PB> This branch makes no sense, I think.
Because...?
PB> Again, why not a simple test?
Again using case when test is not needed is a good old Bourne
shell idiom.
PB> [ "$debug" ] && eval "$*"
PB> (Actually, eval will do the wrong thing here - it just concatenates the
PB> arguments. Just "$@" would do, I guess.)
No, I wrote "$*" because that was what I wanted and not "$@". I
wanted to give eval a _single_ string.
PB> Please clean up after yourself in this case.
I would not mind, but I'd mildly disagree. The next test will
start by cleaning up test-repo/ anyway. What we are lacking is
t/Makefile that drives all the tests and clean-up can be done
there.
>> +git-init-db 2>/dev/null || error "cannot run git-init-db"
PB> But there's no 'error' thing.
Yes, and that way you can get an error message ;-). Simple
oversight.
PB> The testcases currently utterly fail,
That is something I told you in the cover letter (or commit log).
^ permalink raw reply
* Re: [PATCH] checkout-cache fix
From: Junio C Hamano @ 2005-05-12 19:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050512193838.GE324@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> ... I've already seen something like this
PB> in one commit merged from git-jc (IIRC some of the Ingo Molnar's leak
PB> fixes),...
Yes, I am very unhappy about that commit, too. I was mucking
with jit-commit command at the time, and apparently used a buggy
one to make that commit---I realized what happened much later
when I reviewed the commit log and it was already too late (I
told everybody that the tree is published and pullable by then).
Sorry about that.
^ permalink raw reply
* Re: [ANNOUNCE] git tracker online
From: Thomas Gleixner @ 2005-05-12 19:58 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20050512190433.GB8176@lug-owl.de>
On Thu, 2005-05-12 at 21:04 +0200, Jan-Benedict Glaw wrote:
> - Browsing the Cogito repository doesn't work. Could you fix
> that?
Sure
> - When the {repository,diff against} drop-down box is changed,
> it would be nice to fire off a onchange="submit()" so that (if
> your browser is wacked with JavaScript) you don't need to
> press the submit button.
>
I thought about that already. I'm currently cleaning up the code and fix
the heuristic guessing a bit and then I will put the code online, so you
can fix yourself if I have not managed to do it until then :)
tglx
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-12 20:07 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <20050511012626.GL26384@pasky.ji.cz>
* [Previous page] [Next page] would be nice in addition to last
10, day, week, etc.
* Putting the commit headline and "X hour"s ago in a separate
div or span next to each other, so that a long commit headline
wraps properly and does not start the second line just under
the "X hours ago" timestamp would be nicer (you can see what I
mean easily by narrowing the browser window).
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Matt Mackall @ 2005-05-12 20:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: linux-kernel, git, mercurial, Linus Torvalds
In-Reply-To: <20050512182340.GA324@pasky.ji.cz>
On Thu, May 12, 2005 at 08:23:41PM +0200, Petr Baudis wrote:
> Dear diary, on Thu, May 12, 2005 at 11:44:06AM CEST, I got a letter
> where Matt Mackall <mpm@selenic.com> told me that...
> > Mercurial is more than 10 times as bandwidth efficient and
> > considerably more I/O efficient. On the server side, rsync uses about
> > twice as much CPU time as the Mercurial server and has about 10 times
> > the I/O and pagecache footprint as well.
> >
> > Mercurial is also much smarter than rsync at determining what
> > outstanding changesets exist. Here's an empty pull as a demonstration:
> >
> > $ time hg merge hg://selenic.com/linux-hg/
> > retrieving changegroup
> >
> > real 0m0.363s
> > user 0m0.083s
> > sys 0m0.007s
> >
> > That's a single http request and a one line response.
>
> So, what about comparing it with something comparable, say git pull over
> HTTP? :-)
..because I get a headache every time I try to figure out how to use git? :-P
Seriously, have a pointer to how this works?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Adapting scripts to work in current (not top) directory
From: Petr Baudis @ 2005-05-12 20:12 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: GIT Mailing List
In-Reply-To: <200505121758.10971.snake@penza-gsm.ru>
Dear diary, on Thu, May 12, 2005 at 03:58:10PM CEST, I got a letter
where Alexey Nezhdanov <snake@penza-gsm.ru> told me that...
> All git and cogito scripts wants .git subdirectory. If I'm in a subdirectory
> that have no .git direcory in it I'm out of luck.
This is fine for Cogito, but Git itself shouldn't care - unless you mean
the bundled mini-plumbing scripts. I don't know if anyone (and who) uses
them except Linus, but I'm not likely to make much effort to maintain
them, or even to actually accept any non-trivial changes to them.
> I have wrote an example script that determines the lowest possible .git
> directory position and changes to it to satisfy user request.
>
> Problems with script:
> 1) May be I misunderstood the git ideology and it needs not this at all.
Cogito really needs it.
> if point (1) is false then there are couple of other problems:
> 2) Script is extremelly ugly. I'm a week bash programmer so please criticize.
> 3) This logic shold be somehow embedded to all git- and cg- scripts. I can not
> figure how to do it non-intruisively.
Add it to cg-Xlib. You can just update $_git appropriately. (Except when
you were explicitly passed GIT_DIR.)
> gitpath=
> subpath=
> curpath=`pwd`
> for ((i=2;i<9999;i=i+1)) ; do {
> path1=`echo $curpath | cut -d / -f 0-$i`
> path2=`echo $curpath | cut -d / -f $((i+1))-`
> [ -d "$path1"/.git ] && gitpath=$path1 && subpath=$path2
> [ "$path1" == "$curpath" ] && break
> }; done
I would gradually trim the $curpath by $(dirname) until I hit
$curpath/.git or the root directory.
--
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: Mercurial 0.4e vs git network pull
From: Petr Baudis @ 2005-05-12 20:14 UTC (permalink / raw)
To: Matt Mackall; +Cc: linux-kernel, git, mercurial, Linus Torvalds
In-Reply-To: <20050512201116.GC5914@waste.org>
Dear diary, on Thu, May 12, 2005 at 10:11:16PM CEST, I got a letter
where Matt Mackall <mpm@selenic.com> told me that...
> On Thu, May 12, 2005 at 08:23:41PM +0200, Petr Baudis wrote:
> > Dear diary, on Thu, May 12, 2005 at 11:44:06AM CEST, I got a letter
> > where Matt Mackall <mpm@selenic.com> told me that...
> > > Mercurial is more than 10 times as bandwidth efficient and
> > > considerably more I/O efficient. On the server side, rsync uses about
> > > twice as much CPU time as the Mercurial server and has about 10 times
> > > the I/O and pagecache footprint as well.
> > >
> > > Mercurial is also much smarter than rsync at determining what
> > > outstanding changesets exist. Here's an empty pull as a demonstration:
> > >
> > > $ time hg merge hg://selenic.com/linux-hg/
> > > retrieving changegroup
> > >
> > > real 0m0.363s
> > > user 0m0.083s
> > > sys 0m0.007s
> > >
> > > That's a single http request and a one line response.
> >
> > So, what about comparing it with something comparable, say git pull over
> > HTTP? :-)
>
> ..because I get a headache every time I try to figure out how to use git? :-P
>
> Seriously, have a pointer to how this works?
Either you use cogito and just pass cg-clone an HTTP URL (to the git
repository as in the case of rsync -
http://www.kernel.org/pub/scm/cogito/cogito.git should work), or you
invoke git-http-pull directly (passing it desired commit ID of the
remote HEAD you want to fetch, and the URL; see
Documentation/git-http-pull.txt).
--
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: [PATCH Cogito] Add -u option to cg-log to show only commits from a specific user
From: Petr Baudis @ 2005-05-12 20:23 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: GIT Mailing List
In-Reply-To: <1115599773.8949.90.camel@pegasus>
Dear diary, on Mon, May 09, 2005 at 02:49:33AM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
Hi,
> the attached patch introduces the -u option for cg-log. Now you can give
> a username or a part of a username and only commits with a matching
> author or committer will be displayed.
>
> This patch also changes the option parsing, because otherwise we are
> stuck to a specific order.
I think that one should be in a separate patch.
At any rate, could you please resend the patch(es) signed off?
--
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: [ANNOUNCE] git tracker online
From: Jan-Benedict Glaw @ 2005-05-12 20:30 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: git
In-Reply-To: <1115927905.11872.48.camel@tglx>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
On Thu, 2005-05-12 21:58:25 +0200, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 2005-05-12 at 21:04 +0200, Jan-Benedict Glaw wrote:
> > - When the {repository,diff against} drop-down box is changed,
> > it would be nice to fire off a onchange="submit()" so that (if
> > your browser is wacked with JavaScript) you don't need to
> > press the submit button.
> >
>
> I thought about that already. I'm currently cleaning up the code and fix
> the heuristic guessing a bit and then I will put the code online, so you
> can fix yourself if I have not managed to do it until then :)
Well, as easy as:
s#<select name='project' size='1'>#<select name='project' onchange="submit()" size='1'>#
You'll manage to add that yourself, I fully trust you :-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH Cogito] Use cg-commit -E to invoke editor and always commit
From: Marcel Holtmann @ 2005-05-12 20:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
Hi Petr,
the attached patch introduces the -E parameter to cg-commit and then
uses it in cg-init. If you use -E instead of -e the editor is invoked
and it will do the commit even it the default commit messages has not
been changed.
Regards
Marcel
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1572 bytes --]
Index: cg-commit
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -13,6 +13,8 @@
# appended to a single commit message, each as separate paragraph.
# -e forces the editor to be brought up even when -m parameters were
# passed to cg-commit.
+# -E forces the editor to be brought up and it will do the commit
+# even if the default commit message is not changed.
. ${COGITO_LIB}cg-Xlib
@@ -21,6 +23,7 @@
forceeditor=
ignorecache=
+commitalways=
msgs=()
while [ "$1" ]; do
case "$1" in
@@ -32,6 +35,11 @@
forceeditor=1
shift
;;
+ -E)
+ forceeditor=1
+ commitalways=1
+ shift
+ ;;
-m*)
msgs=("${msgs[@]}" "${1#-m}")
shift
@@ -126,10 +134,10 @@
if tty -s; then
if ! [ "$msgs" ] || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
- fi
- if ! [ "$msgs" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
- rm $LOGMSG $LOGMSG2
- die 'Commit message not modified, commit aborted'
+ if ! [ "$commitalways" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Commit message not modified, commit aborted'
+ fi
fi
else
cat >>$LOGMSG2
Index: cg-init
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-init (mode:100755)
+++ uncommitted/cg-init (mode:100755)
@@ -32,6 +32,6 @@
else
git-read-tree # Seed the dircache
find * | xargs cg-add
- cg-commit -C -m"Initial commit" -e
+ cg-commit -C -m"Initial commit" -E
fi
exit 0
^ permalink raw reply
* [PATCH Cogito] Remove heading and trailing empty lines from commit messages
From: Marcel Holtmann @ 2005-05-12 20:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 192 bytes --]
Hi Petr,
the attached patch removes heading and trailing empty lines from the
commit message before doing the commit.
Regards
Marcel
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 365 bytes --]
Index: cg-commit
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -134,7 +134,7 @@
else
cat >>$LOGMSG2
fi
-grep -v ^CG: $LOGMSG2 >$LOGMSG
+grep -v ^CG: $LOGMSG2 | sed '/./,${/./b;:a;$d;N;/\n$/ba;b;};d' >$LOGMSG
rm $LOGMSG2
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7vvf5ogxdu.fsf@assigned-by-dhcp.cox.net>
On Thu, 2005-05-12 at 10:35 -0700, Junio C Hamano wrote:
> Thanks for a very clear explanation. The situation is
> intriguing in that both R and M after converging end up with
> exactly the same HEAD with the same set of objects but still
> would want to see history leading to the HEAD differently.
Yes, thats what I wanted to achieve first hand with the repository id. I
think my first attempt is far from perfect and I agree with hpa on
having a .git/repoid file.
> I wonder what happens to a third person S, who pulls from both R
> and M. What does S see?
> Does the commit order observed by S depend on which one S pulls
> from first? That is, if S pulls from R then at that point Mn-1
> and Mn comes after Rn-1 in S's history? And after that what
> hapens if S pulls from M (which is obviously a no-op except that
> it would update .git/refs/heads/M)? Does the history for S
> change?
That's an interesting question. Of course, if you change the head you
see the tree from a different POV, but you can detect this when S pulls
from M after a pull from R. So the tool can ask the user, if he really
wants to change the commit order or not. You might even argue that they
could refuse to do the head change
> The answer to the above could be "the merge order history is per
> tree and not something to be exported or given away to other
> trees", in which case it may make sense from S's point of view
> that Mn and Rn-1 are compares solely based on their commit
> timestamps. You will get consistent history and switching which
> tree is being tracked would not change the history. Is the goal
> here to give the merge order history from R and M to S?
The goal from my side is to preserve the merge order history of R, M and
S in the individual way of commit order per repository, which includes
the merge order R->S, M->S or the other way round. See above
> If that is not needed, then you can record in an auxiliary file
> that is local to each tree the timestamp of when merge happened
> in that tree along with set of foreign commit objects, and teach
> rev-tree or rev-list to read from that auxiliary file and use
> that timestamp for foreign commit objects instead of commit time
> recorded in them when sorting by time is needed.
As I said before timestamps can be a horrid source of information. Also
if you keep a list of commits merges and head forwards in timed order it
is simple to read the repository history, but in case of corruption you
have to reconstruct it manually. There is no way to do so with the
information available.
Repository id's can be lost, but are simple to replace as they are
recorded in the commit blob.
tglx
^ permalink raw reply
* [PATCH Cogito] Improve option parsing for cg-log
From: Marcel Holtmann @ 2005-05-12 20:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 182 bytes --]
Hi Petr,
the attached patch changes the option parsing, because otherwise we are
stuck to a specific order.
Regards
Marcel
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 1294 bytes --]
Index: cg-log
===================================================================
--- 456fffab323ed972b8e47fa0fb83c3b5cd9243d7/cg-log (mode:100755)
+++ uncommitted/cg-log (mode:100755)
@@ -27,29 +27,34 @@
# at least somewhere it does. Bash is broken.
trap exit SIGPIPE
-if [ "$1" = "-c" ]; then
- shift
- # See terminfo(5), "Color Handling"
- colheader="$(tput setaf 2)" # Green
- colauthor="$(tput setaf 6)" # Cyan
- colcommitter="$(tput setaf 5)" # Magenta
- colfiles="$(tput setaf 4)" # Blue
- colsignoff="$(tput setaf 3)" # Yellow
- coldefault="$(tput op)" # Restore default
-else
- colheader=
- colauthor=
- colcommitter=
- colfiles=
- colsignoff=
- coldefault=
-fi
-
+colheader=
+colauthor=
+colcommitter=
+colfiles=
+colsignoff=
+coldefault=
list_files=
-if [ "$1" = "-f" ]; then
- shift
- list_files=1
-fi
+while [ "$1" ]; do
+ case "$1" in
+ -c)
+ # See terminfo(5), "Color Handling"
+ colheader="$(tput setaf 2)" # Green
+ colauthor="$(tput setaf 6)" # Cyan
+ colcommitter="$(tput setaf 5)" # Magenta
+ colfiles="$(tput setaf 4)" # Blue
+ colsignoff="$(tput setaf 3)" # Yellow
+ coldefault="$(tput op)" # Restore default
+ shift
+ ;;
+ -f)
+ list_files=1
+ shift
+ ;;
+ *)
+ break
+ ;;
+ esac
+done
list_commit_files()
{
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Matt Mackall @ 2005-05-12 20:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: linux-kernel, git, mercurial, Linus Torvalds
In-Reply-To: <20050512201406.GJ324@pasky.ji.cz>
On Thu, May 12, 2005 at 10:14:06PM +0200, Petr Baudis wrote:
> Dear diary, on Thu, May 12, 2005 at 10:11:16PM CEST, I got a letter
> where Matt Mackall <mpm@selenic.com> told me that...
> > On Thu, May 12, 2005 at 08:23:41PM +0200, Petr Baudis wrote:
> > > Dear diary, on Thu, May 12, 2005 at 11:44:06AM CEST, I got a letter
> > > where Matt Mackall <mpm@selenic.com> told me that...
> > > > Mercurial is more than 10 times as bandwidth efficient and
> > > > considerably more I/O efficient. On the server side, rsync uses about
> > > > twice as much CPU time as the Mercurial server and has about 10 times
> > > > the I/O and pagecache footprint as well.
> > > >
> > > > Mercurial is also much smarter than rsync at determining what
> > > > outstanding changesets exist. Here's an empty pull as a demonstration:
> > > >
> > > > $ time hg merge hg://selenic.com/linux-hg/
> > > > retrieving changegroup
> > > >
> > > > real 0m0.363s
> > > > user 0m0.083s
> > > > sys 0m0.007s
> > > >
> > > > That's a single http request and a one line response.
> > >
> > > So, what about comparing it with something comparable, say git pull over
> > > HTTP? :-)
> >
> > ..because I get a headache every time I try to figure out how to use git? :-P
> >
> > Seriously, have a pointer to how this works?
>
> Either you use cogito and just pass cg-clone an HTTP URL (to the git
> repository as in the case of rsync -
> http://www.kernel.org/pub/scm/cogito/cogito.git should work), or you
> invoke git-http-pull directly (passing it desired commit ID of the
> remote HEAD you want to fetch, and the URL; see
> Documentation/git-http-pull.txt).
Does this need an HTTP request (and round trip) per object? It appears
to. That's 2200 requests/round trips for my 800 patch benchmark.
How does git find the outstanding changesets?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-12 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bssfbsj.fsf@assigned-by-dhcp.cox.net>
On Thu, 2005-05-12 at 13:07 -0700, Junio C Hamano wrote:
> * [Previous page] [Next page] would be nice in addition to last
> 10, day, week, etc.
That should be easy to do with the parameters we have now for the
git-rev-list. I will first finish the new browser through the
trees/files, then the project overview page and after that try the
pager,
> * Putting the commit headline and "X hour"s ago in a separate
> div or span next to each other, so that a long commit headline
> wraps properly and does not start the second line just under
> the "X hours ago" timestamp would be nicer (you can see what I
> mean easily by narrowing the browser window).
Block elements (div) are not allowed inside an a-tag in XHTML/Strict -
don't know how to do this, cause the whole headline should be a link
without the use of javascript. :)
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 21:09 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115930845.11872.79.camel@tglx>
On Thu, May 12, 2005 4:47 pm, Thomas Gleixner said:
> As I said before timestamps can be a horrid source of information. Also
> if you keep a list of commits merges and head forwards in timed order it
> is simple to read the repository history, but in case of corruption you
> have to reconstruct it manually. There is no way to do so with the
> information available.
>
> Repository id's can be lost, but are simple to replace as they are
> recorded in the commit blob.
And the time is recorded on the commit blob too. In case of corruption,
restore the blobs from backup, you get everything back. Corruption can
wipe out repoids and complete git objects too, you had better have
backups. Repoids offer no protection from corruption or otherwise lost
blobs.
Sean
^ permalink raw reply
* Re: [PATCH Cogito] Improve option parsing for cg-log
From: Petr Baudis @ 2005-05-12 21:13 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: GIT Mailing List
In-Reply-To: <1115931114.18499.66.camel@pegasus>
Dear diary, on Thu, May 12, 2005 at 10:51:54PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
Hi,
> the attached patch changes the option parsing, because otherwise we are
> stuck to a specific order.
thanks, applied. However, you didn't include the -r options parsing in
there yet.
--
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: gitweb wishlist
From: Junio C Hamano @ 2005-05-12 21:18 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <1115931627.8465.6.camel@dhcp-188.off.vrfy.org>
>>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
>> * Putting the commit headline and "X hour"s ago in a separate
>> div or span next to each other, so that a long commit headline
>> wraps properly and does not start the second line just under
>> the "X hours ago" timestamp would be nicer (you can see what I
>> mean easily by narrowing the browser window).
KS> Block elements (div) are not allowed inside an a-tag in XHTML/Strict -
KS> don't know how to do this,...
Wouldn't splitting the commit headline and "X hours ago" into
two separate elements and wrap them individually inside an a-tag
each pointing at the same destination good enough then?
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 21:21 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <4776.10.10.10.24.1115932163.squirrel@linux1>
On Thu, 2005-05-12 at 17:09 -0400, Sean wrote:
> On Thu, May 12, 2005 4:47 pm, Thomas Gleixner said:
>
> > As I said before timestamps can be a horrid source of information. Also
> > if you keep a list of commits merges and head forwards in timed order it
> > is simple to read the repository history, but in case of corruption you
> > have to reconstruct it manually. There is no way to do so with the
> > information available.
> >
> > Repository id's can be lost, but are simple to replace as they are
> > recorded in the commit blob.
>
> And the time is recorded on the commit blob too.
How do you enforce correct timestamps ?
tglx
Received: from simmts5-srv.bellnexxia.net (simmts5.bellnexxia.net
[206.47.199.163]) by mail.tglx.de (Postfix) with ESMTP id 623FE65C003
for <tglx@linutronix.de>; Thu, 12 May 2005 23:09:21 +0200 (CEST)
Received: from linux1 ([69.156.111.46]) by simmts5-srv.bellnexxia.net
(InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id
<20050512210923.CCQN11606.simmts5-srv.bellnexxia.net@linux1>; Thu, 12
May 2005 17:09:23 -0400
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Daniel Barkalow @ 2005-05-12 21:24 UTC (permalink / raw)
To: Matt Mackall; +Cc: Petr Baudis, linux-kernel, git, mercurial, Linus Torvalds
In-Reply-To: <20050512205735.GE5914@waste.org>
On Thu, 12 May 2005, Matt Mackall wrote:
> Does this need an HTTP request (and round trip) per object? It appears
> to. That's 2200 requests/round trips for my 800 patch benchmark.
It requires a request per object, but it should be possible (with
somewhat more complicated code) to overlap them such that it doesn't
require a serial round trip for each. Since the server is sending static
files, the overhead for each should be minimal.
> How does git find the outstanding changesets?
In the present mainline, you first have to find the head commit you
want. I have a patch which does this for you over the same
connection. Starting from that point, it tracks reachability on the
receiving end, and requests anything it doesn't have.
For the case of having nothing to do, it should be a single one-line
request/response for a static file (after which the local end determines
that it has everything it needs without talking to the server).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Ignore file filter
From: David Greaves @ 2005-05-12 21:30 UTC (permalink / raw)
To: Petr Baudis, GIT Mailing Lists
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
Hi Petr
This is an inline filter that introduces the concept of .git/ignore
It is intended to be used within the cogito scripts like the other cg-X*
files.
Signed-off-by: David Greaves <david@dgreaves.com>
--
[-- Attachment #2: cg-Xignore --]
[-- Type: text/plain, Size: 2346 bytes --]
#!/usr/bin/env bash
#
# Takes a list of files on stdin and only passes valid ones agording to .git/ignore
# Copyright (c) David Greaves, 2005
#
# This filter implements cogito ignore rules and should typically be used in find pipelines
#
# Synopsis
# cg-Xignore [-debug] [-f] [-h] [-d] < file-list >useful-file-list
#
# Options
# -debug::
# produce helpful debug output
#
# -q::
# don't say what paths are ignored
#
# -f::
# passes files
#
# -d::
# passes directories
#
# -h::
# passes symbolic links
#
# The default is to pass all file types that are not ignored.
#
# Note that the .git/ignore file contains multiple expressions, 1 per line
# Lines beginning with a '#' are ignored (allowing comments)
# These are 'bash regular expressions' not glob patterns
# This allows ignore rules to take the directory into account
# Suggested contents:
# # bash regexps (not globs)
# ^\.[^/]
# /\.
# /$
# .*\.o$
# This doesn't allow the -h which is the [ arg for symlinks...
#. ${COGITO_LIB}cg-Xlib
_git=${GIT_DIR:-.git}
IGNORE_FILE="$_git/ignore"
if [ "$1" = "-0" ]; then
# doesn't work :(
zerosep=$'-d "\0"'
shift
fi
# Defaults
pass_files=0
pass_dirs=0
pass_links=0
pass_all=1
while [ $# -gt 0 ]; do
case $1 in
"-f")
pass_all=0
pass_files=1
;;
"-d")
pass_all=0
pass_dirs=1
;;
"-h")
pass_all=0
pass_links=1
;;
"-q")
quiet=1
;;
"-debug")
debug=1
;;
esac
shift
done
# save stderr
exec 5>&2
if [ $quiet ]; then
# turn off noise
exec 2>&-
fi
if [ $debug ]; then
exec 4>&5
else
exec 4>/dev/null
fi
# Strip out the common leading ./ allowing "find ."
sed 's:^./::' | \
while read $zerosep file; do
echo "consider file: $file" >&4
ignore=0
if [ -f $IGNORE_FILE ]; then
exec 3<$IGNORE_FILE
while read -r -u3 patt ; do
if [[ $patt =~ "^\w*#" ]]; then
continue
fi
echo "consider pattern: $patt" >&4
if [[ $file =~ $patt ]]; then
ignore=1
echo "Ignoring $file because of $patt" >&2
break
fi
done
fi
echo "passing file: $file" >&4
if [ $ignore != "1" \
-a \( $pass_all -eq 1 \
-o \( $pass_files -eq 1 -a -f $file \) \
-o \( $pass_dirs -eq 1 -a -d $file \) \
-o \( $pass_links -eq 1 -a -h $file \) \
\) \
]; then
echo $file
fi
done
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 21:32 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115932872.11872.86.camel@tglx>
On Thu, May 12, 2005 5:21 pm, Thomas Gleixner said:
>> And the time is recorded on the commit blob too.
>
> How do you enforce correct timestamps ?
When an object is committed locally it is set to the local time. You can
only have this feature when you use private commit objects (shared blobs
are okay). It doesn't matter if the timestamps are correct in the global
sense, just that they're correct for the local server, because they'll
only ever be compared against each other.
By the way, repoid doesn't work when all the branches are done in the same
repository. You'd need to use something like repoid-branch.
One area where your repoid is superior that i missed in my previous email
is that you can actually recover a corrupt blob from an unrelated
repository that happens to contain it, and you've lost no information.
Which is what Linus was expounding as one of the benefits of the git
design.
Sean
^ permalink raw reply
* [PATCH] update README and #include in git.txt
From: David Greaves @ 2005-05-12 21:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
Hi Petr
I sent this to Junio just as he was shutting down his tree.
Can you take it into yours?
(This is the README from Linus' tree)
David
Makefile understands the includes git.txt #includes README
README reformatted to asciidoc to allow inclusion in git.txt
Signed-off-by: David Greaves <david@dgreaves.com>
---
commit 14d464865c5e204793c2244bdc4aba0ecd6d593d
tree e0e578bb02a7d8db1c105fddf5b5168ad0c79088
parent d81ed1b591b1db413c91e29b66de6a14dc543ffc
author David Greaves <david@dgreaves.com> Wed, 11 May 2005 16:20:23 +0100
committer David Greaves <david@dgreaves.com> Wed, 11 May 2005 16:20:23 +0100
Documentation/Makefile | 8
Documentation/git.txt | 19 -
README | 728 +++++++++++++++++++++++++------------------------
3 files changed, 390 insertions(+), 365 deletions(-)
Index: Documentation/Makefile
===================================================================
--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/Documentation/Makefile (mode:100644)
+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/Documentation/Makefile (mode:100644)
@@ -8,8 +8,12 @@
man: $(DOC_MAN)
-git-%: %.c $(LIB_FILE)
- $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
+# 'include' dependencies
+git.txt: ../README
+ touch git.txt
+
+git-diff-*.txt: diff-format.txt
+ touch $@
clean:
rm -f *.xml *.html *.1
Index: Documentation/git.txt
===================================================================
--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/Documentation/git.txt (mode:100644)
+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/Documentation/git.txt (mode:100644)
@@ -16,9 +16,10 @@
This is reference information for the core git commands.
-The link:README[] contains much useful definition and clarification
-info - read that first. And of the commands, I suggest reading
-'git-update-cache' and 'git-read-tree' first - I wish I had!
+The Discussion section below contains much useful definition and
+clarification info - read that first. And of the commands, I suggest
+reading link:git-update-cache.html[git-update-cache] and
+link:git-read-tree.html[git-read-tree] first - I wish I had!
David Greaves <david@dgreaves.com>
08/05/05
@@ -230,18 +231,12 @@
Terminology
-----------
-Each line contains terms used interchangeably
+Each line contains terms which you may see 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
Environment Variables
@@ -295,6 +290,10 @@
link:git-diff-files.html[git-diff-files];
link:git-diff-tree.html[git-diff-tree]
+Discussion
+----------
+include::../README[]
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
Index: README
===================================================================
--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/README (mode:100644)
+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/README (mode:100644)
@@ -1,9 +1,13 @@
+////////////////////////////////////////////////////////////////
+ GIT - the stupid content tracker
-
- GIT - the stupid content tracker
+Note that this README is written in asciidoc format and is #include'd
+in the git.txt docs
+The rest of this README is #included in the git.txt file
+////////////////////////////////////////////////////////////////
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
@@ -23,21 +27,19 @@
"current directory cache" aka "index".
-
- The Object Database (GIT_OBJECT_DIRECTORY)
-
-
+The Object Database
+~~~~~~~~~~~~~~~~~~~
The object database is literally just a content-addressable collection
of objects. All objects are named by their content, which is
approximated by the SHA1 hash of the object itself. Objects may refer
-to other objects (by referencing their SHA1 hash), and so you can build
-up a hierarchy of objects.
+to other objects (by referencing their SHA1 hash), and so you can
+build up a hierarchy of objects.
All objects have a statically determined "type" aka "tag", which is
determined at object creation time, and which identifies the format of
-the object (i.e. how it is used, and how it can refer to other objects).
-There are currently three different object types: "blob", "tree" and
-"commit".
+the object (ie how it is used, and how it can refer to other objects).
+There are currently four different object types: "blob", "tree",
+"commit" and "tag".
A "blob" object cannot refer to any other object, and is, like the tag
implies, a pure storage object containing some user data. It is used to
@@ -48,7 +50,7 @@
directory structure. In addition, a tree object can refer to other tree
objects, thus creating a directory hierarchy.
-Finally, a "commit" object ties such directory hierarchies together into
+A "commit" object ties such directory hierarchies together into
a DAG of revisions - each "commit" is associated with exactly one tree
(the directory hierarchy at the time of the commit). In addition, a
"commit" refers to one or more "parent" commit objects that describe the
@@ -62,12 +64,17 @@
just going to confuse people. So aim for the notion of "one root object
per project", even if git itself does not enforce that.
+A "tag" object symbolically identifies and can be used to sign other
+objects. It contains the identifier and type of another object, a
+symbolic name (of course!) and, optionally, a signature.
+
Regardless of object type, all objects are share the following
characteristics: they are all in deflated with zlib, and have a header
that not only specifies their tag, but also size information about the
data in the object. It's worth noting that the SHA1 hash that is used
-to name the object is always the hash of this _compressed_ object, not
-the original data.
+to name the object is the hash of the original data (historical note:
+in the dawn of the age of git this was the sha1 of the _compressed_
+object)
As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
@@ -76,157 +83,179 @@
forms a sequence of <ascii tag without space> + <space> + <ascii decimal
size> + <byte\0> + <binary object data>.
-The structured objects can further have their structure and connectivity
-to other objects verified. This is generally done with the "fsck-cache"
-program, which generates a full dependency graph of all objects, and
-verifies their internal consistency (in addition to just verifying their
-superficial consistency through the hash).
+The structured objects can further have their structure and
+connectivity to other objects verified. This is generally done with
+the "git-fsck-cache" program, which generates a full dependency graph
+of all objects, and verifies their internal consistency (in addition
+to just verifying their superficial consistency through the hash).
The object types in some more detail:
- BLOB: A "blob" object is nothing but a binary blob of data, and
- doesn't refer to anything else. There is no signature or any
- other verification of the data, so while the object is
- consistent (it _is_ indexed by its sha1 hash, so the data itself
- is certainly correct), it has absolutely no other attributes.
- No name associations, no permissions. It is purely a blob of
- data (i.e. normally "file contents").
-
- In particular, since the blob is entirely defined by its data,
- if two files in a directory tree (or in multiple different
- versions of the repository) have the same contents, they will
- share the same blob object. The object is totally independent
- of it's location in the directory tree, and renaming a file does
- not change the object that file is associated with in any way.
-
- TREE: The next hierarchical object type is the "tree" object. A tree
- object is a list of mode/name/blob data, sorted by name.
- Alternatively, the mode data may specify a directory mode, in
- which case instead of naming a blob, that name is associated
- with another TREE object.
-
- Like the "blob" object, a tree object is uniquely determined by
- the set contents, and so two separate but identical trees will
- always share the exact same object. This is true at all levels,
- i.e. it's true for a "leaf" tree (which does not refer to any
- other trees, only blobs) as well as for a whole subdirectory.
-
- For that reason a "tree" object is just a pure data abstraction:
- it has no history, no signatures, no verification of validity,
- except that since the contents are again protected by the hash
- itself, we can trust that the tree is immutable and its contents
- never change.
-
- So you can trust the contents of a tree to be valid, the same
- way you can trust the contents of a blob, but you don't know
- where those contents _came_ from.
-
- Side note on trees: since a "tree" object is a sorted list of
- "filename+content", you can create a diff between two trees
- without actually having to unpack two trees. Just ignore all
- common parts, and your diff will look right. In other words,
- you can effectively (and efficiently) tell the difference
- between any two random trees by O(n) where "n" is the size of
- the difference, rather than the size of the tree.
-
- Side note 2 on trees: since the name of a "blob" depends
- entirely and exclusively on its contents (i.e. there are no names
- or permissions involved), you can see trivial renames or
- permission changes by noticing that the blob stayed the same.
- However, renames with data changes need a smarter "diff" implementation.
-
-CHANGESET: The "changeset" object is an object that introduces the
- notion of history into the picture. In contrast to the other
- objects, it doesn't just describe the physical state of a tree,
- it describes how we got there, and why.
-
- A "changeset" is defined by the tree-object that it results in,
- the parent changesets (zero, one or more) that led up to that
- point, and a comment on what happened. Again, a changeset is
- not trusted per se: the contents are well-defined and "safe" due
- to the cryptographically strong signatures at all levels, but
- there is no reason to believe that the tree is "good" or that
- the merge information makes sense. The parents do not have to
- actually have any relationship with the result, for example.
-
- Note on changesets: unlike real SCM's, changesets do not contain
- rename information or file mode change information. All of that
- is implicit in the trees involved (the result tree, and the
- result trees of the parents), and describing that makes no sense
- in this idiotic file manager.
-
-TRUST: The notion of "trust" is really outside the scope of "git", but
- it's worth noting a few things. First off, since everything is
- hashed with SHA1, you _can_ trust that an object is intact and
- has not been messed with by external sources. So the name of an
- object uniquely identifies a known state - just not a state that
- you may want to trust.
-
- Furthermore, since the SHA1 signature of a changeset refers to
- the SHA1 signatures of the tree it is associated with and the
- signatures of the parent, a single named changeset specifies
- uniquely a whole set of history, with full contents. You can't
- later fake any step of the way once you have the name of a
- changeset.
-
- So to introduce some real trust in the system, the only thing
- you need to do is to digitally sign just _one_ special note,
- which includes the name of a top-level changeset. Your digital
- signature shows others that you trust that changeset, and the
- immutability of the history of changesets tells others that they
- can trust the whole history.
-
- In other words, you can easily validate a whole archive by just
- sending out a single email that tells the people the name (SHA1
- hash) of the top changeset, and digitally sign that email using
- something like GPG/PGP.
-
- In particular, you can also have a separate archive of "trust
- points" or tags, which document your (and other peoples) trust.
- You may, of course, archive these "certificates of trust" using
- "git" itself, but it's not something "git" does for you.
-
-Another way of saying the last point: "git" itself only handles content
-integrity, the trust has to come from outside.
-
-
-
- The "index" aka "Current Directory Cache" (".git/index")
+Blob Object
+~~~~~~~~~~~
+A "blob" object is nothing but a binary blob of data, and doesn't
+refer to anything else. There is no signature or any other
+verification of the data, so while the object is consistent (it _is_
+indexed by its sha1 hash, so the data itself is certainly correct), it
+has absolutely no other attributes. No name associations, no
+permissions. It is purely a blob of data (ie normally "file
+contents").
+
+In particular, since the blob is entirely defined by its data, if two
+files in a directory tree (or in multiple different versions of the
+repository) have the same contents, they will share the same blob
+object. The object is toally independent of it's location in the
+directory tree, and renaming a file does not change the object that
+file is associated with in any way.
+
+A blob is created with link:git-write-blob.html[git-write-blob] and
+it's data can be accessed by link:git-cat-file.html[git-cat-file]
+
+Tree Object
+~~~~~~~~~~~
+The next hierarchical object type is the "tree" object. A tree object
+is a list of mode/name/blob data, sorted by name. Alternatively, the
+mode data may specify a directory mode, in which case instead of
+naming a blob, that name is associated with another TREE object.
+
+Like the "blob" object, a tree object is uniquely determined by the
+set contents, and so two separate but identical trees will always
+share the exact same object. This is true at all levels, ie it's true
+for a "leaf" tree (which does not refer to any other trees, only
+blobs) as well as for a whole subdirectory.
+
+For that reason a "tree" object is just a pure data abstraction: it
+has no history, no signatures, no verification of validity, except
+that since the contents are again protected by the hash itself, we can
+trust that the tree is immutable and its contents never change.
+
+So you can trust the contents of a tree to be valid, the same way you
+can trust the contents of a blob, but you don't know where those
+contents _came_ from.
+
+Side note on trees: since a "tree" object is a sorted list of
+"filename+content", you can create a diff between two trees without
+actually having to unpack two trees. Just ignore all common parts,
+and your diff will look right. In other words, you can effectively
+(and efficiently) tell the difference between any two random trees by
+O(n) where "n" is the size of the difference, rather than the size of
+the tree.
+
+Side note 2 on trees: since the name of a "blob" depends entirely and
+exclusively on its contents (ie there are no names or permissions
+involved), you can see trivial renames or permission changes by
+noticing that the blob stayed the same. However, renames with data
+changes need a smarter "diff" implementation.
+
+A tree is created with link:git-write-tree.html[git-write-tree] and
+it's data can be accessed by link:git-ls-tree.html[git-ls-tree]
+
+Commit Object
+~~~~~~~~~~~~~
+The "commit" object is an object that introduces the notion of
+history into the picture. In contrast to the other objects, it
+doesn't just describe the physical state of a tree, it describes how
+we got there, and why.
+
+A "commit" is defined by the tree-object that it results in, the
+parent commits (zero, one or more) that led up to that point, and a
+comment on what happened. Again, a commit is not trusted per se:
+the contents are well-defined and "safe" due to the cryptographically
+strong signatures at all levels, but there is no reason to believe
+that the tree is "good" or that the merge information makes sense.
+The parents do not have to actually have any relationship with the
+result, for example.
+
+Note on commits: unlike real SCM's, commits do not contain
+rename information or file mode chane information. All of that is
+implicit in the trees involved (the result tree, and the result trees
+of the parents), and describing that makes no sense in this idiotic
+file manager.
+
+A commit is created with link:git-commit-tree.html[git-commit-tree] and
+it's data can be accessed by link:git-cat-file.html[git-cat-file]
+
+Trust
+~~~~~
+An aside on the notion of "trust". Trust is really outside the scope
+of "git", but it's worth noting a few things. First off, since
+everything is hashed with SHA1, you _can_ trust that an object is
+intact and has not been messed with by external sources. So the name
+of an object uniquely identifies a known state - just not a state that
+you may want to trust.
+
+Furthermore, since the SHA1 signature of a commit refers to the
+SHA1 signatures of the tree it is associated with and the signatures
+of the parent, a single named commit specifies uniquely a whole set
+of history, with full contents. You can't later fake any step of the
+way once you have the name of a commit.
+
+So to introduce some real trust in the system, the only thing you need
+to do is to digitally sign just _one_ special note, which includes the
+name of a top-level commit. Your digital signature shows others
+that you trust that commit, and the immutability of the history of
+commits tells others that they can trust the whole history.
+
+In other words, you can easily validate a whole archive by just
+sending out a single email that tells the people the name (SHA1 hash)
+of the top commit, and digitally sign that email using something
+like GPG/PGP.
+
+To assist in this, git also provides the tag object...
+
+Tag Object
+~~~~~~~~~~
+Git provides the "tag" object to simplify creating, managing and
+exchanging symbolic and signed tokens. The "tag" object at its
+simplest simply symbolically identifies another object by containing
+the sha1, type and symbolic name.
+
+However it can optionally contain additional signature information
+(which git doesn't care about as long as there's less than 8k of
+it). This can then be verified externally to git.
+
+Note that despite the tag features, "git" itself only handles content
+integrity; the trust framework (and signature provision and
+verification) has to come from outside.
+A tag is created with link:git-mktag.html[git-mktag] and
+it's data can be accessed by link:git-cat-file.html[git-cat-file]
+The "index" aka "Current Directory Cache"
+-----------------------------------------
The index is a simple binary file, which contains an efficient
representation of a virtual directory content at some random time. It
does so by a simple array that associates a set of names, dates,
permissions and content (aka "blob") objects together. The cache is
always kept ordered by name, and names are unique (with a few very
specific rules) at any point in time, but the cache has no long-term
-meaning, and can be partially updated at any time.
+meaning, and can be partially updated at any time.
In particular, the index certainly does not need to be consistent with
the current directory contents (in fact, most operations will depend on
different ways to make the index _not_ be consistent with the directory
hierarchy), but it has three very important attributes:
- (a) it can re-generate the full state it caches (not just the directory
- structure: it contains pointers to the "blob" objects so that it
- can regenerate the data too)
-
- As a special case, there is a clear and unambiguous one-way mapping
- from a current directory cache to a "tree object", which can be
- efficiently created from just the current directory cache without
- actually looking at any other data. So a directory cache at any
- one time uniquely specifies one and only one "tree" object (but
- has additional data to make it easy to match up that tree object
- with what has happened in the directory)
-
- (b) it has efficient methods for finding inconsistencies between that
- cached state ("tree object waiting to be instantiated") and the
- current state.
-
- (c) it can additionally efficiently represent information about merge
- conflicts between different tree objects, allowing each pathname to
- be associated with sufficient information about the trees involved
- that you can create a three-way merge between them.
+'(a) it can re-generate the full state it caches (not just the
+directory structure: it contains pointers to the "blob" objects so
+that it can regenerate the data too)'
+
+As a special case, there is a clear and unambiguous one-way mapping
+from a current directory cache to a "tree object", which can be
+efficiently created from just the current directory cache without
+actually looking at any other data. So a directory cache at any one
+time uniquely specifies one and only one "tree" object (but has
+additional data to make it easy to match up that tree object with what
+has happened in the directory)
+
+'(b) it has efficient methods for finding inconsistencies between that
+cached state ("tree object waiting to be instantiated") and the
+current state.'
+
+'(c) it can additionally efficiently represent information about merge
+conflicts between different tree objects, allowing each pathname to be
+associated with sufficient information about the trees involved that
+you can create a three-way merge between them.'
Those are the three ONLY things that the directory cache does. It's a
cache, and the normal operation is to re-generate it completely from a
@@ -245,216 +274,209 @@
- The Workflow
-
-
+The Workflow
+------------
Generally, all "git" operations work on the index file. Some operations
-work _purely_ on the index file (showing the current state of the
+work *purely* on the index file (showing the current state of the
index), but most operations move data to and from the index file. Either
from the database or from the working directory. Thus there are four
main combinations:
- 1) working directory -> index
-
- You update the index with information from the working directory
- with the "update-cache" command. You generally update the index
- information by just specifying the filename you want to update,
- like so:
-
- update-cache filename
-
- but to avoid common mistakes with filename globbing etc, the
- command will not normally add totally new entries or remove old
- entries, i.e. it will normally just update existing cache entries.
-
- To tell git that yes, you really do realize that certain files
- no longer exist in the archive, or that new files should be
- added, you should use the "--remove" and "--add" flags
- respectively.
-
- NOTE! A "--remove" flag does _not_ mean that subsequent
- filenames will necessarily be removed: if the files still exist
- in your directory structure, the index will be updated with
- their new status, not removed. The only thing "--remove" means
- is that update-cache will be considering a removed file to be a
- valid thing, and if the file really does not exist any more, it
- will update the index accordingly.
-
- As a special case, you can also do "update-cache --refresh",
- which will refresh the "stat" information of each index to match
- the current stat information. It will _not_ update the object
- status itself, and it will only update the fields that are used
- to quickly test whether an object still matches its old backing
- store object.
-
- 2) index -> object database
-
- You write your current index file to a "tree" object with the
- program
-
- write-tree
-
- that doesn't come with any options - it will just write out the
- current index into the set of tree objects that describe that
- state, and it will return the name of the resulting top-level
- tree. You can use that tree to re-generate the index at any time
- by going in the other direction:
-
- 3) object database -> index
-
- You read a "tree" file from the object database, and use that to
- populate (and overwrite - don't do this if your index contains
- any unsaved state that you might want to restore later!) your
- current index. Normal operation is just
-
- read-tree <sha1 of tree>
-
- and your index file will now be equivalent to the tree that you
- saved earlier. However, that is only your _index_ file: your
- working directory contents have not been modified.
-
- 4) index -> working directory
-
- You update your working directory from the index by "checking
- out" files. This is not a very common operation, since normally
- you'd just keep your files updated, and rather than write to
- your working directory, you'd tell the index files about the
- changes in your working directory (i.e. "update-cache").
-
- However, if you decide to jump to a new version, or check out
- somebody else's version, or just restore a previous tree, you'd
- populate your index file with read-tree, and then you need to
- check out the result with
-
- checkout-cache filename
-
- or, if you want to check out all of the index, use "-a".
-
- NOTE! checkout-cache normally refuses to overwrite old files, so
- if you have an old version of the tree already checked out, you
- will need to use the "-f" flag (_before_ the "-a" flag or the
- filename) to _force_ the checkout.
-
-
-Finally, there are a few odds and ends which are not purely moving from
-one representation to the other:
-
- 5) Tying it all together
-
- To commit a tree you have instantiated with "write-tree", you'd
- create a "commit" object that refers to that tree and the
- history behind it - most notably the "parent" commits that
- preceded it in history.
-
- Normally a "commit" has one parent: the previous state of the
- tree before a certain change was made. However, sometimes it can
- have two or more parent commits, in which case we call it a
- "merge", due to the fact that such a commit brings together
- ("merges") two or more previous states represented by other
- commits.
-
- In other words, while a "tree" represents a particular directory
- state of a working directory, a "commit" represents that state
- in "time", and explains how we got there.
-
- You create a commit object by giving it the tree that describes
- the state at the time of the commit, and a list of parents:
-
- commit-tree <tree> -p <parent> [-p <parent2> ..]
-
- and then giving the reason for the commit on stdin (either
- through redirection from a pipe or file, or by just typing it at
- the tty).
-
- commit-tree will return the name of the object that represents
- that commit, and you should save it away for later use.
- Normally, you'd commit 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.
-
- 6) Examining the data
-
- You can examine the data represented in the object database and
- the index with various helper tools. For every object, you can
- use "cat-file" to examine details about the object:
-
- cat-file -t <objectname>
-
- shows the type of the object, and once you have the type (which
- is usually implicit in where you find the object), you can use
-
- cat-file blob|tree|commit <objectname>
-
- to show its contents. NOTE! Trees have binary content, and as a
- result there is a special helper for showing that content,
- called "ls-tree", which turns the binary content into a more
- easily readable form.
-
- It's especially instructive to look at "commit" objects, since
- those tend to be small and fairly self-explanatory. In
- particular, if you follow the convention of having the top
- commit name in ".git/HEAD", you can do
-
- cat-file commit $(cat .git/HEAD)
-
- to see what the top commit was.
-
- 7) Merging multiple trees
-
- Git helps you do a three-way merge, which you can expand to
- n-way by repeating the merge procedure arbitrary times until you
- finally "commit" the state. The normal situation is that you'd
- only do one three-way merge (two parents), and commit it, but if
- you like to, you can do multiple parents in one go.
-
- To do a three-way merge, you need the two sets of "commit"
- objects that you want to merge, use those to find the closest
- common parent (a third "commit" object), and then use those
- commit objects to find the state of the directory ("tree"
- object) at these points.
-
- To get the "base" for the merge, you first look up the common
- parent of two commits with
-
- merge-base <commit1> <commit2>
-
- which will return you the commit they are both based on. You
- should now look up the "tree" objects of those commits, which
- you can easily do with (for example)
-
- cat-file commit <commitname> | head -1
-
- since the tree object information is always the first line in a
- commit object.
-
- Once you know the three trees you are going to merge (the one
- "original" tree, aka the common case, and the two "result" trees,
- aka the branches you want to merge), you do a "merge" read into
- the index. This will throw away your old index contents, so you
- should make sure that you've committed those - in fact you would
- normally always do a merge against your last commit (which
- should thus match what you have in your current index anyway).
- To do the merge, do
-
- read-tree -m <origtree> <target1tree> <target2tree>
-
- which will do all trivial merge operations for you directly in
- the index file, and you can just write the result out with
- "write-tree".
-
- NOTE! Because the merge is done in the index file, and not in
- your working directory, your working directory will no longer
- match your index. You can use "checkout-cache -f -a" to make the
- effect of the merge be seen in your working directory.
+1) working directory -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- NOTE2! Sadly, many merges aren't trivial. If there are files
- that have been added.moved or removed, or if both branches have
- modified the same file, you will be left with an index tree that
- contains "merge entries" in it. Such an index tree can _NOT_ be
- written out to a tree object, and you will have to resolve any
- such merge clashes using other tools before you can write out
- the result.
+You update the index with information from the working directory with
+the link:git-update-cache.html[git-update-cache] command. You
+generally update the index information by just specifying the filename
+you want to update, like so:
+
+ git-update-cache filename
+
+but to avoid common mistakes with filename globbing etc, the command
+will not normally add totally new entries or remove old entries, ie it
+will normally just update existing cache entryes.
+
+To tell git that yes, you really do realize that certain files no
+longer exist in the archive, or that new files should be added, you
+should use the "--remove" and "--add" flags respectively.
+
+NOTE! A "--remove" flag does _not_ mean that subsequent filenames will
+necessarily be removed: if the files still exist in your directory
+structure, the index will be updated with their new status, not
+removed. The only thing "--remove" means is that update-cache will be
+considering a removed file to be a valid thing, and if the file really
+does not exist any more, it will update the index accordingly.
+
+As a special case, you can also do "git-update-cache --refresh", which
+will refresh the "stat" information of each index to match the current
+stat information. It will _not_ update the object status itself, and
+it wil only update the fields that are used to quickly test whether an
+object still matches its old backing store object.
+
+2) index -> object database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You write your current index file to a "tree" object with the program
+
+ git-write-tree
+
+that doesn't come with any options - it will just write out the
+current index into the set of tree objects that describe that state,
+and it will return the name of the resulting top-level tree. You can
+use that tree to re-generate the index at any time by going in the
+other direction:
+
+3) object database -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You read a "tree" file from the object database, and use that to
+populate (and overwrite - don't do this if your index contains any
+unsaved state that you might want to restore later!) your current
+index. Normal operation is just
+
+ git-read-tree <sha1 of tree>
+
+and your index file will now be equivalent to the tree that you saved
+earlier. However, that is only your _index_ file: your working
+directory contents have not been modified.
+
+4) index -> working directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You update your working directory from the index by "checking out"
+files. This is not a very common operation, since normally you'd just
+keep your files updated, and rather than write to your working
+directory, you'd tell the index files about the changes in your
+working directory (ie "git-update-cache").
+
+However, if you decide to jump to a new version, or check out somebody
+elses version, or just restore a previous tree, you'd populate your
+index file with read-tree, and then you need to check out the result
+with
+ git-checkout-cache filename
+
+or, if you want to check out all of the index, use "-a".
+
+NOTE! git-checkout-cache normally refuses to overwrite old files, so
+if you have an old version of the tree already checked out, you will
+need to use the "-f" flag (_before_ the "-a" flag or the filename) to
+_force_ the checkout.
+
+
+
+Finally, there are a few odds and ends which are not purely moving
+from one representation to the other:
+
+5) Tying it all together
+~~~~~~~~~~~~~~~~~~~~~~~~
+To commit a tree you have instantiated with "git-write-tree", you'd
+create a "commit" object that refers to that tree and the history
+behind it - most notably the "parent" commits that preceded it in
+history.
+
+Normally a "commit" has one parent: the previous state of the tree
+before a certain change was made. However, sometimes it can have two
+or more parent commits, in which case we call it a "merge", due to the
+fact that such a commit brings together ("merges") two or more
+previous states represented by other commits.
+
+In other words, while a "tree" represents a particular directory state
+of a working directory, a "commit" represents that state in "time",
+and explains how we got there.
+
+You create a commit object by giving it the tree that describes the
+state at the time of the commit, and a list of parents:
+
+ git-commit-tree <tree> -p <parent> [-p <parent2> ..]
+
+and then giving the reason for the commit on stdin (either through
+redirection from a pipe or file, or by just typing it at the tty).
+
+git-commit-tree will return the name of the object that represents
+that commit, and you should save it away for later use. Normally,
+you'd commit 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.
+
+6) Examining the data
+~~~~~~~~~~~~~~~~~~~~~
+You can examine the data represented in the object database and the
+index with various helper tools. For every object, you can use
+link:git-cat-file.html[git-cat-file] to examine details about the
+object:
+
+ git-cat-file -t <objectname>
+
+shows the type of the object, and once you have the type (which is
+usually implicit in where you find the object), you can use
+
+ git-cat-file blob|tree|commit <objectname>
+
+to show its contents. NOTE! Trees have binary content, and as a result
+there is a special helper for showing that content, called
+"git-ls-tree", which turns the binary content into a more easily
+readable form.
+
+It's especially instructive to look at "commit" objects, since those
+tend to be small and fairly self-explanatory. In particular, if you
+follow the convention of having the top commit name in ".git/HEAD",
+you can do
+
+ git-cat-file commit $(cat .git/HEAD)
+
+to see what the top commit was.
+
+7) Merging multiple trees
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Git helps you do a three-way merge, which you can expand to n-way by
+repeating the merge procedure arbitrary times until you finally
+"commit" the state. The normal situation is that you'd only do one
+three-way merge (two parents), and commit it, but if you like to, you
+can do multiple parents in one go.
+
+To do a three-way merge, you need the two sets of "commit" objects
+that you want to merge, use those to find the closest common parent (a
+third "commit" object), and then use those commit objects to find the
+state of the directory ("tree" object) at these points.
+
+To get the "base" for the merge, you first look up the common parent
+of two commits with
+
+ git-merge-base <commit1> <commit2>
+
+which will return you the commit they are both based on. You should
+now look up the "tree" objects of those commits, which you can easily
+do with (for example)
+
+ git-cat-file commit <commitname> | head -1
+
+since the tree object information is always the first line in a commit
+object.
+
+Once you know the three trees you are going to merge (the one
+"original" tree, aka the common case, and the two "result" trees, aka
+the branches you want to merge), you do a "merge" read into the
+index. This will throw away your old index contents, so you should
+make sure that you've committed those - in fact you would normally
+always do a merge against your last commit (which should thus match
+what you have in your current index anyway).
+
+To do the merge, do
+
+ git-read-tree -m <origtree> <target1tree> <target2tree>
+
+which will do all trivial merge operations for you directly in the
+index file, and you can just write the result out with "git-write-tree".
+
+NOTE! Because the merge is done in the index file, and not in your
+working directory, your working directory will no longer match your
+index. You can use "git-checkout-cache -f -a" to make the effect of
+the merge be seen in your working directory.
+
+NOTE2! Sadly, many merges aren't trivial. If there are files that have
+been added.moved or removed, or if both branches have modified the
+same file, you will be left with an index tree that contains "merge
+entries" in it. Such an index tree can _NOT_ be written out to a tree
+object, and you will have to resolve any such merge clashes using
+other tools before you can write out the result.
- [ fixme: talk about resolving merges here ]
+[ fixme: talk about resolving merges here ]
-
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
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Junio C Hamano @ 2005-05-12 21:44 UTC (permalink / raw)
To: Sean; +Cc: tglx, Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <2477.10.10.10.24.1115933520.squirrel@linux1>
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> When an object is committed locally it is set to the local time. You can
S> only have this feature when you use private commit objects (shared blobs
S> are okay).
This brings up an interesting possibility, which is off topic
from this thread.
You _could_ (I am not advocating this, just thinking aloud) have
GIT_OBJECT_DIRECTORY and GIT_COMMIT_OBJECT_DIRECTORY pointing at
two separate object pools, with the value of
GIT_COMMIT_OBJECT_DIRECTORY being on
GIT_ALTERNATE_OBJECT_DIRECTORIES list. Your commits go to
GIT_COMMIT_OBJECT_DIRECTORY (local to the tree) and everything
else go to GIT_OBJECT_DIRECTORY (can be shared across trees).
Hmm.... Interesting. My gut feeling tells me not to go there,
though.
^ 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