| Junio C Hamano | Re: [PATCH] git-fetch: Avoid reading packed refs over an ...
I think the name --filter-blah makes it unclear if it is a
filter that picks up items that match the criteria "blah" out of
its input, or if it filters out the ones that do not match the
criteria.
In either case, you are not filtering "invalid vs valid" but
"existing vs missing".
If you are making a git-fetch specific extension, it would make
sense to include what the upstream sed does as well. That is,
the user would become:
echo "$ls_remote_result" |
- sed -n -e ...
| Dec 17, 6:54 pm 2006 |
| Jakub Narebski |
| Dec 17, 1:54 pm 2006 |
| Johannes Schindelin | [PATCH] git-fetch: Avoid reading packed refs over and ov ...
When checking which tags to fetch, the old code used to call
git-show-ref --verify for _each_ remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out valid
(i.e. locally stored) refs from stdin, when passing the parameter
--filter-invalid to git-show-ref, and feeding it lines in the
form 'sha1 refname'.
Signed-off-by: Johannes Schindelin ...
| Dec 17, 12:52 pm 2006 |
| Jim Meyering | [PATCH] git-diff: don't add trailing blanks (i.e., do wh ...
You may recall that GNU diff -u changed recently so that it no
longer outputs any trailing space unless the input data has it.
This means that blank context lines are now blank also in diff -u output.
Before, they would have a single trailing space.
Then, git was changed to allow that new diff output format.
Now that git-diff generates output using its internal diff, its
output is no longer identical to what you get when using GNU diff.
This patch makes the output of git-diff the same as GNU ...
| Dec 17, 12:32 pm 2006 |
| Junio C Hamano |
| Dec 17, 1:09 pm 2006 |
| Jim Meyering |
| Dec 17, 1:36 pm 2006 |
| Linus Torvalds |
| Dec 17, 1:00 pm 2006 |
| Vincent Legoll | git-diff & cg-diff behavior difference
I did not find something relevant in the docs, so I'll ask here.
git-diff works from everywhere in the tree, whereas cg-diff
does not, is that intentional ?
steps to reproduce:
--------------------
mkdir tmp
cd tmp
touch titi.txt
mkdir tutu
touch tutu/toto.txt
cg-init -I
cg-add -r .
cg-commit -C -m INIT
echo "tata" > titi.txt
git-diff
cg-diff
cd tutu
git-diff
cg-diff
--------------------
The 2 git-diff & 1st cg-diff outputs are the same, whereas the 2nd
cg-diff one is ...
| Dec 17, 10:11 am 2006 |
| Quy Tonthat | [PATCH] Documentation: new option -P for git-svnimport
Documentation: new option -P for git-svnimport.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
Documentation/git-svnimport.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index b1b87c2..df604e1 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] ...
| Dec 17, 7:50 am 2006 |
| Johannes Schindelin | [PATCH] Adjust t5510 to put remotes in config
Since .git/remotes/ is no longer created by default, t5510 failed.
While at it, convert the tests to use the config way of specifying
remotes instead of creating a file in .git/remotes/.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t5510-fetch.sh | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index a11ab0a..6229433 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -23,20 +23,16 @@ ...
| Dec 17, 7:46 am 2006 |
| Jakub Narebski | Re: Subprojects tasks
In the absence of sparse/partial checkout, and it's use in submodule
support, this can be solvd purely on porcelain level.
You would have to simply maintain separate 'includes' branch, similarly
to how 'html' and 'man' (and 'todo') branches are maintained in git.git
repository -- it would be your 'set of commit objects'. Then the only
think that would be needed is some commit / post-commit hook which would
examine if commit touches "include" files and if it does, make a commit
in the ...
| Dec 17, 3:01 am 2006 |
| Shawn O. Pearce | [PATCH] Default GIT_COMMITTER_NAME to login name in reci ...
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to ...
| Dec 17, 1:15 am 2006 |
| Johannes Schindelin | [PATCH] Documentation/git-merge-file.txt: make asciidoc ...
Noticed by Randal L. Schwartz, this is a fix proposed by
A Large Angry SCM.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Sat, 16 Dec 2006, A Large Angry SCM wrote:
> Randal L. Schwartz wrote:
> > asciidoc -b xhtml11 -d manpage -f asciidoc.conf git-merge-file.txt
> > ERROR: manpage document title is mandatory
> > ERROR: git-merge-file.txt: line 3: title not permitted in sidebar body
> > [...]
> > make[1]: *** [git-merge-file.html] Error 1
> > make: *** ...
| Dec 17, 7:48 am 2006 |
| Randal L. Schwartz | Re: [BUG] making docs blows up in b1bfcae438ad:git-merge ...
>>>>> "The" == The Answering Machine <merlyn.'s-answering.machine@stonehenge.com> writes:
The> I've received your mail.
The> Your message has been queued, and will probably be read within 48 hours.
Naughty SCM sent email addressed to me personally, but added a reply-to
of the list.
My answering machine behaved perfectly in this case, but SCM triggered it
badly. :(
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> ...
| Dec 17, 11:20 am 2006 |
| Josef Weidendorfer | Re: What's cooking in git.git (topics)
Isn't it enough to specify further subdirectories of .git/, holding
references which should be taken into account while pruning?
Hmm.. Grafting would be a special case.
Josef
-
| Dec 17, 4:38 pm 2006 |
| Yann Dirson | Re: What's cooking in git.git (topics)
I think that is quite near to other issues: we already have other pieces
of information that we would like to sometimes have ignored and
sometimes not, when running fsck-objects/prune. Namely, revisions
hidden by grafts, as already discussed on this list.
An idea I had to handle that case, and which could be useful with the
current problem, as well as others, like dealing with stgit's patch
logging, would be to define "reachable commits" using a modular
architecture. That way we would be ...
| Dec 17, 10:35 am 2006 |
| Andy Parkins |
| Dec 17, 4:41 pm 2006 |
| Junio C Hamano |
| Dec 17, 12:38 pm 2006 |
| Linus Torvalds | Re: [PATCH] revision: introduce ref@{N..M} syntax.
Well, logically, if you do that, then you should also allow
git log master@{one.week.ago..yesterday}
as a reflog expression.
"Because It Only Makes Sense(tm)".
Linus
PS. Yeah, I'm only half serious. I like our revision parsing, and the
above _would_ actually be consistent with the "master@{1..3}" kind of
specification, but at the same time, it's also obviously more complex, and
maybe it's not THAT usable.
But I think the "master@{date..date}" syntax would actually fall ...
| Dec 17, 11:14 am 2006 |
| Junio C Hamano | [PATCH] revision: introduce ref@{N..M} syntax.
I happen to find it a reasonable way to present how a topic was
rewind and rebuilt, but I think that is I rewind my internal
topic (i.e. the parts that have not been merged into 'next' yet)
This is not a 'git reflog' command, but is another way to show
the tips of reflog entries (use it with 'git show'). I find the
show-branch variant easier to see, but you can judge for
yourself.
This happens to show why pruning while not culling reflog
entries is a bad idea. If your master@{2} is gone ...
| Dec 16, 11:46 pm 2006 |
| Josef Weidendorfer | Re: Subprojects tasks
I see that you always use "refs/heads/master" in the submodule.
What happens if you do development in the submodule, create a new commit
there, and want to switch supermodule branch afterwards?
Wouldn't you lose your new work, as "refs/heads/master" has to be reset
to another commit when you switch the supermodule branch?
IMHO it would be nice to have refs in the submodule matching all the
branches/tags of the supermodule.
Meaning: "this is the commit which is used by branch/tag XYZ in ...
| Dec 17, 4:23 pm 2006 |
| Martin Waitz | Re: Subprojects tasks
hoi :)
I can see the reason for wanting to use another object database,
but HEAD and index should always be stored together with the
checked out directory. So perhaps we just need some smart way to
search for the object database, but keep the .git directory.
--=20
Martin Waitz
| Dec 17, 4:45 am 2006 |
| Martin Waitz | Re: Subprojects tasks
hoi :)
What about .git/link or something?
The version tracked by the supermodule is completely independent from
any branches you define in your submodule.
It is of course possible to use different versions of your submodule in
different branches of your supermodule. But the supermodule does not
know the name of these branches.
In the setup you described a git-checkout in the supermodule would have
to switch to a different branch in the submodule, depending on the
branchname which would ...
| Dec 17, 6:48 am 2006 |
| Jakub Narebski | Re: Subprojects tasks
Well, the .gitlink proposal at it is now (by Josef) serves both as a way
to implement lightweight checkout (i.e. having additional working dir to
some repository, or having working dir separate from bare repository),
and as a way to have "smart" submodules (which you can move and rename)
in submodules/subproject support.
Besides, I'd rather either use config file for this (core.link or
O.K. Now I understand why you prefer specified branch to HEAD.
I have forgot that checkout must update ...
| Dec 17, 7:29 am 2006 |
| Jakub Narebski | Re: Subprojects tasks
Well, in the .gitlink proposal you could specify GIT_DIR for checkout,
or separately: GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE, GIT_REFS_DIRECTORY
(does not exist yet), GIT_HEAD_FILE (does not exist yet, and I suppose
it wouldn't be easy to implement it). By the way, that's why I'm for
.gitlink name for the file, not .git -- this way .gitlink can "shadow"
what's in .git, for example specifying in a smart way where to search
(where to find) object database, but HEAD and index would be ...
| Dec 17, 6:01 am 2006 |
| Josef Weidendorfer | Re: Subprojects tasks
Ah.
What is "<submodule>" in your implementation?
Is this some encoding of the path where the submodule currently lives
in the supermodule, or are you giving the submodules unique names
in the context of the supermodule?
Josef
-
| Dec 17, 4:27 pm 2006 |
| Martin Waitz | Re: Subprojects tasks
hoi :)
At the moment I simply use refs/heads/master of the submodule
repository, just because it is the default branch anyway.
In order to make the submodule refs which are not added to the
supermodule available to the supermodule anyway (for fsck and prune),
I added a symlink .git/refs/module/<submodule> -> <submodule>/.git/refs,
so that the submodule branch is also available as
refs/module/<submodule>/heads/master in the supermodule.
But I expect that all this setup stuff can be ...
| Dec 17, 12:54 pm 2006 |
| Alan Chandler | Re: Subprojects tasks
I have been following the submodules (subprojects - is there any
difference?) discussion from afar, getting lost quite frequently in
what is actually being discussed and why. I don't think the idea I
express below has been mentioned, but apologies if it has.
One element I felt has been missing is a vigorous discussion of what
submodules are for and what are their use cases. The "submodule is on
its own" issue seems to have crept into the discussion - but there was
one use case that ...
| Dec 17, 1:48 am 2006 |
| Martin Waitz | Re: Subprojects tasks
hoi :)
Most of the things you described are already implemented in
http://git.admingilde.org/tali/git.git/module2
If there is interest in it, I can generate some nice patches out of it.
However with Linus concerns about scalability I'm not sure it is ready
In contrast to your description, my implementation does not
introduce a new "link" type but instead adds the reference to the
submodule commit directly to the parent tree object and to its
yes, this is essential.
There may be links ...
| Dec 17, 4:17 am 2006 |
| Junio C Hamano | [PATCH] git-add: remove conflicting entry when adding.
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'git add' did not succeed because
it forgot to pass the allow-replace flag to add_cache_entry().
It might be safer to leave this as an error and require the user
to explicitly remove the existing A first before adding A/B
since it is an unusual case, but doing that automatically is
much easier to use.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
read-cache.c | 2 +-
1 files changed, 1 ...
| Dec 17, 2:11 am 2006 |
| Andy Parkins | Re: [RFC/PATCH] Change "refs/" references to symbolic co ...
I'd not even considered that; I liked it because of a natural disinclination
While true - is there ever such a time? :-)
On the other hand, this is (hopefully) a zero-impact change, and should leave
If I know it's wanted I will happily maintain it indefinitely. It's part of
my rebase on master set anyway, so it's no pain to do so. I'll keep an eye
out for quiet times, or if you prod me when you want it I'll make you a
rebased version instantly.
While we're on this subject, ...
| Dec 17, 2:00 am 2006 |
| Stefano Spinucci | Re: Can git be tweaked to work cross-platform, on FAT32?
I recompiled git with NO_MMAP and used it successfully, then I added a
note in the wiki
page http://git.or.cz/gitwiki/WindowsInstall on how to compile git to
work on a FAT32
filesystem.
Now, two questions...
if you are sure that there are more problems with using MMAP, shouldn't NO_MMAP
be commented better in the Makefile and in INSTALL, pointing out to
use it always on
cygwin ???
finally on cygwin there is a precompiled git package (v 1.4.4.1);
however, I found if it was
compiled ...
| Dec 17, 6:36 pm 2006 |
| Johannes Schindelin |
| Dec 17, 7:54 am 2006 |
| Martin Langhoff |
| Dec 17, 3:21 am 2006 |
| Juergen Ruehle | Re: Can git be tweaked to work cross-platform, on FAT32?
Stefano Spinucci writes:
> I just tried to use git writing to my FAT32 formatted usb stick.
>
> On windows XP, I compiled git with and without NO_D_TYPE_IN_DIRENT,
> but after the
> following actions I always got the error "fatal: Unable to write new
> index file" or
> "fatal: unable to create '.git/index': File exists":
Compile git with NO_MMAP. The problem is that the old index file is
mmaped while it is replaced. Cygwin supports this operation only on
NTFS. I don't know whether ...
| Dec 17, 11:16 am 2006 |
| Stefano Spinucci | Re: Can git be tweaked to work cross-platform, on FAT32?
I just tried to use git writing to my FAT32 formatted usb stick.
On windows XP, I compiled git with and without NO_D_TYPE_IN_DIRENT,
but after the
following actions I always got the error "fatal: Unable to write new
index file" or
"fatal: unable to create '.git/index': File exists":
mkdir git-test-repo
cd git-test-repo
git-init-db
echo iii>test
git add test
git commit -m "test msg"
echo ooo>test1
git add test1 ***error***
converting the stick to NTFS I have no problems.
any hint ...
| Dec 17, 7:33 am 2006 |
| Johannes Schindelin | Re: Can git be tweaked to work cross-platform, on FAT32?
Hi,
I encountered a problem with git-log, where the fork() tried to
reestablish a mmap()ed file, which unfortunately was renamed (since it was
a .lock file[*1*]). This triggered the implementation of NO_MMAP.
I am sure that there are more problems with it. BTW the problem stems from
Windows having _no_ equivalent to fork().
Notefoot 1: Isn't it funny that Windows cannot delete files which are
still opened, but does not care when it is renamed?
Ciao,
Dscho
-
| Dec 17, 12:33 pm 2006 |
| Yann Dirson | Re: Collection of stgit issues and wishes
At least we could shoot them when stdout is not a tty ?
Not sure there is a good way of detecting if we're being run directly
Sure, I'd hate having to type "stg sta" :)
Best regards,
--
Yann.
-
| Dec 17, 4:21 pm 2006 |
| Yann Dirson | Re: Collection of stgit issues and wishes
If you're only looking for bugtracking, I wonder whether
bugzilla.kernel.org could be used (as well as for core git and other
git-related tools). Or maybe a new git-specialized bugzilla could be
setup somewhere ?
BTW, and a bit off-topic, one thing that would be great to have would be
git-bugzilla coupling (mainly, recording into bugzilla when a commit
addressing an issue gets pushed to an official tree).
Scmbug already provides a framework for such couplings, and already has
I tend do ...
| Dec 17, 4:15 pm 2006 |
| Sven Verdoolaege |
| Dec 17, 4:32 am 2006 |
