* [PATCH 2/2] git-svn 1.0.0
From: Eric Wong @ 2006-05-05 19:35 UTC (permalink / raw)
To: junkio, git; +Cc: Eric Wong
In-Reply-To: <11468577403821-git-send-email-normalperson@yhbt.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3680a525691232e2f45f2bcf63458e547ff109ba
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index e003501..de13a96 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $REV_DIR/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
-$VERSION = '0.11.0';
+$VERSION = '1.0.0';
use Cwd qw/abs_path/;
$GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
--
1.3.2.ge3d7
^ permalink raw reply related
* script to create debian package
From: Matthias Lederhofer @ 2006-05-05 20:53 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
I wrote a script similar to the script in scripts/package/builddeb in
the kernel tree for git. Is there any interest to integrate it into
the git source tree? I've attached the script.
[-- Attachment #2: git-deb-build --]
[-- Type: text/plain, Size: 826 bytes --]
#!/bin/sh
tmpdir="`pwd`/debian/tmp"
make prefix=/usr all doc
make prefix="$tmpdir/usr" install install-doc
version="`cat GIT-VERSION-FILE | cut -d ' ' -f 3`"
name="git debian package script <`id -nu`@`hostname -f`>"
mkdir -p "$tmpdir/DEBIAN"
cat <<EOF > debian/control
Source: git
Section: devel
Priority: optional
Maintainer: $name
Standards-Version: 3.6.1
Package: git
Conflicts: git-arch, git-core, git-cvs, git-doc, git-email, git-svn, gitk
Provides: git-arch, git-core, git-cvs, git-doc, git-email, git-svn, gitk
Architecture: any
Description: git, version $version
This package contains git version $version.
EOF
cat <<EOF > debian/changelog
git ($version-1) unstable; urgency=low
* A standard release
-- $name `date -R`
EOF
chmod -R og-w debian/tmp
dpkg-gencontrol -isp
fakeroot dpkg --build "$tmpdir" ..
^ permalink raw reply
* [PATCH/RFC (git-core)] update-index --again
From: Junio C Hamano @ 2006-05-06 5:05 UTC (permalink / raw)
To: git; +Cc: Carl Worth
After running 'git-update-index' for some paths, you may want to
do the update on the same set of paths again.
The new flag --again checks the paths whose index entries are
are different from the HEAD commit and updates them from the
working tree contents.
This was brought up by Carl Worth on #git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I want to reorganize index file to contain both blob and tree
entries in not so distant future, so I probably should not be
doing something like this which _would_ need rework when that
happens, but I think what Carl wanted to do is a reasonable
thing to ask.
http://colabti.de/irclogger/irclogger_log/git?date=2006-05-05,Fri&sel=16#l31
Documentation/git-update-index.txt | 6 ++-
t/t2101-update-index-reupdate.sh | 73 ++++++++++++++++++++++++++++++++++++
update-index.c | 56 ++++++++++++++++++++++++++--
3 files changed, 131 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 57177c7..d043e86 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -15,7 +15,7 @@ SYNOPSIS
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
- [--really-refresh] [--unresolve]
+ [--really-refresh] [--unresolve] [--again]
[--info-only] [--index-info]
[-z] [--stdin]
[--verbose]
@@ -80,6 +80,10 @@ OPTIONS
filesystem that has very slow lstat(2) system call
(e.g. cifs).
+--again::
+ Runs `git-update-index` itself on the paths whose index
+ entries are different from those from the `HEAD` commit.
+
--unresolve::
Restores the 'unmerged' or 'needs updating' state of a
file during a merge if it was cleared by accident.
diff --git a/t/t2101-update-index-reupdate.sh b/t/t2101-update-index-reupdate.sh
new file mode 100755
index 0000000..5c505c6
--- /dev/null
+++ b/t/t2101-update-index-reupdate.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Junio C Hamano
+#
+
+test_description='git-update-index --again test.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'update-index --add' \
+ 'echo hello world >file1 &&
+ echo goodbye people >file2 &&
+ git-update-index --add file1 file2 &&
+ git-ls-files -s >current &&
+ cmp current - <<\EOF
+100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
+100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
+EOF'
+
+test_expect_success 'update-index --again' \
+ 'rm -f file1 &&
+ echo hello everybody >file2 &&
+ if git-update-index --again
+ then
+ echo should have refused to remove file1
+ exit 1
+ else
+ echo happy - failed as expected
+ fi &&
+ git-ls-files -s >current &&
+ cmp current - <<\EOF
+100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
+100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
+EOF'
+
+test_expect_success 'update-index --remove --again' \
+ 'git-update-index --remove --again &&
+ git-ls-files -s >current &&
+ cmp current - <<\EOF
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF'
+
+test_expect_success 'first commit' 'git-commit -m initial'
+
+test_expect_success 'update-index again' \
+ 'mkdir -p dir1 &&
+ echo hello world >dir1/file3 &&
+ echo goodbye people >file2 &&
+ git-update-index --add file2 dir1/file3 &&
+ echo hello everybody >file2
+ echo happy >dir1/file3 &&
+ git-update-index --again &&
+ git-ls-files -s >current &&
+ cmp current - <<\EOF
+100644 53ab446c3f4e42ce9bb728a0ccb283a101be4979 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF'
+
+test_expect_success 'update-index --update from subdir' \
+ 'echo not so happy >file2 &&
+ cd dir1 &&
+ cat ../file2 >file3 &&
+ git-update-index --again &&
+ cd .. &&
+ git-ls-files -s >current &&
+ cmp current - <<\EOF
+100644 d7fb3f695f06c759dbf3ab00046e7cc2da22d10f 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF'
+
+test_done
+
diff --git a/update-index.c b/update-index.c
index 1870ac7..e6c460b 100644
--- a/update-index.c
+++ b/update-index.c
@@ -473,7 +473,7 @@ static void read_index_info(int line_ter
}
static const char update_index_usage[] =
-"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--really-refresh] [--cacheinfo] [--chmod=(+|-)x] [--assume-unchanged] [--info-only] [--force-remove] [--stdin] [--index-info] [--unresolve] [--ignore-missing] [-z] [--verbose] [--] <file>...";
+"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--really-refresh] [--cacheinfo] [--chmod=(+|-)x] [--assume-unchanged] [--info-only] [--force-remove] [--stdin] [--index-info] [--unresolve] [--again] [--ignore-missing] [-z] [--verbose] [--] <file>...";
static unsigned char head_sha1[20];
static unsigned char merge_head_sha1[20];
@@ -488,11 +488,13 @@ static struct cache_entry *read_one_ent(
struct cache_entry *ce;
if (get_tree_entry(ent, path, sha1, &mode)) {
- error("%s: not in %s branch.", path, which);
+ if (which)
+ error("%s: not in %s branch.", path, which);
return NULL;
}
if (mode == S_IFDIR) {
- error("%s: not a blob in %s branch.", path, which);
+ if (which)
+ error("%s: not a blob in %s branch.", path, which);
return NULL;
}
size = cache_entry_size(namelen);
@@ -597,6 +599,47 @@ static int do_unresolve(int ac, const ch
return err;
}
+static int do_reupdate(int ac, const char **av,
+ const char *prefix, int prefix_length)
+{
+ /* Read HEAD and run update-index on paths that are
+ * merged and already different between index and HEAD.
+ */
+ int pos;
+ int has_head = 1;
+
+ if (read_ref(git_path("HEAD"), head_sha1))
+ /* If there is no HEAD, that means it is an initial
+ * commit. Update everything in the index.
+ */
+ has_head = 0;
+ redo:
+ for (pos = 0; pos < active_nr; pos++) {
+ struct cache_entry *ce = active_cache[pos];
+ struct cache_entry *old = NULL;
+ int save_nr;
+ if (ce_stage(ce))
+ continue;
+ if (has_head)
+ old = read_one_ent(NULL, head_sha1,
+ ce->name, ce_namelen(ce), 0);
+ if (old && ce->ce_mode == old->ce_mode &&
+ !memcmp(ce->sha1, old->sha1, 20)) {
+ free(old);
+ continue; /* unchanged */
+ }
+ /* Be careful. The working tree may not have the
+ * path anymore, in which case, under 'allow_remove',
+ * or worse yet 'allow_replace', active_nr may decrease.
+ */
+ save_nr = active_nr;
+ update_one(ce->name + prefix_length, prefix, prefix_length);
+ if (save_nr != active_nr)
+ goto redo;
+ }
+ return 0;
+}
+
int main(int argc, const char **argv)
{
int i, newfd, entries, has_errors = 0, line_termination = '\n';
@@ -714,6 +757,13 @@ int main(int argc, const char **argv)
active_cache_changed = 0;
goto finish;
}
+ if (!strcmp(path, "--again")) {
+ has_errors = do_reupdate(argc - i, argv + i,
+ prefix, prefix_length);
+ if (has_errors)
+ active_cache_changed = 0;
+ goto finish;
+ }
if (!strcmp(path, "--ignore-missing")) {
not_new = 1;
continue;
--
1.3.2.g2749
^ permalink raw reply related
* Re: Unresolved issues #2
From: Junio C Hamano @ 2006-05-06 5:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605041715500.3611@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I'm actually growing pretty fond of the config file interfaces that Dscho
> is pushing. I really like the idea of "git pull" doing different things
> depending on which branch is active at the time, because different
> branches really can have different sources they come from.
> Always pulling from the same default source seems wrong,...
> So Johannes' patches seem to move into that direction, and having it all
> in the config file actually seems to be quite readable.
I share the same reasoning and that is why I am carrying the
series in "next". I think per branch attributes are wonderful
things.
> So I'd argue that (a) yes, we do want to have the "proto porcelain" that
> sets remote branch information without the user having to know the magic
> "git repo-config" incantation, or know which file in .git/remotes/ to
> edit, but that (b) it's even more important to try to decide on what the
> remote description format _is_.
Is it format you care about or the semantics?
> I personally have just two preferences:
>
> - I'd like each branch I'm on to have a "default source" for pulling (and
> _maybe_ for pushing too). I'd like to just say "git pull", and it would
> automatically select the appropriate thing to pull from.
>
> - maybe the same per-branch thing for "push", but more importantly for
> me, I like to push to multiple destinations, and I'd like the
> description format to be sane. I think it may already be sane in the
> form it is in now (supporting both config file _and_ .git/remotes/
> formats), I'd just like us to decide on exactly what the meaning is,
> and hopefully get to the point where we can tell porcelain how to use
> that meaning to their advantage (and not change it)
>
> Others may disagree, or (equally importantly), may have additional
> preferences. We should try to find something that works for everybody, and
> that is easy to work with.
In my day job, I maintain a base code for a generic application
in "master", various topics, mostly branched from "master" but
sometimes from another topic branch, and one branch each per
customer installation, which pulls from the master, topics and
contains specific customizations. While on master or any one of
generic topic branch, I need to remember not to pull from
installation branches. For that matter, the installation
branches should not be pulled into anything else. So not just
"this branch usually merges from there", but "this branch should
not be merged into others" (mark "installation branches" as
such), and "this branch should never merge from that one" (mark
"master" with "installation branches") would prevent mistakes.
One thing I noticed in "What's in libata.git" Jeff did by
mimicking my "What's in git.git" was that the description for
each topic branch included where it branched from (iow, what
other branch it builds on). This is sometimes derivable, but
having it as a property for a branch is very handy.
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Martin Langhoff @ 2006-05-06 6:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0605050848230.3622@g5.osdl.org>
On 5/6/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Of course, that would require another slight difference to "rev-list.c",
> where we'd only recurse into trees of selected commit objects (ie we'd
> have to mark the HAVE/WANT commits specially, but it's not exactly
> complex either).
Would it make sense to make all the shallow clone clone machinery walk
everything and trim only blob objects? In that case, all the machinery
that walks commits/trees would remain intact -- we only have to deal
with the case of not having blob objects, which affects less
codepaths.
It means that for a merge or checkout involving stuff we "don't have",
it's trivial to know we are missing, and so we can attempt a fetch of
the missing objects or tell the user how to request them them before
retrying.
And in any case commits and trees are lightweight and compress well...
> Of course, the complexity of _both_ of these approaches is really in the
> fsck stage, and all the crud you need to then do other things with these
> pared-down repos. For example, do you allow cloning? And do you just
> automatically notice that you're cloning a shallow repo, and only do a
> shallow clone. Etc etc..
Definitely.
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Martin Langhoff @ 2006-05-06 6:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vr738w8t4.fsf@assigned-by-dhcp.cox.net>
On 5/6/06, Junio C Hamano <junkio@cox.net> wrote:
> > If you use persistent file ids, you never miss it _AND_ you DO NOT WALK
> > THE COMMIT CHAIN! You still just match file ids in the two trees.
>
> It is unworkable.
+1 -- explicit file ids are evil. Arch/TLA demonstrated that amply...
they are a serious annoyance to the end user, they have a lot of
not-elegantly solvable cases (same file created with the same contents
in several repos -- say via an emailed patch) that git gets right
_today_.
They _are_ useful in a very small set of cases -- namely in the case
of a naive mv, which git handles correctly today. Subtler things git
sometimes does right, sometimes fails, but it can be made to be much
smarter by interpreting content changes better, for instance all this
talk about getting pickaxe to guess where the patch should be applied
for a file that got split into 3.
But those subtler cases are totally impossible with explicit id
tracking. I used Arch for a long time with very large trees, and
renames coming left, right and centre. Explicit ids didn't help much,
and the number of manual fixups we had to do was awful.
I am using GIT with the very same project, and just now, typing this,
I realised that there are still many renames happening in the project.
I had forgotten about it -- well, not really: I do use git-merge
instead of cg-merge when I suspect there may be interesting cases ;-)
Of course, YMMV, and I have to confess I was a sceptic for a while...
but now as an end-user dealing with messy projects, I say LIRAR: Linus
Is Right About Renames.
OTOH,
>> Try doing
>>
>> git diff v1.3.0..
>>
>> and think about what that actually _means_. Think about the fact that it
>> doesn't actually walk the commit chain at all: it diffs the trees between
>> v1.3.0 and the current one. What if the rename happened in a commit in
>> the middle?
>
> Then the automated renames detection will miss it given that the other
> accumulated differences are large enough, and the suggested workarounds
> _are_ precisely walking the commit chain.
I agree here with Pasky that after a while the automated
renames/copy/splitup detection will miss the operation in cases where
it would be interesting to note it to the user. IIRC git-rerere is the
tool that knows about this (still voodoo to me how) and could be used
to help here. At what (runtime) cost, I don't know, but that kind of
walking history to tell me more interesting things about the diff is
something that is usually worthwhile.
Usual disclaimers apply.
martin
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Junio C Hamano @ 2006-05-06 7:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605052323o29f8bfadr7426f97d8dfc2319@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 5/6/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> Of course, that would require another slight difference to "rev-list.c",
>> where we'd only recurse into trees of selected commit objects (ie we'd
>> have to mark the HAVE/WANT commits specially, but it's not exactly
>> complex either).
>
> Would it make sense to make all the shallow clone clone machinery walk
> everything and trim only blob objects? In that case, all the machinery
> that walks commits/trees would remain intact -- we only have to deal
> with the case of not having blob objects, which affects less
> codepaths.
>
> It means that for a merge or checkout involving stuff we "don't have",
> it's trivial to know we are missing, and so we can attempt a fetch of
> the missing objects or tell the user how to request them them before
> retrying.
>
> And in any case commits and trees are lightweight and compress well...
Commit maybe, but is this based on a hard fact?
Earlier Linus said something about "git log" working on
commit-only copy, but obviously you would want at least trees
for the path limiting part to work, so having commits and trees
would be handy, but my impression was that at least for deep
project like the kernel trees tend to be nonnegligible (a commit
consists of 18K paths and 1200 trees or something like that).
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Junio C Hamano @ 2006-05-06 7:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605052353m2d2aca11weac7efee80c6fb35@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> I agree here with Pasky that after a while the automated
> renames/copy/splitup detection will miss the operation in cases where
> it would be interesting to note it to the user. IIRC git-rerere is the
> tool that knows about this (still voodoo to me how) and could be used
> to help here. At what (runtime) cost, I don't know, but that kind of
> walking history to tell me more interesting things about the diff is
> something that is usually worthwhile.
FYI rerere is a totally unrelated voodoo.
It remembers the conflict marker pattern <<< === >>> immediately
after it runs "merge" (ah, that reminds me -- I should replace
them with diff3), and then remembers the result of the manual
resolution just before the user makes a commit. Then, when next
time it runs "merge" for something and notices <<< === >>>
pattern it has seen before, it runs a three-way merge between
the previous resolution result and the current conflicted state,
using the previous conflicted state as the common origin.
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-06 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90605052353m2d2aca11weac7efee80c6fb35@mail.gmail.com>
Martin Langhoff wrote:
> On 5/6/06, Junio C Hamano <junkio@cox.net> wrote:
>>> Try doing
>>>
>>> git diff v1.3.0..
>>>
>>> and think about what that actually _means_. Think about the fact that it
>>> doesn't actually walk the commit chain at all: it diffs the trees
>>> between v1.3.0 and the current one. What if the rename happened in a
>>> commit in the middle?
>>
>> Then the automated renames detection will miss it given that the other
>> accumulated differences are large enough, and the suggested workarounds
>> _are_ precisely walking the commit chain.
>
> I agree here with Pasky that after a while the automated
> renames/copy/splitup detection will miss the operation in cases where
> it would be interesting to note it to the user.
Perhaps an option to do rename detection with walking the commit chain?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] binary patch.
From: Junio C Hamano @ 2006-05-06 7:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xgzsiu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> Yeah, things still to be done are deflating both delta and
>> optionally perhaps use just deflate without delta for "new file"
>> codepath.
>>
>> And testsuite.
>
> -- >8 --
> [PATCH] binary diff: further updates.
>...
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * Have done only very minimum testing, and unlike somebody else ;-)
> my code is not always perfect, so this will still stay out of
> "next" for a while.
OK, now it passes the testsuite I wrote, so I'll push this out
in "next". I was not drunk while doing the testsuite so the
code now must be perfect ;-).
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Junio C Hamano @ 2006-05-06 7:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3hjfk$bjn$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Perhaps an option to do rename detection with walking the commit chain?
Have fun implementing that ;-).
^ permalink raw reply
* [RFC] Managing projects - advanced Git tutorial/walkthrough
From: Jakub Narebski @ 2006-05-06 8:43 UTC (permalink / raw)
To: git
I have browsed through Git documentation: "A tutorial introduction to
git" (tutorial.txt), "A short git tutorial" (core-tutorial.txt) which
contrary to the title is the tutorial in low-level git commands and is
longer that the first one, "Everyday GIT With 20 Commands Or
So" (everyday.txt) and "git for CVS users" (cvs-migration.txt) which does
not mention git-blame and git-annotate.
What I miss is walkthrough type tutorial, describing typical workflow (or
workflows), and tutorial concentrating on advanced topics which may come
once in a while or for some topics only, but it would be nice to know how
to resolve them.
Perhaps some of the following problems would need Git improvement (e.g.
better support for subprojects: "bind" idea)...
1. Description of typical workflow, with 'stable'/'maintenance'/'fixes' and
'development'/'master'/'main' branches, how to put bugfixes into both
branches etc. Perhaps description of git branches and workflow, or Linux
kernel branches and workflow.
2. Contrib: how to add project which was externally managed to contrib and
later/or to core, preserving history. Examples: gitk for git, or like
perhaps parsecvs would be for git, or like git-svn for git.
3. Subprojects: how to manage project which depends on other externally
managed (third-party) project, and perhaps needs patches for it. Examples:
out of tree kernel patches + userspace tools, plugin for some program which
may need bugfixes, program which need some library, gitk before
incorporating into git,... Perhaps description of the whole sequence of
project development from add-on project (some new filesystem for Linux,
gitk) to being incorporated into bigger project (filesystem included in
Linux kernel, gitk in git repository).
4. Splitting repository: splitting one big project (X.org, Linux
distribution) into modules.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Bertrand Jacquin @ 2006-05-06 12:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vslnntxay.fsf@assigned-by-dhcp.cox.net>
On 5/6/06, Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Perhaps an option to do rename detection with walking the commit chain?
>
> Have fun implementing that ;-).
I agree that it could be interesting to have a such thing. But that's
increndibly stupid and moreover a rare case.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Jakub Narebski @ 2006-05-06 13:37 UTC (permalink / raw)
To: git
In-Reply-To: <e3g9m6$8i0$1@sea.gmane.org>
Jakub Narebski wrote:
> Petr Baudis wrote:
>> If you use persistent file ids, you never miss it _AND_ you DO NOT WALK
>> THE COMMIT CHAIN! You still just match file ids in the two trees.
>
> Let not jump to the one of the possible solution. The detecting and noting
> renames and content moving (with user interaction) at commit is nice...
> unless does something which cannot allow interactiveness (like applying
> patchbomb), but even then detecting and saving info at commit would be
> good idea.
>
> What we need is to for two given linked revisions (with a path between
> them) to easily extract information about renames (content moving).
> Perhaps using additional structure... best if we could do this without
> walking the chain. The rest is details... ;-P
Or rather structure, which for given file F in given revision A, for given
other revision B would tell ALL the files in the revision B which are
source of contents (via history/commit tree) of the file F.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Unresolved issues #2
From: Linus Torvalds @ 2006-05-06 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Git Mailing List
In-Reply-To: <7vhd43vgnm.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 May 2006, Junio C Hamano wrote:
>
> > So I'd argue that (a) yes, we do want to have the "proto porcelain" that
> > sets remote branch information without the user having to know the magic
> > "git repo-config" incantation, or know which file in .git/remotes/ to
> > edit, but that (b) it's even more important to try to decide on what the
> > remote description format _is_.
>
> Is it format you care about or the semantics?
I _personally_ care about the semantics, but not very deeply - since I
tend to actually have just one main branch, and a couple of throw-away
ones if I ended up working on something.
But I think that for this thing to become useful, we want to care about
the format - or at least the interface to the different users (with the
acknowledgement that "users" should often be porcelain above us).
Right now we've basically had people hand-editing the remotes files, and I
think cogito still uses the older branches format that came from cogito in
the first place. I think we should just try to decide on a config file
format, and make it easy for cogito etc to use it.
Linus
^ permalink raw reply
* Re: Unresolved issues #2
From: sean @ 2006-05-06 15:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, barkalow, git
In-Reply-To: <Pine.LNX.4.64.0605060821430.16343@g5.osdl.org>
On Sat, 6 May 2006 08:26:36 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> I _personally_ care about the semantics, but not very deeply - since I
> tend to actually have just one main branch, and a couple of throw-away
> ones if I ended up working on something.
>
> But I think that for this thing to become useful, we want to care about
> the format - or at least the interface to the different users (with the
> acknowledgement that "users" should often be porcelain above us).
>
> Right now we've basically had people hand-editing the remotes files, and I
> think cogito still uses the older branches format that came from cogito in
> the first place. I think we should just try to decide on a config file
> format, and make it easy for cogito etc to use it.
Linus,
Wondering why you feel so strongly that most "users" shouldn't be real people.
What is wrong with continuing to make git easier for developers to use without
needing any extra software?
Sean
^ permalink raw reply
* Re: Unresolved issues #2
From: Linus Torvalds @ 2006-05-06 16:30 UTC (permalink / raw)
To: sean; +Cc: junkio, barkalow, git
In-Reply-To: <BAYC1-PASMTP10F63ADF30C26A29D070C5AEAA0@CEZ.ICE>
On Sat, 6 May 2006, sean wrote:
>
> Wondering why you feel so strongly that most "users" shouldn't be real people.
> What is wrong with continuing to make git easier for developers to use without
> needing any extra software?
Basically, it boils down to the end result.
If you design things for "people", then things tend to become hard to
automate, and it's hard to make wrappers around it. Maybe you've even made
the interfaces interactive, and thus any wrappers around it are simply
screwed, or need to do insane things.
On the other hand, if you design things for automation, doing a "people
wrapper" that uses the automation should be trivial if the design is even
remotely any good at all.
In other words: you should always design things for automation, and
consider the "people interface" to be be just _one_ wrapper layer among
many.
This has worked really well in git. The whole system was designed from the
start to be all about scripting and automation, and the "people wrappers"
tend to be trivial scripts around it.
This was even more obvious when we had a number of basically one-liner
scripts like "git log", which just did some trivial wrapping around
git-rev-list | git-diff-tree --stdin | $PAGER
(Now we still have that trivial wrapper, but you just need to look into C
code to see it, so it's not _as_ obviously trivial).
Contrast this with going the other way: if you talk about the interfaces
that _people_ want first, you immediately start doing pretty-printing,
nice parsing, maybe interactive stuff that asks questions. Nice GUIs. And
the end result is CRAP. Exactly because it lost its ability to be generic.
To some degree, this is the fundamental difference between the Windows and
the UNIX mindset. At least it used to be.
Linus
^ permalink raw reply
* Re: Unresolved issues #2
From: sean @ 2006-05-06 16:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, barkalow, git
In-Reply-To: <Pine.LNX.4.64.0605060923050.16343@g5.osdl.org>
On Sat, 6 May 2006 09:30:48 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> Basically, it boils down to the end result.
>
> If you design things for "people", then things tend to become hard to
> automate, and it's hard to make wrappers around it. Maybe you've even made
> the interfaces interactive, and thus any wrappers around it are simply
> screwed, or need to do insane things.
Okay, I mistook the scope of you comments to apply to all of git rather than
as a reminder that we can't forget about the toolkit design. So I take it
you're not at all against git including higher level user commands; just so
long as they're built on top of lower level toolkit commands that other
porcelain can use as well.
In this particular case I see "git repo-config" as the low level command that
any porcelain can use to access the remotes information and the proposed
"git remotes" as a simple convenience wrapper on top of this. Of course,
everyone has to agree on the config file format; but that is true whether
the human-friendly wrapper exists or not.
Sean
^ permalink raw reply
* Re: Unresolved issues #2
From: Linus Torvalds @ 2006-05-06 17:20 UTC (permalink / raw)
To: sean, Johannes Schindelin; +Cc: Junio C Hamano, barkalow, Git Mailing List
In-Reply-To: <BAYC1-PASMTP0824AA77198F95FE28B79DAEAA0@CEZ.ICE>
On Sat, 6 May 2006, sean wrote:
>
> Okay, I mistook the scope of you comments to apply to all of git rather than
> as a reminder that we can't forget about the toolkit design. So I take it
> you're not at all against git including higher level user commands; just so
> long as they're built on top of lower level toolkit commands that other
> porcelain can use as well.
Correct. I think we've been able to handle that balance particularly well
so far. Or maybe the porcelains don't complain enough.
> In this particular case I see "git repo-config" as the low level command that
> any porcelain can use to access the remotes information and the proposed
> "git remotes" as a simple convenience wrapper on top of this. Of course,
> everyone has to agree on the config file format; but that is true whether
> the human-friendly wrapper exists or not.
I agree, but my point is that in order for a porcelain to _use_
"repo-config", the config file format needs to be defined somewhere, and
we need to tell people that it's not changing. Are we there yet?
That was my argument for why we should concentrate not on what the user
wrapper should be named, but why we should look at what the low-level
meaning of these things are.
Finally, I think "git repo-config" is buggy. Try with this .config file:
[user]
name = Bozo the Clown
email = bozo@circus.com
[core]
filemode = true
[merge]
summary = true
and then do
git repo-config core.gitproxy 'dummy example'
and look where it ends up. For me, it ends up at the end, in the "[merge]"
section, which is obviously bogus.
So we'd really be screwing with porcelain if we made them use this ;)
Linus
^ permalink raw reply
* [PATCH] Another config file parsing fix.
From: sean @ 2006-05-06 18:14 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
If the variable we need to store should go into a section
that currently only has a single variable (not matching
the one we're trying to insert), we will already be into
the next section before we notice we've bypassed the correct
location to insert the variable.
To handle this case we store the current location as soon
as we find a variable matching the section of our new
variable.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
config.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
1ba487db7393d773a2a4b7c404ba1b807272eb7d
diff --git a/config.c b/config.c
index 87fb220..41066e4 100644
--- a/config.c
+++ b/config.c
@@ -336,8 +336,10 @@ static int store_aux(const char* key, co
store.state = KEY_SEEN;
store.seen++;
} else if (strrchr(key, '.') - key == store.baselen &&
- !strncmp(key, store.key, store.baselen))
+ !strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
+ store.offset[store.seen] = ftell(config_file);
+ }
}
return 0;
}
--
1.3.2.g6e99a-dirty
^ permalink raw reply related
* Re: [PATCH] Another config file parsing fix.
From: sean @ 2006-05-06 18:25 UTC (permalink / raw)
To: sean; +Cc: git, torvalds
In-Reply-To: <20060506141402.3909cb37.seanlkml@sympatico.ca>
On Sat, 6 May 2006 14:14:02 -0400
sean <seanlkml@sympatico.ca> wrote:
> If the variable we need to store should go into a section
> that currently only has a single variable (not matching
> the one we're trying to insert), we will already be into
> the next section before we notice we've bypassed the correct
> location to insert the variable.
>
> To handle this case we store the current location as soon
> as we find a variable matching the section of our new
> variable.
>
Sorry.. this should really be amended to mention that it was Linus
who spotted the problem.
Sean
^ permalink raw reply
* [PATCH] t1300-repo-config: two new config parsing tests.
From: sean @ 2006-05-06 19:43 UTC (permalink / raw)
To: git; +Cc: torvalds
In-Reply-To: <BAYC1-PASMTP08FCAC8B8FB768ED1791F1AEAA0@CEZ.ICE>
- correctly insert a new variable into a section that only
contains a single (different) variable.
- correctly insert a new section that matches the initial
substring of an existing section.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Both tests fail with v1.3.2 and pass with latest patches.
t/t1300-repo-config.sh | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
ef2178a10e27f43d4120884bc587c460e9b1bfcb
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1bf728f..0914be2 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -278,5 +278,36 @@ git-repo-config > output 2>&1
test_expect_success 'no arguments, but no crash' \
"test $? = 129 && grep usage output"
+cat > .git/config << EOF
+[a.b]
+ c = d
+EOF
+
+git-repo-config a.x y
+
+cat > expect << EOF
+[a.b]
+ c = d
+[a]
+ x = y
+EOF
+
+test_expect_success 'new section is partial match of another' 'cmp .git/config expect'
+
+git-repo-config b.x y
+git-repo-config a.b c
+
+cat > expect << EOF
+[a.b]
+ c = d
+[a]
+ x = y
+ b = c
+[b]
+ x = y
+EOF
+
+test_expect_success 'new variable inserts into proper section' 'cmp .git/config expect'
+
test_done
--
1.3.2.gd777c
^ permalink raw reply related
* Re: [RFC] Managing projects - advanced Git tutorial/walkthrough
From: Junio C Hamano @ 2006-05-06 20:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3hnjg$k9f$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I have browsed through Git documentation: "A tutorial introduction to
> git" (tutorial.txt), "A short git tutorial" (core-tutorial.txt) which
> contrary to the title is the tutorial in low-level git commands and is
> longer that the first one, "Everyday GIT With 20 Commands Or
> So" (everyday.txt) and "git for CVS users" (cvs-migration.txt) which does
> not mention git-blame and git-annotate.
I was initially somewhat dissapointed that a posting marked as
RFC did not contain a draft that is commentable, but we would
probably want to know how the updated document set will be
organized in general first. There was a discussion both here
and on #irc, while Pasky and gang were working on the wiki,
about sprucing up the introductory documentation set.
The core-tutorial grow out of a short tutorial to start from
Plumbing basics (what's in object store) to cover Porcelainish;
when it was written there was not another user-level document,
so it had to cover both, but it is probably a good idea to move
the parts that talk about Porcelainish to other documents and
make it "A short tutorial on git Plumbing" document. Maybe we
can have a tiered document set like this:
- Your first experience with git with walkthru. This shows the
minimum basic operations to get started a stand-alone "hello
world" project, without talking about index nor object store.
The current tutorial.txt is probably good enough with
updates.
- Understanding git as an end user. Currently, this is
included in the global map git(7) documentation. It might
make sense to separate it out. This should talk about
concepts like blobs/trees/commits/trust/index without going
into lowlevel details of the implementation. The stress
should be on what they are for, not operationally but
philosophically. What's currently in README would be
suitable for this part, with some additional topics:
- branches. "Tying it all together" section talks about the
single branch and "the HEAD state"; we should talk about
why you would want to use multiple branches (either
keeping track of your own development, or keeping track of
somebody else's) and stress branches are to keep separate
things separate (explained that way it becomes clear why
you should not commit on a remote tracking branch).
- ancestry traversal. what "A..B" or "^A ^B C" means and why
you would want to say them.
- Everyday.
- Special interests: cvs migration, howto/ documents.
- The global map git(7) with pointers to individual commands,
and the glossary.
- Tutorial on Plumbing.
For a new end-user, the order to read would be from the top to
bottom. "Everyday" should cover most of what are needed for
different classes of users, and other things can be looked up
from the global map.
I think tutorial.txt is the right "your first experience with
git with walkthru" document, and the materials it gives, and the
order in which it introduces them, are very well thought out;
kudos to JBF. We might also want to show "git grep", but other
than that I do not think of anything that a new user might want
to use on the first day.
It is deliberately sketchy at times to keep the flow of walkthru
clean and simple, and I'd like to keep it that way. I would
however like to see the examples to show the expected output
from the commands, like the initial part of the current
core-tutorial.txt does. Also, I'd like to see a "see also" link
to each step that refers the user to "what if this step does not
work as expected for you", either separate document or a section
in the appendix part of the same document, without cluttering
the main text too much.
Some commands and syntax it mentions may need to be rethought in
the light what happened recently, especially the internal
version of diff and log/show/whatchanged unification that
happened before the 1.3.0 came out.
* "git diff A B" should probably be spelled as "git diff A..B"
throughout for consistency.
* Today's "git log" is more powerful than the one we had when
the tutorial was first written, and we probably want to
recommend "git log [-p|--stat]" in place of whatchanged;
whatchanged is kept primarily for historical reasons and to
give a different default output format than log. A new user
does not have to even know about it.
Then reorganize the initial part core-tutorial.txt to match the
examples tutorial.txt gives, and demonstrate what is happening
under the hood. The tutorial says "git init-db" then "git
add". The core-tutorial would match that and explain what
happens when "git init-db" is run (creates .git/objects etc.)
and "git add" is run (populates the index).
^ permalink raw reply
* [PATCH] fmt-patch: understand old <his> notation
From: Johannes Schindelin @ 2006-05-06 20:56 UTC (permalink / raw)
To: git, junkio
When calling "git fmt-patch HEAD~5", you now get the same as if you would
have said "git fmt-patch HEAD~5..". This makes it easier for my fingers
which are so used to the old syntax.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I wonder: would it make sense to make add_pending_object() and
get_reference() in revision.c non-static?
builtin-diff.c | 2 +-
builtin-log.c | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 636edbf..2087316 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -232,7 +232,7 @@ static int builtin_diff_combined(struct
return 0;
}
-static void add_head(struct rev_info *revs)
+void add_head(struct rev_info *revs)
{
unsigned char sha1[20];
struct object *obj;
diff --git a/builtin-log.c b/builtin-log.c
index 0027998..d5bbc1c 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -11,6 +11,9 @@ #include "revision.h"
#include "log-tree.h"
#include "builtin.h"
+/* this is in builtin-diff.c */
+void add_head(struct rev_info *revs);
+
static int cmd_log_wc(int argc, const char **argv, char **envp,
struct rev_info *rev)
{
@@ -185,6 +188,11 @@ int cmd_format_patch(int argc, const cha
if (argc > 1)
die ("unrecognized argument: %s", argv[1]);
+ if (rev.pending_objects && rev.pending_objects->next == NULL) {
+ rev.pending_objects->item->flags |= UNINTERESTING;
+ add_head(&rev);
+ }
+
if (!use_stdout)
realstdout = fdopen(dup(1), "w");
--
1.3.1.g9ba6-dirty
^ permalink raw reply related
* Re: [PATCH] Another config file parsing fix.
From: Johannes Schindelin @ 2006-05-06 21:01 UTC (permalink / raw)
To: sean; +Cc: git, torvalds
In-Reply-To: <BAYC1-PASMTP08FCAC8B8FB768ED1791F1AEAA0@CEZ.ICE>
Hi,
On Sat, 6 May 2006, sean wrote:
> On Sat, 6 May 2006 14:14:02 -0400
> sean <seanlkml@sympatico.ca> wrote:
>
> > If the variable we need to store should go into a section
> > that currently only has a single variable (not matching
> > the one we're trying to insert), we will already be into
> > the next section before we notice we've bypassed the correct
> > location to insert the variable.
> >
> > To handle this case we store the current location as soon
> > as we find a variable matching the section of our new
> > variable.
> >
>
> Sorry.. this should really be amended to mention that it was Linus
> who spotted the problem.
Thanks to both of you!
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