* Re: git-walkthrough-add script
From: Pedro Melo @ 2008-01-04 23:26 UTC (permalink / raw)
To: William Morgan; +Cc: Git Mailing List
In-Reply-To: <1199426431-sup-6092@south>
Hi,
On Jan 4, 2008, at 6:14 AM, William Morgan wrote:
> I've written a little script to do darcs-style hunk-by-hunk
> walkthroughs. It's based on the git-hunk-commit script that was
> floating
> around. Maybe someone else will find it useful.
>
> http://git-wt-commit.rubyforge.org/
Maybe I'm doing something wrong, but comparing git-add -p with your
script, git-add -p is more darcs'ish. With git-add, if I have several
changes in the same file, I get to choose per hunk.
You script asks me to add all the changes in the same file at once.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: Trouble importing from public CVS repo
From: Sean @ 2008-01-04 23:17 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Matthias Urlichs
In-Reply-To: <477EA7F6.1010608@garzik.org>
On Fri, 04 Jan 2008 16:41:10 -0500
Jeff Garzik <jeff@garzik.org> wrote:
> $ git-cvsimport -v -d:pserver:anonymous@cvs.lysator.liu.se:/cvsroot/unfs3 unfs3
>
> produces
>
> Initialized empty Git repository in /spare/repo/unfs3/.git/
> Running cvsps...
> connect error: Network is unreachable
> cvs rlog: Logging unfs3
> cvs rlog: Logging unfs3/Config
> cvs rlog: Logging unfs3/Extras
> cvs rlog: Logging unfs3/contrib
> cvs rlog: Logging unfs3/contrib/nfsotpclient
> cvs rlog: Logging unfs3/contrib/nfsotpclient/mountclient
> cvs rlog: Logging unfs3/contrib/rpcproxy
> cvs rlog: Logging unfs3/doc
> Fetching LICENSE v 1.1
> New LICENSE: 1416 bytes
> Fetching Makefile.in v 1.1
> Unknown: error
>
Hi Jeff,
See the same problem here and it has something to do with how files are being fetched
from the cvs server. I'm not much inclined to research it further, however the ugly hack
below appears to allow the repo to be imported. At least importing the first 10 commits
(-L 10) looked okay... Perhaps it's a clue to how the issue could be resolved properly.
HTH,
Sean
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 6d8ff93..357665d 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -421,7 +421,7 @@ sub _line {
$res += $self->_fetchfile($fh, $cnt);
} else {
chomp $line;
- if ($line eq "ok") {
+ if ($line eq "ok" or $line =~ /^error/i) {
# print STDERR "S: ok (".length($res).")\n";
return $res;
} elsif ($line =~ s/^E //) {
--
1.5.4.rc2.17.g257f
^ permalink raw reply related
* Re: Retroactively change email signature? [resend]
From: Sam Vilain @ 2008-01-04 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio Hamano, git
In-Reply-To: <477EBB92.605@vilain.net>
Sam Vilain wrote:
> Linus Torvalds wrote:
>> I don't care. If some commit refers to another commit that isn't its
>> ancestor, then that is undefined *anyway*.
>>
>> So the only case that really matters is when you refer to your own strict
>> ancestor.
>>
>> This is one reason why it was so crazy that "git cherry-pick" used to have
>> "-x" by default - appending the original SHA1 (which is generally *not* an
>> ancestor) is meaningless and stupid.
>
> Not stupid at all. It gives you an easily clickable link to the
> previous version of the patch, which may be of interest, and is
> otherwise irretrievable information if the patch needed resolving.
footnote: of course it is entirely meaningless if the referred SHA1 is
not published anywhere, so I agree with the cherry-pick default setting.
Sam.
^ permalink raw reply
* Re: Retroactively change email signature? [resend]
From: Sam Vilain @ 2008-01-04 23:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio Hamano, git
In-Reply-To: <alpine.LFD.1.00.0801041031590.2811@woody.linux-foundation.org>
Linus Torvalds wrote:
> I don't care. If some commit refers to another commit that isn't its
> ancestor, then that is undefined *anyway*.
>
> So the only case that really matters is when you refer to your own strict
> ancestor.
>
> This is one reason why it was so crazy that "git cherry-pick" used to have
> "-x" by default - appending the original SHA1 (which is generally *not* an
> ancestor) is meaningless and stupid.
Not stupid at all. It gives you an easily clickable link to the
previous version of the patch, which may be of interest, and is
otherwise irretrievable information if the patch needed resolving.
Sam.
^ permalink raw reply
* Re: Octopus? Really? Interesting...
From: Junio C Hamano @ 2008-01-04 22:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List
In-Reply-To: <1199471321.3133.22.camel@ld0161-tx32>
Jon Loeliger <jdl@freescale.com> writes:
> Couple questions:
>
> Is it ever NOT the case, that if you are on one
> branch ("master") and name it as a "to be merged"
> branch along with some others, that we can simplify
> the request by noting that it is the same as the
> current "to be merged into" target branch?
Yes we can, but "filter ancestors out from the remotes"
computation does not happen before the merge strategy is chosen.
> Other than creating a log message with "merged
> by octopus", will this merge be content-identical
> to the obvious simplified merge?
I think octopus actually tries to be careful not to run the
read-tree 3-way merge when merging a true ancestor (see ll.77-87
in git-merge-octopus.sh, but see below), so the resulting tree
should be identical to "-s resolve" merge.
But that does not mean the user's wish to record such a commit
as one ancestor should not be honored, and I think there
actually is a benign bug there. Due to the "Already up-to-date
with $SHA1" part, the codepath that says "Fast forwarding to:"
never actually triggers, so in practice we end up dropping any
true ancestor from the parent list of the resulting merge. That
contradicts the comment in ll.77-87 that suggests we try not to
outsmart the user who told us to create such an octopus for
unfathomable reason ;-)
^ permalink raw reply
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Junio C Hamano @ 2008-01-04 22:00 UTC (permalink / raw)
To: Michael Stefaniuc; +Cc: Nicolas Pitre, git
In-Reply-To: <477EA06A.5090606@redhat.com>
Michael Stefaniuc <mstefani@redhat.com> writes:
>> What Nico said.
> Not sure if you read my reply to Nico but the reflog is not there for
> deleted branches. Nor for a cleared stash. Common operations where one
> can loose work by mistake.
I am sure you read what Nico pointed out about HEAD reflog.
> Nevertheless is there a reason why git gc needs to run after applying
> each patch in git-am? Why can't it run just once at the end? git prune
> is optional and there's no reason to penalize a user that doesn't feel
> safe to run it by cluttering the output of git am/rebase. There is also
> a time penalty: git gc --auto on a pruned tree runs so fast that it
> isn't measurable but on my unpruned wine it took 1.5 seconds. Waiting
> 1.5 seconds per am/rebase is acceptable; wasting 1.5 seconds per patch
> in the mailbox/rebase isn't that much fun if there are more than a
> handful of patches to apply.
"Optional" does not mean "whether you do it or not you will see
identical behaviour". Not pruning may slow things down but you
may still choose not to prune and suffer the penalty --- that's
your choice. But we still produce the correct result (hopefully
;-) --- and that is what "Optional" means.
The message from "gc --auto" may serve as a coalmine canary for
you to know when to prune.
I do not think moving "gc --auto" outside the loop hurts in
practice because you are not likely to be rebasing a truly huge
series every day, but cruft can accumulate during "git am" run
and the "gc --auto" inside loop was meant to clean them up. The
idea was taken from importers that run repack every once in a
while (e.g. cvsimport runs every 1k commits), but "gc --auto"
was designed to be much more lightweight than a full repack and
that was the reason it was placed in the loop without counting
"every N commits".
^ permalink raw reply
* Trouble importing from public CVS repo
From: Jeff Garzik @ 2008-01-04 21:41 UTC (permalink / raw)
To: Git Mailing List; +Cc: Matthias Urlichs
I'm trying to convert this public repo into a git repository:
:pserver:anonymous@cvs.lysator.liu.se:/cvsroot/unfs3
cvsps seems to produce a nice long list of patchesets for the "unfs3"
module, and running
cvs -d:pserver:anonymous@cvs.lysator.liu.se:/cvsroot/unfs3 co -P unfs3
works as expected. However, running
[jgarzik@core unfs3]$ git-cvsimport -v
-d:pserver:anonymous@cvs.lysator.liu.se:/cvsroot/unfs3 unfs3
produces
Initialized empty Git repository in /spare/repo/unfs3/.git/
Running cvsps...
connect error: Network is unreachable
cvs rlog: Logging unfs3
cvs rlog: Logging unfs3/Config
cvs rlog: Logging unfs3/Extras
cvs rlog: Logging unfs3/contrib
cvs rlog: Logging unfs3/contrib/nfsotpclient
cvs rlog: Logging unfs3/contrib/nfsotpclient/mountclient
cvs rlog: Logging unfs3/contrib/rpcproxy
cvs rlog: Logging unfs3/doc
Fetching LICENSE v 1.1
New LICENSE: 1416 bytes
Fetching Makefile.in v 1.1
Unknown: error
This machines and package (git-cvs-1.5.3.3-3.fc7) work just fine with a
large number of other CVS repositories [nice work].
Jeff
^ permalink raw reply
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Michael Stefaniuc @ 2008-01-04 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vhchtjphk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
>> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
>>
>>> With "too many unreachable loose objects" git gc --auto will always
>>> trigger. This clutters the output of git am and thus git rebase.
>>>
>>> The work flow of the Wine project doesn't include git merge. git rebase
>>> is therefor used to track the origin. This will produce soon too many
>>> loose objects for git gc --auto's taste. Pruning the repository would
>>> "fix" it. But we tell Wine developers new to git to NOT prune as long as
>>> they aren't confident enough with git; just as a safety net in case they
>>> have thrown away month of work.
>> The safety is the reflog. What it refers to doesn't get pruned.
>
> What Nico said.
Not sure if you read my reply to Nico but the reflog is not there for
deleted branches. Nor for a cleared stash. Common operations where one
can loose work by mistake.
> More importantly, ones who are not confident with git would not
> be able to resurrect unreachables that are left unpruned anyway.
> The unreachables are by definition not connected to anything, so
> they cannot do much better than grepping through droppings left
> by "fsck --lost-found", which they probably even do not know how
> to do yet.
The smarter ones come and ask on irc. We helped a few people with git
problems on the Wine channels. Depending on the amount of time someone
put into his "lost" work grepping through "fsck --lost-found" might be
well worth it.
Nevertheless is there a reason why git gc needs to run after applying
each patch in git-am? Why can't it run just once at the end? git prune
is optional and there's no reason to penalize a user that doesn't feel
safe to run it by cluttering the output of git am/rebase. There is also
a time penalty: git gc --auto on a pruned tree runs so fast that it
isn't measurable but on my unpruned wine it took 1.5 seconds. Waiting
1.5 seconds per am/rebase is acceptable; wasting 1.5 seconds per patch
in the mailbox/rebase isn't that much fun if there are more than a
handful of patches to apply.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
Consulting Communications Engineer Fax.: +49-711-96437-111
--------------------------------------------------------------------
Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart
Handelsregister: Amtsgericht Stuttgart HRB 153243
Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
^ permalink raw reply
* Re: git-walkthrough-add script
From: Jeff King @ 2008-01-04 21:07 UTC (permalink / raw)
To: William Morgan; +Cc: Git Mailing List
In-Reply-To: <1199471454-sup-4786@south>
On Fri, Jan 04, 2008 at 10:31:03AM -0800, William Morgan wrote:
> > However, I'm not clear what advantages this has over "git add -p".
>
> A better interface. (Where by "better", I mean, behaves how I personally
> prefer.)
OK. If it works for you, then I'm not one to say you shouldn't use it.
But if you have interface improvement suggestions for "git-add -i" or
"git-add -p", I'm sure they would be well-received (post-1.5.4 release,
of course).
-Peff
^ permalink raw reply
* Re: [PATCH] git stash: one bug and one feature request
From: Jeff King @ 2008-01-04 21:04 UTC (permalink / raw)
To: Jakub Narebski
Cc: Pascal Obry, Brandon Casey, Marco Costalba, Junio C Hamano,
Git Mailing List
In-Reply-To: <m3abnlo4xv.fsf@roke.D-201>
On Fri, Jan 04, 2008 at 09:51:05AM -0800, Jakub Narebski wrote:
> or "git stash delete"
>
> This probably would require the command to delete single reflog,
> which was posted some time ago and is in either pu or in offcuts,
> or in next.
>
> But I guess this is post 1.5.4
There is a "git reflog delete" in next (but not in master). See
552cecc2. Using the same name makes sense, since they are equivalent
actions (and "git stash delete" should be very easy, since it is
implemented in terms of reflogs).
-Peff
^ permalink raw reply
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Nicolas Pitre @ 2008-01-04 20:58 UTC (permalink / raw)
To: Michael Stefaniuc; +Cc: git
In-Reply-To: <477E9536.6050401@redhat.com>
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
> Nicolas Pitre wrote:
> > On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
> >
> >> With "too many unreachable loose objects" git gc --auto will always
> >> trigger. This clutters the output of git am and thus git rebase.
> >>
> >> The work flow of the Wine project doesn't include git merge. git rebase
> >> is therefor used to track the origin. This will produce soon too many
> >> loose objects for git gc --auto's taste. Pruning the repository would
> >> "fix" it. But we tell Wine developers new to git to NOT prune as long as
> >> they aren't confident enough with git; just as a safety net in case they
> >> have thrown away month of work.
> >
> > The safety is the reflog. What it refers to doesn't get pruned.
> Then git gc --auto should just prune too and not spam, right?
Pruning might be dangerous if some other operation is happening
concurrently, which is why it is not done by default.
> But the reflog is only there for branches that still exist; the rest is
> gone. A git stash clear will also remove the reflog for the stash.
But the reflog for HEAD remains nevertheless, and it contains everything
that happened to be the current branch.
> Regardless of the safety of git prune i don't see a reason why git gc
> --auto needs to be called for every patch in a git-am run and not once
> at the end.
Indeed.
Nicolas
^ permalink raw reply
* Re: [PATCH 3/2] attribute "coding": specify blob encoding
From: Junio C Hamano @ 2008-01-04 20:53 UTC (permalink / raw)
To: Tsugikazu Shibata; +Cc: nanako3, git
In-Reply-To: <20080105.011649.26949633.tshibata@ab.jp.nec.com>
Tsugikazu Shibata <tshibata@ab.jp.nec.com> writes:
> So, question is why we should think of this field in case of non
> programming language files ?
> In case of text file using any coding, Should we need to add something
> after "@@"?
See gitattributes(5), "Defining a custom hunk-header". The
associated configuration variable for this feature is somewhat
misnamed [*1*], but if you do not want to see anything, I think
you should be able to define a custom pattern that match
emptyness.
For .txt files, I always hoped that someday, somebody clever
would come up with a custom pattern to grok AsciiDoc mark-up to
pick a label-looking line so that the hunks in patches to our
documentation would be easier to find. A simpler and more
generally applicable possibility is to find the previous line
that starts a paragraph (e.g. you would pick "For .txt files..."
for this part because it is the non-blank line that immediately
follows the first blank line before this part). But I think the
code to find an appropriate string for hunk header is not
capable of looking at more than one line, so neither of these
would be easy to implement without changing the underlying logic
and semantics of "diff.*.funcname" configuration.
[Footnote]
*1* It may be misnamed but it is in line with GNU diff, though.
They call -p "show-c-function" and -F "show-function-line" --
both assume function names are what people are interested in
having on hunk headers.
^ permalink raw reply
* Re: libgit: git_setup_directory() is not reentrant
From: Junio C Hamano @ 2008-01-04 20:40 UTC (permalink / raw)
To: Christian Thaeter; +Cc: git
In-Reply-To: <477E67C5.5020301@pipapo.org>
Christian Thaeter <ct@pipapo.org> writes:
> While working on a git-browser, I noticed that git_setup_directory() is
> not reentrant.
Yup, that comes from a longstanding design of git that "a
command runs once and exits". Do not call that twice, or help
the libification effort.
^ permalink raw reply
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Junio C Hamano @ 2008-01-04 20:38 UTC (permalink / raw)
To: Michael Stefaniuc; +Cc: Nicolas Pitre, git
In-Reply-To: <alpine.LFD.1.00.0801041437190.2649@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
>
>> With "too many unreachable loose objects" git gc --auto will always
>> trigger. This clutters the output of git am and thus git rebase.
>>
>> The work flow of the Wine project doesn't include git merge. git rebase
>> is therefor used to track the origin. This will produce soon too many
>> loose objects for git gc --auto's taste. Pruning the repository would
>> "fix" it. But we tell Wine developers new to git to NOT prune as long as
>> they aren't confident enough with git; just as a safety net in case they
>> have thrown away month of work.
>
> The safety is the reflog. What it refers to doesn't get pruned.
What Nico said.
More importantly, ones who are not confident with git would not
be able to resurrect unreachables that are left unpruned anyway.
The unreachables are by definition not connected to anything, so
they cannot do much better than grepping through droppings left
by "fsck --lost-found", which they probably even do not know how
to do yet.
^ permalink raw reply
* Re: [PATCH] git-filter-branch could be confused by similar names
From: Junio C Hamano @ 2008-01-04 20:28 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Johannes Schindelin
In-Reply-To: <20080104155114.GS3373@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> It works only if the name "unambiguous" for git show-ref, which
> interprets refname differently than rev-list as I wrote above.
> Nevertheless, I believe we can use 'git show-ref' if we try
> something like this:
Ahh.
But at that point I would say that exposing the refname dwimming
logic to the scripts could be a much cleaner solution. After
all, get_sha1_basic() knows what ref it used to come up with the
answer, but we are discarding that information.
How about making "rev-parse --symbolic-full-name" give what it
eventually dwimmed the given ref to, perhaps like the attached
patch? Then you can do:
git rev-parse --revs-only --symbolic-full-name "$@" >"$tempdir"/heads
without any need for the loop there in filter-branch.
---
builtin-rev-parse.c | 37 ++++++++++++++++++++++++++++++++++---
1 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 20d1789..b9af1a5 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -21,6 +21,9 @@ static const char *def;
#define NORMAL 0
#define REVERSED 1
static int show_type = NORMAL;
+
+#define SHOW_SYMBOLIC_ASIS 1
+#define SHOW_SYMBOLIC_FULL 2
static int symbolic;
static int abbrev;
static int output_sq;
@@ -103,8 +106,32 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
if (type != show_type)
putchar('^');
- if (symbolic && name)
- show(name);
+ if (symbolic && name) {
+ if (symbolic == SHOW_SYMBOLIC_FULL) {
+ unsigned char discard[20];
+ char *full;
+
+ switch (dwim_ref(name, strlen(name), discard, &full)) {
+ case 0:
+ /*
+ * Not found -- not a ref. We could
+ * emit "name" here, but symbolic-full
+ * users are interested in finding the
+ * refs spelled in full, and they would
+ * need to filter non-refs if we did so.
+ */
+ break;
+ case 1: /* happy */
+ show(full);
+ break;
+ default: /* ambiguous */
+ error("refname '%s' is ambiguous", name);
+ break;
+ }
+ } else {
+ show(name);
+ }
+ }
else if (abbrev)
show(find_unique_abbrev(sha1, abbrev));
else
@@ -421,7 +448,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--symbolic")) {
- symbolic = 1;
+ symbolic = SHOW_SYMBOLIC_ASIS;
+ continue;
+ }
+ if (!strcmp(arg, "--symbolic-full-name")) {
+ symbolic = SHOW_SYMBOLIC_FULL;
continue;
}
if (!strcmp(arg, "--all")) {
^ permalink raw reply related
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Michael Stefaniuc @ 2008-01-04 20:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.1.00.0801041437190.2649@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
>
>> With "too many unreachable loose objects" git gc --auto will always
>> trigger. This clutters the output of git am and thus git rebase.
>>
>> The work flow of the Wine project doesn't include git merge. git rebase
>> is therefor used to track the origin. This will produce soon too many
>> loose objects for git gc --auto's taste. Pruning the repository would
>> "fix" it. But we tell Wine developers new to git to NOT prune as long as
>> they aren't confident enough with git; just as a safety net in case they
>> have thrown away month of work.
>
> The safety is the reflog. What it refers to doesn't get pruned.
Then git gc --auto should just prune too and not spam, right?
But the reflog is only there for branches that still exist; the rest is
gone. A git stash clear will also remove the reflog for the stash.
Regardless of the safety of git prune i don't see a reason why git gc
--auto needs to be called for every patch in a git-am run and not once
at the end.
bye
michael
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Jan Hudec @ 2008-01-04 19:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Grégoire Barbier, Jakub Narebski, git
In-Reply-To: <46a038f90801031554j6218f08cl6c9608b24e1675f8@mail.gmail.com>
On Fri, Jan 04, 2008 at 12:54:58 +1300, Martin Langhoff wrote:
> On Jan 4, 2008 10:15 AM, Jan Hudec <bulb@ucw.cz> wrote:
> > Now to keep it stateless, I thought that:
> ...
> > This would guarantee, that when you want n revisions, you make at most
> > log2(n) requests and get at most 2*n revisions (well, the requests are for
>
> That is still a lot! How about, for each ref
The whole point of that is that the packs can be statically precomputed and
served with quite low CPU load, which is useful for serving from shared
computers (like servers in school computer labs or cheapo web hosting) or
slow servers like NSLU2. Also it makes HTTP caching actually useful, because
the set of possible requests is quite limited.
Also, while I said it's for each ref, the packs should really be optimized
for the common case of fetching all refs, which would really make it just
log2(n) packs and 2*n revisions for each whole download.
> - Client sends a POST listing the ref and the latest related commit
> it has that the server is likely to have (from origin/heads/<ref>).
> Optionally, it can provide a blacklist of <treeish> (where every
> object refered is known) and blob sha1s.
> - Server sends the new sha1 of the ref, and a thin pack that covers the changes
> - The client can disconnect to stop the transaction. For example --
> if it sees the sha1 of a huge object that it already has. It can
> re-request, with a blacklist.
>
> A good number of objects will be sent unnecesarily - with no option to
> the client to say "I have this" - but by using the hint of letting the
> server know we have origin/heads/<ref> I suspect that it will be
> minimal.
It would be better to only unnecesarily send revlists. Since each HTTP packed
will likely have something like 1kb overhead, sending few kb worth of revlist
is still pretty efficient. So just send part of revlist, than more revlist
and so on until you find exactly which revisions you need and than ask for
them. That will save *both* bandwidth *and* server CPU. The only reason to
waste bandwidth is to save CPU and you are not doing that.
> Also:
> - It will probably be useful to list all the refs the client knows
> from that server in the request.
> - If the ref has changed with a non-fast-forward, the server needs to
> say so, and provide a listing of the commits. As soon as the client
> spots a common commit, it can close the connection -- it now knows
> what ref to tell the server about in a subsequent command.
>
> This way, you ideally have 1 request per ref, 2 if it has been
> rebased/rewound. This can probably get reorganised to do several refs
> in one request.
>
> cheers,
>
>
> m
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] git-am: Run git gc only once and not for every patch.
From: Nicolas Pitre @ 2008-01-04 19:38 UTC (permalink / raw)
To: Michael Stefaniuc; +Cc: git
In-Reply-To: <20080104185926.GA11912@redhat.com>
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
> With "too many unreachable loose objects" git gc --auto will always
> trigger. This clutters the output of git am and thus git rebase.
>
> The work flow of the Wine project doesn't include git merge. git rebase
> is therefor used to track the origin. This will produce soon too many
> loose objects for git gc --auto's taste. Pruning the repository would
> "fix" it. But we tell Wine developers new to git to NOT prune as long as
> they aren't confident enough with git; just as a safety net in case they
> have thrown away month of work.
The safety is the reflog. What it refers to doesn't get pruned.
Nicolas
^ permalink raw reply
* Re: [PATCH] git stash: one bug and one feature request
From: Brian Swetland @ 2008-01-04 19:36 UTC (permalink / raw)
To: Jakub Narebski
Cc: Pascal Obry, Brandon Casey, Marco Costalba, Junio C Hamano,
Git Mailing List
In-Reply-To: <m3abnlo4xv.fsf@roke.D-201>
[Jakub Narebski <jnareb@gmail.com>]
> Pascal Obry <pascal@obry.net> writes:
> > Brandon Casey a écrit :
> > >
> > > Not sure how often such a command would be used though, so
> > > it may not be worth it.
> >
> > I've missed it many times. Especially in some scripts when I want to use
> > the stash-stack to store current working tree and clear it before
> > exiting. This is not possible today as all the stash-stack would be cleared.
> >
> > I agree that drop seems better.
>
> or "git stash delete"
Something like drop or delete would be nice.
I tried to "clear" a single stash once. Oops!
Is there a reason that git stash apply couldn't take a small integer
as the argument (at least as an alternative) instead of stash@{0}, etc?
Brian
^ permalink raw reply
* [PATCH] receive-pack: reject invalid refnames
From: Martin Koegler @ 2008-01-04 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
receive-pack.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/receive-pack.c b/receive-pack.c
index d0a563d..3267495 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -165,7 +165,8 @@ static const char *update(struct command *cmd)
unsigned char *new_sha1 = cmd->new_sha1;
struct ref_lock *lock;
- if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
+ /* only refs/... are allowed */
+ if (prefixcmp(name, "refs/") || check_ref_format(name + 5)) {
error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
--
1.4.4.4
^ permalink raw reply related
* [PATCH] git-am: Run git gc only once and not for every patch.
From: Michael Stefaniuc @ 2008-01-04 18:59 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
With "too many unreachable loose objects" git gc --auto will always
trigger. This clutters the output of git am and thus git rebase.
The work flow of the Wine project doesn't include git merge. git rebase
is therefor used to track the origin. This will produce soon too many
loose objects for git gc --auto's taste. Pruning the repository would
"fix" it. But we tell Wine developers new to git to NOT prune as long as
they aren't confident enough with git; just as a safety net in case they
have thrown away month of work.
Signed-off-by: Michael Stefaniuc <mstefani@redhat.com>
---
git-am.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 65c634f..5f0f241 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -469,9 +469,9 @@ do
"$GIT_DIR"/hooks/post-applypatch
fi
- git gc --auto
-
go_next
done
+git gc --auto
+
rm -fr "$dotest"
--
1.5.4.rc2
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] git stash: one bug and one feature request
From: Marco Costalba @ 2008-01-04 18:46 UTC (permalink / raw)
To: Brandon Casey; +Cc: Pascal Obry, Junio C Hamano, Git Mailing List
In-Reply-To: <477E7C3D.8030501@nrlssc.navy.mil>
On Jan 4, 2008 7:34 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
> Doesn't seem like too far of a stretch.
>
I'm very bad at naming, so I don't argue any more.
Just one thing (that is the only that matters) call this command as
you want but let it take one argument, the name of the reflog to
remove:
git stash drop stash@{3}
should be allowed.
git stash drop
defaults to stash@{0}
Thanks
Marco
^ permalink raw reply
* Re: git-walkthrough-add script
From: William Morgan @ 2008-01-04 18:31 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20080104072650.GA24685@coredump.intra.peff.net>
Excerpts from Jeff King's message of Thu Jan 03 23:26:50 -0800 2008:
> It didn't work for me, since the diff parsing failed to match my
> particular colors (I needed /^.....diff/ instead of /^....diff/). I
> suspect the color matching needs to be more flexible to be generally
> useful.
Fixed, thanks.
> However, I'm not clear what advantages this has over "git add -p".
A better interface. (Where by "better", I mean, behaves how I personally
prefer.)
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply
* Re: Retroactively change email signature? [resend]
From: Linus Torvalds @ 2008-01-04 18:34 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio Hamano, git
In-Reply-To: <477C7837.9000303@vilain.net>
On Thu, 3 Jan 2008, Sam Vilain wrote:
>
> Assuming, of course, that the commit you refer to in a message like that
> is in your history. If it's referring to another commit in a different
> branch, which may be being re-written, you've got two problems:
I don't care. If some commit refers to another commit that isn't its
ancestor, then that is undefined *anyway*.
So the only case that really matters is when you refer to your own strict
ancestor.
This is one reason why it was so crazy that "git cherry-pick" used to have
"-x" by default - appending the original SHA1 (which is generally *not* an
ancestor) is meaningless and stupid.
But in the case of "git revert", it should be an ancestor (or the _user_
is just insane, in which case it doesn't matter - insane people can do
insane things)
Linus
^ permalink raw reply
* Re: [PATCH] git stash: one bug and one feature request
From: Brandon Casey @ 2008-01-04 18:34 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pascal Obry, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550801041005x3ab682dam8535c7bde75038dc@mail.gmail.com>
Marco Costalba wrote:
> On Jan 4, 2008 7:00 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Marco Costalba wrote:
>>> Ok, drop is better then clear, but, if we need to add a new command I
>>> vote for 'delete' or 'rm' to be consistent with git naming.
>> If the stash list is thought of as a stack, then drop makes sense.
>>
>
> Yes, but is _not_ as a stack because you can say
>
> git stash apply stash@{3}
> git stash apply stash@{1}
> git stash apply stash@{4}
>
> i.e. you can access reflogs in any order, so thinking to a stack is
> misleading IMHO.
I think it is like a stack because new things are always added to the top
and shift everything else down.
i.e. we can't say 'git stash replace stash@{3}' and we probably wouldn't
want to.
When we call git stash, the previous item on 'top' is pushed down
so that it is the second item stash@{1}. The new item just stashed
(pushed), is now on top at stash@{0}.
Doesn't seem like too far of a stretch.
-brandon
^ 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