* Re: [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Johannes Schindelin @ 2009-03-25 15:44 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <20090325152338.GD30959@zoy.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 703 bytes --]
Hi,
On Wed, 25 Mar 2009, Sam Hocevar wrote:
> On Wed, Mar 25, 2009, Sverre Rabbelier wrote:
> > Heya,
> >
> > On Wed, Mar 25, 2009 at 00:19, Sam Hocevar <sam@zoy.org> wrote:
> > > ---
> > > ▁▂▃▄▅▆▇█
> >
> > I'm curious, where'd this come from?
>
> Just a few characters from the "Block Elements" Unicode block.
> For some reason, even though my locale is en_GB.UTF-8, Mutt insists
> on converting my messages to iso8859-1 when doing so does not lose
> information, resulting in corrupted patches, hence my addition of the
> above characters.
>
> By the way, your own mailer seems to be mangling those Unicode
> characters when answering.
Works correctly here.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] format-patch: add arbitrary email headers
From: Michael Hendricks @ 2009-03-25 15:58 UTC (permalink / raw)
To: git, gitster; +Cc: Michael Hendricks
format-patch supports the format.headers configuration for adding
arbitrary email headers to the patches it outputs. This patch adds
support for a --header argument which makes the same feature available
from the command line. This is useful when the content of custom
email headers must change from branch to branch.
This patch has been sponsored by Grant Street Group
Signed-off-by: Michael Hendricks <michael@ndrix.org>
---
Documentation/git-format-patch.txt | 5 +++++
builtin-log.c | 2 ++
t/t4014-format-patch.sh | 15 +++++++++++++++
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..e6fe7f3 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -161,6 +161,11 @@ if that is not set.
Add a "Cc:" header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
+--header=<header>::
+ Add an arbitrary header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+ For example, --header="Organization: git-foo"
+
--cover-letter::
In addition to the patches, generate a cover letter file
containing the shortlog and the overall diffstat. You can
diff --git a/builtin-log.c b/builtin-log.c
index c7a5772..35701a7 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -918,6 +918,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
cover_letter = 1;
else if (!strcmp(argv[i], "--no-binary"))
no_binary_diff = 1;
+ else if (!prefixcmp(argv[i], "--header="))
+ add_header( argv[i] + 9 );
else
argv[j++] = argv[i];
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index f187d15..5f8d9b4 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -128,6 +128,21 @@ test_expect_success 'additional command line cc' '
grep "^ *S. E. Cipient <scipient@example.com>$" patch5
'
+test_expect_success 'command line headers' '
+
+ git config --unset-all format.headers &&
+ git format-patch --header="Cc: R. E. Cipient <rcipient@example.com>" --stdout master..side | sed -e "/^$/q" >patch6 &&
+ grep "^Cc: R. E. Cipient <rcipient@example.com>$" patch6
+'
+
+test_expect_success 'configuration headers and command line headers' '
+
+ git config --replace-all format.headers "Cc: R. E. Cipient <rcipient@example.com>" &&
+ git format-patch --header="Cc: S. E. Cipient <scipient@example.com>" --stdout master..side | sed -e "/^$/q" >patch7 &&
+ grep "^Cc: R. E. Cipient <rcipient@example.com>,$" patch7 &&
+ grep "^ *S. E. Cipient <scipient@example.com>$" patch7
+'
+
test_expect_success 'multiple files' '
rm -rf patches/ &&
--
1.6.2.1.318.ged85d
^ permalink raw reply related
* Re: [BUG] Infinite loop in git send-email if ran non-interactively.
From: Jay Soffian @ 2009-03-25 16:03 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqiqlyj64o.fsf@bauges.imag.fr>
On Wed, Mar 25, 2009 at 5:36 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> I think, non-interactive runs of send-email should assume "yes"
Hmm, probably.
> instead of prompting. In any case, it should not do infinite loop (I
> guess I don't have to argue for this ;-) )
Right, I'll followup with a fix.
> Can someone more fluent in perl than me add a
>
> if(session-is-interactive) {
> ...
> }
>
> around this confirmation prompt?
>
> (side-note : there is indeed some code to handle the cases where the
> terminal doesn't work with readline, added by Junio in 280242d1, but
> the FakeTerm part doesn't seem to be executed in my case:
>
> my $term = eval {
> $ENV{"GIT_SEND_EMAIL_NOTTY"}
> ? new Term::ReadLine 'git-send-email', \*STDIN, \*STDOUT
> : new Term::ReadLine 'git-send-email';
> };
> if ($@) {
> $term = new FakeTerm "$@: going non-interactive";
> }
> )
>
> (in the meantime, I'll add --confirm never to my script)
Actually, FakeTerm is only triggered if Term::ReadLine is not
available. The "going non-interactive" message is misleading in this
case, as it has nothing to do with whether stdin is a tty or not.
j.
^ permalink raw reply
* Re: [BUG] Infinite loop in git send-email if ran non-interactively.
From: Jay Soffian @ 2009-03-25 16:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqiqlyj64o.fsf@bauges.imag.fr>
On Wed, Mar 25, 2009 at 5:36 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Hi,
>
> I've been hit by c1f2aa45b (send-email: add --confirm option and
> configuration setting) running git send-email from a cron job.
BTW, can you provide the details on how you are invoking send-email?
Have stdin/stdout/stderr been redirected? What arguments are you
giving it? And is this Vixie cron?
Thanks,
j.
^ permalink raw reply
* Re: [PATCH] avoid possible overflow in delta size filtering computation
From: Nicolas Pitre @ 2009-03-25 16:18 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: Junio C Hamano, git
In-Reply-To: <86hc1hdcj1.fsf@broadpark.no>
On Wed, 25 Mar 2009, Kjetil Barvik wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On a 32-bit system, the maximum possible size for an object is less than
> > 4GB, while 64-bit systems may cope with larger objects. Due to this
> > limitation, variables holding object sizes are using an unsigned long
> > type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
> >
> > When large objects are encountered, and/or people play with large delta
> > depth values, it is possible for the maximum allowed delta size
> > computation to overflow, especially on a 32-bit system. When this
> > occurs, surviving result bits may represent a value much smaller than
> > what it is supposed to be, or even zero. This prevents some objects
> > from being deltified although they do get deltified when a smaller depth
> > limit is used. Fix this by always performing a 64-bit multiplication.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
>
> I added this patch and rerun the 2 test cases form the table where
> --depth is 20000 and 95000, and got the following result:
>
> --depth=20000 => file size: 19126077 delta: 73814
> --depth=95000 => file size: 19126087 delta: 73814
>
> So, it seems that this patch almost fixed the issue. But notice that
> the pack file was 10 bytes larger for the --depth=95000 case.
>
> I made a small perl script to compare the output from 'git verify-pack
> -v' of the 2 idx/pack files, and found the following difference(1)
> (first line from --depth=20000 case, second from --depth=95000):
>
> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 9 19 18921247 731 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d
> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 20 29 18921247 730 12e560f7fb28558b15e3a2008fba860f9a4b2222
OK. Apparently, a different base object for that one delta was chosen
between those two runs.
Is your machine SMP?
Nicolas
^ permalink raw reply
* Re: [PATCH 2/5] Document details of transport function APIs
From: Daniel Barkalow @ 2009-03-25 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63hy9k0l.fsf@gitster.siamese.dyndns.org>
On Tue, 24 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > In particular, explain which of the fields of struct ref is used for
> > what purpose in the input to and output from each function.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > ---
> > transport.h | 38 ++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 38 insertions(+), 0 deletions(-)
> >
> > diff --git a/transport.h b/transport.h
> > index 489e96a..2e1650a 100644
> > --- a/transport.h
> > +++ b/transport.h
> > @@ -18,11 +18,49 @@ struct transport {
> > int (*set_option)(struct transport *connection, const char *name,
> > const char *value);
> >
> > + /**
> > + * Returns a list of the remote side's refs. In order to allow
> > + * the transport to try to share connections, for_push is a
> > + * hint as to whether the ultimate operation is a push or a fetch.
> > + *
>
> It is unclear what this "hint" is intended to be used for, what the
> transport is and isn't allowed to use it for, and what existing transports
> typically use it for.
I don't think there's anything the transport isn't allowed to use the hint
for (of course, it shouldn't go and do things that haven't been requested
at all yet, but that's true with or without a hint). It's intended to be
used for things like the git native protocol, where the client side has to
declare up front whether it wants to talk to receive-pack or upload-pack,
and it would have to disconnect and reconnect to get the other one.
It's probably also legitimate for the http transport to guess that, if
"for_push" is true, that it's worth trying to list directories with
webdav, although perhaps it should try both in any case.
> > + /**
> > + * Push the objects and refs. Send the necessary objects, and
> > + * then tell the remote side to update each ref in the list
> > + * from old_sha1 to new_sha1.
> > + *
> > + * Where possible, set the status for each ref appropriately.
> > + *
> > + * If, in the process, the transport determines that the
> > + * remote side actually responded to the push by updating the
> > + * ref to a different value, the transport should modify the
> > + * new_sha1 in the ref. (Note that this is a matter of the
> > + * remote accepting but rewriting the change, not rejecting it
> > + * and reporting that a different update had already taken
> > + * place)
> > + **/
>
> It this even a sane thing to allow? How would it interact with the
> "pretend we immediately turned around and fetched them into the remote
> tracking branches" local updates we usually do?
We already allow a git server to rewrite refs with a hook when it gets
them, and we record the pre-rewriting value. This allows the transport to
propagate the post-rewriting value back (if it can get it), and we'd
update the tracking branches with what the server actually did instead of
what we asked it to (i.e., we do what we would do if we really did turn
around and fetch them immediately).
Of course, I primarily want this for the case where it's a foreign system
and we don't get to control everything in the foreign history, even when
it is accepted (e.g., it applies its own timestamp and attributes it to a
different username), and we want to avoid simply losing the information as
to what became of the commit.
> > int (*push_refs)(struct transport *transport, struct ref *refs, int flags);
> > int (*push)(struct transport *connection, int refspec_nr, const char **refspec, int flags);
> >
> > + /** get_refs_list(), fetch(), and push_refs() can keep
> > + * resources (such as a connection) reserved for futher
> > + * use. disconnect() releases these resources.
> > + **/
> > int (*disconnect)(struct transport *connection);
> > char *pack_lockfile;
> > signed verbose : 2;
>
> It is just a style thing, but all of our multi-line comments are
>
> /*
> * of
> * this
> * form
> */
>
> and these new comments are formatted slightly differently with double
> asterisks on only the first and the last lines. In addition, th last
> comment block uses a yet another different style, which is a bit of
> eyesore.
Ah, yes, I'll correct that.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/5] Add option for using a foreign VCS
From: Daniel Barkalow @ 2009-03-25 16:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vsm9jwd.fsf@gitster.siamese.dyndns.org>
On Tue, 24 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This simply configures the remote to use a transport that doesn't have
> > any methods at all and is therefore unable to do anything yet.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > ---
> > Documentation/config.txt | 4 ++++
> > remote.c | 2 ++
> > remote.h | 2 ++
> > transport.c | 3 ++-
> > 4 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/remote.h b/remote.h
> > index de3d21b..e77dc1b 100644
> > --- a/remote.h
> > +++ b/remote.h
> > @@ -11,6 +11,8 @@ struct remote {
> > const char *name;
> > int origin;
> >
> > + const char *foreign_vcs;
> > +
> > const char **url;
> > int url_nr;
> > int url_alloc;
>
> What are these extra blank lines for? Isn't it pretty much part of the
> URL group that immediately follows it?
I'd been thinking of it as being a higher-level switch than the URLs, but
it could go together.
> > diff --git a/transport.c b/transport.c
> > index 26c578e..8a37db5 100644
> > --- a/transport.c
> > +++ b/transport.c
> > @@ -939,7 +939,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
> > ret->remote = remote;
> > ret->url = url;
> >
> > - if (!prefixcmp(url, "rsync:")) {
> > + if (remote && remote->foreign_vcs) {
> > + } else if (!prefixcmp(url, "rsync:")) {
>
> if (...) {
> ; /* empty */
> } else ...
I don't think I've ever tried writing an empty block for git before. It's
braces containing a semicolon and comment? (Of course, the reason I wrote
this one this way is so that the next patch could put two "+" lines in
there and have no "-" lines)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.
From: Daniel Barkalow @ 2009-03-25 16:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskl284bt.fsf@gitster.siamese.dyndns.org>
On Wed, 25 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > +'capabilities'::
> > + Prints the capabilities of the helper, one per line. These are:
> > + - import: the basic import command
> > + - marks: import should be done with a saved marks file
> > + - find-new-branches: detect new branches
> > + - export: the general export command
> > + - fork: create a new branch and export to it
> > + - anonymous-fork: make commits on a branch without an inherent name
> > + - merge: merge branches (of whatever type the system supports)
> > +
> > + If the helper doesn't support "merge", the default for pull is
> > + to rebase instead of merging.
> > +
> > +'list'::
> > + Takes the remote name, and outputs the names of refs. These
> > + may be followed, after a single space, by "changed" or
> > + "unchanged", indicating whether the foreign repository has
> > + changed from the state in the ref. If the helper doesn't know,
> > + it doesn't have to provide a value. (In particular, it
> > + shouldn't do expensive operations, such as importing the
> > + content, to see whether it matches.)
>
> Does this roughly corresponds to get_remote_refs(), with "unchanged"
> return turned into the current value of the ref while "changed" returned
> as 0{40} in old_sha1 value?
Yes, with the [1/5] change to make 0{40} tell git to consider it different
but unknown. Also, not giving either of these flags counts as 0{40}, but
we might someday want to have the native side report the difference
between knowing that it changed and not knowing at all.
> For a vcs backend that lacks find-new-branches capability, when does the
> set of refnames returned by this operation change? Can the end user
> request an expensive operation to make the list up-to-date? Does the end
> user need to?
What I've done for my p4 backend is have an option for whether it should
search for new branches (which is somewhat expensive, at least currently,
because it involves connecting to the server in this step). If the backend
actually lacks the capability, the user has to do something (probably add
them to the config file) to include new branches. In some cases, what the
backend exposes as branches may be something that there isn't a complete
list of; there may be systems that are structured sort of like repo.or.cz,
where the URL is for the whole system, and there are some things on it
that are branches of the project (like various people's git.git
repositories) and some things that are completely unrelated and not
interesting, and there's no machine-readable way to distinguish them.
> > +'import'::
> > + Takes the remote name and a list of names of refs, and imports
> > + whatever it describes, by outputting it in git-fast-import
> > + format.
> > +
> > +'export'::
> > + Sends the branch to the foreign system and reimports it in
> > + fast-import format.
>
> The above two description is inconsistent; say "git-fast-import" for both.
Not "fast-import" for both, now that other systems have adopted the format
as input?
> This seems to follow the model of git-svn in that we treat our history as
> throw-away, export the history and give the authority to the other system
> by discarding and replacing our history with whatever the other end gives
> back to us by re-importing. Because git is more flexible than anything
> else, we could afford to do so, but I wonder if it is the right model and
> mentality.
I think that there is always the requirement that the other system
(whether it's foreign, git through filter-branch, or even a regular remote
git repository) contains a sane, consistant, and normal-looking history.
It's rarely going to be possible to export a history that will import as
the same hash (and incremental imports on top of local history that isn't
what a fresh complete import would contain seems even crazier). I don't
think there's any particular use for using a foreign system to store
history that only makes sense in git.
But, as a general principle, the reason a git developer would push to a
non-git remote repository is because the remote repository is
authoritative. I don't think it makes sense to have an environment where
the authoritative history is in git, but people are sharing it through a
bzr server (even if the bzr server can accurately represent the git
history).
Of course, we may want a different mechanism some day to generalize
git-cvsserver, where the authoritative history is in git, but we're
supporting foreign clients. But that requires very different code from
what I'm working on.
> One downside is that you end up rebasing the git side by operating this
> way, and a topology where multiple developers use one git repository as a
> synchronization point and use that git repository to interface with the
> foreign system becomes impossible. Instead, these multiple developers
> need to treat the foreign system as the central repository, and interface
> with it individually.
Yeah, this is unfortunate. You can at least import through a shared
system, which is pretty close to how git.git development goes (we pull
from your public repo, make changes locally, and email patches, which you
put in upstream, and we get back commits that are not the same hash we
created locally).
I think it might be possible to do something where the synchronization
point has a list of authoritative commit-swaps, where it can tell the
multiple developers: "commit Y is really the same thing as commit X; they
have the same tree, and their parents Y1..Yn are the same as X1..Xn
(either based on the same criterion applied recursively, or having
identical hashes)". This list of commit-swaps allows the developers to be
comfortable with trivial rebases (in a commit Z with X as a parent, make a
commit Z' with Y replacing X and no other changes, and replace Z with Z'
in refs and other commits). Of course, this depends on being able to get
the foreign system to agree on both complete content and history topology,
but otherwise we kind of have to throw away our history, because the
public history simply can't be like what we've made locally.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [BUG] Infinite loop in git send-email if ran non-interactively.
From: Jay Soffian @ 2009-03-25 16:23 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <76718490903250903t530983abi8a641e6b7aee6c0@mail.gmail.com>
On Wed, Mar 25, 2009 at 12:03 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Actually, FakeTerm is only triggered if Term::ReadLine is not
> available. The "going non-interactive" message is misleading in this
> case, as it has nothing to do with whether stdin is a tty or not.
Sorry, that's not true. Apparently the non-interactive test is not
working properly in this case.
j.
^ permalink raw reply
* Re: [BUG] Infinite loop in git send-email if ran non-interactively.
From: Matthieu Moy @ 2009-03-25 16:23 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490903250904q3ca9f20ak7288e49e226bb9fb@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Mar 25, 2009 at 5:36 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> Hi,
>>
>> I've been hit by c1f2aa45b (send-email: add --confirm option and
>> configuration setting) running git send-email from a cron job.
>
> BTW, can you provide the details on how you are invoking send-email?
patches=$(git format-patch [...])
[...]
git send-email --to "$to" --from "$from" $patches
> Have stdin/stdout/stderr been redirected?
stdout and stderr are redirected to a file. stdin is not (I don't know
exactly what cron sets it to).
> What arguments are you giving it? And is this Vixie cron?
The "cron" package in Debian etch (oldstable now).
Thanks,
--
Matthieu
^ permalink raw reply
* [PATCH] Guard a few Makefile variables against user environments
From: Johannes Schindelin @ 2009-03-25 16:27 UTC (permalink / raw)
To: git, gitster; +Cc: a1291762
In-Reply-To: <cover.1237998428u.git.johannes.schindelin@gmx.de>
Some variables are not initialized in the Makefile, but appended to. If
the user has those variables in her environment, it will break the
build.
The variable names were found using these commands:
$ s='[ \t]';
$ S='[^ \t]';
$ comm -23 \
<(sed -n "s/^$s*\($S*\)$s$s*+=.*/\1/p" < Makefile |
sort | uniq) \
<(sed -n "s/^$s*\($S*\)$s$s*=.*/\1/p" < Makefile |
sort | uniq)
This fixes msysGit issue 216.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Makefile | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 43a8364..d77fd71 100644
--- a/Makefile
+++ b/Makefile
@@ -263,6 +263,18 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
BASIC_CFLAGS =
BASIC_LDFLAGS =
+# Guard against environment variables
+BUILTIN_OBJS =
+BUILT_INS =
+COMPAT_CFLAGS =
+COMPAT_OBJS =
+LIB_H =
+LIB_OBJS =
+PROGRAMS =
+SCRIPT_PERL =
+SCRIPT_SH =
+TEST_PROGRAMS =
+
SCRIPT_SH += git-am.sh
SCRIPT_SH += git-bisect.sh
SCRIPT_SH += git-difftool-helper.sh
--
1.6.2.1.493.g67cf3
^ permalink raw reply related
* Re: [PATCH] avoid possible overflow in delta size filtering computation
From: Kjetil Barvik @ 2009-03-25 16:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0903250936100.26337@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 25 Mar 2009, Kjetil Barvik wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > On a 32-bit system, the maximum possible size for an object is less than
>> > 4GB, while 64-bit systems may cope with larger objects. Due to this
>> > limitation, variables holding object sizes are using an unsigned long
>> > type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
>> >
>> > When large objects are encountered, and/or people play with large delta
>> > depth values, it is possible for the maximum allowed delta size
>> > computation to overflow, especially on a 32-bit system. When this
>> > occurs, surviving result bits may represent a value much smaller than
>> > what it is supposed to be, or even zero. This prevents some objects
>> > from being deltified although they do get deltified when a smaller depth
>> > limit is used. Fix this by always performing a 64-bit multiplication.
>> >
>> > Signed-off-by: Nicolas Pitre <nico@cam.org>
>>
>> I added this patch and rerun the 2 test cases form the table where
>> --depth is 20000 and 95000, and got the following result:
>>
>> --depth=20000 => file size: 19126077 delta: 73814
>> --depth=95000 => file size: 19126087 delta: 73814
>>
>> So, it seems that this patch almost fixed the issue. But notice that
>> the pack file was 10 bytes larger for the --depth=95000 case.
>>
>> I made a small perl script to compare the output from 'git verify-pack
>> -v' of the 2 idx/pack files, and found the following difference(1)
>> (first line from --depth=20000 case, second from --depth=95000):
>>
>> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 9 19 18921247 731 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d
>> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 20 29 18921247 730 12e560f7fb28558b15e3a2008fba860f9a4b2222
>
> OK. Apparently, a different base object for that one delta was chosen
> between those two runs.
>
> Is your machine SMP?
kjetil ~$ uname -a
Linux localhost 2.6.28.4 #26 SMP PREEMPT Tue Feb 10 17:07:14 CET 2009
i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
-- kjetil
^ permalink raw reply
* warn_unused_result problem, and a solution
From: Johannes Schindelin @ 2009-03-25 16:34 UTC (permalink / raw)
To: git
Hi,
when I updated one of my Ubuntu machine's packages, it automatically
updated libc6 to a newer version.
I was in for a surprise: the output is littered with spurious warnings
about lack of handling of return values to all kinds of functions.
It took me a while to figure out what had happened, and it took me even
longer to find this:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/305176
Apparently, the good Ubuntu people think it is fine that people who
compile stuff themselves are drowned in warnings.
To make a long story less long: I have this in my config.mak for now:
CFLAGS += -U_FORTIFY_SOURCE
Hopefully, this helps others, too.
Ciao,
Dscho
^ permalink raw reply
* .git/index
From: Jon Smirl @ 2009-03-25 17:16 UTC (permalink / raw)
To: Git Mailing List
I pushed a repo up to my server. I want to view this repo with gitweb
but it is not visible in my project list like my other projects. I
suspect this is because the newly pushed repo is missing .git/index. I
ran update-server-info on the repo and that didn't create .git/index.
What command builds this index?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: Irene Ros @ 2009-03-25 17:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: John Tapsell, git
In-Reply-To: <alpine.LNX.1.00.0903242304530.19665@iabervon.org>
Hi Daniel,
Thank you for the explanation, doing a git fetch actually did do the
trick although I still don't quite see the difference between
git pull origin myBranch
and
git fetch
When I push to origin myBranch it's clear that it actually pushes my
changes to our remote repository since others can then pull and get
them. So is it the case that:
git push ==> actual remote repository
while
git pull <== local copy of remote repository for this branch ?
In that case why is it that in all branches that I have, besides this
one, doing a 'git pull origin whateverBranch' actually pulls from the
remote branch and not the local copy? This case has been quite unique
given dozens of branches that we constantly switch to and from. We've
never actually used (or clearly saw the need for) git fetch until now.
Thank you so much for your insight, it's very helpful in understanding
these subtleties.
-- Irene
On Tue, Mar 24, 2009 at 11:19 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 24 Mar 2009, Irene Ros wrote:
>
>> Hi All,
>>
>> Thank you for the good advice. I may be the case I am somehow misusing
>> git... I couldn't resolve the issue and so I created a new project off
>> of the same repo. Switching to the same branch in question yielded an
>> even stranger result: In this new project, the commits were there (I
>> could see them in git log and in git log origin/myBranch) whereas in
>> the previous older project I did not... does that make sense? Our
>> origin branches are located on a central server so can't quite figure
>> out why viewing the log of the same remote branch from two different
>> projects would yield different results. Any suggestions? At this
>> point, I'm just really curious.
>
> origin/* is a copy of what git saw the last time it talked to the remote
> repository. This may be different from what the remote repository now
> contains. (Also, there are a few cases in which pushing to a remote
> repository doesn't count as talking to it; fetching with a configured
> remote always counts.) The local copies are handy for being able to
> compare the work you've done locally with what is in the remote repository
> when you don't necessarily have a network connection, don't expect
> constant updates remotely, or don't want to be distracted by remote
> changes. For example, you might have your local work, and you might want
> to compare it with what other people have done. You want to avoid having
> additional changes that other people make while you're making this
> comparison show up in the middle.
>
> Of course, when you make a new clone of the same repository, this clone
> will look at the repository when you make the clone, and will have the
> latest information (as of that time).
>
> In order to get an existing repository to see changes to a remote
> repository, use "git fetch <remote>" (you can leave off the <remote> to
> get the oone you gave to "clone", which is configured as "origin").
> Alternatively, you can use "git pull" to get the data and also merge it in
> the same command, which may or may not be a useful addition depending on
> your workflow.
>
> -Daniel
> *This .sig left intentionally blank*
>
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: Santi Béjar @ 2009-03-25 17:32 UTC (permalink / raw)
To: Irene Ros; +Cc: Daniel Barkalow, John Tapsell, git
In-Reply-To: <7001b7a00903251023r1ce5cc0dnb29b7f9379408c42@mail.gmail.com>
2009/3/25 Irene Ros <imirene@gmail.com>:
> Hi Daniel,
>
> Thank you for the explanation, doing a git fetch actually did do the
> trick although I still don't quite see the difference between
> git pull origin myBranch
This fetches myBranch from origin, and merges with the current branch.
> and
> git fetch
This fetches and *saves* the configured branches (all by default) from
the configured remote (origin by default).
>
> When I push to origin myBranch it's clear that it actually pushes my
> changes to our remote repository since others can then pull and get
> them. So is it the case that:
>
> git push ==> actual remote repository
> while
> git pull <== local copy of remote repository for this branch ?
I don't know if I understand correctly, but pull always uses the
branches from the remote repository, but depending on how you call it
it will also update the local copy (origin/*).
HTH,
Santi
^ permalink raw reply
* Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.
From: Junio C Hamano @ 2009-03-25 17:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903251050430.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> > +'import'::
>> > + Takes the remote name and a list of names of refs, and imports
>> > + whatever it describes, by outputting it in git-fast-import
>> > + format.
>> > +
>> > +'export'::
>> > + Sends the branch to the foreign system and reimports it in
>> > + fast-import format.
>>
>> The above two description is inconsistent; say "git-fast-import" for both.
>
> Not "fast-import" for both, now that other systems have adopted the format
> as input?
I did not mean anything deeper than just pointing out that one sentence
calls the format "git-fast-import format" and the other one calls
"fast-import format".
^ permalink raw reply
* Re: git + eclipse on windows
From: Robin Rosenberg @ 2009-03-25 17:44 UTC (permalink / raw)
To: Native; +Cc: git
In-Reply-To: <22700038.post@talk.nabble.com>
onsdag 25 mars 2009 12:50:09 skrev Native <enc-music@narod.ru>:
>
> Hello!
>
> I try clone the repository via Eclipse plugin on Windows. After successful
> connecting and choosing of branch, I obtain such message:
>
> D:\EclipseProjects\example\exapp\:q (The filename, directory name, or volume
> label syntax is incorrect)
> D:\EclipseProjects\example\exapp\:q (The filename, directory name, or volume
> label syntax is incorrect)
>
> Help, pls
Too little input. Cannot compute.
Please tell us what the name you give to eclipse for the source, targets etc and
exactly when this message occurs. Looking into the workspace .metadata/.log
might yield useful information too.
-- robin
^ permalink raw reply
* Question: Is it possible to host a writable git repo over both http and ssh?
From: Mike Gaffney @ 2009-03-25 17:29 UTC (permalink / raw)
To: git
I am trying to setup a git repo internally at my work. I would like to
make the repo accessable via https for both read and write so that we
may access it from customer locations which don't allow anything but
https. I would also like to host it via SSH because that protocol is
much faster. I know that when you push with http it runs 'git
update-server-info', would I have to make the ssh pushes do the same?
Will this even work?
Thanks,
Mike Gaffney
^ permalink raw reply
* Re: .git/index
From: Julian Phillips @ 2009-03-25 17:52 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910903251016n117c37fdp94f91b2862cd7bf@mail.gmail.com>
On Wed, 25 Mar 2009, Jon Smirl wrote:
> I pushed a repo up to my server. I want to view this repo with gitweb
> but it is not visible in my project list like my other projects. I
> suspect this is because the newly pushed repo is missing .git/index. I
> ran update-server-info on the repo and that didn't create .git/index.
> What command builds this index?
.git/index is the default name used for what is commonly referred to as
the staging area these days. It's only needed when you have a work tree,
and is expected to be absent from a bare repository.
A more likely cause for a repository to not be picked up by gitweb is
file permissions.
--
Julian
---
<MFGolfBal> rit/ara: There's something really demented about UNIX
underwear...
^ permalink raw reply
* Re: .git/index
From: Junio C Hamano @ 2009-03-25 18:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910903251016n117c37fdp94f91b2862cd7bf@mail.gmail.com>
The index is associated with the work tree. Since gitweb is supposed to
read and show the history and never the work tree state, it would be a bug
if it required it to operate.
^ permalink raw reply
* Re: [PATCH 2/5] Document details of transport function APIs
From: Junio C Hamano @ 2009-03-25 18:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903251142470.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> > + * If, in the process, the transport determines that the
>> > + * remote side actually responded to the push by updating the
>> > + * ref to a different value, the transport should modify the
>> > + * new_sha1 in the ref. (Note that this is a matter of the
>> > + * remote accepting but rewriting the change, not rejecting it
>> > + * and reporting that a different update had already taken
>> > + * place)
>> > + **/
>>
>> It this even a sane thing to allow? How would it interact with the
>> "pretend we immediately turned around and fetched them into the remote
>> tracking branches" local updates we usually do?
>
> We already allow a git server to rewrite refs with a hook when it gets
> them, and we record the pre-rewriting value. This allows the transport to
> propagate the post-rewriting value back (if it can get it), and we'd
> update the tracking branches with what the server actually did instead of
> what we asked it to (i.e., we do what we would do if we really did turn
> around and fetch them immediately).
But how are you guaranteeing that objects necessary to complete the
history the remote end re-written are already available on the local end?
Do you have a reverse object transfer phase now in send-pack protocol?
Otherwise I am afraid that you are corrupting the local repository.
^ permalink raw reply
* Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.
From: Junio C Hamano @ 2009-03-25 18:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903251050430.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Wed, 25 Mar 2009, Junio C Hamano wrote:
>
>> This seems to follow the model of git-svn in that we treat our history as
>> throw-away, export the history and give the authority to the other system
>> by discarding and replacing our history with whatever the other end gives
>> back to us by re-importing. Because git is more flexible than anything
>> else, we could afford to do so, but I wonder if it is the right model and
>> mentality.
> ...
> But, as a general principle, the reason a git developer would push to a
> non-git remote repository is because the remote repository is
> authoritative. I don't think it makes sense to have an environment
> where the authoritative history is in git, but people are sharing it
> through a bzr server (even if the bzr server can accurately represent
> the git history).
Suppose a project used to use subversion, but it migrated to git (not an
unheard-of scenario these days, I hope). The git repository now is the
authoritative one, all the development happens on this side.
But in order to help:
- people who have established their workflow to follow the project
(e.g. not necessarily contributing anything back, but just doing
regular "svn update");
- people who have leftover local changes from the subversion days; and
- other project infrastracture (e.g. trac) that the project hasn't
managed to interface to the new git repository yet;
the project decides to keep feeding recent updates to the subversion
repository that used to be authoritative, even though it is now declared
read-only (i.e. the only update comes from the git end).
My understanding is that the above scenario would not work if git-vcs-svn
rewrites commits when git exports to svn, and existing git-svn two-way
interface using its "dcommit" may have exactly the same issue.
The reason I brought this up was to involve people who have already faced
this issue with git-svn in the discussion to see if we can avoid it by
doing somethink similar to clever tricks they are using in their git-svn
workflow, if there are some. Perhaps your paragraph below may be one of
those clever tricks, but there may be others.
> I think it might be possible to do something where the synchronization
> point has a list of authoritative commit-swaps, where it can tell the
> multiple developers: "commit Y is really the same thing as commit X; they
> have the same tree, and their parents Y1..Yn are the same as X1..Xn
> (either based on the same criterion applied recursively, or having
> identical hashes)". This list of commit-swaps allows the developers to be
> comfortable with trivial rebases (in a commit Z with X as a parent, make a
> commit Z' with Y replacing X and no other changes, and replace Z with Z'
> in refs and other commits). Of course, this depends on being able to get
> the foreign system to agree on both complete content and history topology,
> but otherwise we kind of have to throw away our history, because the
> public history simply can't be like what we've made locally.
^ permalink raw reply
* Re: [PATCH 3/5] Add option for using a foreign VCS
From: Junio C Hamano @ 2009-03-25 18:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903251042280.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> > - if (!prefixcmp(url, "rsync:")) {
>> > + if (remote && remote->foreign_vcs) {
>> > + } else if (!prefixcmp(url, "rsync:")) {
>>
>> if (...) {
>> ; /* empty */
>> } else ...
>
> I don't think I've ever tried writing an empty block for git before. It's
> braces containing a semicolon and comment? (Of course, the reason I wrote
> this one this way is so that the next patch could put two "+" lines in
> there and have no "-" lines)
Wasn't a serious "this has to be the final style" suggestion, but more
about "what do you mean by this? are you going to add more code here in
the later round?" question.
^ permalink raw reply
* Re: .git/index
From: Jon Smirl @ 2009-03-25 18:03 UTC (permalink / raw)
To: Julian Phillips; +Cc: Git Mailing List
In-Reply-To: <alpine.LNX.2.00.0903251749270.11062@reaper.quantumfyre.co.uk>
On Wed, Mar 25, 2009 at 1:52 PM, Julian Phillips
<julian@quantumfyre.co.uk> wrote:
> On Wed, 25 Mar 2009, Jon Smirl wrote:
>
>> I pushed a repo up to my server. I want to view this repo with gitweb
>> but it is not visible in my project list like my other projects. I
>> suspect this is because the newly pushed repo is missing .git/index. I
>> ran update-server-info on the repo and that didn't create .git/index.
>> What command builds this index?
>
> .git/index is the default name used for what is commonly referred to as the
> staging area these days. It's only needed when you have a work tree, and is
> expected to be absent from a bare repository.
>
> A more likely cause for a repository to not be picked up by gitweb is file
> permissions.
It needed to be added to the gitweb projects file.
>
> --
> Julian
>
> ---
> <MFGolfBal> rit/ara: There's something really demented about UNIX
> underwear...
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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