* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Jeffrey C. Ollie @ 2007-06-21 15:00 UTC (permalink / raw)
To: Dave O'Neill; +Cc: Steven Grimm, git
In-Reply-To: <20070621141415.GA21065@magnesium.roaringpenguin.com>
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]
On Thu, 2007-06-21 at 10:14 -0400, Dave O'Neill wrote:
> On Wed, Jun 20, 2007 at 08:19:33PM -0700, Steven Grimm wrote:
>
> > Any chance of applying this to git-svn instead? There has been talk of
> > deprecating git-svnimport since git-svn now does everything
> > git-svnimport does, and more. (If you believe that's not the case,
> > please describe what you're doing with git-svnimport that you can't do
> > with git-svn.)
>
> Sure, I can probably apply it to git-svn as well, but based on the
> testing I've done, git-svnimport still works better for what I'm doing.
> I'm trying to do a straight conversion from SVN to git, so we can do
> away with our Subversion repositories, so I won't need the bidirectional
> support of git-svn.
>
> If git-svn had a --one-way option that could
> - know that I'm converting, and import my SVN tags and branches to
> local tags and heads rather than remotes
This quickie Python script should convert the "tag branches" to regular
Git tags:
import os
refs = os.popen('git-for-each-ref --format="%(objectname)%00%(refname)%00" refs/remotes/tags')
for line in refs:
[sha, ref] = line.split('\0')[:2]
os.system('git tag %s %s' % (ref[18:], sha))
> - turn off the git-svn-id: tags in the commit
git svn fetch --no-metadata
> - avoid preserving a .git/svn/ directory (a git-svn conversion was 50%
> larger than one from git-svnimport because of this)
Once you are done importing, you can delete that directory.
> - convert svn:ignore attrs to .gitignore (like the -I option of
> git-svnignore)
git svn show-ignore
> then I wouldn't need git-svnimport. Alternatively, if there's some way
> to postprocess my clone to do all of the above, that would probably be
> good enough.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Dave O'Neill @ 2007-06-21 14:22 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <467A141D.1050502@vilain.net>
On Thu, Jun 21, 2007 at 06:01:01PM +1200, Sam Vilain wrote:
> This is a good idea, of course if somebody didn't specify the magic -I
> switch to their 'svk sm' incantation then there will be multiple changes
> listed in a single revision
Yeah, I don't think there's much hope of fully cleaning up those
messages. My goal was just to make 'git log --pretty=oneline' show
something meaningful from the commit message, rather than:
edfbf48adabb68f9b3973f5950570c355f3ee811 r6211@oxygen: dmo | 2007-04-17 17:28:23 -0400
d5b3268e815ce9e88dd617a5b62df80da263f396 r6210@oxygen: dmo | 2007-04-17 15:54:04 -0400
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Dave O'Neill @ 2007-06-21 14:14 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <4679EE45.2080605@midwinter.com>
On Wed, Jun 20, 2007 at 08:19:33PM -0700, Steven Grimm wrote:
> Any chance of applying this to git-svn instead? There has been talk of
> deprecating git-svnimport since git-svn now does everything
> git-svnimport does, and more. (If you believe that's not the case,
> please describe what you're doing with git-svnimport that you can't do
> with git-svn.)
Sure, I can probably apply it to git-svn as well, but based on the
testing I've done, git-svnimport still works better for what I'm doing.
I'm trying to do a straight conversion from SVN to git, so we can do
away with our Subversion repositories, so I won't need the bidirectional
support of git-svn.
If git-svn had a --one-way option that could
- know that I'm converting, and import my SVN tags and branches to
local tags and heads rather than remotes
- turn off the git-svn-id: tags in the commit
- avoid preserving a .git/svn/ directory (a git-svn conversion was 50%
larger than one from git-svnimport because of this)
- convert svn:ignore attrs to .gitignore (like the -I option of
git-svnignore)
then I wouldn't need git-svnimport. Alternatively, if there's some way
to postprocess my clone to do all of the above, that would probably be
good enough.
Cheers,
Dave
^ permalink raw reply
* Re: Moving a directory with history from one repository to another while renaming
From: Johannes Schindelin @ 2007-06-21 14:05 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Jeff King
In-Reply-To: <200706211457.29030.andyparkins@gmail.com>
Hi,
On Thu, 21 Jun 2007, Andy Parkins wrote:
> On Thursday 2007 June 21, Jeff King wrote:
>
> > You can do this much more efficiently by just operating on the index.
> > Something like:
> >
> > git-filter-branch --index-filter \
> > 'git-ls-files -s | sed -n 's/change/paths/p' | git-update-index
> > --index-info' \ directorymoved
>
> :-D Even better. I am definitely in the "fan of git-filter-branch" camp.
>
> Thanks for sharing that line; I've actually found it instructive for more than
> just git-filter-branch. I definitely hadn't appreciated the fact that the
> index can be so easily manipulated.
You have to adapt the line minimally: As is, it will possibly catch the
wrong names, and it does not _move_ the directory, but rather _copy_ it.
So I think something like
git-ls-files -s | sed "s-\t-&newsubdir/-" |
GIT_INDEX_FILE="$GIT_INDEX_FILE".new git-update-index --index-info &&
mv "$GIT_INDEX_FILE".new "$GIT_INDEX_FILE"
is needed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Schindelin @ 2007-06-21 14:03 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <20070621131915.GD4487@coredump.intra.peff.net>
Hi,
On Thu, 21 Jun 2007, Jeff King wrote:
> On Thu, Jun 21, 2007 at 12:52:11PM +0100, Johannes Schindelin wrote:
>
> > When there are several candidates for a rename source, and one of them
> > has an identical basename to the rename target, take that one.
>
> That's a reasonable heuristic, but it unfortunately won't match simple
> things like:
>
> i386_widget.c -> arch/i386/widget.c
That's right. But every heuristic falls down eventually. Personally, I
think basename_same() is good enough, even if the technical challenge to
implement a small enough Levenshtein, which still respects directory
boundaries somehow (and not just throws them away).
Besides, Levenshtein would introduce a ranking, not a boolean value like
basename_same(). And that complicates the code.
All in all, I'd say Levenshtein is not worth the _result_.
Ciao,
Dscho
^ permalink raw reply
* Re: Moving a directory with history from one repository to another while renaming
From: Andy Parkins @ 2007-06-21 13:57 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20070621130137.GB4487@coredump.intra.peff.net>
On Thursday 2007 June 21, Jeff King wrote:
> You can do this much more efficiently by just operating on the index.
> Something like:
>
> git-filter-branch --index-filter \
> 'git-ls-files -s | sed -n 's/change/paths/p' | git-update-index
> --index-info' \ directorymoved
:-D Even better. I am definitely in the "fan of git-filter-branch" camp.
Thanks for sharing that line; I've actually found it instructive for more than
just git-filter-branch. I definitely hadn't appreciated the fact that the
index can be so easily manipulated.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Johannes Schindelin @ 2007-06-21 13:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Andy Parkins, git, Junio C Hamano
In-Reply-To: <vpqfy4lxwvl.fsf@bauges.imag.fr>
Hi,
On Thu, 21 Jun 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Have you checked the files? They are all some blobs in the test scripts.
>
> Yes, but how does it make any difference? You still want git to manage
> them properly, don't you?
Yes. And Git explicitely allows what I call stupid. And yes, those
_identical_ files in the test suit should probably all be folded into
single files, and the places where they are used should reference _that_
single instance.
Ciao,
Dscho
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Matthieu Moy @ 2007-06-21 13:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706211417090.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Have you checked the files? They are all some blobs in the test scripts.
Yes, but how does it make any difference? You still want git to manage
them properly, don't you?
--
Matthieu
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Johannes Schindelin @ 2007-06-21 13:22 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200706211344.47560.andyparkins@gmail.com>
Hi,
On Thu, 21 Jun 2007, Andy Parkins wrote:
> I open up gimp, draw a big red X and save it as new-button.png. Then I
> copy that file to open-button.png and save-button.png, knowing that at
> some point in the future, someone will come and replace those red-X
> images with something appropriate.
So you have a couple of identical files in your repo, which are
placeholders. That is quite different from what I criticised of being
stupid.
Well, I would not have checked in the files in your place, but only one:
dumb-red-X.png
Then, my Makefile would have checked for the existence of, say,
my-wonderful-ok-button.png, and if it does not exist yet, copy
dumb-red-X.png to it.
Now, when somebody comes along, paining the prettiest ok button I ever
saw, I copy that over the copy of dumb-red-X.png, and check it in.
It has the further bonus that I know exactly which buttons I have to find
a suck^Wgifted artist for.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Jeff King @ 2007-06-21 13:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <Pine.LNX.4.64.0706211248420.4059@racer.site>
On Thu, Jun 21, 2007 at 12:52:11PM +0100, Johannes Schindelin wrote:
> When there are several candidates for a rename source, and one of them
> has an identical basename to the rename target, take that one.
That's a reasonable heuristic, but it unfortunately won't match simple
things like:
i386_widget.c -> arch/i386/widget.c
You really don't care about "is this a good match" as much as providing
an order to potential matches. I think something like a Levenshtein
distance between the full pathnames would give good results, and would
cover almost every situation that the basename heuristic would (there
are a few exceptions, like getting "file.c" from either "file2.c" or
"foo/file.c", but that seems kind of pathological).
Sorry to post without a patch, but I don't have time right this second.
I'll add it to the end of my (ever-growing) todo list if you think it's
a good idea and don't do it yourself. :)
-Peff
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Johannes Schindelin @ 2007-06-21 13:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Andy Parkins, git, Junio C Hamano
In-Reply-To: <vpqodj9zcxf.fsf@bauges.imag.fr>
Hi,
On Thu, 21 Jun 2007, Matthieu Moy wrote:
> Well, why look so far to find an example of people having identical
> files in their tree?
>
> $ cd git
> $ git-ls-files -z | xargs -0 md5sum | cut -f 1 -d ' ' | wc -l
> 973
> $ git-ls-files -z | xargs -0 md5sum | cut -f 1 -d ' ' | sort | uniq | wc -l
> 964
> $
Have you checked the files? They are all some blobs in the test scripts.
Ciao,
Dscho
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Jeff King @ 2007-06-21 13:10 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Johannes Schindelin, Junio C Hamano
In-Reply-To: <vpqodj9zcxf.fsf@bauges.imag.fr>
On Thu, Jun 21, 2007 at 02:53:32PM +0200, Matthieu Moy wrote:
> Well, why look so far to find an example of people having identical
> files in their tree?
>
> $ cd git
> $ git-ls-files -z | xargs -0 md5sum | cut -f 1 -d ' ' | wc -l
> 973
> $ git-ls-files -z | xargs -0 md5sum | cut -f 1 -d ' ' | sort | uniq | wc -l
> 964
md5? What is this, CVS? How about:
git-ls-files -s | cut -d' ' -f2 | sort | uniq -d | wc -l
Your pipeline will also list files in the working directory, which can
inflate the number of duplicates (note that git-foo.sh and git-foo will
have the same content).
-Peff
PS Please don't take this to mean I think duplicate files are stupid; I
think they can be quite useful. I just wanted to nitpick your shell
command. :)
^ permalink raw reply
* Re: Moving a directory with history from one repository to another while renaming
From: Jeff King @ 2007-06-21 13:01 UTC (permalink / raw)
To: Andy Parkins; +Cc: Git Mailing List
In-Reply-To: <200706211337.32978.andyparkins@gmail.com>
On Thu, Jun 21, 2007 at 01:37:30PM +0100, Andy Parkins wrote:
> git checkout directoryonly
> git-filter-branch --tree-filter "mkdir -p sub/dir/repoB_directory; \
> mv file1 file2 file3 sub/dir/repoB_directory" directorymoved
You can do this much more efficiently by just operating on the index.
Something like:
git-filter-branch --index-filter \
'git-ls-files -s | sed -n 's/change/paths/p' | git-update-index --index-info' \
directorymoved
-Peff
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Matthieu Moy @ 2007-06-21 12:53 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Schindelin, Junio C Hamano
In-Reply-To: <200706211344.47560.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2007 June 21, Johannes Schindelin wrote:
>
>> > would let people keep their copies. What I was objecting to was the
>> > idea that any repository with duplicate files was "stupid".
>>
>> FWIW I find it stupid, too.
>
> Thanks very much. Okay, as I've been put in the position of defending this,
> let me give you the use case that has cropped up for me to do this stupid
> thing.
Well, why look so far to find an example of people having identical
files in their tree?
$ cd git
$ git-ls-files -z | xargs -0 md5sum | cut -f 1 -d ' ' | wc -l
973
$ git-ls-files -z | xargs -0 md5sum | cut -f 1 -d ' ' | sort | uniq | wc -l
964
$
--
Matthieu
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Andy Parkins @ 2007-06-21 12:44 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706211252190.4059@racer.site>
On Thursday 2007 June 21, Johannes Schindelin wrote:
> > would let people keep their copies. What I was objecting to was the
> > idea that any repository with duplicate files was "stupid".
>
> FWIW I find it stupid, too.
Thanks very much. Okay, as I've been put in the position of defending this,
let me give you the use case that has cropped up for me to do this stupid
thing.
I've got a GUI program with a load of tool buttons. Each of those buttons
will, in the final product, be unique images. When I write the program, I
want to be able to refer to each of the button images in the correct place.
e.g.
setImage( NewButton, "path/to/new-button.png" );
setImage( OpenButton, "path/to/open-button.png" );
setImage( SaveButton, "path/to/save-button.png" );
Unfortunately, I can't draw. So, I open up gimp, draw a big red X and save it
as new-button.png. Then I copy that file to open-button.png and
save-button.png, knowing that at some point in the future, someone will come
and replace those red-X images with something appropriate.
All those images now go in the repository. Symbolic links are not an option,
as it's got to be checkable out on Windows.
Tell me what part of that is stupid?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Moving a directory with history from one repository to another while renaming
From: Andy Parkins @ 2007-06-21 12:37 UTC (permalink / raw)
To: Git Mailing List
Hello,
I'm sure this has come up before, and I'm sure the answer is
git-filter-branch.
I have repositoryA, which has a subdirectory, say "repoA_directory", and I've
done some development in it. I now wish I'd done this development in a
different repository, repositoryB and that it would have been in a different
directory, "sub/dir/repoB_directory".
What's the best way to do this?
*** Stop press (I tried a bit harder before sending the above email) ***
This is what I did, and am reporting here for future googlers; and in case
you're all interested in git-filter-branch success stories (which,
incidentally is a fabulous little tool).
In repositoryA...
git-filter-branch --subdirectory-filter "repoA_directory" directoryonly
Now, the branch "directoryonly" contains repoA_directory (and history) as a
new root commit, and as the root directory of the repository.
git checkout directoryonly
git-filter-branch --tree-filter "mkdir -p sub/dir/repoB_directory; \
mv file1 file2 file3 sub/dir/repoB_directory" directorymoved
Now, the branch "directorymoved" contains repoA_directory (and history) alone,
moved to "sub/dir/repoB_directory".
In repositoryB...
git-fetch /path/to/repositoryA directorymoved:repoAbranch
repositoryB now contains a new, independently rooted, branch containing only
sub/dir/repoB_directory. We would ideally at this point just rebase that
independent branch to the appropriate point in the main development branch of
repoB, but we can't because repoAbranch doesn't share a common ancestor with
any of the repositoryB branches.
That is to say, we have these two branches:
* --- * --- * --- * --- * (master)
B --- * --- * (repoAbranch)
but we want:
* --- * --- * --- * --- * (master)
\
B --- * --- * (repoAbranch)
Find the commit hash of the first commit in repoAbranch, B, and apply that one
commit as a patch to your mainline branch (probably making a temporary branch
on your way, to preserve your current master)
git checkout -b temp
git show --pretty=email hash-of-B | git-am
* --- * --- * --- * --- * (master)
\
B' (temp)
B --- * --- * (repoAbranch)
We've now got a commit that will serve as a common ancestor.
git-rebase --onto temp hash-of-B repoAbranch
git-branch -D temp
* --- * --- * --- * --- * (master)
\
B' --- *' --- *' (repoAbranch)
B --- * --- * [orphan branch]
Voila. repoAbranch is now the original repoA_directory, but stored at
sub/dir/repoB_directory and includes the development history.
git-gc --prune will get rid of the orphan branch if you're bothered about the
storage.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Johannes Schindelin @ 2007-06-21 11:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vr6o5zt76.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Thu, 21 Jun 2007, Junio C Hamano wrote:
> [...] using "git version" to check the version and say "1.5.3 has blame
> -w" > might be easier to manage [ than list-features maintenance ...]
We do something similar already with curl features. So this sounds
sensible to me. Shawn?
Ciao,
Dscho
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Johannes Schindelin @ 2007-06-21 11:52 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200706211050.03519.andyparkins@gmail.com>
Hi,
On Thu, 21 Jun 2007, Andy Parkins wrote:
> On Thursday 2007 June 21, Junio C Hamano wrote:
>
> > It's not even an argument, nor an attempt to justify it. It was just
> > an explanation of historical fact "It did not bother". Please re-read
> > the final part of the message, which you omitted from your quote.
>
> I appreciated (as always) your practicality in that what you proposed
> would let people keep their copies. What I was objecting to was the
> idea that any repository with duplicate files was "stupid".
FWIW I find it stupid, too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] diffcore-rename: favour identical basenames
From: Johannes Schindelin @ 2007-06-21 11:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <alpine.LFD.0.98.0706202031200.3593@woody.linux-foundation.org>
When there are several candidates for a rename source, and one of them
has an identical basename to the rename target, take that one.
Noticed by Govind Salinas, posted by Shawn O. Pearce, partial patch
by Linus Torvalds.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 20 Jun 2007, Linus Torvalds wrote:
> I think we should just consider the basename as an "added
> similarity bonus".
>
> IOW, we currently sort purely by data similarity, but how about
> just adding a small increment for "same base name".
>
> [patch suggestion snipped, since it is identical what is below]
How 'bout this?
diffcore-rename.c | 33 ++++++++++++++++++++++++++++++++-
t/t4001-diff-rename.sh | 13 +++++++++++++
2 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 93c40d9..79c984c 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -119,6 +119,21 @@ static int is_exact_match(struct diff_filespec *src,
return 0;
}
+static int basename_same(struct diff_filespec *src, struct diff_filespec *dst)
+{
+ int src_len = strlen(src->path), dst_len = strlen(dst->path);
+ while (src_len && dst_len) {
+ char c1 = src->path[--src_len];
+ char c2 = dst->path[--dst_len];
+ if (c1 != c2)
+ return 0;
+ if (c1 == '/')
+ return 1;
+ }
+ return (!src_len || src->path[src_len - 1] == '/') &&
+ (!dst_len || dst->path[dst_len - 1] == '/');
+}
+
struct diff_score {
int src; /* index in rename_src */
int dst; /* index in rename_dst */
@@ -186,8 +201,11 @@ static int estimate_similarity(struct diff_filespec *src,
*/
if (!dst->size)
score = 0; /* should not happen */
- else
+ else {
score = (int)(src_copied * MAX_SCORE / max_size);
+ if (basename_same(src, dst))
+ score++;
+ }
return score;
}
@@ -295,9 +313,22 @@ void diffcore_rename(struct diff_options *options)
if (rename_dst[i].pair)
continue; /* dealt with an earlier round */
for (j = 0; j < rename_src_nr; j++) {
+ int k;
struct diff_filespec *one = rename_src[j].one;
if (!is_exact_match(one, two, contents_too))
continue;
+
+ /* see if there is a basename match, too */
+ for (k = j; k < rename_src_nr; k++) {
+ one = rename_src[k].one;
+ if (basename_same(one, two) &&
+ is_exact_match(one, two,
+ contents_too)) {
+ j = k;
+ break;
+ }
+ }
+
record_rename_pair(i, j, (int)MAX_SCORE);
rename_count++;
break; /* we are done with this entry */
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 2e3c20d..90c085f 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -64,4 +64,17 @@ test_expect_success \
'validate the output.' \
'compare_diff_patch current expected'
+test_expect_success 'favour same basenames over different ones' '
+ cp path1 another-path &&
+ git add another-path &&
+ git commit -m 1 &&
+ git rm path1 &&
+ mkdir subdir &&
+ git mv another-path subdir/path1 &&
+ git runstatus | grep "renamed: .*path1 -> subdir/path1"'
+
+test_expect_success 'favour same basenames even with minor differences' '
+ git show HEAD:path1 | sed "s/15/16/" > subdir/path1 &&
+ git runstatus | grep "renamed: .*path1 -> subdir/path1"'
+
test_done
--
1.5.2.2.2822.g027a6-dirty
^ permalink raw reply related
* Re: Suggestions for documentation
From: Claudio Scordino @ 2007-06-21 11:24 UTC (permalink / raw)
To: Luiz Fernando N. Capitulino; +Cc: git, Johannes.Schindelin
In-Reply-To: <20070620180615.529dff2a@localhost>
Hi,
actually I didn't understand the difference between "git clone --bare" and
"git --bare fetch" either... (maybe is not clear in the documentation ?)
For instance, what should be used when setting up a public not-working repository ?
I mean, we can use both
git --bare init
git --bare fetch ... master:master
and
git clone --bare ...
Thank you in advance.
Regards,
Claudio
Luiz Fernando N. Capitulino wrote:
> Em Tue, 19 Jun 2007 09:33:05 +0200
> Claudio Scordino <cloud.of.andor@gmail.com> escreveu:
>
> | Hi,
> |
> | I just want to suggest to put some missing information in the git manpages.
> |
> | 1) As my previous question shown, how to clone from a specified port is not
> | currently documented. You should just add a sentence saying that the command is
> |
> | git clone git://server:port/path/
> |
> | 2) Maybe it is better to highlight that after a push on a remote repository, the
> | user has to do a checkout on that repository (people from the CVS and SVN worlds
> | get easily confused, otherwise).
> |
> | Moreover (and I did not fully understood why) if I just use "git checkout"
> | without the -f option, I cannot see the changes that have been pushed from the
> | cloned repository.
>
> git-rebase documentation needs some change too. We should add some high level
> description in one paragraph at the top of the file.
>
> I answer the very same question ('why should I want to use git-rebase?')
> three times per week.
>
> I'll submit a patch shortly.
>
^ permalink raw reply
* Re: Strange diff behavior?
From: Johannes Schindelin @ 2007-06-21 10:31 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Jason Sewall, git
In-Reply-To: <1182408458.6159.0.camel@localhost>
Hi,
On Thu, 21 Jun 2007, Raimund Bauer wrote:
> On Thu, 2007-06-21 at 02:13 +0100, Johannes Schindelin wrote:
>
> > Just a guess: core.autocrlf=true?
>
> My guess: apply.whitespace=strip
Much better guess, I guess. Jason?
Ciao,
Dscho
^ permalink raw reply
* [PATCH][RESEND] git-submodule: provide easy way of adding new submodules
From: Sven Verdoolaege @ 2007-06-21 9:53 UTC (permalink / raw)
To: git, Lars Hjemli, Junio C Hamano; +Cc: skimo
To make a submodule effectively usable, the path and
a URL where the submodule can be cloned need to be stored
in .gitmodules. This subcommand takes care of setting
this information after cloning the new submodule.
Only the index is updated, so, if needed, the user may still
change the URL or switch to a different branch of the submodule
before committing.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
I didn't get any reaction (negative or positive) to this patch.
The only difference with the previous version is that I know
check for the existence of the destination path before calling
module_clone.
skimo
Documentation/git-submodule.txt | 8 ++++
git-submodule.sh | 68 +++++++++++++++++++++++++++++++++++---
2 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index f8fb80f..bf9cbf9 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -8,11 +8,19 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
+'git-submodule' [--quiet] add <repository> [<path>]
'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
COMMANDS
--------
+add::
+ Add the given repository as a submodule at the given path
+ to the changeset to be committed next. In particular, the
+ repository is cloned at the specified path, added to the
+ changeset and registered in .gitmodules. If no path is
+ specified, the path is deduced from the repository specification.
+
status::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
diff --git a/git-submodule.sh b/git-submodule.sh
index 89a3885..3df7121 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1,13 +1,14 @@
#!/bin/sh
#
-# git-submodules.sh: init, update or list git submodules
+# git-submodules.sh: add, init, update or list git submodules
#
# Copyright (c) 2007 Lars Hjemli
-USAGE='[--quiet] [--cached] [status|init|update] [--] [<path>...]'
+USAGE='[--quiet] [--cached] [add <repo>|status|init|update] [--] [<path>...]'
. git-sh-setup
require_work_tree
+add=
init=
update=
status=
@@ -25,6 +26,17 @@ say()
fi
}
+get_repo_base() {
+ (
+ cd "`/bin/pwd`" &&
+ cd "$1" || cd "$1.git" &&
+ {
+ cd .git
+ pwd
+ }
+ ) 2>/dev/null
+}
+
#
# Map submodule path to submodule name
#
@@ -66,6 +78,44 @@ module_clone()
}
#
+# Add a new submodule to the working tree, .gitmodules and the index
+#
+# $@ = repo [path]
+#
+module_add()
+{
+ repo=$1
+ path=$2
+
+ # Turn the source into an absolute path if
+ # it is local
+ if base=$(get_repo_base "$repo"); then
+ repo="$base"
+ fi
+
+ # Guess path from repo if not specified or strip trailing slashes
+ if test -z "$path"; then
+ path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+ else
+ path=$(echo "$path" | sed -e 's|/*$||')
+ fi
+
+ test -e "$path" &&
+ die "'$path' already exists"
+
+ module_clone "$path" "$repo" || exit
+ (unset GIT_DIR && cd "$path" && git checkout -q) ||
+ die "Unable to checkout submodule '$path'"
+ git add "$path" ||
+ die "Failed to add submodule '$path'"
+
+ GIT_CONFIG=.gitmodules git config submodule."$path".path "$path" &&
+ GIT_CONFIG=.gitmodules git config submodule."$path".url "$repo" &&
+ git add .gitmodules ||
+ die "Failed to register submodule '$path'"
+}
+
+#
# Register submodules in .git/config
#
# $@ = requested paths (default to all)
@@ -173,6 +223,9 @@ modules_list()
while case "$#" in 0) break ;; esac
do
case "$1" in
+ add)
+ add=1
+ ;;
init)
init=1
;;
@@ -201,14 +254,17 @@ do
shift
done
-case "$init,$update,$status,$cached" in
-1,,,)
+case "$add,$init,$update,$status,$cached" in
+1,,,,)
+ module_add "$@"
+ ;;
+,1,,,)
modules_init "$@"
;;
-,1,,)
+,,1,,)
modules_update "$@"
;;
-,,*,*)
+,,,*,*)
modules_list "$@"
;;
*)
--
1.5.2.2.250.g1cd90-dirty
^ permalink raw reply related
* Re: Basename matching during rename/copy detection
From: Andy Parkins @ 2007-06-21 9:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vtzt1ybld.fsf@assigned-by-dhcp.pobox.com>
On Thursday 2007 June 21, Junio C Hamano wrote:
> It's not even an argument, nor an attempt to justify it. It was
> just an explanation of historical fact "It did not bother".
> Please re-read the final part of the message, which you omitted
> from your quote.
I omitted it because I didn't object to that part :-)
I appreciated (as always) your practicality in that what you proposed would
let people keep their copies. What I was objecting to was the idea that any
repository with duplicate files was "stupid".
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Junio C Hamano @ 2007-06-21 9:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <7vhcp1y954.fsf_-_@assigned-by-dhcp.pobox.com>
I am now getting sort of convinced that the list-features is a
slippery slop towards total suckage, unless managed very
carefully.
The "auto manage" patch I am responding to would tempt anybody
to extend the mechanism to do something like the attached patch,
because a one-line comment near the code, like:
/* FEATURE<oneline-first-paragraph> */
does not look very useful nor pretty by itself in the source
code. It makes it very tempting to actually describe the
"feature". People with only half a brain would even advocate
updating supported_features[] to a tuple of (name, explanation),
and have "git version --list-features" to spit both out, or
something like that. I really do not think we would want to go
there.
A few years down the road, do we really care if we did not do
something long time ago, but the code was updated and added as a
new feature? That information belongs to the commit log, not to
in-source comments. This will lead to the same mistake often
made by users of other SCMs, embedding "$Log$" in their sources.
=== sample diff that is not acceptable ===
diff --git a/commit.c b/commit.c
index dbb28b5..4b713b6 100644
--- a/commit.c
+++ b/commit.c
@@ -1016,6 +1016,12 @@ static void pp_header(enum cmit_fmt fmt,
}
}
+/*
+ * FEATURE<oneline-first-paragraph>: we used to treat the first line of the
+ * commit messages special, but messages imported from foreign culture often
+ * have more than one line in the first "paragraph". We now treat the
+ * first paragraph as special for the purposes of --pretty=oneline.
+ */
static void pp_title_line(enum cmit_fmt fmt,
const char **msg_p,
unsigned long *len_p,
@@ -1140,6 +1146,11 @@ static void pp_remainder(enum cmit_fmt fmt,
}
}
+/*
+ * FEATURE<log-unlimited-message>: we used to have a hard limit
+ * of 16kB message, but that is sometimes not enough for huge commits
+ * imported from foreign culture. We now dynamically grow the buffer.
+ */
unsigned long pretty_print_commit(enum cmit_fmt fmt,
const struct commit *commit,
unsigned long len,
^ permalink raw reply related
* [PATCH] Make list of features auto-managed.
From: Junio C Hamano @ 2007-06-21 9:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <7vr6o5zt76.fsf@assigned-by-dhcp.pobox.com>
This updates the build procedure so that a mark-up in the form
of:
SP "FEATURE<" feature-name ">" SP
is picked up from the sources, in order to help keeping
supported_features[] array automatically in sync.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> So, first of all, I would want the list of features in
> supported_features[] to come from a separate file, whose sole
> purpose is to have that list. I would even suggest making it an
> generated file, which depends on the source files (not
> necessarily limited to C files), and built from within the build
> procedure.
> ...
> Assuming if this --list-features is a viable approach in the
> long run, my gut feeling of relative order of things is:
>
> (1) We prepare rock-solid runtime with an _EMPTY_ feature array
> in 'master'.
>
> (2) We add automated feature array management in 'master', as
> outlined above.
>
> (3) Merge the above two to 'next'.
>
> (4) Update all existing topics, including the ones that are
> already in 'next', with the feature mark-up in comment
> (i.e. "FEATURE[[[feature-name]]]").
>
> After (3) happens, any new topics that introduce a new feature
> should be accompanied with the feature mark-up.
So here is a PoC for step (2). It loses more lines than it
adds, primarily because we can lose is_feature_name_sane(); it
is done at the build time now.
.gitignore | 1 +
Makefile | 12 +++++++++++-
builtin-blame.c | 1 +
generate-features.sh | 9 +++++++++
help.c | 48 +++++++++++++-----------------------------------
5 files changed, 35 insertions(+), 36 deletions(-)
create mode 100755 generate-features.sh
diff --git a/.gitignore b/.gitignore
index e8b060c..64ee08b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -169,3 +169,4 @@ config.status
config.mak.autogen
config.mak.append
configure
+features.h
diff --git a/Makefile b/Makefile
index c09dfaf..d8d1ddc 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,13 @@ BUILT_INS = \
git-fsck-objects$X git-cherry-pick$X \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
+# what are the source files
+SOURCE_FILES = $(sort \
+ $(SCRIPT_SH) $(SCRIPT_PERL) $(SCRIPT_PYTHON) \
+ $(patsubst git-%$X,%.c,$(PROGRAMS)) \
+ $(LIB_H) \
+ $(patsubst %.o,%.c,$(LIB_OBJS) $(BUILTIN_OBJS)))
+
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
@@ -755,7 +762,10 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(ALL_CFLAGS) -o $@ $(filter %.c,$^) git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.o: common-cmds.h
+features.h: $(SOURCE_FILES) generate-features.sh
+ $(QUIET_GEN)./generate-features.sh $(SOURCE_FILES) > $@+ && mv $@+ $@
+
+help.o: common-cmds.h features.h
git-merge-subtree$X: git-merge-recursive$X
$(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@
diff --git a/builtin-blame.c b/builtin-blame.c
index f7e2c13..c84d96a 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2162,6 +2162,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
else if (!strcmp("-s", arg))
output_option |= OUTPUT_NO_AUTHOR;
else if (!strcmp("-w", arg))
+ /* FEATURE<blame-ignore-whitespace> */
xdl_opts |= XDF_IGNORE_WHITESPACE;
else if (!strcmp("-S", arg) && ++i < argc)
revs_file = argv[i];
diff --git a/generate-features.sh b/generate-features.sh
new file mode 100755
index 0000000..674c5fe
--- /dev/null
+++ b/generate-features.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+#
+# New features that Porcelains may care about can be marked in the
+# source code with FEATURE<feature name>. This script is driven
+# by Makefile to pick them out and sort them to prepare features.h
+# file, which is included by help.c.
+
+sed -n -e 's|.* FEATURE<\([a-z0-9][-a-z0-9]*[a-z0-9]\)> .*/| "\1",|p' "$@" |
+sort -u
diff --git a/help.c b/help.c
index d050cbf..b0887ea 100644
--- a/help.c
+++ b/help.c
@@ -9,9 +9,10 @@
#include "common-cmds.h"
#include <sys/ioctl.h>
+/* FEATURE<list-features> */
+
static const char *supported_features[] = {
- "blame-ignore-whitespace",
- "list-features",
+#include "features.h"
};
/* most GUI terminals set COLUMNS (although some don't export it) */
@@ -195,51 +196,28 @@ void help_unknown_cmd(const char *cmd)
exit(1);
}
-static int is_feature_name_sane(const char *a)
+static void list_features(void)
{
- if (!*a || *a == '-')
- return 0;
- for (; *a; a++) {
- if (! ((*a >= 'a' && *a <= 'z')
- || (*a >= '0' && *a <= '9')
- || *a == '-'))
- return 0;
- }
- return 1;
+ unsigned cnt = ARRAY_SIZE(supported_features);
+ unsigned i;
+
+ for (i = 0; i < cnt; i++)
+ printf("%s\n", supported_features[i]);
}
static int cmp_feature(const void *a_, const void *b_)
{
const char *a = *((const char **)a_);
const char *b = *((const char **)b_);
- return strcmp(a, b);
-}
-static void list_features()
-{
- unsigned cnt = ARRAY_SIZE(supported_features);
- unsigned i;
-
- qsort(supported_features, cnt,
- sizeof(supported_features[0]), cmp_feature);
- for (i = 0; i < cnt; i++) {
- const char *f = supported_features[i];
- if (!is_feature_name_sane(f))
- die("feature name \"%s\" is bogus", f);
- printf("%s\n", f);
- }
+ return strcmp(a, b);
}
static int supports_feature(const char *the_feature)
{
- unsigned cnt = ARRAY_SIZE(supported_features);
- unsigned i;
-
- for (i = 0; i < cnt; i++) {
- if (!strcmp(supported_features[i], the_feature))
- return 0;
- }
- return 1;
+ return !bsearch(&the_feature, supported_features,
+ (size_t) ARRAY_SIZE(supported_features),
+ sizeof(const char *), cmp_feature);
}
static const char version_usage[] =
--
1.5.2.2.1050.g51a8b
^ 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