* Re: [PATCH] Also handle CVS branches with a '/' in their name
From: Junio C Hamano @ 2005-08-17 7:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508170839030.27628@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I track a CVS project which has a branch with a '/' in the branch name.
> Since git wants the branch name to be a file name at the same time,
> translate that character to a '-'. This should work well, despite the
> fact that a division and a difference are completely different :-)
My feeling is that there should be nothing to prevent you from
having a non-flat namespace in .git/refs/heads; i.e. we should
allow ".git/refs/heads/foo/bar". Some of the existing tools may
be forgetting to call either "mkdir -p $(dirname $ref)" if they
are written in shell, or safe_create_leading_directories(ref) in
C, but I consider that is a bug.
^ permalink raw reply
* Re: [PATCH] Also handle CVS branches with a '/' in their name
From: Johannes Schindelin @ 2005-08-17 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6il11wi.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 893 bytes --]
Hi,
On Wed, 17 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I track a CVS project which has a branch with a '/' in the branch name.
> > Since git wants the branch name to be a file name at the same time,
> > translate that character to a '-'. This should work well, despite the
> > fact that a division and a difference are completely different :-)
>
> My feeling is that there should be nothing to prevent you from
> having a non-flat namespace in .git/refs/heads; i.e. we should
> allow ".git/refs/heads/foo/bar".
That may be true, but CVS branches being named "Hänsel/Gretel" do not
logically denote hierarchies. I never ever saw hierarchical CVS branch
names with a "/" separator. I saw some with a "." separator.
My feeling is that it would be wrong to map CVS branch names to a
hierarchy.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Also handle CVS branches with a '/' in their name
From: Junio C Hamano @ 2005-08-17 7:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508170906480.10754@wgmdd8.biozentrum.uni-wuerzburg.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 717 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> That may be true, but CVS branches being named "H^[.A^[Ndnsel/Gretel" do not
> logically denote hierarchies. I never ever saw hierarchical CVS branch
> names with a "/" separator. I saw some with a "." separator.
>
> My feeling is that it would be wrong to map CVS branch names to a
> hierarchy.
Although I've used / in CVS branch names to denote hierarchy,
I now agree with you for a different reason. A CVS repository
can have branches "Hnsel" and "Hnsel/Gretel" at the same time,
which we cannot express it with '/'.
However, this may make CVS tags Hnsel/Gretel and Hnsel-Gretel
clash, so maybe the name mangling should be made somehow
configurable?
^ permalink raw reply
* Re: [PATCH] When copying or renaming, keep the mode, please
From: Junio C Hamano @ 2005-08-17 7:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508170900420.3236@wgmdd8.biozentrum.uni-wuerzburg.de>
Good catch. Thanks.
^ permalink raw reply
* Re: [PATCH] Fixed two bugs in git-cvsimport-script.
From: David Kågedal @ 2005-08-17 8:07 UTC (permalink / raw)
To: git
In-Reply-To: <u5tacjjdpxq.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> The git-cvsimport-script had a copule of small bugs that prevented me
> from importing a big CVS repository.
>
> The first was that it didn't handle removed files with a multi-digit
> primary revision number.
I noticed that this patch was accepted, which is great. But there is
a problem with the character encoding in the commit message.
The commit in question is b0921331030d52febf52839753eee1b2b9ca1f24
The "author" field is written as "iso-8859-1?Q?David_K=E5gedal
<davidk@lysator.liu.se>", which is taken from the "From:" line in my
email. This should be decoded by the patch import script before
generating the commit message.
But the trickier question is what encoding to use in the commit
message.
This is the signed-off line in my mail:
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
This is what appears in the commit:
Signed-off-by: David K?5gedal <davidk@lysator.liu.se>
Using ISO-8859-15 or UTF-8 would probably have made more sense here.
Apparently, my mail was encoded as QP, which is not very popular
around here. But it seems that the diff part was decoded properly
before applying. Was that done manually?
Since my name contains a character that is not part of ASCII, it isn't
really an option to send the mails encoded as ASCII. I could probably
convince my mailer (Gnus) to send it as "8bit" or "binary", but that
is a pretty limited solution. An it isn't even legal to use anything
but ASCII in the mail header.
--
David Kågedal
^ permalink raw reply
* Re: gitk with hyperspace support
From: Sean @ 2005-08-17 8:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vr7ct124c.fsf@assigned-by-dhcp.cox.net>
On Wed, August 17, 2005 2:58 am, Junio C Hamano said:
> Paul Mackerras <paulus@samba.org> writes:
>
>> My reasoning is that it is the local short-range connections which are
>> interesting and informative. The long-range connections aren't really
>> visually informative; if you want to know about the long-range
>> connections, the parent and child lists in the details pane are much
>> more useful.
>
> Correct.
>
> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count. I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed
> that it did not happen. I could click the "Parent" link at that
> point, but then the upward arrow was above and outside the
> visible portion of that pane, which broke visual continuity and
> I lost track at that point. I think my being color challenged
> exacerbated the resulting confusion; otherwise I could have
> probably found the line with the same color as the color of the
> downarrow I clicked.
This change looks really good in gitk and clicking on an arrowhead to hop
to the corresponding arrowhead would sure be great too. There's may be a
way to further reduce the line clutter too; once a line is terminated with
an arrowhead, it could often be trimmed back much further.
For instance looking at Linus' tree:
03938c3f1062b0f279a0ef937a471d4db83702ed
powernow-k8 requires that a data structure for
The line flowing from this commit extends ~200 more commits downward
before it is finally terminated with an arrowhead. It would be nice if
this line could be made shorter, such that the arrowhead was drawn much
closer to commit in question.
Cheers,
Sean
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-17 8:27 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: martin.langhoff, git
Daniel Barkalow wrote:
>>2) Practical: The round trip git-format-patch + git-applymbox is the logical and
>>natural way to reach this goal or, also in this case, I intend to stretch some tools,
>>designed for one thing, for something else?
>
>
>I'd guess that git-diff-tree + git-apply (without the rest of the
>scripting) would be more effective when you're not doing anything with the
>intermediate files, since it saves doing a bunch of formatting and
>parsing.
>
>
It would be surely better, but I need to import also the original subject and
description. I can use git-diff-tree --pretty -p for the patch creation, but this
format is not compatible with git-apply* scripts, and the git command git-apply does
not import subject + description info.
Of course I can feed proper subject and description to git-commit but I would like
to find something less intrusive as possible, ie. one command for patch export, one
command for patch import.
Thanks
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] git-format-patch fix
From: Marco Costalba @ 2005-08-17 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>Introduces --keep-subjects flag to tell it not to munge the
>first line of the commit message. Running "git applymbox" on
>the output from "git format-patch -m -k" would preserve the
>original commit information better this way.
>
>Opinions? Objections?
>
This is exaclty what I was looking for. This indirectly answer also to my
concerns about the method.
Thanks
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Martin Langhoff @ 2005-08-17 9:07 UTC (permalink / raw)
To: Marco Costalba; +Cc: Daniel Barkalow, git
In-Reply-To: <20050817082709.28135.qmail@web26301.mail.ukl.yahoo.com>
On 8/17/05, Marco Costalba <mcostalba@yahoo.it> wrote:
> Of course I can feed proper subject and description to git-commit but I would like
> to find something less intrusive
I don't know if it helps, but I think that StGIT is what you are
looking for, not only because you have more tools to deal with
patches, but also because patches that are in the 'stack' are actually
really malleable. You can edit and reedit the patch w its commit msg
and all, commit it to the stack, and reedit it again later. It only
becomes immutable when you commit to the underlying git repo.
cheers,
martin
^ permalink raw reply
* [PATCH 2nd try] Also handle CVS branches with a '/' in their name
From: Johannes Schindelin @ 2005-08-17 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr3x10rr.fsf@assigned-by-dhcp.cox.net>
I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
substitute that character to a '-' by default (override with "-s <subst>").
This should work well, despite the fact that a division and a difference
are completely different :-)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/git-cvsimport-script.txt | 6 +++++-
git-cvsimport-script | 8 +++++---
2 files changed, 10 insertions(+), 4 deletions(-)
b4327595f6cd2a0a4e573ceb12983765321f4790
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,8 @@ SYNOPSIS
--------
'git-cvsimport-script' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ -i ] [ -k ] [ <CVS_module> ]
+ [ -C <GIT_repository> ] [ -i ] [ -k ]
+ [ -s <subst> ] [ <CVS_module> ]
DESCRIPTION
@@ -69,6 +70,9 @@ OPTIONS
-z <fuzz>::
Pass the timestamp fuzz factor to cvsps.
+-s <subst>::
+ Substitute the character "/" in branch names with <subst>
+
OUTPUT
------
If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
[ -p opts-for-cvsps ] [ -C GIT_repository ] [ -z fuzz ]
- [ -i ] [ -k ] [ CVS_module ]
+ [ -i ] [ -k ] [-s subst] [ CVS_module ]
END
exit(1);
}
-getopts("hivko:d:p:C:z:") or usage();
+getopts("hivko:d:p:C:z:s:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -59,6 +59,7 @@ if($opt_d) {
die "CVSROOT needs to be set";
}
$opt_o ||= "origin";
+$opt_s ||= "-";
my $git_tree = $opt_C;
$git_tree ||= ".";
@@ -621,6 +622,7 @@ while(<CVS>) {
$state = 4;
} elsif($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
+ s/[\/]/$opt_s/g;
$branch = $_;
$state = 5;
} elsif($state == 5 and s/^Ancestor branch:\s+//) {
^ permalink raw reply
* Re: [PATCH] Fixed two bugs in git-cvsimport-script.
From: Junio C Hamano @ 2005-08-17 9:22 UTC (permalink / raw)
To: David =?iso-2022-jp-2?B?SxsuQRtOZWdlZGFs?=; +Cc: git
In-Reply-To: <u5tiry50ywy.fsf@lysator.liu.se>
> Apparently, my mail was encoded as QP, which is not very popular
> around here. But it seems that the diff part was decoded properly
> before applying. Was that done manually?
Yes, the patch had some context conflicts with some other patch
so the patch application was done by hand, and I did a quick and
dirty cut & paste of the commit message from "cat mbox" output.
I will probably drop future patches encoded in QP.
^ permalink raw reply
* Re: gitk with hyperspace support
From: Paul Mackerras @ 2005-08-17 9:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7ct124c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count. I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed
OK, you're the second person to ask for that, so I'll see what I can
do about it. I can think of 3 possible behaviors when you click on
the arrowhead:
1. scroll to bring the other arrowhead on-screen and briefly make it
larger or something similar to draw attention to it
2. scroll to bring the other arrowhead on-screen and warp the pointer
to it
3. select the next commit in the indicated direction which is a child
or parent that the line connects (scroll to make it visible,
highlight it, show its diff).
Which do you think would be best?
> > http://ozlabs.org/~paulus/gitk/gitk.hs
>
> I first thought you rewrote it in Haskell ;-).
Hmmm, maybe it's apache on ozlabs.org that is under that
misapprehension?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] Fixed two bugs in git-cvsimport-script.
From: Junio C Hamano @ 2005-08-17 10:01 UTC (permalink / raw)
To: David =?iso-2022-jp-2?B?SxsuQRtOZWdlZGFs?=; +Cc: git
In-Reply-To: <7v3bp829zj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Yes, the patch had some context conflicts with some other patch
> so the patch application was done by hand, and I did a quick and
> dirty cut & paste of the commit message from "cat mbox" output.
>
> I will probably drop future patches encoded in QP.
This was totally inappropriate; sorry, but I was in a bad mood.
A more serious response.
- I personally consider commit message encoding a per project
issue (so is blob contents encoding). If for example a
project is Japanese only, MS-DOS^WWindows programming
project, I do not think it is unreasonable if all the commit
messages and source files are encoded in Shift-JIS. More
Unixy projects over there might use EUC-JP in source files
and maybe ISO-2022 in the log messages (because the latter is
the standard way to exchange e-mails there). As long as
project participants agree to use the same encodings, things
should work just fine within a project.
- However, weird people are known to merge projects that
started out as totally separate into one. It would be a
disaster for the commit log viewer when this happens. For
this reason, some people recommend using a common deniminator
encoding, namely UTF-8, for commit logs from day one, even if
you do not envision such a merge may happen in the future.
This recommendation also goes to author and committer
identification (but not blob contents). But this is just an
recommendation, and it is still up to the individual project
what encoding to use in the log messages, and the low-level
GIT should not dictate nor interfere; "git-commit-tree" and
"git-cat-file commit" are 8-bit clean.
- The e-mail patch acceptance machinery found in tools/
directory is tuned for the established patch exchange
practice used in the linux-kernel mailing list. No MIME, no
QP, no guarantee to pass things outside ASCII.
- Eventually, tools/mailinfo.c should be taught about MIME to
do at least:
- detect whitespace corrupted patch via sending MUA using
flowed-text and reject it;
- detect multipart PGP signed message, discard the attached
signature which is often useless, and unwrap the payload;
- decode QP and B encodings as necessary, and after splitting
the message to the info, msg and patch part, transliterate
the info and msg part from original encoding to UTF-8 (when
'--utf8' flag is given, perhaps).
One of the requirement there is that it still needs to be
_fast_. Linus needs to be able to make 5 commits per second
out of his mailbox.
So that is the technical part of the response. There is one
Project policy part of the response: I would endorse the
application of that UTF-8 recommendation to the git project
itself, at least in principle.
But that in practice would happen only after the above mailinfo
update takes place. Until then, it is very likely that I will
occasionally fail to spot and to hand-correct people's name left
undecoded the way the patch acceptance machinery passed through
in the log message. Please live with it (or send such patches
to mailinfo ;-).
^ permalink raw reply
* Re: [PATCH] Fixed two bugs in git-cvsimport-script.
From: David Kågedal @ 2005-08-17 10:07 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bp829zj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> Apparently, my mail was encoded as QP, which is not very popular
>> around here. But it seems that the diff part was decoded properly
>> before applying. Was that done manually?
>
> Yes, the patch had some context conflicts with some other patch
> so the patch application was done by hand, and I did a quick and
> dirty cut & paste of the commit message from "cat mbox" output.
>
> I will probably drop future patches encoded in QP.
Ok, but do you have an answer to my real question? What is the
character encoding for commit objects in your git repository?
It is obviously one that is compatible with ASCII, which probably
leaves you with the alternatives ASCII, Latin1, and UTF-8. And plain
ASCII obviously doesn't work very well for me.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Fixed two bugs in git-cvsimport-script.
From: David Kågedal @ 2005-08-17 11:22 UTC (permalink / raw)
To: git
In-Reply-To: <7vacjgyj94.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Yes, the patch had some context conflicts with some other patch
>> so the patch application was done by hand, and I did a quick and
>> dirty cut & paste of the commit message from "cat mbox" output.
>>
>> I will probably drop future patches encoded in QP.
>
> This was totally inappropriate; sorry, but I was in a bad mood.
>
> A more serious response.
>
> - I personally consider commit message encoding a per project
> issue (so is blob contents encoding).
Agreed. And your response is probably good enough for now. I also
think that having UTF-8 as the standard convention is the way to go.
--
David Kågedal
^ permalink raw reply
* [PATCH] Let git-format-patch-script write on stdout
From: Marco Costalba @ 2005-08-17 12:17 UTC (permalink / raw)
To: git
Avoid that git-format-patch writes out patch series
information on stderr when there are no errors
Signed-off-by: Marco Costalba <mcostalba@yahoo.it>
---
git-format-patch-script | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
47238497f48d19a0bf44eb9b23875bbb8e8a12aa
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -146,7 +146,7 @@ do
file=`printf '%04d-%stxt' $i "$title"`
i=`expr "$i" - 1`
- echo >&2 "* $file"
+ echo >&1 "* $file"
{
mailScript='
/./d
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: gitk with hyperspace support
From: Matthias Urlichs @ 2005-08-17 14:37 UTC (permalink / raw)
To: git
In-Reply-To: <17154.33520.584666.701545@cargo.ozlabs.ibm.com>
Hi, Paul Mackerras wrote:
> http://ozlabs.org/~paulus/gitk/gitk.hs
>
Unfortunately, this fails on my git-plus-assorted-crap archive:
can't read "mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283)": no such element in array
can't read "mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283)": no such element in array
while executing
"if {$mainlinearrow($id) ne "none"} {
set mainline($id) [trimdiagstart $mainline($id)]
}"
(procedure "drawcommitline" line 44)
invoked from within
"drawcommitline $dlevel"
(procedure "drawmore" line 65)
invoked from within
"drawmore 1"
(procedure "drawcommit" line 33)
invoked from within
"drawcommit $id"
(procedure "getcommitlines" line 50)
invoked from within
"getcommitlines file23"
Another problem: when I click on a line, I get the parent and *all* its
children, not just the child(ren) on the other end of the segment I was
clicking on.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
There are some micro-organisms that exhibit characteristics of both plants
and animals. When exposed to light they undergo photosynthesis; and when
the lights go out, they turn into animals. But then again, don't we all?
^ permalink raw reply
* First stab at glossary
From: Johannes Schindelin @ 2005-08-17 14:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6614 bytes --]
Hi,
long, long time. Here´s my first stab at the glossary, attached the
alphabetically sorted, asciidoc marked up txt file (Comments?
Suggestions? Pizzas?):
object::
The unit of storage in GIT. It is uniquely identified by
the SHA1 of its contents. Consequently, an object can not
be changed.
SHA1::
A 20-byte sequence (or 41-byte file containing the hex
representation and a newline). It is calculated from the
contents of an object by the Secure Hash Algorithm 1.
object database::
Stores a set of "objects", and an individial object is identified
by its SHA1 (its ref). The objects are either stored as single
files, or live inside of packs.
object name::
Synonym for SHA1.
blob object::
Untyped object, i.e. the contents of a file.
tree object::
An object containing a list of blob and/or tree objects.
(A tree usually corresponds to a directory without
subdirectories).
tree::
Either a working tree, or a tree object together with the
dependent blob and tree objects (i.e. a stored representation
of a working tree).
cache::
A collection of files whose contents are stored as objects.
The cache is a stored version of your working tree. Well, can
also contain a second, and even a third version of a working
tree, which are used when merging.
cache entry::
The information regarding a particular file, stored in the index.
A cache entry can be unmerged, if a merge was started, but not
yet finished (i.e. if the cache contains multiple versions of
that file).
index::
Contains information about the cache contents, in particular
timestamps and mode flags ("stat information") for the files
stored in the cache. An unmerged index is an index which contains
unmerged cache entries.
working tree::
The set of files and directories currently being worked on.
Think "ls -laR"
directory::
The list you get with "ls" :-)
checkout::
The action of updating the working tree to a revision which was
stored in the object database.
revision::
A particular state of files and directories which was stored in
the object database. It is referenced by a commit object.
commit::
The action of storing the current state of the cache in the
object database. The result is a revision.
commit object::
An object which contains the information about a particular
revision, such as parents, committer, author, date and the
tree object which corresponds to the top directory of the
stored revision.
changeset::
BitKeeper/cvsps speak for "commit". Since git does not store
changes, but states, it really does not make sense to use
the term "changesets" with git.
ent::
Favorite synonym to "tree-ish" by some total geeks.
clean::
A working tree is clean, if it corresponds to the revision
referenced by the current head.
dirty::
A working tree is said to be dirty if it contains modifications
which have not been committed to the current branch.
head::
The top of a branch. It contains a ref to the corresponding
commit object.
branch::
A non-cyclical graph of revisions, i.e. the complete history of
a particular revision, which does not (yet) have children, which
is called the branch head. The branch heads are stored in
$GIT_DIR/refs/heads/.
ref::
A 40-byte hex representation of a SHA1 pointing to a particular
object. These are stored in $GIT_DIR/refs/.
head ref::
A ref pointing to a head. Often, this is abbreviated to "head".
Head refs are stored in $GIT_DIR/refs/heads/.
tree-ish::
A ref pointing to either a commit object, a tree object, or a
tag object pointing to a commit or tree object.
tag object::
An object containing a ref pointing to another object. It can
contain a (PGP) signature, in which case it is called "signed
tag object".
tag::
A ref pointing to a tag or commit object. In contrast to a head,
a tag is not changed by a commit. Tags (not tag objects) are
stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
a Lisp tag (which is called object type in git's context).
merge::
To merge branches means to try to accumulate the changes since a
common ancestor and apply them to the first branch. An automatic
merge uses heuristics to accomplish that. Evidently, an automatic
merge can fail.
resolve::
The action of fixing up manually what a failed automatic merge
left behind.
repository::
A collection of refs together with an object database containing
all objects, which are reachable from the refs. A repository can
share an object database with other repositories.
alternate object database::
Via the alternates mechanism, a repository can inherit part of its
object database from another object database, which is called
"alternate".
reachable::
An object is reachable from a ref/commit/tree/tag, if there is a
chain leading from the latter to the former.
chain::
A list of objects, where each object in the list contains a
reference to its successor (for example, the successor of a commit
could be one of its parents).
parent::
A commit object contains a (possibly empty) list of the logical
predecessor(s) in the line of development, i.e. its parents.
fetch::
Fetching a branch means to get the branch's head ref from a
remote repository, to find out which objects are missing from
the local object database, and to get them, too.
pull::
Pulling a branch means to fetch it and merge it.
push::
Pushing a branch means to get the branch's head ref from a remote
repository, find out if it is an ancestor to the branch's local
head ref is a direct, and in that case, putting all objects, which
are reachable from the local head ref, and which are missing from
the remote repository, into the remote object database, and updating
the remote head ref. If the remote head is not an ancestor to the
local head, the push fails.
pack::
A set of objects which have been compressed into one file (to save
space or to transmit them efficiently).
pack index::
Contains offsets into a pack, so the pack can be used instead of
the unpacked objects.
plumbing::
Cute name for core git.
porcelain::
Cute name for programs and program suites depending on core git,
presenting a high level access to core git. Porcelains expose
more of a SCM interface than the plumbing.
object type:
One of the identifiers "commit","tree","tag" and "blob" describing
the type of an object.
SCM::
Source code management (tool).
dircache::
You are *waaaaay* behind.
[-- Attachment #2: Type: TEXT/plain, Size: 9230 bytes --]
GIT Glossary
============
Aug 2005
[[ref_SCM]]SCM::
Source code management (tool).
[[ref_SHA1]]SHA1::
A 20-byte sequence (or 41-byte file containing the hex representation
and a newline). It is calculated from the contents of an
<<ref_object,object>> by the Secure Hash Algorithm 1.
[[ref_alternate_object_database]]alternate object database::
Via the alternates mechanism, a <<ref_repository,repository>> can
inherit part of its <<ref_object_database,object database>> from another
<<ref_object_database,object database>>, which is called "alternate".
[[ref_blob_object]]blob object::
Untyped <<ref_object,object>>, i.e. the contents of a file.
[[ref_branch]]branch::
A non-cyclical graph of revisions, i.e. the complete history of a
particular <<ref_revision,revision>>, which does not (yet) have
children, which is called the <<ref_branch,branch>> <<ref_head,head>>.
The <<ref_branch,branch>> heads are stored in $GIT_DIR/refs/heads/.
[[ref_cache]]cache::
A collection of files whose contents are stored as objects. The
<<ref_cache,cache>> is a stored version of your
<<ref_working_tree,working tree>>. Well, can also contain a second, and
even a third version of a working <<ref_tree,tree>>, which are used when
merging.
[[ref_cache_entry]]cache entry::
The information regarding a particular file, stored in the
<<ref_index,index>>. A <<ref_cache_entry,cache entry>> can be unmerged,
if a <<ref_merge,merge>> was started, but not yet finished (i.e. if the
<<ref_cache,cache>> contains multiple versions of that file).
[[ref_chain]]chain::
A list of objects, where each <<ref_object,object>> in the list contains
a reference to its successor (for example, the successor of a
<<ref_commit,commit>> could be one of its parents).
[[ref_changeset]]changeset::
BitKeeper/cvsps speak for "<<ref_commit,commit>>". Since git does not
store changes, but states, it really does not make sense to use the term
"changesets" with git.
[[ref_checkout]]checkout::
The action of updating the <<ref_working_tree,working tree>> to a
<<ref_revision,revision>> which was stored in the
<<ref_object_database,object database>>.
[[ref_clean]]clean::
A <<ref_working_tree,working tree>> is <<ref_clean,clean>>, if it
corresponds to the <<ref_revision,revision>> referenced by the current
<<ref_head,head>>.
[[ref_commit]]commit::
The action of storing the current state of the <<ref_cache,cache>> in
the <<ref_object_database,object database>>. The result is a
<<ref_revision,revision>>.
[[ref_commit_object]]commit object::
An <<ref_object,object>> which contains the information about a
particular <<ref_revision,revision>>, such as parents, committer,
author, date and the <<ref_tree_object,tree object>> which corresponds
to the top <<ref_directory,directory>> of the stored
<<ref_revision,revision>>.
[[ref_dircache]]dircache::
You are *waaaaay* behind.
[[ref_directory]]directory::
The list you get with "ls" :-)
[[ref_dirty]]dirty::
A <<ref_working_tree,working tree>> is said to be <<ref_dirty,dirty>> if
it contains modifications which have not been committed to the current
<<ref_branch,branch>>.
[[ref_ent]]ent::
Favorite synonym to "<<ref_tree-ish,tree-ish>>" by some total geeks.
[[ref_fetch]]fetch::
Fetching a <<ref_branch,branch>> means to get the
<<ref_branch,branch>>'s <<ref_head_ref,head ref>> from a remote
<<ref_repository,repository>>, to find out which objects are missing
from the local <<ref_object_database,object database>>, and to get them,
too.
[[ref_head]]head::
The top of a <<ref_branch,branch>>. It contains a <<ref_ref,ref>> to the
corresponding <<ref_commit_object,commit object>>.
[[ref_head_ref]]head ref::
A <<ref_ref,ref>> pointing to a <<ref_head,head>>. Often, this is
abbreviated to "<<ref_head,head>>". Head refs are stored in
$GIT_DIR/refs/heads/.
[[ref_index]]index::
Contains information about the <<ref_cache,cache>> contents, in
particular timestamps and mode flags ("stat information") for the files
stored in the <<ref_cache,cache>>. An unmerged <<ref_index,index>> is an
<<ref_index,index>> which contains unmerged <<ref_cache,cache>> entries.
[[ref_merge]]merge::
To <<ref_merge,merge>> branches means to try to accumulate the changes
since a common ancestor and apply them to the first
<<ref_branch,branch>>. An automatic <<ref_merge,merge>> uses heuristics
to accomplish that. Evidently, an automatic <<ref_merge,merge>> can
fail.
[[ref_object]]object::
The unit of storage in GIT. It is uniquely identified by the
<<ref_SHA1,SHA1>> of its contents. Consequently, an
<<ref_object,object>> can not be changed.
[[ref_object_database]]object database::
Stores a set of "objects", and an individial <<ref_object,object>> is
identified by its <<ref_SHA1,SHA1>> (its <<ref_ref,ref>>). The objects
are either stored as single files, or live inside of packs.
[[ref_object_name]]object name::
Synonym for <<ref_SHA1,SHA1>>.
[[ref_pack]]pack::
A set of objects which have been compressed into one file (to save space
or to transmit them efficiently).
[[ref_pack_index]]pack index::
Contains offsets into a <<ref_pack,pack>>, so the <<ref_pack,pack>> can
be used instead of the unpacked objects.
[[ref_parent]]parent::
A <<ref_commit_object,commit object>> contains a (possibly empty) list
of the logical predecessor(s) in the line of development, i.e. its
parents.
[[ref_plumbing]]plumbing::
Cute name for core git.
[[ref_porcelain]]porcelain::
Cute name for programs and program suites depending on core git,
presenting a high level access to core git. Porcelains expose more of a
<<ref_SCM,SCM>> interface than the <<ref_plumbing,plumbing>>.
[[ref_pull]]pull::
Pulling a <<ref_branch,branch>> means to <<ref_fetch,fetch>> it and
<<ref_merge,merge>> it.
[[ref_push]]push::
Pushing a <<ref_branch,branch>> means to get the <<ref_branch,branch>>'s
<<ref_head_ref,head ref>> from a remote <<ref_repository,repository>>,
find out if it is an ancestor to the <<ref_branch,branch>>'s local
<<ref_head_ref,head ref>> is a direct, and in that case, putting all
objects, which are <<ref_reachable,reachable>> from the local
<<ref_head_ref,head ref>>, and which are missing from the remote
<<ref_repository,repository>>, into the remote
<<ref_object_database,object database>>, and updating the remote
<<ref_head_ref,head ref>>. If the remote <<ref_head,head>> is not an
ancestor to the local <<ref_head,head>>, the <<ref_push,push>> fails.
[[ref_reachable]]reachable::
An <<ref_object,object>> is <<ref_reachable,reachable>> from a
<<ref_ref,ref>>/<<ref_commit,commit>>/<<ref_tree,tree>>/<<ref_tag,tag>>,
if there is a <<ref_chain,chain>> leading from the latter to the former.
[[ref_ref]]ref::
A 40-byte hex representation of a <<ref_SHA1,SHA1>> pointing to a
particular <<ref_object,object>>. These are stored in $GIT_DIR/refs/.
[[ref_repository]]repository::
A collection of refs together with an <<ref_object_database,object
database>> containing all objects, which are <<ref_reachable,reachable>>
from the refs. A <<ref_repository,repository>> can share an
<<ref_object_database,object database>> with other repositories.
[[ref_resolve]]resolve::
The action of fixing up manually what a failed automatic
<<ref_merge,merge>> left behind.
[[ref_revision]]revision::
A particular state of files and directories which was stored in the
<<ref_object_database,object database>>. It is referenced by a
<<ref_commit_object,commit object>>.
[[ref_tag]]tag::
A <<ref_ref,ref>> pointing to a <<ref_tag,tag>> or
<<ref_commit_object,commit object>>. In contrast to a <<ref_head,head>>,
a <<ref_tag,tag>> is not changed by a <<ref_commit,commit>>. Tags (not
<<ref_tag,tag>> objects) are stored in $GIT_DIR/refs/tags/. A git
<<ref_tag,tag>> has nothing to do with a Lisp <<ref_tag,tag>> (which is
called <<ref_object,object>> type in git's context).
[[ref_tag_object]]tag object::
An <<ref_object,object>> containing a <<ref_ref,ref>> pointing to
another <<ref_object,object>>. It can contain a (PGP) signature, in
which case it is called "signed <<ref_tag_object,tag object>>".
[[ref_tree]]tree::
Either a <<ref_working_tree,working tree>>, or a <<ref_tree_object,tree
object>> together with the dependent blob and <<ref_tree,tree>> objects
(i.e. a stored representation of a <<ref_working_tree,working tree>>).
[[ref_tree_object]]tree object::
An <<ref_object,object>> containing a list of blob and/or
<<ref_tree,tree>> objects. (A <<ref_tree,tree>> usually corresponds to a
<<ref_directory,directory>> without subdirectories).
[[ref_tree-ish]]tree-ish::
A <<ref_ref,ref>> pointing to either a <<ref_commit_object,commit
object>>, a <<ref_tree_object,tree object>>, or a <<ref_tag_object,tag
object>> pointing to a <<ref_commit,commit>> or <<ref_tree_object,tree
object>>.
[[ref_working_tree]]working tree::
The set of files and directories currently being worked on. Think "ls
-laR"
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Linus Torvalds @ 2005-08-17 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6il2jz8.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> This is a companion patch to the previous format-patch fix.
> With "-k", format-patch can be told not to remove the [PATCH] in
> the original commit, nor to add the [PATCH] on its own.
I think this might be the point in time to just make the "[PATCH]" prefix
go away.
It made much more sense with BK than it does with git: since git keeps
track of "author" and "committer" separately, you can always see when the
committer wasn't the author of the change, which is what the "[PATCH]"
thing was all about.
In other words, at least for the kernel, [PATCH] was a marker that said
"the author didn't commit this directly". Git already has that information
explicitly in the git data.
(Also, with proper "Signed-off-by:" lines it's also always clear that
there were other people involved, and that the author of the patch is
different from the person who applied it).
So I would personally not mind if we just made the "[PATCH]" prefix go
away entirely, or perhaps had a separate flag to "git-applymbox" that told
it to prepend a specific prefix to the Subject: line (which might not be
"[PATCH] " at all) defaulting to "no prefix".
Linus
PS. Another historical reason for marking patches explicitly was that
people were worried that introducing BK would somehow make the old
patch-based submissions be "second-class citizens". It was easy to make
statistics and show that at least half the real changes (as opposed to
merges) were still patch-based. So again, the "PATCH" marker had some
historical relevance, but I don't think it matters any more.
^ permalink raw reply
* Re: gitk with hyperspace support
From: Matthias Urlichs @ 2005-08-17 15:56 UTC (permalink / raw)
To: git
In-Reply-To: <60088.10.10.10.28.1124266400.squirrel@linux1>
Hi, Sean wrote:
> The line flowing from this commit extends ~200 more commits downward
> before it is finally terminated with an arrowhead. It would be nice if
> this line could be made shorter, such that the arrowhead was drawn much
> closer to commit in question.
Good point. The arrowheads tend to get lost otherwise; in my tree, the
problem is even worse since the downward-pointing arrow (drawn in grey) is
directly below a horizontal line connecting two unrelated changes -- which
is *also* grey. That makes the actual arrowhead perceptually invisible.
If the arrow appears directly below a node, you don't get that problem.
Another point I just noticed: The arrows should be directly below
each other, if at all possible; i.e. the one pointing up should be in the
same column as the corresponding arrow pointing down.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Money is the root of all evil, and man needs roots.
^ permalink raw reply
* rc6-git8 Makefile from cg-export and bz2 patch don't agree
From: Sanjoy Mahajan @ 2005-08-17 16:20 UTC (permalink / raw)
To: git
I wanted to get a clean 2.6.12-rc6-git8 tree, so I looked up the commit
id (3edea4833a1efcd43e1dff082bc8001fdfe74b34) at
<http://kernel.org/pub/linux/kernel/v2.6/snapshots/>, updated my .git
repository with
rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
.git/
then did
cg-export /tmp/xyz <commit-id>
Strangely, the Makefile doesn't match what I would get by applying
patch-2.6.13-rc6-git8.bz2. In the exported Makefile,
EXTRAVERSION =-rc6
whereas from the patch, Makefile (line 151 of the diff) has
EXTRAVERSION = -rc6-git8
Was this a case of hand-editing the diff or did I not use the cg/git
commands correctly?
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Catalin Marinas @ 2005-08-17 17:12 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> wrote:
> Suppose a possible scenario involves using a couple of git archives, one
> for releases and stable code, say MAIN, and one for experimental stuff
> or new development, say HEAD.
>
> Suppose there is stuff in HEAD you don't want merged in MAIN, more,
> you need to update MAIN with only a subset of patches in HEAD, peraphs
> in different order. Or simply, you are not interested to see the history
> of the HEAD tree when looking MAIN. All this points could keep you
> from merging.
As others already recommended StGIT, I will just add a simple usage
scenario (I do this with my StGIT repository).
The MAIN/stable repository (or branch) is only managed with GIT, not
StGIT. The HEAD one is managed with StGIT (only, you can use 'stg
clone'). You can create patches, modify them etc. (I updated the
README in the latest snapshot and it contains some kind of tutorial).
Once you want a subset of these patches merged into MAIN, just pop
everything from the stack and only push those you want merged, in the
order you want (if there are some dependencies, the push will fail and
you can correct them or the order). When you are happy with the
patches pushed on the stack, just do a 'git pull <HEAD>' in the MAIN
repository. After this, doing a 'stg pull <MAIN>' in the HEAD one will
mark the patches already integrated into MAIN as empty and you can
safely remove them ('stg clean' does this automatically).
This way I found StGIT useful for maintainers as well, not only for
contributors.
--
Catalin
^ permalink raw reply
* git-format-patch + git-applymbox small issue
From: Marco Costalba @ 2005-08-17 17:18 UTC (permalink / raw)
To: git
Hi,
the round trip
1) git-format-patch --mbox --keep-subject
2) git-applymbox -k
is not perfect for revisions where there is only the subject.
An example is c35a7b8d806317dc1762e36561cbd31c2530dd9c in git archive
Original text is:
Skip merges in format-patch.
After round trip:
Skip merges in format-patch.
git-format-patch-script | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
c35a7b8d806317dc1762e36561cbd31c2530dd9c
I know I'm a bit annoying ;-)
Marco
P.S: I say 'revision', and 'git archive' but are very common also 'commit' and
'git repository'. This is just a silly example where a common dictionary
should be useful.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Add merge detection to git-cvsimport
From: Matthias Urlichs @ 2005-08-17 17:29 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f9050816143646fa4137@mail.gmail.com>
Hi, Martin Langhoff wrote:
> this one is the
> most likely one to be from a bug in cvsps or the cvsimport logic.
That's not a bug in the import logic, just a failure of the CVS-merging
person to be consistent. (Which is hardly news. :-/ )
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Reason:
Bad, toxic entity, that foolish people use when they ought to use
their inner voice, or angels, or intuition, or a gut feeling, or
their hearts, or the I Ching.
-- Fashionable Dictionary (www.butterfliesandwheels.com)
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Johannes Schindelin @ 2005-08-17 17:32 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050817171844.57566.qmail@web26301.mail.ukl.yahoo.com>
Hi,
On Wed, 17 Aug 2005, Marco Costalba wrote:
> P.S: I say 'revision', and 'git archive' but are very common also
> 'commit' and 'git repository'. This is just a silly example where a
> common dictionary should be useful.
How about the glossary, which I posted a few hours ago?
Ciao,
Dscho
^ 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