* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <20061201104256.GQ12463MdfPADPa@greensroom.kotnet.org>
On Friday 2006 December 01 10:42, Sven Verdoolaege wrote:
> He showed it to you in the example. The "submodule object" is the COMMIT
> of the submodule itself.
That's no different from mine. I need more detail than that.
Is that commit in the submodule or the supermodule? If it's in the submodule
then we're talking about the same thing, as that's all I want. If it's in
the supermodule then I want to know what the tree object that that commit
points to contains. I also want to know how we tell the difference between a
commit-in-supermodule and a
commit-in-supermodule-which-is-actually-in-submodule.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-12-01 11:00 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vlklranrt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> What's wrong is that the ancestry graph around that commit
> roughly looks like this:
>
> z---o---o---o
> / \
> 808239a--v1.4.3--o---*---o---v1.4.4
> ...
> While what blame outputs is technically correct, it is not very
> useful for this kind of application. As you said, it probably
> makes sense to gray-out the lines that are blamed on boundary
> commits.
>
> Side note: one might be tempted to say "then blame v1.4.3 for
> lines that 808239a is blamed for", but that is a good
Gaah. "that is NOT a good workaround". Sorry about the wasted
bandwidth.
> workaround. The original command line could have more than one
> bottom commits, and the final blame might go to a common
> ancestor of them, and we need to randomly choose between them,
> which is worse than telling the truth as we currently do.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 11:00 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612010902.51264.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6668 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 09:02:48AM +0000, Andy Parkins wrote:
> On Thursday 2006 November 30 17:06, Martin Waitz wrote:
>
> > You can easily have several topic-branches and merge updates from the
> > master branch.
> > otherwise you always have to remember which branch holds your current
> > contents from the supermodule.
>
> WHAT? I've got to make merges (that I don't necessarily want) in
> order to commit in the supermodule? This completely negates any
> useful functioning of branches in the submodule. I want to be able to
> make a quick development branch in the submodule and NOT merge that
> code into master and then be able to still commit that in the
> supermodule.
exactly!
Please think about it.
If you track HEAD, then this means that you track HEAD.
In _both_ directions!
So you not only store your submodule HEAD commit in the supermodule when you
do commit to the supermodule, it also means that your submodule HEAD
will be updated when you update your supermodule.
And what happens if you already commited something to HEAD in the mean
time? Exactly: a merge is needed.
And you are right: you might not want to do this now, because you
branched off, because you _wanted_ to have some development which is
_independent_ to the current supermodule work.
So tracking HEAD really makes branching in the submodule hard to work
with.
What does the supermodule provide to the submodule? It stores one
reference to a commit sha1. Just like a reference inside refs/heads
inside the submodule. There really is not much difference between the
sha1 stored inside the supermodules tree and one stored inside refs/.
So from the submodules point of view, the supermodule is not much more
then one special branch.
But it is not possible to use the supermodule index directly as one
"magic" branch for several reasons.
So we need synchronization methods between the index entry for the
submodule which is stored in the supermodule and the references in the
submodule. These are git-update-index/git-commit and git-checkout, both
called explicitly or implicitly in the supermodule.
And I really think it makes sense to have a one-to-one relationship
between the submodule "branch" stored in the supermodule and the
branchname used in the submodule.
> I think you're imagining the binding between the super and sub is very much
> tighter than it should be. What if I'm working on a development version of
> the supermodule, which includes a stable version of the submodule? Vice
> versa?
I don't see your problem here.
> > When viewed from the supermodule, you are storing one branch per
> > submodule in your tree.
>
> That prevents me "trying something out" on a topic branch in the submodule.
> Here's a scenario using my suggested "supermodule tracks submodule HEAD"
> method.
>
> * You're developerA
> * Make a development branch in the supermodule
> * In the submodule, make a whole load of topic branches
> * Make a development branch in the submodule
> * Merge the topic branches into the development branch of the submodule
> * Commit in the supermodule. This capture
> * Tag that commit "my-tested-arrangement-of-submodule-features"
> * Push that tag to the central repository - tell the world.
> * DeveloperB checks out that tag and tries it. Great stuff.
This is still supposed to be a distributed system.
DeveloperB does not only check out the whole project including several
modules. He is also supposed to _work_ with it.
What if DeveloperB also has several topic branches?
When he checks out the new supermodule, only his current HEAD in the
submodule will be updated.
So he first has to change to some supermodule-tracking branch inside the
submodule, then pull the supermodule updates, then eventually merge the
new contents of his supermodule-tracking branch into his topic branches.
So why not make this "let's update one supermodule-tracking-branch"
automatic?
> Now: here's the secret fact that I didn't tell you that will break
> your "supermodule tracks submodule branch" method. DeveloperB has
> decided to have this in his remote:
> Pull: refs/heads/master:refs/heads/upstream/master
> Oops. The supermodule, which has been told to track the "master"
> branch in the submodule is tracking different things in developerA's
> repository from developerB's repository.
So what? He can do to the repository whatever he wants?
He wants to change one submodule to a different branch?
He can do so!
But please do not expect the system to magically be able to resolve
problems. If you _by intent_ changed the submodule to another branch
which is incompatible to the one used in the submodule you can't expect
that this is magically merged.
This is the same as with normal files.
Sure you can replace one file with new contents that are different to
the one used by someone else. Don't expect this can be merged
automatically. So now you have two forks/branches of the project.
So what?
Same for a system including submodules:
If you change one submodule to a totally different branch, then you
effectivley forked/branched the entire project.
(Nomenclature is a bit difficult here: what I mean by totally different
branch is: the submodule commit tracked by the supermodule is not
directly connected to the one tracked by an old version of the
supermodule).
So whenever you introduce conflicting changes somewhere in the project
(be it in a submodule or in a file) you _always_ fork/branch the entire
project (i.e. the topmost supermodule).
You can't circumvent that.
So what are submodule branches good for then?
To store other lines of development which are not yet / not any more
tracked by the supermodule. Perhaps you store references to branches
stored in another supermodule, or another standalone repository.
Or a temporary branch which is only used for testing.
There are really many possiblilities.
But they all have one thing in common: they are not meant to be tracked
by the supermodule.
> Branches are completely arbitrary per-repository.
Yes, but a submodule is special here: it really has one special branch.
The module is not independent any more. That is the _nature_ of a
submodule.
> You cannot rely on them being consistent between different
> repositories.
Sure, we are in a distributed system.
But the supermodule always has to know which branch in the submodule has
to be tracked. The easiest thing is to always use the default
refs/heads/master. Surely this could be changed if there is a need.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-12-01 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <ekn0ne$nuk$1@sea.gmane.org>
On Thursday 2006 November 30 16:28, Jakub Narebski wrote:
> Insount on #git pointed out fragility of this solution with respect
> to adding/removing/moving files, which dirties index (which might not be
> understood by newbie user: "git commit" used to work, but doesn't work the
> same when I added some files).
It does, provided they only added files and didn't change anything else. If
they did then we're out of it for this patch anyway.
Anyway, this is only meant to help ease people into the index. As discussed
elsewhere, hiding the index is a silly policy.
This patch isn't /just/ for the newbies by the way (who are already confused,
so that hasn't changed), I know about the index, but I still like it.
Remember, all it's really saying is "when commit would do nothing, do
something". So it only takes away an option that you can't have been using
anyway because it didn't do anything.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-12-01 10:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061201081117.GA20025@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 28, 2006 at 04:57:00PM -0800, Junio C Hamano wrote:
>
>> > The top 15 for v1.4.3 to v1.4.4 are:
>> >
>> > 1604 6973dcaee76ef7b7bfcabd2f26e76205aae07858 Libify diff-files.
>>
>> Something is SERIOUSLY wrong.
>>
>> That commit is not even between v1.4.3 and v1.4.4.
>
> Hmm, you're right. I haven't quite figured out what went wrong with the
> script I posted. However, a somewhat simpler approach is to just use the
> revision limiting in git-blame. The problem with this is that commits
> whose parents aren't in the revision range end up getting blamed for a
> lot of lines they're not responsible for.
The way you used "-S rev" was wrong. It is a way to temporarily
install grafts and nothing else; but your grafts introduced that
way exactly matched the true parenthood except for the bottom
commit and side branches merged during the timeframe leaked
right through your grafts. The digger started from your HEAD
(whatever that happened to be) along with the true parenthood
and found an way ancient ancestor.
A "bit more correct" script would have been something like this.
-- >8 --
#!/bin/sh
#
# Usage: sh ./run-me v1.4.3 v1.4.4
#
bottom=${1?bottom} top=${2?top}
bottom=$(git rev-parse --verify "$bottom^0")
range="$bottom..$top"
top=$(git rev-parse --verify "$top^0")
for path in $(git diff --name-only -r --diff-filter=AM "$range")
do
echo >&2 "* $path"
git blame -l -C "$range" -- "$path"
done | sed -e 's/ .*//' | sort | uniq -c | sort -n -r |
while read num hash
do
test "$hash" = "$bottom" && continue
it=$(git rev-list --pretty=oneline --abbrev --abbrev-commit -1 "$hash")
printf '%6d %s\n' $num "$it"
done
-- 8< --
But as you correctly observed, even the above script is wrong.
The top one blamed with the above script is this commit:
8301 808239a Merge branch 'sk/ftp'
But that is an ancestor of v1.4.3!
What's wrong is that the ancestry graph around that commit
roughly looks like this:
z---o---o---o
/ \
808239a--v1.4.3--o---*---o---v1.4.4
The pickaxe passes the blame around to the parents but does not
allow a "boundary" commits to pass the blame to their parents.
As the result, the blame at the commit marked with '*' are split
along both branches, and after the leftmost commit 'z' passes
its blame to its parent, it stops there and ends up blaming
808239a, which is an ancestor of the original "boundary" commit
v1.4.3 given from the command line. What's wrong with my script
quoted above is that the filter that checks $hash with $bottom;
it needs to check if $hash is an ancestor of $bottom.
With that change, the top commits are:
1109 9f613dd Add git-for-each-ref: helper for language bindings
1087 cee7f24 git-pickaxe: blame rewritten.
218 c31820c Make git-branch a builtin
209 636171c make index-pack able to complete thin packs.
200 fe142b3 Rework cvsexportcommit to handle binary files for all cases.
which looks a bit more reasonable (I did not realize
for-each-ref was that big, but in fact it has its own
mini-language).
While what blame outputs is technically correct, it is not very
useful for this kind of application. As you said, it probably
makes sense to gray-out the lines that are blamed on boundary
commits.
Side note: one might be tempted to say "then blame v1.4.3 for
lines that 808239a is blamed for", but that is a good
workaround. The original command line could have more than one
bottom commits, and the final blame might go to a common
ancestor of them, and we need to randomly choose between them,
which is worse than telling the truth as we currently do.
And here is an experimental patch to do that.
-- >8 --
[PATCH] git-blame: mark lines blamed on boundary commits.
Lines can be blamed on a commit that is older than the boundary
commit given on the command line when a merge with a branch that
forked before the boundary is involved. Mark them specially so
that later changes in the interested area can be easily
identified.
In porcelain format, their header line that describe the commit
gets an extended attribute line "boundary". In human format,
the commit SHA-1 are prefixed with a '-' character.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-blame.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index dc3ffea..46a9d0e 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1090,6 +1090,11 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
if (!(commit->object.flags & UNINTERESTING) &&
!(revs->max_age != -1 && commit->date < revs->max_age))
pass_blame(sb, suspect, opt);
+ else {
+ commit->object.flags |= UNINTERESTING;
+ if (commit->object.parsed)
+ mark_parents_uninteresting(commit);
+ }
/* Take responsibility for the remaining entries */
for (ent = sb->ent; ent; ent = ent->next)
@@ -1273,6 +1278,8 @@ static void emit_porcelain(struct scoreboard *sb, struct blame_entry *ent)
printf("committer-tz %s\n", ci.committer_tz);
printf("filename %s\n", suspect->path);
printf("summary %s\n", ci.summary);
+ if (suspect->commit->object.flags & UNINTERESTING)
+ printf("boundary\n");
}
else if (suspect->commit->object.flags & MORE_THAN_ONE_PATH)
printf("filename %s\n", suspect->path);
@@ -1308,8 +1315,14 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
cp = nth_line(sb, ent->lno);
for (cnt = 0; cnt < ent->num_lines; cnt++) {
char ch;
+ int length = (opt & OUTPUT_LONG_OBJECT_NAME) ? 40 : 8;
+
+ if (suspect->commit->object.flags & UNINTERESTING) {
+ length--;
+ putchar('-');
+ }
- printf("%.*s", (opt & OUTPUT_LONG_OBJECT_NAME) ? 40 : 8, hex);
+ printf("%.*s", length, hex);
if (opt & OUTPUT_ANNOTATE_COMPAT)
printf("\t(%10s\t%10s\t%d)", ci.author,
format_time(ci.author_time, ci.author_tz,
^ permalink raw reply related
* Re: [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-12-01 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0611300914u521a5351idde23618c2fbf017@mail.gmail.com>
On Thursday 2006 November 30 17:14, Alex Riesen wrote:
> The is dangerous on filesystems which lie to the programs about file
> metadata. The "virtual filesystem" of cygwin is one of this kind: exec-bit
> of the files depend
> on its contents. Just calling git-commit -a will commit executability
> at this particular
> moment. For whatever reason, disabling handling of the exec-mode in gits
> config does not work.
Surely this is a separate fault?
> If you about to change the behaviour, provide at least a config option
> to go back
> to the old git-commit, which didn't do any magic.
Wasn't the whole point of this to avoid needing another config option?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-12-01 10:42 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Martin Waitz
In-Reply-To: <200612011029.28059.andyparkins@gmail.com>
On Fri, Dec 01, 2006 at 10:29:26AM +0000, Andy Parkins wrote:
> I notice though that you avoided my question: what does YOUR submodule object
> contain?
He showed it to you in the example. The "submodule object" is the COMMIT
of the submodule itself.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 10:38 UTC (permalink / raw)
To: git
In-Reply-To: <456FF6D1.4040500@op5.se>
On Friday 2006 December 01 09:33, Andreas Ericsson wrote:
> True, but this makes one repo of the submodule special. Let's say you
> have this layout
In a way, but it's information that doesn't need to be transmitted.
> mozilla/.git
> mozilla/openssl/.git
> mozilla/xlat/.git
>
> Now, we can be reasonably sure that the 'xlat' repo is something the
> mozilla core team can push to, or at least we can consider the core repo
> owners an official "vendor" of tags for the submodule repo. I'm fairly
> certain openssl authors won't be too happy with allowing the thousands
> of projects using its code to push tags to its official repo though.
No need, when cloning a supermodule, it will make those special tags
automatically in the submodule repo. They are only there to prevent prune
from destroying those referenced commits after all. If the submodule is
cloned directly, they aren't needed anyway, and those objects won't be part
of the dependency chain so wouldn't be downloaded.
> Now that I think about it more, I realize this is completely irrelevant
> as the ui can create the tags in the submodule with info only from the
> the supermodule, which means the submodule repo will only be special if
> it's connected to the supermodule. We just need a command for creating
> those tags in the submodule repo so people who use the same submodule
> code for several projects can use the alternates mechanism effectively.
Is that even necessary? git-clone of a supermodule will make those tags
automatically. If a submodule was alternative-cloned into a different
supermodule, well then THAT supermodule would make the right tags for itself.
Ah, I think I see what you mean now though, a method would be needed for
creating those tags if we managed to manually get a submodule repository in
to the supermodule - then supermodule-clone wouldn't have run. Perhaps they
could be checked for at commit time and recreated then?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 10:29 UTC (permalink / raw)
To: git; +Cc: Martin Waitz
In-Reply-To: <20061201095751.GK18810@admingilde.org>
On Friday 2006 December 01 09:57, Martin Waitz wrote:
> So why do you need the url hint committed to the supermodule?
> We don't store remote information in the object database, too.
That's why it was a hint, probably configured when you first create the
submodule connection.
> Remember: this is still a distributed project, there is no one URL to
> any submodule.
That point applies equally to your "tracking a submodule branch" point, except
mine is only a URL hint, to help when first cloning that supermodule. In
truth, the clone will be perfectly able to get the submodule objects from the
upstream supermodule, maintaining the distributed nature easily.
> > I say:
> > submodulecommithash points at a commit /in the submodule/
>
> But unluckily, this does not work.
Eh? "Not work", we're talking about code that doesn't even exist, of course
it doesn't "work". Do you mean "doesn't work if we're using my
implementation of submodules"? Well that hardly seems like a fair attack.
> You really have to be able to traverse the entire commit chain
> from the supermodule into all submodules.
You can: when you hit a submodule tree object you set GIT_DIR to that
submodule and continue. If you don't do it like that then you have stored
submodule trees in the supermodule and it's no longer a separate repository.
Why you'd want to - I have no idea. What purpose would you have for
traversing the commit chain into the submodules? The commit in the submodule
is just a note of where that submodule was during the supermodule commit in
question.
I notice though that you avoided my question: what does YOUR submodule object
contain? I really do want to know, as there is obviously a fundamental
difference in what I think a submodule does and what you (and maybe everybody
else) thinks a submodule does. I'm perfectly willing to accept I'm wrong,
but not without understanding how your method is going to work.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 10:19 UTC (permalink / raw)
To: git, skimo
In-Reply-To: <20061201093244.GP12463MdfPADPa@greensroom.kotnet.org>
On Friday 2006 December 01 09:32, Sven Verdoolaege wrote:
> This is heresy. Any object referenced in a tree should be in the repo
> (possibly via alternates).
The "submodule" object would be in the local repository. That would refer to
another object, and is merely part of the submodule object. Just as
the "Author" and "Commiter" fields are part of the commit object but aren't
actual objects in the tree.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 9:57 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612010919.06030.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 09:19:04AM +0000, Andy Parkins wrote:
> Let's imagine a supermodule repository, and guess at it in more detail (I'll
> abbreviate some of the less interesting output):
>
> $ git-cat-file -p HEAD
> tree fb02e78085ecf2f29045603df858b5362e5bf8a4
> parent 4f2dba685507e4a8e07dac298c4024feaec6bd7d
> author Andy Parkins
> committer Andy Parkins
> $ git-cat-file -p fb02e78085ecf2f29045603df858b5362e5bf8a4
> 100644 blob 46bd4e284a57e2faa539e7b72d62a38867075af5 Makefile
> 040000 tree 49ea01373a986a3db44d66702714aa75059ffa2c doc
> 040000 subm d0a877464dc0198667a3e27ed3af8448ddacf947 libxcb
at the moment, it is:
140000 commit ccddf1d4b0cf7fd3a699d8b33cf5bc4c5c4435b7 libxcb
> The "subm" type is our new ODB object that's going to store whatever we will
> need to access the submodule. "libxcb" has already told us where this
> submodule is in the supermodule tree.
>
> $ git-cat-file -p d0a877464dc0198667a3e27ed3af8448ddacf947
> submodulecommithash ccddf1d4b0cf7fd3a699d8b33cf5bc4c5c4435b7
> submoduleurlhint git://anongit.freedesktop.org/git/xcb/libxcb
So why do you need the url hint committed to the supermodule?
We don't store remote information in the object database, too.
Remember: this is still a distributed project, there is no one URL to
any submodule.
> I say:
> submodulecommithash points at a commit /in the submodule/
But unluckily, this does not work.
You really have to be able to traverse the entire commit chain
from the supermodule into all submodules.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git and bzr
From: Andreas Ericsson @ 2006-12-01 9:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, bazaar-ng
In-Reply-To: <ekndmb$7e9$1@sea.gmane.org>
Jakub Narebski wrote:
> Theodore Tso wrote:
>
>> * When no <ent> is given, the working tree and the index file
>> is compared, using git-diff-files.
>
> * When no <tree-ish> is given, the working tree and the index file are
> compared, using git-diff-files.
>
> Use more modern git.
More modern git (pull'ed 10 minutes ago) has this, at least when cut
from Documentation/git-diff.txt:
---%<---%<---%<---
SYNOPSIS
--------
'git-diff' [ --diff-options ] <tree-ish>{0,2} [<path>...]
DESCRIPTION
-----------
Show changes between two trees, a tree and the working tree, a
tree and the index file, or the index file and the working tree.
The combination of what is compared with what is determined by
the number of trees given to the command.
* When no <tree-ish> is given, the working tree and the index
file are compared, using `git-diff-files`.
* When one <tree-ish> is given, the working tree and the named
tree are compared, using `git-diff-index`. The option
`--index` can be given to compare the index file and
the named tree.
`--cached` is a deprecated alias for `--index`. It's use is
discouraged.
* When two <tree-ish>s are given, these two trees are compared
using `git-diff-tree`.
---%<---%<---%<---
This needs an update, I think. I'll look into it on sunday if no-one's
beaten me to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] git-add update with all-0 object
From: Andy Parkins @ 2006-12-01 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612010223010.20138@iabervon.org>
On Friday 2006 December 01 08:10, Daniel Barkalow wrote:
> My position on this subject is that "index" is a good name, but that
> description is a terrible description, and "index" is a word that needs a
> good description in context. If we just said up front:
If we need to explain what "index" means in the context of diff then it's not
a good name :-)
An index /everywhere else/ is a lookup table. topic->page number;
author->book title. record id->byte position. There is never any content in
an index, indices just point at content.
I imagine that's how git's index got it's name. (I'm only guessing as I've
not looked at what's actually inside git's "index"). Here's my guess:
git update-index file1 hashes file1, stores it somewhere under that hash and
writes the hash->filename connection to .git/index. That is why git's index
is called an index. It's a hash->filename index.
Unfortunately, "index" in colloquial git actually means the combination
of .git/index plus the hashed file itself. That's no longer an index, it's
a "book". :-)
It's made worse, I think, by the fact that git doesn't want to do any
index-like things with the "index". Being content-oriented rather than
name-oriented means that an entry like "file1->NOTHING" is impossible in git.
This leads to the sort of "git-add means track this filename" confusion that
turns up a lot with new users.
It's probably all too late to change the nomenclature, but I've always been of
the opinion that names are important, they confer meaning. When we use a
common word, with common meaning and deviate from that common meaning we are
bound to create confusion. New users don't have any "git-way-of-thinking"
knowledge when they begin, so when they hear "index" they can only fall back
on their standard understanding of that word. We shouldn't be surprised then
when new users don't get "the index".
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-01 9:33 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612010849.11176.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2006 November 30 18:57, Andreas Ericsson wrote:
>
> (agree with everything in your mail)
>
>> The only problem I'm seeing atm is that the supermodule somehow has to
>> mark whatever commits it's using from the submodule inside the submodule
>> repo so that they effectively become un-prunable, otherwise the
>> supermodule may some day find itself with a history that it can't restore.
>
> What about submodule/.git/refs/supermodule/commit12345678, where "12345678" is
> the hash of the supermodule commit? This gives a convenient route in the
> submodule to which commit contains that commit from the submodule; but
> doesn't write anything into the submodule repository itself. It's just a tag
> with a different intent.
>
True, but this makes one repo of the submodule special. Let's say you
have this layout
mozilla/.git
mozilla/openssl/.git
mozilla/xlat/.git
Now, we can be reasonably sure that the 'xlat' repo is something the
mozilla core team can push to, or at least we can consider the core repo
owners an official "vendor" of tags for the submodule repo. I'm fairly
certain openssl authors won't be too happy with allowing the thousands
of projects using its code to push tags to its official repo though.
Now that I think about it more, I realize this is completely irrelevant
as the ui can create the tags in the submodule with info only from the
the supermodule, which means the submodule repo will only be special if
it's connected to the supermodule. We just need a command for creating
those tags in the submodule repo so people who use the same submodule
code for several projects can use the alternates mechanism effectively.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-12-01 9:32 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612010001.57111.andyparkins@gmail.com>
On Fri, Dec 01, 2006 at 12:01:54AM +0000, Andy Parkins wrote:
> On Thursday 2006, November 30 16:33, Sven Verdoolaege wrote:
> > > Well, I know what the commit is /that/ was all that was stored. So I
> >
> > Then I have no idea what you are talking about.
> > A commit _contains_ all the history that lead up to that commit,
> > so if you have the commit, then you also have the history.
>
> It's not so much an actual commit, as a reference to a commit in another
> repository.
This is heresy. Any object referenced in a tree should be in the repo
(possibly via alternates).
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Han-Wen Nienhuys @ 2006-12-01 9:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
In-Reply-To: <456FEB53.7080703@op5.se>
Andreas Ericsson escreveu:
> Carl Worth wrote:
>>
>> See? Git _is_ harder to learn, and a user really cannot learn it
>> without being careful about the index right from the very beginning.
>>
>
> I'm not so sure about that. I came from CVS / SVN, although I've fiddled
> quite a bit with other scm's as well. The two-step commit process of git
> didn't terrify me at all, and I had used git at least a month before I
> joined the mailing-list and found out that there's this thing called an
I still don't know exactly how to operate adds and commits from the
command line. I regularly get bitten by not supplying the -a and -i
options.
I'm coming from darcs, where you can select which each diff hunk
to put in a commit separately.
However, I almost never do that. I operate git like darcs, from the
emacs support mode. I almost never do -a commits anyway, because with
emacs (M-x git-status) it's more natural to make functionally distinct
commits, at the risk of introducing non-tested tree states in the
repository.
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 9:19 UTC (permalink / raw)
To: git
In-Reply-To: <456F0153.5000107@b-i-t.de>
On Thursday 2006 November 30 16:05, sf wrote:
> Step 2: You commit to myproject. myproject now contains a new commit
> object in path libxcb. (How to do that is up to the UI but at the
> repository level the outcome should be obvious). This commit is local to
> your repository.
Let's imagine a supermodule repository, and guess at it in more detail (I'll
abbreviate some of the less interesting output):
$ git-cat-file -p HEAD
tree fb02e78085ecf2f29045603df858b5362e5bf8a4
parent 4f2dba685507e4a8e07dac298c4024feaec6bd7d
author Andy Parkins
committer Andy Parkins
$ git-cat-file -p fb02e78085ecf2f29045603df858b5362e5bf8a4
100644 blob 46bd4e284a57e2faa539e7b72d62a38867075af5 Makefile
040000 tree 49ea01373a986a3db44d66702714aa75059ffa2c doc
040000 subm d0a877464dc0198667a3e27ed3af8448ddacf947 libxcb
The "subm" type is our new ODB object that's going to store whatever we will
need to access the submodule. "libxcb" has already told us where this
submodule is in the supermodule tree.
$ git-cat-file -p d0a877464dc0198667a3e27ed3af8448ddacf947
submodulecommithash ccddf1d4b0cf7fd3a699d8b33cf5bc4c5c4435b7
submoduleurlhint git://anongit.freedesktop.org/git/xcb/libxcb
Here "submodulecommithash" is telling us what commit in the submodule is
stored in this supermodule tree. The "submoduleurlhint" is to help when
git-clone is used to clone this supermodule.
They key thing I wanted to point out here is the line:
submodulecommithash ccddf1d4b0cf7fd3a699d8b33cf5bc4c5c4435b7
This is the ONLY link you have to the submodule. I think this line represents
the fundamental difference between our thinking on submodules.
I say:
submodulecommithash points at a commit /in the submodule/
You say:
"This commit is local to your repository". i.e. it points at a commit in
the supermodule, which in turn implies that the local commit object points
at a local tree and local parents.
My question is therefore: tell me what that local commit's tree and parent's
are? At the moment I am having difficulty understanding what meaningful
things you could have in those fields.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 9:02 UTC (permalink / raw)
To: git
In-Reply-To: <20061130170625.GH18810@admingilde.org>
On Thursday 2006 November 30 17:06, Martin Waitz wrote:
> You can easily have several topic-branches and merge updates from the
> master branch.
> otherwise you always have to remember which branch holds your current
> contents from the supermodule.
WHAT? I've got to make merges (that I don't necessarily want) in order to
commit in the supermodule? This completely negates any useful functioning of
branches in the submodule. I want to be able to make a quick development
branch in the submodule and NOT merge that code into master and then be able
to still commit that in the supermodule.
I think you're imagining the binding between the super and sub is very much
tighter than it should be. What if I'm working on a development version of
the supermodule, which includes a stable version of the submodule? Vice
versa?
> When viewed from the supermodule, you are storing one branch per
> submodule in your tree.
That prevents me "trying something out" on a topic branch in the submodule.
Here's a scenario using my suggested "supermodule tracks submodule HEAD"
method.
* You're developerA
* Make a development branch in the supermodule
* In the submodule, make a whole load of topic branches
* Make a development branch in the submodule
* Merge the topic branches into the development branch of the submodule
* Commit in the supermodule. This capture
* Tag that commit "my-tested-arrangement-of-submodule-features"
* Push that tag to the central repository - tell the world.
* DeveloperB checks out that tag and tries it. Great stuff.
Now: here's the secret fact that I didn't tell you that will break
your "supermodule tracks submodule branch" method. DeveloperB has decided to
have this in his remote:
Pull: refs/heads/master:refs/heads/upstream/master
Oops. The supermodule, which has been told to track the "master" branch in the
submodule is tracking different things in developerA's repository from
developerB's repository. Worse, what if developerB did this:
Pull: refs/heads/master:refs/heads/development
Pull: refs/heads/development:refs/heads/master
Branches are completely arbitrary per-repository. You cannot rely on them
being consistent between different repositories. If you store the name of a
submodule branch in a supermodule - that supermodule is only valid for that
one special case of your particular version of the submodule.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Andreas Ericsson @ 2006-12-01 8:59 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Carl Worth, Theodore Tso,
Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0611301624430.9647@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 30 Nov 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>>> ... But let me repeat my last question:
>>>
>>> Would it make sense for "git add" to do the same as "git update-index"
>>> on already tracked files? Given the explanation above this would make
>>> 100% sense to me.
>> I think this makes sense and what we did in the original "git
>> add".
>
> Wonderful! We might be converging to something then.
>
> Because, conceptually, it then becomes much easier to tell newbies about
> the index as follows (this could be pasted in a tutorial somewhere):
>
> Contrary to other SCMs, with GIT you have to explicitly "add" all
> the changes you want to commit together. This can be done in a few
> different ways:
>
> 1) By using "git add <file_spec...>"
>
> This can be performed multiple times before a commit. Note that
> this is not only for adding new files. Even modified files must be
> added to the set of changes about to be committed. The "git
> status" command gives you a summary of what is included so far for
> the commit. When done you should use the "git commit" command to
> make it real.
>
> Note: don't forget to "add" a file again if you modified it after
> the first "add" and before "commit". Otherwise only the previous
> "added" state of that file will be committed.
>
"This is because git tracks content, so what you're really 'add'ing to
the commit is the *content* of the file in the state it is in when you
'add' it."
> 2) By using "git commit -a" directly
>
> This is a quick way to automatically "add" all modified files to
.. "add" all tracked and modified files to ...
> the set of changes and perform the actual commit without having to
> separately "add" them. This will not "add" new files -- those
> files still have to be added explicitly before performing a commit.
>
> Here's a twist. If you do "git commit <file1> <file2> ..." then
> only the changes belonging to those explicitly specified files will
> be committed, entirely bypassing the current "added" changes. Those
> "added" changes will still remain available for a subsequent commit.
>
> There is a twist about that twist: if you do "git commit -i <file>..."
> then the commit will consider changes to those specified files
> _including_ all "added" changes so far.
>
> But for instance it is best to only remember "git add" + "git
> commit" and/or "git commit -a".
>
> Doesn't it sounds nice? The index is being introduced up front without
> even mentioning it, and I think the above should be fairly palatable to
> newbies as well. Would only lack some enhancements to the commit
> template and the "nothing to commit" message so the user is cued about
> the fact that "current changeset is empty -- don't forget to 'git add'
> modified files, or use 'git commit -a'".
>
> What do you think?
>
me likes
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 8:49 UTC (permalink / raw)
To: git
In-Reply-To: <456F29A2.1050205@op5.se>
On Thursday 2006 November 30 18:57, Andreas Ericsson wrote:
(agree with everything in your mail)
> The only problem I'm seeing atm is that the supermodule somehow has to
> mark whatever commits it's using from the submodule inside the submodule
> repo so that they effectively become un-prunable, otherwise the
> supermodule may some day find itself with a history that it can't restore.
What about submodule/.git/refs/supermodule/commit12345678, where "12345678" is
the hash of the supermodule commit? This gives a convenient route in the
submodule to which commit contains that commit from the submodule; but
doesn't write anything into the submodule repository itself. It's just a tag
with a different intent.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Andreas Ericsson @ 2006-12-01 8:44 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <87fyc0u56z.wl%cworth@cworth.org>
Carl Worth wrote:
>
> See? Git _is_ harder to learn, and a user really cannot learn it
> without being careful about the index right from the very beginning.
>
I'm not so sure about that. I came from CVS / SVN, although I've fiddled
quite a bit with other scm's as well. The two-step commit process of git
didn't terrify me at all, and I had used git at least a month before I
joined the mailing-list and found out that there's this thing called an
"index". I knew about it before, since back then (June or July 2005)
there was only git-update-index to mark things to commit. I just didn't
worry about it but expected the scm to tell me if I was about to break
something horribly (which it often but not always did).
I think the main thing people are having difficulties with when it comes
to git is that it doesn't do things like other SCM's do it. Imo this is
a good thing, because it allows git to be more powerful than other
SCM's. Otoh it forces users migrating from
darcs/hg/monotone/perforce/whatever to git actually read the
documentation (and quite a lot of it), while hg -> bzr migrators use
pretty much the same commands for pretty much the same actions. This
makes users accustomed to not reading docs / trying things out before
attempting Real Work(tm), which breaks down horribly when user
expectations doesn't match reality. The simplest and usually most
effective solution is to meet the users half-way, and tell them early on
that this power comes at the cost of having to read the documentation
and do the tutorials.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Andy Parkins @ 2006-12-01 8:34 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611301253380.3513@woody.osdl.org>
On Thursday 2006 November 30 21:03, Linus Torvalds wrote:
> Yeah, I think it would probably make sense. I also think it would make
> sense to rename "update-index" entirely, or at least offer other names for
How about this:
git-update-index becomes plumbing only - never expect a user to run it.
Hence,
git-add becomes git-prepare and does
a) update-index --add
when the file being "prepared" is not tracked
b) update-index
when the file is already tracked
git-rm takes on "git-update-index --remove" (and --force-remove) with
appropriate switches.
git-mv does what it does - it's already pretty perfect
git-cp gets added; even though it's simply "cp a b; git-prepare b"
Obviously with all the details that I've left out filled in.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Resolving conflicts
From: Wink Saville @ 2006-12-01 8:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611302359400.3695@woody.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 30 Nov 2006, Linus Torvalds wrote:
>> No, kdiff3 probably doesn't have the same semantics, so better get the
>> "real" merge. It's almost certainly in the rcs package, so "emerge rcs"
>> should do it.
>
> ..and just to be safe, remove the symlink first, so that you don't end up
> overwriting the "kdiff3" binary by mistake when you install the real
> "merge". Not that I think emerge is quite that stupid a package manager,
> but anyway..
>
> Linus
>
Ubuntu is debian based and I use Synaptic GUI, a front end to apt-get. My earlier problem
was I couldn't find which package "merge" was in. But now I just figured it out by going
to debian.org and using "Search the contents of packages" for "merge". Turns out "merge"
is in devel/rcs which of course the whole world knows, unless your a neophyte like me:)
Any way after getting the real merge, I reverted the first pull and re-did it and all was well:
wink@winkc2d1:~/linux/linux-2.6$ git-checkout -f
wink@winkc2d1:~/linux/linux-2.6$ git-status
# On branch refs/heads/ace
nothing to commit
wink@winkc2d1:~/linux/linux-2.6$ git-pull . master
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 0215ffb08ce99e2bb59eca114a99499a4d06e704
Merging:
d7083db038fb98266e331a7f96198ec35a12367a A partial fix BUG 061124 (crashing when 1ms interrrupts).
0215ffb08ce99e2bb59eca114a99499a4d06e704 Linux 2.6.19
found 1 common ancestor(s):
1abbfb412b1610ec3a7ec0164108cee01191d9f5 [PATCH] x86_64: fix bad page state in process 'swapper'
Auto-merging kernel/fork.c
Auto-merging kernel/spinlock.c
Merge made by recursive.
Documentation/rtc.txt | 463 ++++++++++++++++---------
Makefile | 2
arch/arm/configs/assabet_defconfig | 1
arch/arm/configs/cerfcube_defconfig | 1
arch/arm/configs/corgi_defconfig | 1
......
sound/pci/emu10k1/emu10k1_main.c | 1
sound/pci/hda/patch_realtek.c | 2
sound/pci/hda/patch_sigmatel.c | 14 -
sound/usb/usbaudio.c | 3
usr/Makefile | 2
92 files changed, 888 insertions(+), 371 deletions(-)
create mode 100644 arch/mips/kernel/topology.c
create mode 100644 arch/um/os-Linux/execvp.c
create mode 100644 include/asm-arm/mach/udc_pxa2xx.h
Thank you very much,
Wink
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-11-30 18:57 UTC (permalink / raw)
To: Martin Waitz; +Cc: Andy Parkins, git
In-Reply-To: <20061130170625.GH18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Wed, Nov 29, 2006 at 08:00:22PM +0000, Andy Parkins wrote:
>> On Wednesday 2006, November 29 16:03, Martin Waitz wrote:
>>
>> Further, how is the supermodule index going to represent working
>> directory changes in the submodule? The only link between the two is
>> a commit hash. It has to be like that otherwise you haven't made a
>> supermodule-submodule, you've just made one super-repository. Also,
>> if you don't store submodule commit hashes, then there is no way to
>> guarantee that you're going to be able get back the state of the
>> submodule again.
>
> This is handled in the next paragraph.
> The argument really is: HEAD always points to the checked out branch,
> so it really has a relationship to the working directory.
>
>>> Contra HEAD:
>>> - HEAD is not garanteed to be equal to the working directory anyway,
>>> you may have uncommitted changes.
>> That's the case for every file in a repository, so isn't really a
>> worry. It's the equivalent of changing a file and not updating the
>> index - who cares? As long as update-index tells you that the
>> submodule is dirty and what to do to clean it, everything is great.
>
> Yes, it's not a real counter-argument, but it relativates the previous
> pro-argument.
>
>>> - when updating the supermodule, you have to take care that your
>>> submodules are on the right branch.
>>> You might for example have some testing-throwawy branch in one
>>> submodule and don't want to merge it with other changes yet.
>> What is the "right" branch though? As I said above, if you're tracking one
>> branch in the submodule then you've effectively locked that submodule to that
>> branch for all supermodule uses.
>
> yes, but luckily GIT branches are very flexible.
>
There's no real technical reason for locking it to a single branch
though, and in case of a fork in the upstream submodule project, you
might suddenly decide that "the other team" is heading in a much more
interesting direction and you want to use their work in your module
instead. Will you now have to maintain a separate branch just to keep
the same name as the branch the original team used?
>> Or you've made yourself a big rod to beat yourself with everytime you
>> want to do some development on an "off" branch on the submodule.
>
> I don't think it is that bad.
>
It could be, and as has already been stated, there's no real reason to
limit this to a particular branch, so I don't see why we would want to
impose such non-real restrictions.
>>> Pro refs/heads/master:
>>> - the supermodule really tracks one defined branch of development.
>> Why is this a pro?
>
> You always know which branch in the submodule is the "upstream" branch
> which is managed by the supermodule.
No you don't. The branch-name might be moved to some other tip of the
DAG, and that's exactly the same as changing the branch you're tracking.
> You can easily have several topic-branches and merge updates from the
> master branch.
> otherwise you always have to remember which branch holds your current
> contents from the supermodule.
>
No you don't. The only thing you need is the commit-sha.
> When viewed from the supermodule, you are storing one branch per
> submodule in your tree.
>
Wrong again. You're storing one particular point in the revision history.
>>> - you can easily overwrite one submodule by changing to another branch,
>>> without fearing that changes in the supermodule change anything
>>> there.
>> You can always do that anyway by simply not running update-index for the
>> submodule in the supermodule.
>
> Suppose you are working on a complicated feature in one submodule.
> You create your own branch for that feature and work on it.
> Now you want to update your project, so you pull a new supermodule
> version. Now this pull also included one (for you unimportant) change
> in the submodule.
git reset to the rescue.
> I think it is more clear to update the master branch with the new
> version coming from the supermodule, while leaving your work intact
> (you haven't commited it to the supermodule yet, so the supermodule
> should not care about your changes, it's just some dirty tree).
> Then you can freely merge between your branch and master as you like and
> are not forced to merge at once. And perhaps you even do not want to
> merge at all, because you are on an experimental branch which really is
> mutually exclusive with the current supermodule contents.
>
This is all just policy though. Tools that enforce a certain policy are
not good tools.
The only problem I'm seeing atm is that the supermodule somehow has to
mark whatever commits it's using from the submodule inside the submodule
repo so that they effectively become un-prunable, otherwise the
supermodule may some day find itself with a history that it can't restore.
The really major problem with this is that now you'll have one
repository of the submodule that is actually special, so it's not
certain you can go and use any repository at all of the submodule code,
since the upstream repo most likely won't be all that interested in
having all of that meta-data inside it. In reality, I'm sure this will
be a small problem though, as submodules that are in reality projects
which the supermodule's maintainer isn't the owner of will most likely
never rewind their history beyond the supermodules stored commit. It's
something fsck will have to be taught to watch for though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Resolving conflicts
From: Alan Chandler @ 2006-12-01 8:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611302359400.3695@woody.osdl.org>
On Friday 01 December 2006 08:00, Linus Torvalds wrote:
> On Thu, 30 Nov 2006, Linus Torvalds wrote:
> > No, kdiff3 probably doesn't have the same semantics, so better get the
> > "real" merge. It's almost certainly in the rcs package, so "emerge rcs"
> > should do it.
>
> ..and just to be safe, remove the symlink first, so that you don't end up
> overwriting the "kdiff3" binary by mistake when you install the real
> "merge". Not that I think emerge is quite that stupid a package manager,
> but anyway..
Ubuntu is a Debian based. I think it uses Synaptic as its package manager gui
with the standard Debian apt-xxx tools underneath.
--
Alan Chandler
^ 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