* Re: [PATCH 1/3] git-fetch: ignore dereferenced tags in expand_refs_wildcard
From: Junio C Hamano @ 2006-12-05 1:08 UTC (permalink / raw)
To: Michael Loeffler; +Cc: git
In-Reply-To: <1165260874.20055.4.camel@ibook.zvpunry.de>
Michael Loeffler <zvpunry@zvpunry.de> writes:
> There was a little bug in the brace expansion which should remove
> the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'},
> the difference is that '#' will remove the given pattern only from the
> beginning of a string and '%' only from the end of a string.
Thanks. Shows that I do not use post 80's shell features ;-).
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Junio C Hamano @ 2006-12-05 1:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612041233.19377.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> You might have sha1 ids in commit message which no longer point to valid
> (existing) object, for example commit which is result of
> "git cherry-pick -x" from no longer existing temporary branch, or commit
> which is result of "git revert" on a branch which got rebased (but not
> reorganized), or shortened sha1 which is no longer unique. This should
> not cause errors to be written to webserver log.
True.
> By the way, is it better to use anonymous subroutines for committags
> subs, or use explicit subroutines?
I vaguely recall a thread that discussed pros and cons of using
anonymous subroutines in certain parts of gitweb some time ago
in which even Merlyn had some comments in, but I do not recall
the technical details, sorry. My gut feeling is that the way
you illustrated your example "our %committags" definition is
fine, but it _might_ turn out that it is easier for sites or for
projects to customize their own set of rewrite rules if you had
explicitly named subroutines available. I dunno.
^ permalink raw reply
* [PATCH 1/2] read-tree: further loosen "working file will be lost" check.
From: Junio C Hamano @ 2006-12-05 1:08 UTC (permalink / raw)
To: git
This follows up commit ed93b449 where we removed overcautious
"working file will be lost" check.
A new option "--ignore=.gitignore" can be used to tell the
"git-read-tree" command that the user does not mind losing
contents in untracked files in the working tree if it needs to
be overwritten by a merge (either a two-way "switch branch"
merge, or a three-way merge).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-read-tree.c | 20 ++++++++++
dir.c | 4 +-
dir.h | 3 ++
t/t1004-read-tree-m-u-wf.sh | 82 ++++++++++++++++++++++++++++++++++++++----
unpack-trees.c | 24 ++++++++++---
unpack-trees.h | 1 +
6 files changed, 119 insertions(+), 15 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index c1867d2..37b2214 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -10,6 +10,7 @@
#include "tree-walk.h"
#include "cache-tree.h"
#include "unpack-trees.h"
+#include "dir.h"
#include "builtin.h"
static struct object_list *trees;
@@ -178,6 +179,23 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
continue;
}
+ if (!strncmp(arg, "--ignore=", 9)) {
+ struct dir_struct *dir;
+
+ if (opts.dir)
+ die("more than one --ignore is given.");
+
+ dir = calloc(1, sizeof(*opts.dir));
+ dir->show_ignored = 1;
+ dir->exclude_per_dir = arg + 9;
+ opts.dir = dir;
+ /* We do not need to nor want to do read-directory
+ * here; we are merely interested in reusing the
+ * per directory ignore stack mechanism.
+ */
+ continue;
+ }
+
/* using -u and -i at the same time makes no sense */
if (1 < opts.index_only + opts.update)
usage(read_tree_usage);
@@ -190,6 +208,8 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
}
if ((opts.update||opts.index_only) && !opts.merge)
usage(read_tree_usage);
+ if ((opts.dir && !opts.update))
+ die("--ignore is meaningless unless -u");
if (opts.prefix) {
int pfxlen = strlen(opts.prefix);
diff --git a/dir.c b/dir.c
index 96389b3..e6a61ee 100644
--- a/dir.c
+++ b/dir.c
@@ -156,7 +156,7 @@ void add_excludes_from_file(struct dir_struct *dir, const char *fname)
die("cannot use %s as an exclude file", fname);
}
-static int push_exclude_per_directory(struct dir_struct *dir, const char *base, int baselen)
+int push_exclude_per_directory(struct dir_struct *dir, const char *base, int baselen)
{
char exclude_file[PATH_MAX];
struct exclude_list *el = &dir->exclude_list[EXC_DIRS];
@@ -170,7 +170,7 @@ static int push_exclude_per_directory(struct dir_struct *dir, const char *base,
return current_nr;
}
-static void pop_exclude_per_directory(struct dir_struct *dir, int stk)
+void pop_exclude_per_directory(struct dir_struct *dir, int stk)
{
struct exclude_list *el = &dir->exclude_list[EXC_DIRS];
diff --git a/dir.h b/dir.h
index 313f8ab..550551a 100644
--- a/dir.h
+++ b/dir.h
@@ -43,6 +43,9 @@ extern int common_prefix(const char **pathspec);
extern int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen);
extern int read_directory(struct dir_struct *, const char *path, const char *base, int baselen);
+extern int push_exclude_per_directory(struct dir_struct *, const char *, int);
+extern void pop_exclude_per_directory(struct dir_struct *, int);
+
extern int excluded(struct dir_struct *, const char *);
extern void add_excludes_from_file(struct dir_struct *, const char *fname);
extern void add_exclude(const char *string, const char *base,
diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh
index 018fbea..3f6f361 100755
--- a/t/t1004-read-tree-m-u-wf.sh
+++ b/t/t1004-read-tree-m-u-wf.sh
@@ -8,23 +8,27 @@ test_description='read-tree -m -u checks working tree files'
test_expect_success 'two-way setup' '
+ mkdir subdir &&
echo >file1 file one &&
echo >file2 file two &&
- git update-index --add file1 file2 &&
+ echo >subdir/file1 file one in subdirectory &&
+ echo >subdir/file2 file two in subdirectory &&
+ git update-index --add file1 file2 subdir/file1 subdir/file2 &&
git commit -m initial &&
git branch side &&
git tag -f branch-point &&
echo file2 is not tracked on the master anymore &&
- rm -f file2 &&
- git update-index --remove file2 &&
- git commit -a -m "master removes file2"
+ rm -f file2 subdir/file2 &&
+ git update-index --remove file2 subdir/file2 &&
+ git commit -a -m "master removes file2 and subdir/file2"
'
test_expect_success 'two-way not clobbering' '
echo >file2 master creates untracked file2 &&
+ echo >subdir/file2 master creates untracked subdir/file2 &&
if err=`git read-tree -m -u master side 2>&1`
then
echo should have complained
@@ -34,20 +38,82 @@ test_expect_success 'two-way not clobbering' '
fi
'
+echo file2 >.gitignore
+
+test_expect_success 'two-way with incorrect --ignore (1)' '
+
+ if err=`git read-tree -m --ignore=.gitignore master side 2>&1`
+ then
+ echo should have complained
+ false
+ else
+ echo "happy to see $err"
+ fi
+'
+
+test_expect_success 'two-way with incorrect --ignore (2)' '
+
+ if err=`git read-tree -m -u --ignore=foo --ignore=.gitignore master side 2>&1`
+ then
+ echo should have complained
+ false
+ else
+ echo "happy to see $err"
+ fi
+'
+
+test_expect_success 'two-way clobbering a ignored file' '
+
+ git read-tree -m -u --ignore=.gitignore master side
+'
+
+rm -f .gitignore
+
# three-tree test
-test_expect_success 'three-way not complaining' '
+test_expect_success 'three-way not complaining on an untracked path in both' '
- rm -f file2 &&
+ rm -f file2 subdir/file2 &&
git checkout side &&
echo >file3 file three &&
- git update-index --add file3 &&
- git commit -a -m "side adds file3" &&
+ echo >subdir/file3 file three &&
+ git update-index --add file3 subdir/file3 &&
+ git commit -a -m "side adds file3 and removes file2" &&
git checkout master &&
echo >file2 file two is untracked on the master side &&
+ echo >subdir/file2 file two is untracked on the master side &&
git-read-tree -m -u branch-point master side
'
+test_expect_success 'three-way not cloberring a working tree file' '
+
+ git reset --hard &&
+ rm -f file2 subdir/file2 file3 subdir/file3 &&
+ git checkout master &&
+ echo >file3 file three created in master, untracked &&
+ echo >subdir/file3 file three created in master, untracked &&
+ if err=`git read-tree -m -u branch-point master side 2>&1`
+ then
+ echo should have complained
+ false
+ else
+ echo "happy to see $err"
+ fi
+'
+
+echo >.gitignore file3
+
+test_expect_success 'three-way not complaining on an untracked file' '
+
+ git reset --hard &&
+ rm -f file2 subdir/file2 file3 subdir/file3 &&
+ git checkout master &&
+ echo >file3 file three created in master, untracked &&
+ echo >subdir/file3 file three created in master, untracked &&
+
+ git read-tree -m -u --ignore=.gitignore branch-point master side
+'
+
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index 7cfd628..79d21e2 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1,6 +1,7 @@
#include <signal.h>
#include <sys/time.h>
#include "cache.h"
+#include "dir.h"
#include "tree.h"
#include "tree-walk.h"
#include "cache-tree.h"
@@ -77,6 +78,12 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
{
int baselen = strlen(base);
int src_size = len + 1;
+ int i_stk = i_stk;
+ int retval = 0;
+
+ if (o->dir)
+ i_stk = push_exclude_per_directory(o->dir, base, strlen(base));
+
do {
int i;
const char *first;
@@ -143,7 +150,7 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
}
/* No name means we're done */
if (!first)
- return 0;
+ goto leave_directory;
pathlen = strlen(first);
ce_size = cache_entry_size(baselen + pathlen);
@@ -240,13 +247,20 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
newbase[baselen + pathlen] = '/';
newbase[baselen + pathlen + 1] = '\0';
if (unpack_trees_rec(subposns, len, newbase, o,
- indpos, df_conflict_list))
- return -1;
+ indpos, df_conflict_list)) {
+ retval = -1;
+ goto leave_directory;
+ }
free(newbase);
}
free(subposns);
free(src);
} while (1);
+
+ leave_directory:
+ if (o->dir)
+ pop_exclude_per_directory(o->dir, i_stk);
+ return retval;
}
/* Unlink the last component and attempt to remove leading
@@ -456,7 +470,7 @@ static void invalidate_ce_path(struct cache_entry *ce)
/*
* We do not want to remove or overwrite a working tree file that
- * is not tracked.
+ * is not tracked, unless it is ignored.
*/
static void verify_absent(const char *path, const char *action,
struct unpack_trees_options *o)
@@ -465,7 +479,7 @@ static void verify_absent(const char *path, const char *action,
if (o->index_only || o->reset || !o->update)
return;
- if (!lstat(path, &st))
+ if (!lstat(path, &st) && !(o->dir && excluded(o->dir, path)))
die("Untracked working tree file '%s' "
"would be %s by merge.", path, action);
}
diff --git a/unpack-trees.h b/unpack-trees.h
index c460162..191f744 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -16,6 +16,7 @@ struct unpack_trees_options {
int verbose_update;
int aggressive;
const char *prefix;
+ struct dir_struct *dir;
merge_fn_t fn;
int head_idx;
--
1.4.4.1.ga37e
^ permalink raw reply related
* Re: [PATCH 1/4] git-svn: let libsvn_ls_fullurl return properties too
From: Junio C Hamano @ 2006-12-05 1:10 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Eric Wong
In-Reply-To: <20061205010428.GA26687@soma>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>>
>> Please CC people who are primarily working on the part of the
>> system you are improving. In the case of git-svn that would be
>> Eric Wong.
>
> Yes, CCs regarding git-svn would be much appreciated, thanks.
> ...
> Please fix the coding style so that it's consistent with the rest of
> git-svn:
Thanks Eric for your quick response.
> a) indentation is done with hard tabs
> b) no spaces around parentheses: "if ($foo) {" vs "if ( $foo ) {"
>
> Also, adding tests would be helpful in helping me maintain it (I'm not
> a regular svk user, so I don't want to break anything you've done down
> the line).
Another request from the maintainer is to Sign-off the patches.
^ permalink raw reply
* [PATCH 2/2] Loosen "working file will be lost" check in Porcelain-ish
From: Junio C Hamano @ 2006-12-05 1:11 UTC (permalink / raw)
To: git
This uses the previous update to read-tree in Porcelain-ish
commands "git checkout" and "git merge" to loosen the check
when switching branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-checkout.sh | 5 +++--
git-merge.sh | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 737abd0..a2be213 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -161,7 +161,7 @@ then
git-read-tree --reset -u $new
else
git-update-index --refresh >/dev/null
- merge_error=$(git-read-tree -m -u $old $new 2>&1) || (
+ merge_error=$(git-read-tree -m -u --ignore=.gitignore $old $new 2>&1) || (
case "$merge" in
'')
echo >&2 "$merge_error"
@@ -172,7 +172,8 @@ else
git diff-files --name-only | git update-index --remove --stdin &&
work=`git write-tree` &&
git read-tree --reset -u $new &&
- git read-tree -m -u --aggressive $old $new $work || exit
+ git read-tree -m -u --aggressive --ignore=.gitignore $old $new $work ||
+ exit
if result=`git write-tree 2>/dev/null`
then
diff --git a/git-merge.sh b/git-merge.sh
index 272f004..830f471 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -264,7 +264,7 @@ f,*)
echo "Updating $(git-rev-parse --short $head)..$(git-rev-parse --short $1)"
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
- git-read-tree -u -v -m $head "$new_head" &&
+ git-read-tree -v -m -u --ignore=.gitignore $head "$new_head" &&
finish "$new_head" "Fast forward"
dropsave
exit 0
--
1.4.4.1.ga37e
^ permalink raw reply related
* Re: [RFC] Two conceptually distinct commit commands
From: Jakub Narebski @ 2006-12-05 1:19 UTC (permalink / raw)
To: git
In-Reply-To: <200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
> Carl Worth <cworth@cworth.org> wrote:
>
> [...]
>
>> Proposal
>> -------
>> Here are the two commit commands I would like to see in git:
>>
>> commit-index-content [paths...]
>>
>> Commits the content of the index for the given paths, (or all
>> paths in the index). The index content can be manipulated with
>> "git add", "git rm", "git mv", and "git update-index".
>>
>> commit-working-tree-content [paths...]
>>
>> Commits the content of the working tree for the given paths, (or
>> all tracked paths). Untracked files can be committed for the first
>> time by specifying their names on the command-line or by using
>> "git add" to add them just prior to the commit. Any rename or
>> removal of a tracked file will be detected and committed
>> automatically.
>
> Edit somefile with, e.g, emacs: Get backup called somefile~
> Realize that somefile is nonsense, delete it(s edited version)
> commit-working-tree-contents: Now you have the undesirable somefile~ saved
No, you don't, assuming that you have *~ in .gitignore or .git/info/exclude
> Edit somefile, utterly changing it: Get backup called somefile~
> mv somefile newfile
> commit-working-tree-contents: somefile~ saved, newfile lost
No, assuming that you use git-mv as you should.
> Edit somefile a bit, move it to newfile. Make sure no backups left over.
> commit-working-tree-contents: somefile deleted, newfile lost
No, as above.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-05 1:18 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200612050052.kB50qcn2026534@laptop13.inf.utfsm.cl>
[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]
On Mon, 04 Dec 2006 21:52:38 -0300, "Horst H. von Brand" wrote:
> > Commits the content of the working tree for the given paths, (or
> > all tracked paths). Untracked files can be committed for the first
> > time by specifying their names on the command-line or by using
> > "git add" to add them just prior to the commit. Any rename or
> > removal of a tracked file will be detected and committed
> > automatically.
>
> Edit somefile with, e.g, emacs: Get backup called somefile~
> Realize that somefile is nonsense, delete it(s edited version)
> commit-working-tree-contents: Now you have the undesirable somefile~ saved
The semantics I intended to describe for commit-working-tree-content
would not add this file. That's a "new file" so would have to be
mentioned either explicitly on the command-line or in a git-add
command before it would be committed.
> Edit somefile, utterly changing it: Get backup called somefile~
> mv somefile newfile
> commit-working-tree-contents: somefile~ saved, newfile lost
OK, you've found a bug in my description above, (though not in the
intended semantics). By "rename...detected automatically" I meant only
that the fact that a file has "disappeared" as part of a rename need
not be mentioned to git. The fact that the contents are made available
as a new file name still would need to be told to git with "git add",
(or would be worthwhile to mention "git mv" I suppose).
> This is /not/ easy to get right, as it depends on what the user wants, and
> the random programs run in between git commands.
>
> You need to tell git somehow what files you want saved, and which ones are
> junk. I.e., just the first command (unfortunately).
Perhaps I was too oblique in calling this thing
commit-working-tree-contents. This isn't some fabricated-from-scratch
command. The intent of my message was that readers would recognize the
description as matching what the current "commit -a" and "commit
files..." commands do. So I really wasn't trying to invent anything
really different than those. So almost any problems of unexpected
behavior you can find almost surely apply to "commit -a" already.
I did throw one new thing into the description, (that does not exist
in current git). That's the mention that new files could be added by
mentioning them explicitly on the command-line. This was intended as a
way to allow a tutorial to sidestep the details of how "git add"
interacts with the index. If this one feature is a bad idea, it could
be dropped with no impact on the rest of the proposal nor my
discussion of it.
Similarly, I worded the mention of "git add" to suggest it be done
"just prior to the commit". Again, I did this just to avoid having to
mention anything about the need to "git add" again if the file was
edited between the time of add and the time of commit. That language
is already proposed for the git-add documentation, so there's no need
to repeat it all here.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] read-tree: further loosen "working file will be lost" check.
From: Jakub Narebski @ 2006-12-05 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vlklnkv39.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A new option "--ignore=.gitignore" can be used to tell the
> "git-read-tree" command that the user does not mind losing
> contents in untracked files in the working tree if it needs to
> be overwritten by a merge (either a two-way "switch branch"
> merge, or a three-way merge).
[...]
> builtin-read-tree.c | 20 ++++++++++
> dir.c | 4 +-
> dir.h | 3 ++
> t/t1004-read-tree-m-u-wf.sh | 82 ++++++++++++++++++++++++++++++++++++++----
> unpack-trees.c | 24 ++++++++++---
> unpack-trees.h | 1 +
> 6 files changed, 119 insertions(+), 15 deletions(-)
Documentation, please?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sam Vilain @ 2006-12-05 1:31 UTC (permalink / raw)
To: Michael K. Edwards
Cc: Linus Torvalds, Josef Weidendorfer, sf, git, Martin Waitz
In-Reply-To: <f2b55d220612041056w68db5891t105054c0d35efe45@mail.gmail.com>
Michael K. Edwards wrote:
> who don't want to run kernel.org-scale mirrors. To make this work,
> you need sparse repositories (conserving resources when fetching, by
> omitting the bulk of currently un-needed submodules that can reliably
> be obtained later from elsewhere) and shallow cloning (conserving
> resources when publishing, by referring cloners to a third-party
> repository for universally available content).
Did you see GitTorrent? http://gittorrent.utsl.gen.nz/ A lot of
similar ideas to what you mention. Sorry, still no prototype :)
I'd see the submodules thing as a good way to glue together a whole
bunch of repositories, so that the core mirror servers only have to
mirror a small-ish number of repositories.
Sam.
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Horst H. von Brand @ 2006-12-05 2:14 UTC (permalink / raw)
To: Carl Worth; +Cc: Horst H. von Brand, git
In-Reply-To: <87zma316oc.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> On Mon, 04 Dec 2006 21:52:38 -0300, "Horst H. von Brand" wrote:
> > > Commits the content of the working tree for the given paths, (or
> > > all tracked paths). Untracked files can be committed for the first
> > > time by specifying their names on the command-line or by using
> > > "git add" to add them just prior to the commit. Any rename or
> > > removal of a tracked file will be detected and committed
> > > automatically.
> > Edit somefile with, e.g, emacs: Get backup called somefile~
> > Realize that somefile is nonsense, delete it(s edited version)
> > commit-working-tree-contents: Now you have the undesirable somefile~ saved
> The semantics I intended to describe for commit-working-tree-content
> would not add this file. That's a "new file" so would have to be
> mentioned either explicitly on the command-line or in a git-add
> command before it would be committed.
How do you distinguish a "new file, same contents as old file" from "old
file, renamed"? What is the difference between:
mv somefile newfile
and
cp somefine newfile
rm somefile
?
How should
cp somefile newfile
vi somefile
be handled? How about
cp somefile oldfile
vi somefile
or just
mv somefile oldfile
? Or
cp somefile somefile.my-own-bakup
vi somefile
?
The whole problem is your description based on "file renaming" and
such. AFAIU git has a list of file names it is tracking, and for those
names it keeps track of what the contents for each are at each commit. That
the name somefile had some contents that later show up as newfile (both
names tracked) is recorded just as that. You could /interpret/ this as a
"rename" if somefile is then gone, but it could well be something else.
Besides, you'd have to search for the old somefile contents among /all/
newfiles just to find out it was renamed. Better don't mix facts with
interpretation (== guesses on what operations came in between the snapshots
git takes). Note that it should never matter what strange ideas a random
user gets for naming her temporary backup files, or their git configuration.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Daniel Barkalow @ 2006-12-05 2:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Torgil Svensson, sf-gmane, sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612021114270.3476@woody.osdl.org>
On Sat, 2 Dec 2006, Linus Torvalds wrote:
> So that's where I come from. And maybe I'm totally wrong. I'd like to hear
> what people who actually _use_ submodules think.
I think you'd rather hear from people who _would_ use submodules; I've
worked on a number of projects that would have benefitted from that
general functionality, but nobody trusted the implementation enough to
actually use it.
At my work, we're doing a bunch of stuff with microcontrollers. We've got
about a dozen different boards with microcontrollers, and each of them has
different firmware. We also have a bunch of code that can go on any of the
boards.
The way things are organized currently is that each board has its own
project, and there's a "common-micro" project with the common code. This
sort of works, but it means that when you change things in common-micro,
you never know what effect this will have on boards other than the one
you're actually working on. What I'd like to have is that each project has
a "common-micro" subdirectory, and changes to each of these can be merged
into each other, but that doesn't happen automaticly, and each board's
revisions include the common-micro revision they were created with.
A few notes:
I'd never work on common-micro in isolation. Nothing in there even
compiles by itself, because the compiler needs to know the target
microcontroller type, which depends on the board it's for. It only makes
sense to prepare a new revision of "common-micro" in the context of some
particular board, at least if you want to test it at all.
I'd sometimes want to include temporary hacks in the common-micro for a
particular board, when things are late and I need to change some library
behavior in a way that I know works for the board I'm working on, but I
don't have time to think about all of the other boards (each of which is
special in some way).
I'd often make some change that I know improves the cleanliness of
common-micro, but which requires changes to every board to compensate. I
don't want to make all of the changes at once; I'll update each board
appropriately the next time I work on it. But, of course, until I update
each board, that board needs to keep using the version of common-micro
without the changes.
I don't want to have repository states where stuff doesn't work, which
means I can't do it as one big tree; I need to be able to make a commit
with board1 and a common-micro change without having a version of board2
that would use the changed common-micro, because I haven't come up with a
board2 version that works with it yet.
-Daniel
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-05 2:32 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200612050214.kB52E7mG027926@laptop13.inf.utfsm.cl>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
On Mon, 04 Dec 2006 23:14:07 -0300, "Horst H. von Brand" wrote:
> What is the difference between:
> mv somefile newfile
> and
> cp somefine newfile
> rm somefile
There is no difference. This is git, a content tracker.
Same for the rest.
> The whole problem is your description based on "file renaming" and
> such.
OK. Strike the words "or rename" from the description, leaving just:
Any removal of a tracked file will be detected and committed
automatically.
The rest of my analysis still stands, I believe. And I'd be glad to
accept further suggestions on documenting these. The goal is simply to
have a user-oriented description of the semantics that are consistent
between the current "git commit -a" and "git commit files..."
commands.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-05 2:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el239s$e1i$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Mon, 04 Dec 2006 22:19:55 +0100, Jakub Narebski wrote:
> Or even new option to git-apply, namely --index-only, which would apply
> patch to index only.
Wouldn't that leave me in a state where my working-tree would be all
set for reverting the patch? Can you imagine a scenario where that
would actually be useful?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] git-svn: collect SVK source URL on mirror paths
From: Sam Vilain @ 2006-12-05 2:39 UTC (permalink / raw)
To: git
In-Reply-To: <20061204235724.5393E1380C2@magnus.utsl.gen.nz>
Sam Vilain wrote:
> + my $uuid = $props->{'svm:uuid'};
> + $uuid =~ m{^[0-9a-f\-]{41,}}
> + or croak "doesn't look right - svm:uuid is '$uuid'";
This joke back-fired. 41 is too long; UUIDs just *look* longer than
SHA1's :). "36" seems a more appropriate value...
^ permalink raw reply
* Re: On removing files and "git-rm is pointless"
From: Nicolas Pitre @ 2006-12-05 3:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Carl Worth, Sam Vilain
In-Reply-To: <7v8xhnm9o6.fsf@assigned-by-dhcp.cox.net>
On Mon, 4 Dec 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > If it doesn't match HEAD, we can't get it back as easily, so maybe that's
> > the case when we want to have "git rm -f filename".
>
> Hmph. Wouldn't this lossage the same as the lossage we are
> removing the "safety valve" for, when "commit --only" jumps the
> index?
Losing an intermediate file state is much less severe than losing the
latest file state I would think.
^ permalink raw reply
* [RFC/PATCH] git-reset to remove "$GIT_DIR/MERGE_MSG"
From: Junio C Hamano @ 2006-12-05 3:44 UTC (permalink / raw)
To: git; +Cc: ltuikov
An earlier commit a9cb3c6e changed git-commit to use the
contents of MERGE_MSG even when we do not have MERGE_HEAD (the
rationale is in its log message).
However, the change tricks the following sequence to include a
merge message in a completely unrelated commit:
$ git pull somewhere
: oops, the conflicts are too much. forget it.
$ git reset --hard
: work work work
$ git commit
To fix this confusion, this patch makes "git reset" to remove
the leftover MERGE_MSG that was prepared when the user abandoned
the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Marked as RFC because I suspect I am missing a valid use case
where a user might want to say "reset" as part of continuing
the conflicted merge resolution, although I do not think of
any offhand...
git-reset.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-reset.sh b/git-reset.sh
index 3133b5b..c0feb44 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -63,6 +63,7 @@ case "$reset_type" in
;;
esac
-rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" "$GIT_DIR/SQUASH_MSG"
+rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" \
+ "$GIT_DIR/SQUASH_MSG" "$GIT_DIR/MERGE_MSG"
exit $update_ref_status
^ permalink raw reply related
* Re: On removing files and "git-rm is pointless"
From: Carl Worth @ 2006-12-05 3:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Linus Torvalds, git, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0612042225220.2630@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Mon, 04 Dec 2006 22:29:13 -0500 (EST), Nicolas Pitre wrote:
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
> > Hmph. Wouldn't this lossage the same as the lossage we are
> > removing the "safety valve" for, when "commit --only" jumps the
> > index?
>
> Losing an intermediate file state is much less severe than losing the
> latest file state I would think.
Or, in fact, the _only_ state, (if using git-rm to "undo" a git-add of
a new file, for instance).
And as for "jumping" the intermediate state without the safety valve
of "git commit files..." I'm waiting to hear what Junio has to say
about my "two conceptually distinct commit commands" proposal which
would provide a way to avoid that, (the user just indicates whether
it's index content or working-tree content that is to be committed).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-explain
From: Junio C Hamano @ 2006-12-05 3:48 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7v1wngwws6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> So "git reset" is generally your friend whenever something goes wrong. If
>> you also want to reset your checked-out files (which you did NOT want to
>> do in this case, of course), you would have added the "--hard" flag to git
>> reset.
>>
>> And that (finally) concludes this particularly boring "git usage 101"
>> session.
>
> One observation about git, made in a relatively distant past,
> was "git is not a usable system yet; there is no 'git undo'". I
> think it was on the kernel list (I think it was from Alan who
> seems to have lost his last name from his From: line lately, but
> I may be mistaken).
>
> It left a deep psychological trauma in me, not because it was
> stated in a brutal way (it wasn't) but because I fully agreed
> with that statement from the end user point of view, but I did
> not see a good solution to the problem (and I from the beginning
> kept saying "I do not do Porcelains" and kept calling what is
> shipped with core "Porcelain-ish").
> ...
> I think one cause of the "problem" (if not having a general
> "undo" is a problem, and I think it is to some extent) is that
> git Porcelain-ish commands try to stay stateless to allow mixing
> and matching of different commands to leave the door open to the
> end user to be flexible, but they go too far.
They go too far by doing too little.
And here is throwing an idea to remedy it; it is far from
complete but sending it out early before spending too much time
on pursuit of a wild goose.
-- >8 --
[PATCH] git-explain
This patch adds "git-explain" script that notices various clues
other commands can leave the working tree and repository in and
intended to guide the end user out of the confused mess.
This is only a demonstration-of-concept, as many commands do not
leave enough information for us to truly figure out what state
we are in nor how we got into the mess. As a demonstration, it
makes "git merge" to leave a new "$GIT_DIR/FAILED_MERGE" file
when it gives up before touching the working tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-explain.sh | 172 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
git-merge.sh | 3 +-
git-reset.sh | 3 +-
3 files changed, 176 insertions(+), 2 deletions(-)
diff --git a/git-explain.sh b/git-explain.sh
new file mode 100755
index 0000000..07115ae
--- /dev/null
+++ b/git-explain.sh
@@ -0,0 +1,172 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Junio C Hamano
+#
+
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+TOP=`git-rev-parse --show-cdup`
+test -z "$TOP" && TOP=./
+
+say_with_indent() {
+ echo "$@" | sed -e 's/^/ /'
+}
+
+explain_merge_conflict () {
+ test -f $GIT_DIR/HEAD &&
+ test -f "$GIT_DIR/MERGE_HEAD" &&
+ test -f "$GIT_DIR/MERGE_MSG" &&
+ test "z`git ls-files -u`" != z || return 1
+
+ title=$(sed -e q "$GIT_DIR/MERGE_MSG")
+
+ conflicts=$(git ls-files -u |
+ sed -e 's/^[0-7]* [0-9a-f]* [0-3] //' |
+ uniq)
+
+ git diff-index -r --name-only HEAD >"$tmp-1"
+ git diff-tree -r --name-only HEAD MERGE_HEAD >"$tmp-2"
+ locals=`comm -23 "$tmp-1" "$tmp-2"`
+
+ cat <<EOF
+You tried a merge whose title will be
+
+ $title
+
+This may have successfully merged some paths and they are already
+staged for the next commit, but the following paths could not be
+automatically merged:
+
+EOF
+
+ say_with_indent "$conflicts"
+
+ if test "z$locals" != z
+ then
+ cat <<\EOF
+
+Also you seem to have local modifications unrelated to this
+merge in the following paths:
+
+EOF
+
+ say_with_indent "$locals"
+ fi
+
+ cat <<\EOF
+
+There are two ways to proceed from here:
+
+(1) You can decide to abort this for now and get back to the
+ state before you started the merge.
+
+ $ git reset --hard
+
+ will revert your working tree files to the latest commit
+ before this merge. Note that you would lose the local
+ modifications with this action, so you might want to
+ preserve them with this command before doing so:
+
+ $ git diff HEAD -- <locally changed files> >preserved-local-changes
+
+ Then you can re-apply the changes after running "git reset
+ --hard".
+
+(2) To resolve the conflicts and record this merge, you first
+ need to examine the conflicted paths listed above, and edit
+ them in your working tree. After you are done, stage the
+ final version of these paths and make a commit, like this:
+
+ $ git add <locally changed files>
+ $ git commit
+
+ Do not use "git commit -a" unless you want the local
+ modifications that are not related to this merge committed
+ along with the changes this merge brings in.
+EOF
+}
+
+explain_merge_stop () {
+ test -f $GIT_DIR/HEAD &&
+ test -f $GIT_DIR/FAILED_MERGE &&
+ test "z`git rev-parse HEAD`" = "z`git rev-parse ORIG_HEAD`" &&
+ test "z`git ls-files -u`" = z || return 1
+
+ git diff-index -r --name-only HEAD >"$tmp-1"
+ git diff-tree -r --name-only HEAD FAILED_MERGE >"$tmp-2"
+ conflicts=`comm -12 "$tmp-1" "$tmp-2"`
+ locals=`comm -23 "$tmp-1" "$tmp-2"`
+
+ cat <<\EOF
+You tried a merge but it stopped without touching your working tree,
+because you had local changes in the following paths that may also
+be involved in the merge:
+
+EOF
+ say_with_indent "$conflicts"
+
+ if test "z$locals" != z
+ then
+ cat <<\EOF
+
+Also you seem to have local modifications unrelated to this
+merge in the following paths:
+
+EOF
+
+ say_with_indent "$locals"
+
+ fi
+
+ cat <<\EOF
+
+There are two ways to proceed from here:
+
+(1) You can decide to abort this merge for now. You do not have
+ to do anything in this case because the merge hasn't touched
+ your working tree files yet.
+
+(2) You can first make the merge and re-apply your local changes
+ on top of the merge result. To do this, first stash away
+ your local changes in a temporary commit, like this:
+
+ $ git commit -a -m 'WIP'
+ $ git tag WIP
+ $ git reset --hard HEAD^
+
+ and run the same "git merge" (or "git pull") again. After
+ you finished the merge, you can review the local change with:
+
+ $ git show WIP
+
+ and re-apply them to your working tree as you see fit.
+EOF
+}
+
+explain_am () {
+ test -d $TOP/.dotest || return 1
+
+ cat <<EOF
+You tried to apply a series of `cat .dotest/last` patch(es) and
+are currently handling patch #`cat .dotest/next`.
+
+EOF
+
+}
+
+explain_base () {
+ # This comes at the end.
+ cat <<EOF
+Don't worry, you are not in the middle of anything complicated.
+EOF
+
+}
+
+tmp="$GIT_DIR/tmp"
+trap 'rm -f $tmp-*' 0
+
+explain_merge_conflict ||
+explain_merge_stop ||
+explain_am ||
+explain_base
\ No newline at end of file
diff --git a/git-merge.sh b/git-merge.sh
index 272f004..674abad 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -20,7 +20,7 @@ index_merge=t
dropsave() {
rm -f -- "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/MERGE_MSG" \
- "$GIT_DIR/MERGE_SAVE" || exit 1
+ "$GIT_DIR/MERGE_SAVE" "$GIT_DIR/FAILED_MERGE" || exit 1
}
savestate() {
@@ -400,6 +400,7 @@ case "$best_strategy" in
'')
restorestate
echo >&2 "No merge strategy handled the merge."
+ echo "$@" >"$GIT_DIR/FAILED_MERGE"
exit 2
;;
"$wt_strategy")
diff --git a/git-reset.sh b/git-reset.sh
index 3133b5b..045ee79 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -63,6 +63,7 @@ case "$reset_type" in
;;
esac
-rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" "$GIT_DIR/SQUASH_MSG"
+rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" \
+ "$GIT_DIR/SQUASH_MSG" "$GIT_DIR/FAILED_MERGE"
exit $update_ref_status
--
1.4.4.1.g15e3
^ permalink raw reply related
* Re: [RFC] Two conceptually distinct commit commands
From: Theodore Tso @ 2006-12-05 3:51 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87d56z32e1.wl%cworth@cworth.org>
On Mon, Dec 04, 2006 at 11:08:22AM -0800, Carl Worth wrote:
>
> Here are the two commit commands I would like to see in git:
>
> commit-index-content [paths...]
>
> Commits the content of the index for the given paths, (or all
> paths in the index). The index content can be manipulated with
> "git add", "git rm", "git mv", and "git update-index".
>
> commit-working-tree-content [paths...]
>
> Commits the content of the working tree for the given paths, (or
> all tracked paths). Untracked files can be committed for the first
> time by specifying their names on the command-line or by using
> "git add" to add them just prior to the commit. Any rename or
> removal of a tracked file will be detected and committed
> automatically.
I think this is a very interesting proposal, although I think I
disagree with the last part:
Any [rename or] removal of a tracked file will be detected and
committed automatically.
If adds aren't going done automatically (because otherwise you have
problems with foo.c~ accidentally getting checked it), then it's
non-symmetric to expect that deletes will also happen automatically.
It's relatively rare that files are removed or renamed, and sometimes
files accidentally disappear.
So in the case where there are no pathnames given to "git
commit-working-tree-content", I would argue that it does not do any
implicit "git add" on new files NOR any implicit "git rm" on missing
files unless the user actually specifies an --implicit-add or
--implicit-delete option, respectively. If users want to make
--implicit-add and/or --implicit-delete the default, that could be a
configuration option, but I don't think it should be a default.
A second issue which you left unspecified is what should
commit-working-tree-content do if the index != HEAD. In particular,
in this case:
edit foo.c
git update-index
edit foo.c
git commit-working-tree-content foo.c
What should happen to foo.c in the index? Should it be stay the same?
Should the contents be replaced with version of foo.c that has just
been commited? The latter seems to make sense, but runs the risk of
losing the data (what was in the index). The former has the downside
that the index might have a version of foo.c which is older than what
has been just commited, which could be confusing. Or should git
commit-working-tree abort with an error message if index != HEAD?
^ permalink raw reply
* Re: [PATCH] git-explain
From: Nicolas Pitre @ 2006-12-05 3:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vwt57j94c.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 4 Dec 2006, Junio C Hamano wrote:
> [PATCH] git-explain
>
> This patch adds "git-explain" script that notices various clues
> other commands can leave the working tree and repository in and
> intended to guide the end user out of the confused mess.
What about calling it git-whatsup instead?
^ permalink raw reply
* Re: [PATCH] git-explain
From: J. Bruce Fields @ 2006-12-05 3:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0612042253250.2630@xanadu.home>
On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
>
> > [PATCH] git-explain
> >
> > This patch adds "git-explain" script that notices various clues
> > other commands can leave the working tree and repository in and
> > intended to guide the end user out of the confused mess.
>
> What about calling it git-whatsup instead?
No, clearly it should be git-wtf.
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-05 4:08 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <20061204205126.GA23853@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Same here.. I'm still waiting for it to fetch and will try to reproduce
> it here.
Update: Nearly 16k revisions later and I still can't reproduce this on
my computer.
--
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-05 4:19 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061205040844.GA6826@localdomain>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> Eric Wong <normalperson@yhbt.net> wrote:
>> Same here.. I'm still waiting for it to fetch and will try to reproduce
>> it here.
Eric> Update: Nearly 16k revisions later and I still can't reproduce this on
Eric> my computer.
I still say it was odd that it happened exactly when I did a git-svn
update in the other window. :)
So, maybe I'll just toss this archive. Oh wait, can I back it up a few dozen
revs and try to roll forward? That might be interesting.
git-reset --hard HEAD~10
blow away everything you had me blow away last time
make git-svn equal to HEAD
git-svn rebuild
git-svn fetch
Lemme try that.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-05 4:33 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <86slfvj7oi.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> Eric Wong <normalperson@yhbt.net> wrote:
>>> Same here.. I'm still waiting for it to fetch and will try to reproduce
>>> it here.
Eric> Update: Nearly 16k revisions later and I still can't reproduce this on
Eric> my computer.
Randal> I still say it was odd that it happened exactly when I did a git-svn
Randal> update in the other window. :)
Randal> So, maybe I'll just toss this archive. Oh wait, can I back it up a few dozen
Randal> revs and try to roll forward? That might be interesting.
Randal> git-reset --hard HEAD~10
Randal> blow away everything you had me blow away last time
Randal> make git-svn equal to HEAD
Randal> git-svn rebuild
Randal> git-svn fetch
Randal> Lemme try that.
Nope. I reset it back 20 revs, and it correctly fast forwarded until
the fatal item again:
M trunk/languages/plumhead/past_xml_to_past_pir.xsl
M trunk/languages/plumhead/t/hello.t
A trunk/languages/plumhead/t/strings.t
M trunk/languages/plumhead/t/arithmetics.t
M trunk/languages/plumhead/TODO
M trunk/languages/plumhead/phc_xml_to_past_xml.xsl
r15936 = 1933fe5f95d4ff29d9bb086faca9059a765b7abb
M trunk/MANIFEST
M trunk/MANIFEST.SKIP
r15937 = 17624a0457339d4eeeecc03632d609b6220ac02d
M trunk/languages/plumhead/phc_xml_to_past_xml.xsl
r15938 = bc577df90b886d8afd89774231cd321a40fd06ed
M trunk/languages/tcl/runtime/builtin/string.pir
r15939 = dddd42d84b38cb5ab9cc8ca377767459f3966a60
M trunk/languages/tcl/runtime/builtin/binary.pir
r15940 = 5cd630a9b67948eb788cb4fdb87998d960977a75
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/RequirePortableShebang.pm
M trunk/compilers/past-pm/POST/Compiler.pir
M trunk/compilers/past-pm/PAST/Compiler.pir
M trunk/compilers/past-pm/PAST-pm.pir
M trunk/languages/perl6/src/quote.pir
M trunk/languages/perl6/src/classes/Str.pir
M trunk/languages/perl6/src/classes/Code.pir
M trunk/languages/perl6/src/classes/Num.pir
M trunk/languages/plumhead/t/selection.txt
M trunk/languages/plumhead/t/superglobals.t
M trunk/languages/plumhead/t/strings.t
M trunk/languages/tcl/runtime/builtin/clock.pir
no blob information
512 at /opt/git/bin/git-svn line 457
main::fetch_lib() called at /opt/git/bin/git-svn line 328
main::fetch() called at /opt/git/bin/git-svn line 973
main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
main::multi_fetch() called at /opt/git/bin/git-svn line 187
512 at /opt/git/bin/git-svn line 980
main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
main::multi_fetch() called at /opt/git/bin/git-svn line 187
It just hates me, perhaps.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* [PATCH 4/5] git-svn: collect revision properties when fetching
From: Sam Vilain @ 2006-12-05 5:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
From: Sam Vilain <sam@vilain.net>
Perhaps there is information in the "revision properties" (unversioned
metadata associated with commits) that will affect the way that we
save the revision. Collect them.
---
Sorry for the long lines.
git-svn.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 800c579..70c34b0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -441,12 +441,16 @@ sub fetch_lib {
if ($last_commit) {
$log_msg = libsvn_fetch(
$last_commit, @_);
+ $log_msg->{revprops}
+ = $SVN->rev_proplist($log_msg->{revision});
$last_commit = git_commit(
$log_msg,
$last_commit,
@parents);
} else {
$log_msg = libsvn_new_tree(@_);
+ $log_msg->{revprops}
+ = $SVN->rev_proplist($log_msg->{revision});
$last_commit = git_commit(
$log_msg, @parents);
}
^ permalink raw reply related
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