* Re: What's cooking in git.git (topics)
From: David Kågedal @ 2007-10-02 8:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkamm16s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * not to do the autostash, but fail as we have always done,
> when "git rebase base other" form was used, first instructing
> rebase to switch to another branch;
I don't like the idea of automatic stashing on a rebase. It makes it
harder to understand what is happening, and figuring out were things
went if everything wasn't successful.
--
David Kågedal
^ permalink raw reply
* mirror pushing
From: Junio C Hamano @ 2007-10-02 7:55 UTC (permalink / raw)
To: git
Existing "git push --all" is almost perfect for backing up to
another repository, except that "--all" only means "all
branches" in modern git, and it does not delete old branches and
tags that exist at the back-up repository that you have removed
from your local repository.
This teaches "git-send-pack" a new "--mirror" option. The
difference from the "--all" option are that (1) it sends all
refs, not just branches, and (2) it deletes old refs you no
longer have on the local side from the remote side.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This even applies to "maint", but it probably should be done
on top of Daniel's remote.c changes. Teaching this to "git
push" wrapper is left as an exercise to the reader.
remote.c | 15 ++++++++++-----
send-pack.c | 35 ++++++++++++++++++++++++-----------
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/remote.c b/remote.c
index bb774d0..a3aa5ad 100644
--- a/remote.c
+++ b/remote.c
@@ -574,10 +574,12 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
* without thinking.
*/
int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
- int nr_refspec, char **refspec, int all)
+ int nr_refspec, char **refspec, int flags)
{
struct refspec *rs =
parse_ref_spec(nr_refspec, (const char **) refspec);
+ int send_all = flags & 01;
+ int send_mirror = flags & 02;
if (match_explicit_refs(src, dst, dst_tail, rs, nr_refspec))
return -1;
@@ -594,7 +596,7 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (!pat)
continue;
}
- else if (prefixcmp(src->name, "refs/heads/"))
+ else if (!send_mirror && prefixcmp(src->name, "refs/heads/"))
/*
* "matching refs"; traditionally we pushed everything
* including refs outside refs/heads/ hierarchy, but
@@ -615,10 +617,13 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (dst_peer && dst_peer->peer_ref)
/* We're already sending something to this ref. */
goto free_name;
- if (!dst_peer && !nr_refspec && !all)
- /* Remote doesn't have it, and we have no
+
+ if (!dst_peer && !nr_refspec && !(send_all || send_mirror))
+ /*
+ * Remote doesn't have it, and we have no
* explicit pattern, and we don't have
- * --all. */
+ * --all nor --mirror.
+ */
goto free_name;
if (!dst_peer) {
/* Create a new one and link it */
diff --git a/send-pack.c b/send-pack.c
index 9fc8a81..39b4b17 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -7,11 +7,12 @@
#include "remote.h"
static const char send_pack_usage[] =
-"git-send-pack [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
+"git-send-pack [--all | --mirror] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
" --all and explicit <ref> specification are mutually exclusive.";
static const char *receivepack = "git-receive-pack";
static int verbose;
static int send_all;
+static int send_mirror;
static int force_update;
static int use_thin_pack;
@@ -200,7 +201,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
if (!remote_tail)
remote_tail = &remote_refs;
if (match_refs(local_refs, remote_refs, &remote_tail,
- nr_refspec, refspec, send_all))
+ nr_refspec, refspec, (send_all | (send_mirror << 1))))
return -1;
if (!remote_refs) {
@@ -215,19 +216,24 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
for (ref = remote_refs; ref; ref = ref->next) {
char old_hex[60], *new_hex;
int will_delete_ref;
+ const unsigned char *new_sha1;
- if (!ref->peer_ref)
- continue;
-
+ if (!ref->peer_ref) {
+ if (!send_mirror)
+ continue;
+ new_sha1 = null_sha1;
+ }
+ else
+ new_sha1 = ref->peer_ref->new_sha1;
- will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
+ will_delete_ref = is_null_sha1(new_sha1);
if (will_delete_ref && !allow_deleting_refs) {
error("remote does not support deleting refs");
ret = -2;
continue;
}
if (!will_delete_ref &&
- !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
+ !hashcmp(ref->old_sha1, new_sha1)) {
if (verbose)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
@@ -257,8 +263,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
!is_null_sha1(ref->old_sha1) &&
!ref->force) {
if (!has_sha1_file(ref->old_sha1) ||
- !ref_newer(ref->peer_ref->new_sha1,
- ref->old_sha1)) {
+ !ref_newer(new_sha1, ref->old_sha1)) {
/* We do not have the remote ref, or
* we know that the remote ref is not
* an ancestor of what we are trying to
@@ -276,7 +281,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
continue;
}
}
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
+ hashcpy(ref->new_sha1, new_sha1);
if (!will_delete_ref)
new_refs++;
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
@@ -396,6 +401,10 @@ int main(int argc, char **argv)
send_all = 1;
continue;
}
+ if (!strcmp(arg, "--mirror")) {
+ send_mirror = 1;
+ continue;
+ }
if (!strcmp(arg, "--force")) {
force_update = 1;
continue;
@@ -420,7 +429,11 @@ int main(int argc, char **argv)
}
if (!dest)
usage(send_pack_usage);
- if (heads && send_all)
+ /*
+ * --all and --mirror are incompatible; neither makes sense
+ * with any refspecs.
+ */
+ if ((heads && (send_all || send_mirror)) || (send_all && send_mirror))
usage(send_pack_usage);
verify_remote_names(nr_heads, heads);
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-02 7:21 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Matthieu Moy
In-Reply-To: <vpq641qroae.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> I'm also concerned about the possibility of stash/unstash to fail:
> that means the user has to deal with two kinds of conflicts (rebase
> can conflict, unstash can also), which can be confusing.
Unstash should be invoked automatically _only_ after rebase
completes, so I do not forsee such confusion.
But the trouble I have with the auto unstashing is more at the
conceptual and workflow level. You start rebasing a branch, and
your work tree is dirty. What branch should the local
modification belong to?
Logically, it is with the branch you were on when you typed "git
rebase" command.
But when "rebase" successfully concludes (either with or without
manual fix-ups), you can be either on your original branch (if
you said "git rebase base") or something totally unrelated (if
you said "git rebase base other"). Currently we auto-unstash in
both cases. I _think_ the former case should auto-unstash, but
the latter shouldn't.
However, this auto-stash uses the new "git stash create" command
that does not update the reflog for "refs/stash", specifically
so that the auto-stashing does _not_ interfere with the normal
stash the end user uses. Which means that it is a bit
cumbersome to give the autostashed state back to the user if we
do _not_ unstash upon completion of rebase.
Perhaps a good compromise would be to
* not to do the autostash, but fail as we have always done,
when "git rebase base other" form was used, first instructing
rebase to switch to another branch;
* autostash when "git rebase base" form was used, and auto
unstash upon completion.
> But the current behavior can be greatly improved by just making the
> error message better. Currently, I have this:
>
> $ git rebase branch
> foo.txt: needs update
> $ _
>
> I'd prefer something like
>
> $ git rebase branch
> cannot rebase: the working tree is not clean.
> foo.txt: Changed but not updated
> Commit your changes, or put them appart with "git stash" and retry.
> $ _
You forgot 'needs merge' case, so that would not fly very well,
but something like this might be a good starting point.
---
git-rebase.sh | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 058fcac..4f8aeb9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -252,7 +252,10 @@ else
fi
# The tree must be really really clean.
-git update-index --refresh || exit
+o=$(git update-index -q --refresh) || {
+ printf "cannot rebase: the work tree is not clean.\n%s\n" "$o"
+ exit 1
+}
diff=$(git diff-index --cached --name-status -r HEAD)
case "$diff" in
?*) echo "cannot rebase: your index is not up-to-date"
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Matthieu Moy @ 2007-10-02 7:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <49137EAF-BB73-40DC-973C-E60C14B3FA7F@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:
>
>>
>> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>> + rebase: allow starting from a dirty tree.
>> + stash: implement "stash create"
>>
>> Instead of refusing to rebase, telling you that your work tree
>> is dirty, this stashes your local changes, runs rebase and then
>> unstashes automatically. That _sounds_ nicer and easier to use,
>> but I am not sure if it is a wise/sane thing to do. We may want
>> to revert the "autostash" from rebase. Opinions?
>
> What would happen if 'git stash' fails to work? Could this bring
> the repo in a state that is hard to recover from? Especially if
> 'stash' commands were run automatically for you. Maybe if you had
> a choice you would not choose to use stash but would commit your
> changes, or would bring your work tree in a clean state by other means.
I'm also concerned about the possibility of stash/unstash to fail:
that means the user has to deal with two kinds of conflicts (rebase
can conflict, unstash can also), which can be confusing.
But the current behavior can be greatly improved by just making the
error message better. Currently, I have this:
$ git rebase branch
foo.txt: needs update
$ _
I'd prefer something like
$ git rebase branch
cannot rebase: the working tree is not clean.
foo.txt: Changed but not updated
Commit your changes, or put them appart with "git stash" and retry.
$ _
--
Matthieu
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steffen Prohaska @ 2007-10-02 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3awunjup.fsf@gitster.siamese.dyndns.org>
On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:
>
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Instead of refusing to rebase, telling you that your work tree
> is dirty, this stashes your local changes, runs rebase and then
> unstashes automatically. That _sounds_ nicer and easier to use,
> but I am not sure if it is a wise/sane thing to do. We may want
> to revert the "autostash" from rebase. Opinions?
What would happen if 'git stash' fails to work? Could this bring
the repo in a state that is hard to recover from? Especially if
'stash' commands were run automatically for you. Maybe if you had
a choice you would not choose to use stash but would commit your
changes, or would bring your work tree in a clean state by other means.
I'm a bit concerned because 'git stash' still doesn't work for me
when the work tree is dirty because of a changed subproject (in
msysgit with git 1.5.3). After I run 'git stash' the work tree stays
dirty. How would "autostash" behave?
BTW, I run 'git submodule update' to bring the tree into a clean
state and later manually check out the previous head in the submodule.
Quite annoying, but not directly related to the discussion above.
Steffen
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steven Grimm @ 2007-10-02 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3awunjup.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Instead of refusing to rebase, telling you that your work tree
> is dirty, this stashes your local changes, runs rebase and then
> unstashes automatically. That _sounds_ nicer and easier to use,
> but I am not sure if it is a wise/sane thing to do. We may want
> to revert the "autostash" from rebase. Opinions?
>
I can say that for people coming from svn (who are often using "git svn
rebase" rather than directly running "git rebase") this is a nice
workflow improvement. It eliminates one more "Why is this more of a pain
to do in git than in svn?" complaint.
I don't see any circumstance in my use of git -- either in a git-svn
context or not -- where this wouldn't be an improvement over the
existing behavior. However, I don't claim to be using git in any
particularly interesting way, so I suppose it's possible that this will
break someone's workflow horribly.
-Steve
^ permalink raw reply
* Re: [PATCH] fixed link in documentation of diff-options
From: Junio C Hamano @ 2007-10-02 6:27 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11913056772885-git-send-email-prohaska@zib.de>
Sharp eyes; thanks.
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Junio C Hamano @ 2007-10-02 6:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Reece Dunn, Git
In-Reply-To: <4701E10C.7050405@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> FWIW, I'm thinking about changing the cpio -p (passthrough) part to use
> 'cp -l --parents --target-directory=...' instead of tar; this gives us
> hard links, even on NTFS. But it needs GNU's cp, of course.
Yeah, that's the reason it is not appropriate than cpio, even if
we forget about Windows.
^ permalink raw reply
* [PATCH] fixed link in documentation of diff-options
From: Steffen Prohaska @ 2007-10-02 6:14 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/diff-options.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 228ccaf..b1f528a 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -179,8 +179,8 @@
--ext-diff::
Allow an external diff helper to be executed. If you set an
- external diff driver with gitlink:gitattributes(5), you need
- to use this option with gitlink:git-log(1) and friends.
+ external diff driver with gitlink:gitattributes[5], you need
+ to use this option with gitlink:git-log[1] and friends.
--no-ext-diff::
Disallow external diff drivers.
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* Re: git clone questions relating to cpio
From: Johannes Sixt @ 2007-10-02 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Reece Dunn, Git
In-Reply-To: <7vwsu6pg0v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 1 Oct 2007, Reece Dunn wrote:
>>
>>> I am running a Linux From Scratch 6.2 system that does not have cpio
>>> installed on it. This means that I can't clone a local repository
>>> unless I install cpio.
>> You might be interested in the workaround Hannes did in mingw.git; he made
>> a wrapper script called 'cpio' using 'tar'.
>
> I think that may be good enough as workaround, but I do not
> think you would get the space saving from hardlinks that way.
FWIW, I'm thinking about changing the cpio -p (passthrough) part to use
'cp -l --parents --target-directory=...' instead of tar; this gives us hard
links, even on NTFS. But it needs GNU's cp, of course.
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-10-02 6:10 UTC (permalink / raw)
To: git
In-Reply-To: <20071002051332.GA4462@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Oct 02, 2007 at 01:08:20AM -0400, Jeff King wrote:
>
>> One approach which I haven't tried but might be promising is to actually
>> keep each list sorted, and then do a "merge" of the two lists, comparing
>> as you go. We don't really need to do arbitrary lookups in the hash; we
>> just need to compare two hash tables at a time. My approach was to be
>> simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
>> order of 2^17), and that's clearly just too big. But with a list merge,
>> it should be O(n), where n is the actual number of lines in the files
>> (or binary chunks for the binary case).
>
> BTW, I don't want to steal credit for this idea...it comes from thinking
> about what David Kastrup said earlier in the thread, though I think he
> was proposing sorting just inside buckets.
Yes: my proposal was about a microoptimization: work with the
basically existing data structures and put the already contained
information to best use.
I have not actually looked at the actual task that the structures are
going to be used in, and whether "reusing" the information is likely
to be worth the trouble.
When we are talking about buzzword compliance, "keep sorted" with the
meaning of "maintain sorted across modifications" has an O(n^2) or at
least O(nm) ring to it. However, if it is possible to sort it just
once, and then then only merge with other lists...
I am actually quite a fan of merge sort and have even posted a small
and quite efficient version to this list once. However, merge sorts
were really greatest at the time when cache memory was unusual to
have. Nowadays, quicksort or similar could be faster due to better
locality of memory accesses. I think the glibc qsort more or less
uses an array-based merge into a separate memory area (unless it runs
out of memory in which case it resorts to regular quicksort).
--
David Kastrup
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-02 5:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vfy11yyxk.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
----------------------------------------------------------------
* ph/strbuf (Thu Sep 27 13:33:19 2007 +0200) 44 commits
+ Make read_patch_file work on a strbuf.
+ strbuf_read_file enhancement, and use it.
+ strbuf change: be sure ->buf is never ever NULL.
+ double free in builtin-update-index.c
+ Clean up stripspace a bit, use strbuf even more.
+ Add strbuf_read_file().
...
Will be in 'master' soon. We've seen nice linecount reduction
and the end result is rather pleasant to read.
* jc/am-quiet (Mon Oct 1 00:27:51 2007 -0700) 2 commits
+ git-am: fix typo in the previous one.
+ git-am: make the output quieter.
Response against recent "rebase being too chatty" complaints.
This should be a 'master' material.
* ap/dateformat (Fri Sep 28 15:17:45 2007 +0100) 3 commits
+ Make for-each-ref's grab_date() support per-atom formatting
+ Make for-each-ref allow atom names like "<name>:<something>"
+ parse_date_format(): convert a format name to an enum date_mode
With some test suite additions, this could go to 'master' soon.
Yes, that's a HINT, people ;-).
* je/hooks (Wed Sep 26 15:31:01 2007 -0600) 1 commit
+ post-checkout hook, tests, and docs
Will be in 'master' soon.
* db/fetch-pack (Mon Oct 1 00:59:39 2007 +0100) 49 commits
+ fetch/push: readd rsync support
+ Introduce remove_dir_recursively()
+ bundle transport: fix an alloc_ref() call
+ Allow abbreviations in the first refspec to be merged
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
...
Has been cooking for quite long time.
There was a regression that made me quite unhappy about the
rewrite, but Daniel fixed it, so I should be happy. There is
another usability regression: http transport is now totally
silent. Even when you fetch daily, if the other end frequently
repacks everything into one big ball of wax like repo.or.cz
does, you will end up transferring quite a large pack every
time, and the total lack of progress report is unacceptably
unnerving. At least we should reinstate "Fetching blah from URL
using http", and preferrably "walk $object_name" lines. The
latter could be replaced with just series of CR + "walked N
commits..." if we do not like many output from the current "walk
$object_name" lines scrolling the other information away.
I am not sure the quality of "rsync" transport near the tip,
either, but at least the change should not affect other
transports. Nobody should using about rsync transport these
days anyway. Perhaps we should put a deprecation notice in the
release notes to 1.5.4, and remove it three months later.
* jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
+ git-gc --auto: run "repack -A -d -l" as necessary.
+ git-gc --auto: restructure the way "repack" command line is built.
+ git-gc --auto: protect ourselves from accumulated cruft
+ git-gc --auto: add documentation.
+ git-gc --auto: move threshold check to need_to_gc() function.
+ repack -A -d: use --keep-unreachable when repacking
+ pack-objects --keep-unreachable
+ Export matches_pack_name() and fix its return value
+ Invoke "git gc --auto" from commit, merge, am and rebase.
+ Implement git gc --auto
I think this one is reasonably sane, but I was the one who wrote
it so people should take that with a grain of salt. What it is
and isn't:
- "gc --auto" is a way to prevent you from keeping your
repository _grossly_ inefficient. Ideally, if you ever
rapacked your repository once, and do the regular repository
maintenance ("'git gc' before you leave for lunch every other
day"), it should never trigger.
- "gc --auto" is not something you can background. We do not
want to lock the repository and worry about associated stale
lock, expiry etc. The complexity is not worth it, compared
to the stated purpose above (I suspect it might already be
safe to run multiple instances at the same time, but the
effort to analyze if it is is not even worth, compared to the
stated purpose above. Just let it run synchronously if it
triggers, but it should not trigger for you).
* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commits
+ rebase -i: work on a detached HEAD
Will be in 'master', together with "gc --auto", soon.
* mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
+ Don't use "<unknown>" for placeholders and suppress printing of
empty user formats.
Will be in 'master' soon.
* lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
+ git-merge: add --ff and --no-ff options
+ git-merge: add support for --commit and --no-squash
+ git-merge: add support for branch.<name>.mergeoptions
+ git-merge: refactor option parsing
+ git-merge: fix faulty SQUASH_MSG
+ Add test-script for git-merge porcelain
Will be in 'master' soon.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
Instead of refusing to rebase, telling you that your work tree
is dirty, this stashes your local changes, runs rebase and then
unstashes automatically. That _sounds_ nicer and easier to use,
but I am not sure if it is a wise/sane thing to do. We may want
to revert the "autostash" from rebase. Opinions?
* kh/commit (Mon Sep 17 20:06:47 2007 -0400)
+ Export rerere() and launch_editor().
+ Introduce entry point add_interactive and add_files_to_cache
+ Clean up stripspace a bit, use strbuf even more.
+ Add strbuf_read_file().
+ rerere: Fix use of an empty strbuf.buf
+ Small cache_tree_write refactor.
...
Stalled.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
Stalled. This is about my pet-peeve that log (diff-tree) family
has much limited pathspec semantics. It should learn to glob
like ls-files and grep do.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-10-02 5:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vhclhyyxw.fsf@gitster.siamese.dyndns.org>
There are a few usability fixes to 'maint' after 1.5.3.3 but
nothing worth doing 1.5.3.4 for yet.
On the 'master' front, handful topics that have been cooking in
'next' have been merged, to be part of 1.5.4. Notable are:
* "git-remote rm"
* "git-send-email --smtp-server-port"
* "git-svn" futureproofing.
There are many changes cooking in 'next' that will graduate to
'master' real soon now. It would probably be a good idea to
slow down and cut 1.5.4 early without aiming to have anything
with huge user visible changes once that happens, because there
are two rather big topics mostly about the implementation and
not about user experience (other than performance gain of fetch
in a repository with insane number of refs).
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.3.3
Andy Parkins (1):
post-receive-hook: Remove the From field from the generated email
header so that the pusher's name is used
Jari Aalto (1):
git-remote: exit with non-zero status after detecting errors.
Jean-Luc Herren (2):
git-add--interactive: Allow Ctrl-D to exit
git-add--interactive: Improve behavior on bogus input
Johannes Schindelin (1):
rebase -i: squash should retain the authorship of the _first_
commit
Junio C Hamano (1):
Whip post 1.5.3.3 maintenance series into shape.
Miklos Vajna (1):
git stash: document apply's --index switch
* The 'master' branch has these since the last announcement
in addition to the above.
Alexandre Julliard (4):
git.el: Preserve file marks when doing a full refresh.
git.el: Do not print a status message on every git command.
git.el: Update a file status in the git buffer upon save.
git.el: Reset the permission flags when changing a file state.
Daniel Barkalow (1):
Fix adding a submodule with a remote url
James Bowes (2):
remote: add 'rm' subcommand
remote: document the 'rm' subcommand
Jari Aalto (1):
git-remote: exit with non-zero status after detecting error in
"rm".
Jeff King (1):
diffcore-rename: cache file deltas
Johannes Schindelin (1):
rebase -i: support single-letter abbreviations for the actions
Junio C Hamano (3):
git-remote rm: add tests and minor fix-ups
send-email --smtp-server-port: allow overriding the default port
Update stale documentation link in the k.org site
Mark Levedahl (1):
git-submodule - allow a relative path as the subproject url
Sam Vilain (3):
git-svn: fix test for trunk svn (commit message not needed)
git-svn: fix test for trunk svn (transaction out of date)
git-svn: handle changed svn command-line syntax
Stefan Sperling (1):
Fix pool handling in git-svnimport to avoid memory leaks.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 5:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20071002050820.GA4261@coredump.intra.peff.net>
On Tue, Oct 02, 2007 at 01:08:20AM -0400, Jeff King wrote:
> One approach which I haven't tried but might be promising is to actually
> keep each list sorted, and then do a "merge" of the two lists, comparing
> as you go. We don't really need to do arbitrary lookups in the hash; we
> just need to compare two hash tables at a time. My approach was to be
> simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
> order of 2^17), and that's clearly just too big. But with a list merge,
> it should be O(n), where n is the actual number of lines in the files
> (or binary chunks for the binary case).
BTW, I don't want to steal credit for this idea...it comes from thinking
about what David Kastrup said earlier in the thread, though I think he
was proposing sorting just inside buckets.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl4up0tf.fsf@gitster.siamese.dyndns.org>
On Mon, Oct 01, 2007 at 10:01:16PM -0700, Junio C Hamano wrote:
> > Just to update, I tried using a non-colliding hash for this (at the
> > expense of much memory), and I wasn't able to get things much faster
> > (and certainly not worth the explosion in memory), short of reducing the
> > size of the hash (which is going to reduce the quality of the output).
> > So I am giving up for the time being, but if others are interested in
> > trying to speed things up, I would be happy to discuss ideas.
>
> Bummer. You are giving up at the same place I gave up the last
> time. I was somehow hoping that other people are more clever
> and determined than I was ;-).
>
> Thanks for trying.
What was so discouraging is that I literally simplified the process to
for(i = 0; i < HASH_SIZE; i++)
if(src[i] < dst[i])
...
and it spent all of the time on that one conditional.
One approach which I haven't tried but might be promising is to actually
keep each list sorted, and then do a "merge" of the two lists, comparing
as you go. We don't really need to do arbitrary lookups in the hash; we
just need to compare two hash tables at a time. My approach was to be
simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
order of 2^17), and that's clearly just too big. But with a list merge,
it should be O(n), where n is the actual number of lines in the files
(or binary chunks for the binary case).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-02 5:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071002041652.GA32133@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Just to update, I tried using a non-colliding hash for this (at the
> expense of much memory), and I wasn't able to get things much faster
> (and certainly not worth the explosion in memory), short of reducing the
> size of the hash (which is going to reduce the quality of the output).
> So I am giving up for the time being, but if others are interested in
> trying to speed things up, I would be happy to discuss ideas.
Bummer. You are giving up at the same place I gave up the last
time. I was somehow hoping that other people are more clever
and determined than I was ;-).
Thanks for trying.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 4:16 UTC (permalink / raw)
To: git
In-Reply-To: <20070927023633.GA28902@coredump.intra.peff.net>
On Wed, Sep 26, 2007 at 10:36:33PM -0400, Jeff King wrote:
> > * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
> > + diffcore-rename: cache file deltas
> >
> > Parked in 'next' for now but is 'master' material.
>
> My tests after this patch show that spanhash_find is responsible for
> a large portion of the processing time in large renames, so I am going
> to look into speeding that up.
Just to update, I tried using a non-colliding hash for this (at the
expense of much memory), and I wasn't able to get things much faster
(and certainly not worth the explosion in memory), short of reducing the
size of the hash (which is going to reduce the quality of the output).
So I am giving up for the time being, but if others are interested in
trying to speed things up, I would be happy to discuss ideas.
-Peff
^ permalink raw reply
* Re: latest git manual pages have some problems
From: Eric Blake @ 2007-10-02 2:26 UTC (permalink / raw)
To: cygwin, git
In-Reply-To: <224419.55330.qm@web59112.mail.re1.yahoo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Cary R. on 10/1/2007 2:22 PM:
> The latest update to git (1.5.3.1) changed how the manual pages are
> displayed.
And that change would probably be the upgrade from asciidoc 8.2.2 to 8.2.3.
> Specifically references to other git manual pages are no longer
> shown by name. Instead a reference number with a cross reference at the
> end of the file is given. From a usability standpoint this is a real
> inconvenience. I am hoping that something changed in the programs used to
> generate the manual pages and a new flag/etc. is required to get the
> original behavior.
I've noticed it, and I hate it too. But don't know enough about asciidoc
or the git documentation process to know how to go about fixing it, so I'm
adding the git list on this mail for advice.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
volunteer cygwin git packager
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHAaxj84KuGfSFAYARAh1LAKDFEURDhGU25xC8Djdxc12Y1Dz6VQCgz++c
WD09VOPGyWeVySdjOau8a3c=
=X91K
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/2] Change "refs/" references to symbolic constants
From: Jeff King @ 2007-10-02 1:16 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200710012141.44459.andyparkins@gmail.com>
On Mon, Oct 01, 2007 at 09:41:43PM +0100, Andy Parkins wrote:
> Please hold off on applying this. I'm getting this when running the tests:
>
> *** t5516-fetch-push.sh ***
> * ok 1: setup
> * ok 2: fetch without wildcard
> * ok 3: fetch with wildcard
> * ok 4: push without wildcard
> * ok 5: push with wildcard
> * ok 6: push with matching heads
> * ok 7: push with no ambiguity (1)
> * ok 8: push with no ambiguity (2)
> * ok 9: push with weak ambiguity (1)
> * ok 10: push with weak ambiguity (2)
> * ok 11: push with ambiguity (1)
> * FAIL 12: push with ambiguity (2)
>
> I'm having trouble seeing where the fault is at the moment though.
>From your patch:
- patlen != namelen - 5 &&
- prefixcmp(name, "refs/heads/") &&
- prefixcmp(name, "refs/tags/")) {
+ patlen != namelen - STRLEN_PATH_REFS_HEADS &&
+ prefixcmp(name, PATH_REFS_HEADS) &&
+ prefixcmp(name, PATH_REFS_HEADS)) {
This is totally bogus. You meant STRLEN_PATH_REFS, and the second path
should be PATH_REFS_TAGS. With those changes, t5516 passes.
I haven't combed through your patch in detail, so there might be similar
problems lurking. I did notice one or two spots where you call
strlen(PATH_REFS_*), which should of course also be changed to
STRLEN_PATH_REFS_*.
And as a final comment, your patch doesn't apply to next at all because
of the reorganization of the fetching API (e.g., fetch-pack.c doesn't
exist at all anymore). You should probably prepare a parallel patch for
next.
-Peff
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Carl Worth @ 2007-10-01 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Barry Fishman, git
In-Reply-To: <7v641qquzq.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Mon, 01 Oct 2007 16:24:09 -0700, Junio C Hamano wrote:
> I think Daniel's rewrite of remote ref matching code that has
> been cooking in 'next' changes the match semantics of the remote
> side in subtle way to make it easier to favor branches when
> pushing branches, but I juggle many topics and I have to go back
> to the code to make sure. Since you are interested, and more
> importantly since I know you are capable to do the digging
> yourself, I won't be doing the digging myself immediately,
> though.
Great. I'll go looking for that.
And if I don't find what I'm thinking of there, I'll see if I can't
cook up something else myself.
Thanks again,
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Shawn O. Pearce @ 2007-10-01 23:35 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> $ git push /pub/git/foo.git master
>
> Is there any reason that that shouldn't be interpreted as
> "master:master" and that that would in turn be interpreted as "create
> a remote refs/heads/master" ?
This is actually read more as:
1) Expand "master" to "refs/heads/master"
2) Expand "refs/heads/master" to "refs/heads/master:refs/heads/master"
We first try to expand the local name to an "absolute" local name,
then if the remote name is missing default it to the same as the
(now expanded) local name. So "push origin master" is not read as
"push origin refs/haeds/master:master".
> PS. As someone who has written some new-user documentation for git,
> there are a few low-level git notions that I would like to avoid in
> that documentation. For example, one is FETCH_HEAD. In my first
> attempt at porting hgbook-chapter2 to git I found myself using
> FETCH_HEAD to simulate "hg incoming". Thankfully, I was able to
> rewrite it by taking advantage of remotes and using "master..origin"
> instead.
How about:
git config alias.incoming 'log ..FETCH_HEAD'
? Or do we need --reverse in there too to simulate "hg incoming"?
The thing is, FETCH_HEAD is a lot more powerful than a tracking
branch. It can contain objects randomly pulled from another
repository (e.g. one shot pulls).
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".
Agreed. We do that in fetch. We should do that in push. We should
only mention "refs/*" if the user is pushing something funny, e.g.
pushing into the remote tracking branch space. Or the stash. Etc.
Tags and normal branches should be denoted as such.
--
Shawn.
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Junio C Hamano @ 2007-10-01 23:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, Git
In-Reply-To: <Pine.LNX.4.64.0710020022470.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 1 Oct 2007, Reece Dunn wrote:
>
>> I am running a Linux From Scratch 6.2 system that does not have cpio
>> installed on it. This means that I can't clone a local repository
>> unless I install cpio.
>
> You might be interested in the workaround Hannes did in mingw.git; he made
> a wrapper script called 'cpio' using 'tar'.
I think that may be good enough as workaround, but I do not
think you would get the space saving from hardlinks that way.
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Johannes Schindelin @ 2007-10-01 23:23 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git
In-Reply-To: <3f4fd2640710011228w61ce34b5ve47ea529eed384fd@mail.gmail.com>
Hi,
On Mon, 1 Oct 2007, Reece Dunn wrote:
> I am running a Linux From Scratch 6.2 system that does not have cpio
> installed on it. This means that I can't clone a local repository
> unless I install cpio.
You might be interested in the workaround Hannes did in mingw.git; he made
a wrapper script called 'cpio' using 'tar'.
Ciao,
Dscho
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Junio C Hamano @ 2007-10-01 23:24 UTC (permalink / raw)
To: Carl Worth; +Cc: Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
>> "master:master") does not exist there, and we do not create it
>> unless you give a full refname that begins with refs/ (so that
>> push can tell if you want to create a tag or a branch).
>
> And why is that?
I think Daniel's rewrite of remote ref matching code that has
been cooking in 'next' changes the match semantics of the remote
side in subtle way to make it easier to favor branches when
pushing branches, but I juggle many topics and I have to go back
to the code to make sure. Since you are interested, and more
importantly since I know you are capable to do the digging
yourself, I won't be doing the digging myself immediately,
though.
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: J. Bruce Fields @ 2007-10-01 23:17 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
On Mon, Oct 01, 2007 at 04:06:09PM -0700, Carl Worth wrote:
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".
I'd be nervous about skipping discussion of the refs/ namespace. Sure,
introduce branch heads and tags on their own first, but you've got to
mention the rest pretty early on. Eventually anyone can find themselves
with a tags, heads, and remotes with the same names, and then it's easy
to get stuck if you don't have a way to disambiguate.
And, really, it doesn't take that much space to explain this stuff.
--b.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox