* 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
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Junio C Hamano @ 2009-03-25 18:06 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090324111645.GA6084@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> On Tue, Mar 24, 2009 at 02:13:18AM -0700, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > $ git push --dry-run sf.net
>> > warning: ...
>> > warning: You can specify what action you want to take in this case, and
>> > warning: avoid seeing this message again, by configuring 'push.default' to:
>> >...
>> > warning: 'current' : Push the current branch
>> > fatal: 'sf.net' does not appear to be a git repository
>> > fatal: The remote end hung up unexpectedly
>> >
>> > The final, most important error messages are dwarfed out by the warning
>> > that talks about setting configuration on the remote that does not even
>> > exist.
>
> I actually agree, but that final error is printed in a very ugly
> place! It would require some surgery to pause the warning until we
> figure out that sf.net is not a valid remote in the current setup.
>
> get_refs_via_connect->connect_setup->git_connect-> .. fork()s .., runs
> "sh -c git-receive-pack 'sf.net'" (which prints the first error)
> and get_remote_heads->packet_read_line->safe_read() dumps the final error
> and dies.
>
> Is there any reason why remote_get needs to return a valid remote for
> a value like "sf.net"? If it didn't, the error message would be even
> better, and not complain about a "remote end".
Yeah, you could work around by special casing colon-less ones as you
suggested, but I do not think it is worth it.
Instead of "sf.net", the example could have been
git-core.git.sourceforge.net:/gitroot/gut-core
which looks like a perfectly valid push destination, but it has a typo in
the pathname, and the remote end will hang up unexpectedly in such a case,
too. I do not think remote_get() is a wrong thing to blame; in that
codepath you simply do not know.
If you want to remove warning when we will eventually go "fatal", the way
to do so is to remember you need to issue a warning but defer it until you
actually start telling the other end in do_send_pack(), or something like
that.
I do not think we would want nor need to go that route. This warning is
about a local configuration that applies to _all_ remotes, and setting the
configuration once will squelch it for future push to any remotes. Giving
the warning even for an _incorrect_ remote is not wrong per-se.
Issuing the warning at first looked incorrect to me, but it warns exactly
about what the patch that added the warning messages wanted to warn about:
If you did not misspell the name of the remote or the URL, you would
have triggered the default "matching refs" semantics, but you may not
have meant to do so, hence we are warning. If you want to change the
default, here is how. If you find this message irritating, you can
squelch it this way.
In this particular case, I _did_ want the default matching refs semantics,
so it was irritating whether I had the last two "fatal" lines or not. But
the point of your patch was to help new people for the cost of irritating
people like me (once), so...
^ permalink raw reply
* reverting initial commit
From: Pascal Obry @ 2009-03-25 18:12 UTC (permalink / raw)
To: git list
Starting a new project I create a new repo and added some files for the
initial revision of the project, something like:
mkdir repo.git
cd repo.git
git init
touch file
git add file
git ci -m "initial revision"
Now one file was not meant to be committed, I wanted to revert this commit:
git reset HEAD^
fatal: ambiguous argument 'HEAD^': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
I understand that HEAD^ does not exist, is there a way to do that?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ 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