* from local to github
From: sigbackup @ 2009-08-31 20:46 UTC (permalink / raw)
To: git
Hello guys,
I'm a git newbie and I'm looking for some good references about using
git locally (on Mac) and synchronize my repositories to my github
account and from there to a Win2003 production server.
Can anyone help me with this?
Thanks and have a great day.
Sig
^ permalink raw reply
* from local to github
From: sigbackup @ 2009-08-31 20:46 UTC (permalink / raw)
To: git
Hello guys,
I'm a git newbie and I'm looking for some good references about using
git locally (on Mac) and synchronize my repositories to my github
account and from there to a Win2003 production server.
Can anyone help me with this?
Thanks and have a great day.
Sig
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Alex Riesen @ 2009-08-31 21:27 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Michael Wookey, git
In-Reply-To: <fabb9a1e0908310529q4c601a73t671cc2813dfdb1a3@mail.gmail.com>
On Mon, Aug 31, 2009 at 14:29, Sverre Rabbelier<srabbelier@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 04:21, Michael Wookey<michaelwookey@gmail.com> wrote:
>> Provide a dummy variable to keep the compiler happy.
>
> Should we not instead check the value?
Why? It is endp (end of the parsed number) we're interested in.
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Sverre Rabbelier @ 2009-08-31 21:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael Wookey, git
In-Reply-To: <81b0412b0908311427t5b4a24ffg1d7d272669476117@mail.gmail.com>
Heya,
On Mon, Aug 31, 2009 at 23:27, Alex Riesen<raa.lkml@gmail.com> wrote:
> Why? It is endp (end of the parsed number) we're interested in.
Ah, my bad, I hadn't checked stroul's signature, sorry for the noise.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Jeff King @ 2009-08-31 22:47 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Sverre Rabbelier, Matthieu Moy, Sitaram Chamarty, git
In-Reply-To: <20090831201911.GA24989@atjola.homenet>
On Mon, Aug 31, 2009 at 10:19:11PM +0200, Björn Steinbrink wrote:
> I see the problem here, too.
>
> doener@atjola:~ $ (mkdir a; cd a; git init)
> Initialized empty Git repository in /home/doener/a/.git/
>
> doener@atjola:~ $ git clone localhost:a b
> Initialized empty Git repository in /home/doener/b/.git/
> warning: You appear to have cloned an empty repository.
> fatal: The remote end hung up unexpectedly
>
> doener@atjola:~ $ ssh localhost git --version
> git version 1.6.4.2.236.gf324c
OK, it is definitely not about mixed versions, and it is definitely
reproducible, even without ssh. The local clone optimization manages to
avoid it, but you can see it with:
git clone file://$PWD/a b
It also happens with git://, except that it is the _remote_ side
producing the message, so git-daemon gets "the remote end hung up
unexpectedly" on its stderr channel.
AFAICT, this problem goes back to v1.6.2, the first version which
handled empty clones. So I blame Sverre. ;)
-Peff
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Sverre Rabbelier @ 2009-08-31 22:50 UTC (permalink / raw)
To: Jeff King; +Cc: Björn Steinbrink, Matthieu Moy, Sitaram Chamarty, git
In-Reply-To: <20090831224749.GA24190@sigill.intra.peff.net>
Heya,
2009/9/1 Jeff King <peff@peff.net>:
> AFAICT, this problem goes back to v1.6.2, the first version which
> handled empty clones. So I blame Sverre. ;)
Eep :(. Any idea what is going on?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Michael Wookey @ 2009-08-31 23:31 UTC (permalink / raw)
To: Alex Riesen, Junio C Hamano; +Cc: Sverre Rabbelier, git
In-Reply-To: <81b0412b0908311427t5b4a24ffg1d7d272669476117@mail.gmail.com>
2009/9/1 Alex Riesen <raa.lkml@gmail.com>:
> On Mon, Aug 31, 2009 at 14:29, Sverre Rabbelier<srabbelier@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 04:21, Michael Wookey<michaelwookey@gmail.com> wrote:
>>> Provide a dummy variable to keep the compiler happy.
>>
>> Should we not instead check the value?
>
> Why? It is endp (end of the parsed number) we're interested in.
Good point, perhaps the commit message should mention why we don't
bother checking the return value. Something like this maybe?
-- >8 --
gcc 4.3.3 (Ubuntu 9.04) warns that the return value of strtoul() was not
checked by issuing the following notice:
warning: ignoring return value of ‘strtoul’, declared with attribute
warn_unused_result
The return value of strtoul() isn't used because we are only interested
in what is placed into endp. As such, provide a dummy variable to keep
the compiler happy.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
-- >8 --
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Junio C Hamano @ 2009-08-31 23:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0908311130190.28290@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Sat, 29 Aug 2009, Junio C Hamano wrote:
>
>> ..., if only to avoid confusion with our own earlier misdesigned
>> syntax git+ssh://), so the canonical syntax would be:
>
> (with the syntax <helper>+, "git+ssh://" would specify the helper "git",
> which is as good an explicit identifier of the internal handling as any)
Sure but how would you explain "ssh+git://" then ;-)?
Luckily neither is advertised in our documentation set as far as I can
tell, so I do not think it is a huge deal between + vs ::, but as Peff
says in
http://thread.gmane.org/gmane.comp.version-control.git/125615
I think the latter is probably less problematic.
With plus, a helper that talks with a Subversion repository whose native
URL is http://host/path would look like svn+http://host/path, which is
reasonable. When talking the Subversion protocol over SSH, however, the
native URL for the repository would be svn+ssh://host/path, so the URL
with helper name on our side becomes svn+svn+ssh://host/path. We could
recognize "svn+" part and implicitly pass the whole thing to svn helper
upon seeing svn+ssh://host/path, but I do not think we would want to make
the dispatcher too familiar with what the backends do. Using something
other than plus sign would avoid this issue.
> If the policy is that we're going to have "traditionally supported"
> schemes, where the internal code knows what helper supports them, I can
> fix up the series so that the curl-based helper is named "curl", and we
> can say that the check for "http://", "ftp://", and "https://" is
> recognizing traditionally-supported schemes, and we can defer coming up
> with what the syntax for the explicit handler selection is. (For that
> matter, if there's a // after the colon, it's obviously not a
> handy ssh-style location, since the second slash would do nothing)
That sounds like a sane approach to first get the "eject curl from
builtin" out the door. We might extend the dispatcher in the future by
changing "traditionally supported" criterion to "commonly used",
e.g. recognize "svn+ssh://" as something the svn helper would want to
handle, but that is a future extension we do not have to address right
now.
>> After you explained this in the thread (I think for the second time), I
>> see no problem with this, except that I think to support this we should
>> notice and raise an error when we see a remote has both vcs and url,
>> because the only reason we would want to say "vcs", if I recall your
>> explanation correctly, is that such a transport does not have the concept
>> of URL, i.e. a well defined single string that identifies the repository.
>
> A user who mostly uses Perforce as a foreign repositories but is using a
> SVN repo on occasion might want to use "vcs" regardless, but I agree with
> forcing the helper to use a different option for the case of a URL that
> git isn't going to look at. That is, you ought to be able to use:
>
> [remote "origin"]
> vcs = svn
> (something) = http://svn.savannah.gnu.org/...
>
> But "(something)" shouldn't be "url".
I actuallly do not have a strong opinion on this one either way. I said
"I think" when I suggested it, but it was actually without thinking too
deeply, hoping that you would come up with a good counter-argument.
For example, if we envision that for most of the helpers there will be one
primary string that identifies the repository, but the primary string
alone is not enough for the helper without some auxiliary information, it
would be natural to use remote.$name.url for that primary string. I do
not know if that would be the case, but I was hoping that you would have a
better intuition[*1*], as you have thought this topic through a lot longer
and deeper than I have. So I'd rather leave the decision on that "no
vcs/url at the same time restriction" up to you. It is in general easier
to start more strict and then loosen the restiction later, than the other
way around, when we cannot decide, though.
Thanks.
[Footnote]
*1* What I mean by intuition is that you do not have to have the right
answer backed by research _now_, but have a good guess as to what the
right answer would be.
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Junio C Hamano @ 2009-08-31 23:36 UTC (permalink / raw)
To: Tom Werner
Cc: Jakub Narebski, Johan Sorensen, Jeff King, Tom Preston-Werner,
git
In-Reply-To: <12c267e40908311150n2aad598aw978c4691c27ac0fa@mail.gmail.com>
Tom Werner <mojombo@gmail.com> writes:
> ... I'd be happy
> with the previous incarnation of the post-upload-pack that simply
> sends the HAVEs and WANTs.
Thanks. This settles the biggest worry I had.
The worry was not about "do we feed clone/fetch info?", but was about
getting a complaint "Now, these changes to feed info from standard input
does not help anybody but forces us to update our hooks for no good
reason" from you guys ;-).
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-31 23:42 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87y6p08lz5.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> --patch:
> -p::
> In a modified work tree, choose interactively which patch hunks to
> add. This gives a change to review the difference between the
> index and the work before adding modified contents to the index.
Sounds sensible. You may want to be even more direct and succinct, e.g.
Interactively choose hunks of patch between the index and the work
tree and add them to the index.
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Junio C Hamano @ 2009-08-31 23:42 UTC (permalink / raw)
To: Michael Wookey; +Cc: git
In-Reply-To: <d2e97e800908310421u7de8ae58o361bd64a026384bf@mail.gmail.com>
Michael Wookey <michaelwookey@gmail.com> writes:
> gcc 4.3.3 (Ubuntu 9.04) warns that the return value of strtoul() was not
> checked by issuing the following notice:
>
> warning: ignoring return value of ‘strtoul’, declared with attribute
> warn_unused_result
>
> Provide a dummy variable to keep the compiler happy.
>
> Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
> ---
> fast-import.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index 7ef9865..1386e75 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1744,10 +1744,11 @@ static int validate_raw_date(const char *src,
> char *result, int maxlen)
> {
> const char *orig_src = src;
> char *endp;
> + unsigned long int unused;
>
> errno = 0;
>
> - strtoul(src, &endp, 10);
> + unused = strtoul(src, &endp, 10);
Isn't this typically done by casting the expression to (void)?
Otherwise a clever compiler has every right to complain "the variable
unused is assigned but never used."
^ permalink raw reply
* Re: [PATCH] git-submodule and --upload-pack
From: Junio C Hamano @ 2009-08-31 23:51 UTC (permalink / raw)
To: Giulio Eulisse; +Cc: git
In-Reply-To: <9D7140EC-EAFD-4408-93E3-0E756BA363DA@cern.ch>
Giulio Eulisse <Giulio.Eulisse@cern.ch> writes:
> There was a thread a while ago aboyt having --upload-pack support for
> git-submodule.
>
> Given that there was no followup (as far as I can tell) and I needed
> pretty much
> the same functionality I ported Jason's patch to work on top of 1.6.4.2.
Thanks.
Can you point at the original patch with a usable commit log message, in
the gmane archive (i.e. http://thread.gmane.org/...) if possible? I
do not think we have that patch queued anywhere even in 'pu'.
Given that it looks like a new feature, I do not think it would be
appropriate for any of the future 1.6.4.X series, but if it is useful we
may want to have it in the upcoming 1.6.5 release.
> Comments?
See below.
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-
> submodule.txt
The patch is linewrapped and will not be applicable. But I'll comment on
the contents to save a round-trip.
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index 5daf750..bf982a6 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -30,6 +30,14 @@ submodule.<name>.path::
> submodule.<name>.url::
> Defines an url from where the submodule repository can be cloned.
>
> +submodule.<name>.receivepack::
> + The default program to execute on the remote side when pushing. See
> + option \--receive-pack of linkgit:git-push[1].
> +
> +submodule.<name>.uploadpack::
> + The default program to execute on the remote side when fetching. See
> + option \--upload-pack of linkgit:git-fetch-pack[1].
This placement of description in the documentation and variables in the
namespace quite sane, as these are properties of the remote site, and they
belong together with submodule.<name>.url.
> @@ -53,12 +60,16 @@ Consider the following .gitmodules file:
>
> [submodule "libbar"]
> path = include/bar
> - url = git://bar.com/git/lib.git
> + url = ssh://bar.com/~/git/lib.git
> + uploadpack = /home/you/bin/git-upload-pack-wrapper
> + receivepack = /home/you/bin/git-receive-pack-wrapper
> ...
> +For `libbar`, packs are retrieved and stored via the upload and receive
> +wrappers, respectively.
Using a custom wrapper in this example feels very misleading. The option
is primarily meant as a workaround for a broken or hard-to-modify sshd
settings that does not allow you to include the directory you installed
upload-pack/receive-pack to the PATH environment when the ssh session is
not interactive.
> @@ -97,13 +99,30 @@ module_clone()
> test -e "$path" &&
> die "A file already exist at path '$path'"
>
> + uploadpackCmd=""
> +
> + if test "$uploadpack"
> + then
> + uploadpackCmd="--upload-pack $uploadpack"
Can the value of uploadpack contain a shell IFS? This is a rhetorical
question---read on.
> + fi
> +
> if test -n "$reference"
> then
> - git-clone "$reference" -n "$url" "$path"
> + git-clone $uploadpackCmd "$reference" -n "$url" "$path"
Without using uploadpackCmd and risking to trash IFS characters in the
variable, you can do something like:
git clone ${uploadpack+--upload-pack "$uploadpack"} ...
I would prefer the code not to set variable "uploadpack" when nothing is
specified, instead of setting it to an empty string like this patch does,
but if you are going to use an empty string as a signal that no uploadpack
is specified, then you would need a colon between 'k'and '+' in the above.
> @@ -738,6 +801,18 @@ cmd_sync()
> remote=$(get_default_remote)
> say "Synchronizing submodule url for '$name'"
> git config remote."$remote".url "$url"
> + uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
> + receivepack=$(git config -f .gitmodules
> submodule."$name".receivepack)
> + if test "$uploadpack"
> + then
> + git config submodule."$name".uploadpack "$uploadpack" ||
> + echo " Warn: Failed to set uploadpack for
> $url' in submodule path '$name'."
> + fi
> + if test "$receivepack"
> + then
> + git config submodule."$name".receivepack "$receivepack" ||
> + echo " Warn: Failed to set receivepack
> for '$url' in submodule path '$name'."
> + fi
> )
I do not agree with this part, nor what the "cmd_init" does.
Having URL/uploadpack/receivepack 3-tuple in the tracked .gitmodules is
sensible, as that is how the project expresses its recommendations to
people who clone the toplevel project.
However, after the top-level project is cloned and the submodules are
populated in the work tree of the person who cloned, I think these values
should be propagated to $path/.git/config, i.e. the configuration file of
the submodule checkout.
Inside cmd_update(), there is this code snippet:
if test -z "$nofetch"
then
(unset GIT_DIR; cd "$path" &&
git-fetch) ||
die "Unable to fetch in submodule path '$path'"
fi
And the patch does not touch it. For this git-fetch to honour the custom
uploadpack your user configured, remote.origin.uploadpack variable in the
configuration file of the submodule checkout needs to be updated, because
this fetch will not (and should not) look at the configuration file of the
superproject.
You _could_ also copy them to submodule.$name.$var of the top-level
project if you really wanted to, but I do not think doing so serves any
useful purpose.
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Michael Wookey @ 2009-08-31 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxb7y2h3.fsf@alter.siamese.dyndns.org>
2009/9/1 Junio C Hamano <gitster@pobox.com>:
> Michael Wookey <michaelwookey@gmail.com> writes:
>
>> gcc 4.3.3 (Ubuntu 9.04) warns that the return value of strtoul() was not
>> checked by issuing the following notice:
>>
>> warning: ignoring return value of ‘strtoul’, declared with attribute
>> warn_unused_result
>>
>> Provide a dummy variable to keep the compiler happy.
>>
>> Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
>> ---
>> fast-import.c | 5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/fast-import.c b/fast-import.c
>> index 7ef9865..1386e75 100644
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -1744,10 +1744,11 @@ static int validate_raw_date(const char *src,
>> char *result, int maxlen)
>> {
>> const char *orig_src = src;
>> char *endp;
>> + unsigned long int unused;
>>
>> errno = 0;
>>
>> - strtoul(src, &endp, 10);
>> + unused = strtoul(src, &endp, 10);
>
> Isn't this typically done by casting the expression to (void)?
I originally tried that - the compiler still complains.
> Otherwise a clever compiler has every right to complain "the variable
> unused is assigned but never used."
I get no other warnings, so does that make gcc less than clever? ;-)
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Jeff King @ 2009-09-01 1:08 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Björn Steinbrink, Matthieu Moy, Sitaram Chamarty, git
In-Reply-To: <fabb9a1e0908311550r1b549eb2k2df65c188a0ea6a0@mail.gmail.com>
On Tue, Sep 01, 2009 at 12:50:25AM +0200, Sverre Rabbelier wrote:
> 2009/9/1 Jeff King <peff@peff.net>:
> > AFAICT, this problem goes back to v1.6.2, the first version which
> > handled empty clones. So I blame Sverre. ;)
>
> Eep :(. Any idea what is going on?
Yeah. We call upload-pack on the remote side, realize there are no refs,
and then we just stop talking. Meanwhile upload-pack is waiting for a
packet to say "these are the refs that I want". So the client really
needs to send an extra packet saying "list of refs is finished".
The patch below seems to work for me, but I'm a little concerned how it
might impact other transports. It actually calls the transport's
fetch method when we have no refs that we want. So each transport must
recognize that we want zero refs and do the appropriate thing. In this
case, for the git protocol, we want to:
- do a packet_flush to signal "no more refs" to the remote side
- be aware that we might have zero refs and avoid establishing a new
connection in that case
Other transports might need to be tweaked similarly, but I don't have
time to test at the moment.
diff --git a/builtin-clone.c b/builtin-clone.c
index 0d2b4a8..f198c01 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -515,8 +515,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_upload_pack);
refs = transport_get_remote_refs(transport);
- if(refs)
- transport_fetch_refs(transport, refs);
+ transport_fetch_refs(transport, refs);
}
if (refs) {
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 629735f..04a3776 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -803,6 +803,8 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
nr_heads = remove_duplicates(nr_heads, heads);
if (!ref) {
packet_flush(fd[1]);
+ if (!nr_heads)
+ return NULL;
die("no matching remote head");
}
ref_cpy = do_fetch_pack(fd, ref, nr_heads, heads, pack_lockfile);
diff --git a/transport.c b/transport.c
index f2bd998..25e8946 100644
--- a/transport.c
+++ b/transport.c
@@ -512,6 +512,8 @@ static int fetch_refs_via_pack(struct transport *transport,
origh[i] = heads[i] = xstrdup(to_fetch[i]->name);
if (!data->conn) {
+ if (!nr_heads)
+ return 0;
connect_setup(transport, 0, 0);
get_remote_heads(data->fd[0], &refs_tmp, 0, NULL, 0, NULL);
}
^ permalink raw reply related
* Re: A note from the maintainer: Follow-up questions (MaintNotes)
From: Junio C Hamano @ 2009-09-01 1:38 UTC (permalink / raw)
To: David Chanters; +Cc: git
In-Reply-To: <ac3d41850908301519s2cf8a45auf11fb4c9285c0cb5@mail.gmail.com>
David Chanters <david.chanters@googlemail.com> writes:
> I'd often wondered when I have read various posts of the git mailing
> list on gmane, just how it is I am supposed to track:
>
> dc/some-topic-feature
>
> ... Junio, are these topic branches ones you actively have somewhere
> in your own private checkout? Yes, I appreciate that when I read a
> given post to the mailing list, you or other people will sometimes
> make reference to these topic branches, but what do I do if I am
> interested in finding out about one of them?
$ git log --oneline --first-parent origin/master..origin/pu
would be a handy way to view where the tip of each branch is.
a71f64a Merge branch 'pk/import-dirs' into pu
ce6cd39 Merge branch 'jh/cvs-helper' into pu
...
2178d02 Merge branch 'jc/log-tz' into pu
...
927d129 Merge branch 'lt/approxidate' into jch
35ada54 Merge branch 'tr/reset-checkout-patch' into jch
d82f86c Merge branch 'db/vcs-helper' (early part) into jch
So if you for example happen to be interested in jc/log-tz topic,
you would do something like:
$ git checkout -b jc/log-tz 2178d02^2
$ git log -p master..
to check out, and view what changes the topic introduces.
Some hawk-eyed people may have already noticed this, but I recently
updated the script I used to maintain the "What's cooking" messages, and
the entries come with when and at what commit each part of the series has
been merged to 'next'. For example, the lt/approxidate topic reads like
this:
* lt/approxidate (2009-08-30) 6 commits
(merged to 'next' on 2009-08-30 at e016e3d)
+ fix approxidate parsing of relative months and years
+ tests: add date printing and parsing tests
+ refactor test-date interface
+ Add date formatting and parsing functions relative to a given time
(merged to 'next' on 2009-08-26 at 62853f9)
+ Further 'approxidate' improvements
+ Improve on 'approxidate'
Time flows from bottom to top in this output, so this tells us that the
first two patches in the series has been in 'next' for five days or so,
and the tests and a fix in 4 follow-up patches came later, merged to
'next' yesterday. You can use
$ git checkout -b lt/approxidate e016e3d^2
to get at its tip.
> ..., how do you go about creating and
> maintaining these topic branches -- are you making heavy use of "git
> am"
Save patches from the list in mbox, review them in the mbox while fixing
trivial breakages, and finally:
$ git checkout -b ai/topic-name master
$ git am -s that.mbox
where "ai" is typically the author's initial, and topic-name names the
topic just like you would name a function. A topic typically forks from
the tip of master if it is a new feature, or a much older commit in maint
if it is a fix (and in such a case, topic-name typically begins with
a string "maint-").
> I ask because of the following snippet from "MaintNotes":
>
> The two branches "master" and "maint" are never rewound, and
> "next" usually will not be either (this automatically means the
> topics that have been merged into "next" are usually not
> rebased, and you can find the tip of topic branches you are
> interested in from the output of "git log next"). You should be
> able to safely track them.
>
> I am not sure if there's any real use-case for this, but I will ask
> anyway: is the above saying that I am able to *checkout* one of these
> topic-branches just from their presence in "next" alone? I appreciate
> that the point is somewhat moot since the topic branch has already
> been merged into "next", but I can surely see this as a really useful
> way for people to manage topic-branches in a shared environment:
> people can simply pick a topic branch out from the integrated one --
> in this case "next".
Surely, see above. And by checking out the topic alone, you can test and
enhance it in isolation.
If you come up with a follow-up patch based on one particular topic, in
other words, building on ai/topic-name created like the above example, as
opposed to building on 'next', it would be easier for me to integrate it,
too, because the way I accept a follow-up patch to a particular topic is
by doing this:
$ git checkout ai/topic-name
$ git am -s followup-mail.mbox
The result will be tested in isolation and if it is good it would be
merged to 'next' again.
$ git merge ai/topic-name
> I'm obviously missing something here -- but why is rebasing these
> existing topic branches (I assume on top of "pu") more useful than
> just merging them into "pu" -- like you do with "next"?
Somebody may send a few patches [PATCH 1/3] thru [PATCH 3/3] whose
quality is sub-par but tries to tackle a good problem. I'd queue it in
'pu'.
$ git checkout -b dc/cool-feature
$ git am -s david-chanters.mbox
$ git checkout pu
$ git merge dc/cool-feature
In a few days, people would notice that the series has a lot of room for
improvement, and offer suggestions. You would send replacement patches
based on the review. Perhaps you squashed the first two patches from the
original into one, and added another patch for test suite, and the new
series is marked as [PATCH v2 1/3] thru [PATCH v2 3/3].
In general, the early attempts of a topic that have never been merged to
'next' are not worth keeping in the public history. The original author
is free to keep them in his private tree, but there is no point in forever
keeping earlier mistakes, bugs, typos and implementation based on a flawed
design, all of which later were corrected in _my_ history.
So I would replace the whole topic with the new series.
$ git checkout dc/cool-feature
$ git reset --hard HEAD~3
$ git am -s david-chanters-v2.mbox
The whole point of replacing the contents of this topic was to get rid of
the mistakes in your earlier round, so it does not make much sense to
merge this to 'pu' without rewinding 'pu' first.
After the topic is merged to 'next', obviously I cannot sanely rewind and
rebuild it. Everything goes incremental from then on (see the earlier
example of applying followup-mail.mbox).
> If regular readers of the git mailing list wish to track this topic
> branch, can they do so from you only until it's merged into "next"?
Sorry, but I am not sure if I understand the question.
> And a related question: If you decide a given topic in pu is declared
> to "be dropped", is this done by rebasing (as you mentioned earlier)
> so as to remove any trace of the topic branch ever having been in
> "pu", or am I reading too much into "dropping" here? :)
Essentially, I keep a list of branches that are in 'next' and another list
of branches that are in 'pu'. At the end of each integration cycle, I do
a rough equivalent of:
$ git checkout next
$ git merge ..a good topic that is not fully in next..
$ git merge ..another good topic that is not fully in next..
$ make test ;# make sure next is ok
$ git branch -f pu ;# get rid of everything in pu
$ git checkout pu
$ for branch in ..the list of branches to be in pu..
do
git merge $branch || break
done
Discarding a topic from 'pu' simply means I do not merge the topic in the
last loop.
^ permalink raw reply
* Troubles building man pages
From: Brian S. Schang @ 2009-09-01 2:30 UTC (permalink / raw)
To: git
Hello:
I am having problem building the man pages for git v1.6.4.2. I am
getting the follow stream of errors: (sorry for the long lines)
> # make ASCIIDOC8=Yes man
> GIT_VERSION = 1.6.4.2
> make -C Documentation man
> make[1]: Entering directory `/raida/packages/git/Documentation'
> GEN doc.dep
> make[2]: Entering directory `/raida/packages/git'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/raida/packages/git'
> make[1]: Leaving directory `/raida/packages/git/Documentation'
> make[1]: Entering directory `/raida/packages/git/Documentation'
> make[2]: Entering directory `/raida/packages/git'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/raida/packages/git'
> ASCIIDOC git-add.xml
> XMLTO git-add.1
> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
> /raida/packages/git/Documentation/git-add.xml:2: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
> D DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
> ^
> ASCIIDOC git-am.xml
> XMLTO git-am.1
> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
> /raida/packages/git/Documentation/git-am.xml:2: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
> D DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
I have read through INSTALL and Documentation/README. I have tried to
cover all dependencies, but I suspect that I'm missing something simple.
Note that 'git' itself compiles fine and I can build the HTML pages fine
also. It seems to be the man pages that cause the problem.
Note that I am using openSUSE 11.1. I was able to build the man pages on
my older openSUSE 11.0 machine, but not any longer.
I would appreciate any advice you are willing to share.
Thank you.
--
Brian Schang
^ permalink raw reply
* Re: Troubles building man pages
From: Junio C Hamano @ 2009-09-01 2:44 UTC (permalink / raw)
To: Brian S. Schang; +Cc: git
In-Reply-To: <4A9C8750.60308@lists.schang.net>
"Brian S. Schang" <git@lists.schang.net> writes:
>> ASCIIDOC git-am.xml
>> XMLTO git-am.1
>> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
>> /raida/packages/git/Documentation/git-am.xml:2: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
>> D DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
>
> I have read through INSTALL and Documentation/README. I have tried to
> cover all dependencies, but I suspect that I'm missing something
> simple.
>
> Note that 'git' itself compiles fine and I can build the HTML pages
> fine also. It seems to be the man pages that cause the problem.
>
> Note that I am using openSUSE 11.1. I was able to build the man pages
> on my older openSUSE 11.0 machine, but not any longer.
The following was an ancient experience of mine with a different distro
but I am reasonably sure it would point you in the right direction.
http://article.gmane.org/gmane.comp.version-control.git/107387
^ permalink raw reply
* Re: A note from the maintainer: Follow-up questions (MaintNotes)
From: Jeff King @ 2009-09-01 2:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Chanters, git
In-Reply-To: <7v8wgzla02.fsf@alter.siamese.dyndns.org>
On Mon, Aug 31, 2009 at 06:38:37PM -0700, Junio C Hamano wrote:
> a71f64a Merge branch 'pk/import-dirs' into pu
> ce6cd39 Merge branch 'jh/cvs-helper' into pu
> ...
> 2178d02 Merge branch 'jc/log-tz' into pu
> ...
> 927d129 Merge branch 'lt/approxidate' into jch
> 35ada54 Merge branch 'tr/reset-checkout-patch' into jch
> d82f86c Merge branch 'db/vcs-helper' (early part) into jch
>
> So if you for example happen to be interested in jc/log-tz topic,
> you would do something like:
>
> $ git checkout -b jc/log-tz 2178d02^2
> $ git log -p master..
>
> to check out, and view what changes the topic introduces.
Another alternative: Thomas Rast wrote a handy script called
'git-resurrect' which does this for you. It's carried in the contrib/
section right now. I used it just the other day to pull out the
lt/approxidate topic branch, which I then built some follow-up patches
for. Usage is something like:
# contrib scripts aren't installed by "make install",
# so put it somewhere in your PATH
$ cp contrib/git-resurrect.sh ~/bin/git-resurrect
$ git resurrect -m lt/approxidate
** Candidates for lt/approxidate **
931e8e2 [22 hours ago] fix approxidate parsing of relative months and years
** Restoring lt/approxidate to 931e8e2 fix approxidate parsing of relative months and years
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/4] tests: add date printing and parsing tests
From: Jeff King @ 2009-09-01 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Alex Riesen, git
In-Reply-To: <20090831023015.GC5507@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 10:30:15PM -0400, Jeff King wrote:
> - We confirm that the improvements in b5373e9 and 1bddb25
> work.
Ugh. I just realized (when explaining how awesome git resurrect was in
another mail) that I managed to bungle these commit hashes (and the one
mentioned in the following patch).
What happened is that I was building on the topic branch and lazily did
a "rebase -i origin" to fix up my patches. I left the first two patches
untouched, of course, but they still ended up with new committer
information.
As my patches are merged to 'next' already, I think it is too late to
fixup the commit message. But for posterity, the correct referenced
commits are 9029055 and 36e4986.
Caveat rebaser.
-Peff
^ permalink raw reply
* Re: Improve on 'approxidate'
From: Linus Torvalds @ 2009-09-01 3:27 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20090830223558.GA29807@coredump.intra.peff.net>
On Sun, 30 Aug 2009, Jeff King wrote:
>
> This breaks relative dates like "3.months.ago", because
> approxidate_alpha needs to see the "current" date in tm (and now it sees
> -1, subtracts from it, and assumes we are just crossing a year boundary
> because of the negative). 3.years.ago is also broken, but I don't think
> 3.days.ago is.
Gaah. Thanks for noticing and the fixes. I had tested the relative modes,
but only the "fixed offset" ones (days, hours, minutes, seconds), not the
months and years cases.
Linus
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Stephen Boyd @ 2009-09-01 4:06 UTC (permalink / raw)
To: Michael Wookey; +Cc: Junio C Hamano, git
In-Reply-To: <d2e97e800908311655t553d6c4bo6ed45fe37819c1d8@mail.gmail.com>
Michael Wookey wrote:
> 2009/9/1 Junio C Hamano <gitster@pobox.com>:
>> Isn't this typically done by casting the expression to (void)?
>
> I originally tried that - the compiler still complains.
>
>> Otherwise a clever compiler has every right to complain "the variable
>> unused is assigned but never used.
>
> I get no other warnings, so does that make gcc less than clever? ;-)
I noticed this warning recently too when I upgraded my box and a flurry
of fwrite() unused warnings came up. Looks like ubuntu patches that
issue[1] by arguing it's a valid programming style to
fwrite/fflush/ferror. Perhaps this programming style could follow a
similar reasoning?
It gets better though. Commit c55fae4 (fast-import.c: stricter strtoul
check, silence compiler warning, 2008-12-21) made this change already.
Then commit eb3a9dd (Remove unused function scope local variables,
2009-03-07) came by and removed it. Unless the definition of strtoul
drops the attribute I fear we'll keep going back and forth.
-- Footnotes --
[1] https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027832.html
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Daniel Barkalow @ 2009-09-01 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbvnzhdq.fsf@alter.siamese.dyndns.org>
On Mon, 31 Aug 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Sat, 29 Aug 2009, Junio C Hamano wrote:
> >
> >> ..., if only to avoid confusion with our own earlier misdesigned
> >> syntax git+ssh://), so the canonical syntax would be:
> >
> > (with the syntax <helper>+, "git+ssh://" would specify the helper "git",
> > which is as good an explicit identifier of the internal handling as any)
>
> Sure but how would you explain "ssh+git://" then ;-)?
That's just weird, and looks wrong to me, like ssh tunnelled over the git
native protocol. I think, if we support it, it would have to be another
special case.
> Luckily neither is advertised in our documentation set as far as I can
> tell, so I do not think it is a huge deal between + vs ::, but as Peff
> says in
>
> http://thread.gmane.org/gmane.comp.version-control.git/125615
>
> I think the latter is probably less problematic.
>
> With plus, a helper that talks with a Subversion repository whose native
> URL is http://host/path would look like svn+http://host/path, which is
> reasonable. When talking the Subversion protocol over SSH, however, the
> native URL for the repository would be svn+ssh://host/path, so the URL
> with helper name on our side becomes svn+svn+ssh://host/path. We could
> recognize "svn+" part and implicitly pass the whole thing to svn helper
> upon seeing svn+ssh://host/path, but I do not think we would want to make
> the dispatcher too familiar with what the backends do. Using something
> other than plus sign would avoid this issue.
I was thinking that the dispatcher would always pass the whole thing, and
the svn helper would have to deal with svn+http:// and svn+svn:// as well
as svn+ssh://. The dispatcher shouldn't be familiar with what the backends
do, but the backends could stand to be familiar with what might be there
just to get to them. On the other hand, I don't have a good intuition for
what makes sense to users of such systems, since I've only extensively
used cvs, git, and perforce.
> > If the policy is that we're going to have "traditionally supported"
> > schemes, where the internal code knows what helper supports them, I can
> > fix up the series so that the curl-based helper is named "curl", and we
> > can say that the check for "http://", "ftp://", and "https://" is
> > recognizing traditionally-supported schemes, and we can defer coming up
> > with what the syntax for the explicit handler selection is. (For that
> > matter, if there's a // after the colon, it's obviously not a
> > handy ssh-style location, since the second slash would do nothing)
>
> That sounds like a sane approach to first get the "eject curl from
> builtin" out the door. We might extend the dispatcher in the future by
> changing "traditionally supported" criterion to "commonly used",
> e.g. recognize "svn+ssh://" as something the svn helper would want to
> handle, but that is a future extension we do not have to address right
> now.
Fair enough.
> >> After you explained this in the thread (I think for the second time), I
> >> see no problem with this, except that I think to support this we should
> >> notice and raise an error when we see a remote has both vcs and url,
> >> because the only reason we would want to say "vcs", if I recall your
> >> explanation correctly, is that such a transport does not have the concept
> >> of URL, i.e. a well defined single string that identifies the repository.
> >
> > A user who mostly uses Perforce as a foreign repositories but is using a
> > SVN repo on occasion might want to use "vcs" regardless, but I agree with
> > forcing the helper to use a different option for the case of a URL that
> > git isn't going to look at. That is, you ought to be able to use:
> >
> > [remote "origin"]
> > vcs = svn
> > (something) = http://svn.savannah.gnu.org/...
> >
> > But "(something)" shouldn't be "url".
>
> I actuallly do not have a strong opinion on this one either way. I said
> "I think" when I suggested it, but it was actually without thinking too
> deeply, hoping that you would come up with a good counter-argument.
>
> For example, if we envision that for most of the helpers there will be one
> primary string that identifies the repository, but the primary string
> alone is not enough for the helper without some auxiliary information, it
> would be natural to use remote.$name.url for that primary string. I do
> not know if that would be the case, but I was hoping that you would have a
> better intuition[*1*], as you have thought this topic through a lot longer
> and deeper than I have. So I'd rather leave the decision on that "no
> vcs/url at the same time restriction" up to you. It is in general easier
> to start more strict and then loosen the restiction later, than the other
> way around, when we cannot decide, though.
Agreed.
> Thanks.
>
> [Footnote]
>
> *1* What I mean by intuition is that you do not have to have the right
> answer backed by research _now_, but have a good guess as to what the
> right answer would be.
I don't really have a particularly good guess about the case of vcs and a
URL, because I haven't used systems that are not git and use URLs.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Style fixes, add a space after if/for/while.
From: Brian Gianforcaro @ 2009-09-01 5:35 UTC (permalink / raw)
To: git, gitster
The majority of code in core git appears to use a single
space after if/for/while. This is an attempt to bring more
code to this standard. These are entirely cosmetic changes.
Signed-off-by: Brian Gianforcaro <b.gianfo@gmail.com>
---
builtin-blame.c | 2 +-
builtin-clone.c | 2 +-
builtin-for-each-ref.c | 2 +-
builtin-pack-objects.c | 2 +-
builtin-remote.c | 4 ++--
builtin-shortlog.c | 2 +-
connect.c | 2 +-
diff.c | 2 +-
pack-redundant.c | 28 ++++++++++++++--------------
remote.c | 2 +-
upload-pack.c | 2 +-
var.c | 4 ++--
wt-status.c | 2 +-
13 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index fd6ca51..7512773 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1348,7 +1348,7 @@ static void get_ac_line(const char *inbuf, const char *what,
/*
* Now, convert both name and e-mail using mailmap
*/
- if(map_user(&mailmap, mail+1, mail_len-1, person, tmp-person-1)) {
+ if (map_user(&mailmap, mail+1, mail_len-1, person, tmp-person-1)) {
/* Add a trailing '>' to email, since map_user returns plain emails
Note: It already has '<', since we replace from mail+1 */
mailpos = memchr(mail, '\0', mail_len);
diff --git a/builtin-clone.c b/builtin-clone.c
index 0d2b4a8..991a7ae 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -515,7 +515,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_upload_pack);
refs = transport_get_remote_refs(transport);
- if(refs)
+ if (refs)
transport_fetch_refs(transport, refs);
}
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index d7cc8ca..a5a83f1 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -576,7 +576,7 @@ static void populate_value(struct refinfo *ref)
if (!prefixcmp(name, "refname"))
refname = ref->refname;
- else if(!prefixcmp(name, "upstream")) {
+ else if (!prefixcmp(name, "upstream")) {
struct branch *branch;
/* only local branches may have an upstream */
if (prefixcmp(ref->refname, "refs/heads/"))
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index c433748..c918d4b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1808,7 +1808,7 @@ static void prepare_pack(int window, int depth)
static int git_pack_config(const char *k, const char *v, void *cb)
{
- if(!strcmp(k, "pack.window")) {
+ if (!strcmp(k, "pack.window")) {
window = git_config_int(k, v);
return 0;
}
diff --git a/builtin-remote.c b/builtin-remote.c
index 008abfe..0777dd7 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -385,7 +385,7 @@ static int get_head_names(const struct ref *remote_refs, struct ref_states *stat
get_fetch_map(remote_refs, &refspec, &fetch_map_tail, 0);
matches = guess_remote_head(find_ref_by_name(remote_refs, "HEAD"),
fetch_map, 1);
- for(ref = matches; ref; ref = ref->next)
+ for (ref = matches; ref; ref = ref->next)
string_list_append(abbrev_branch(ref->name), &states->heads);
free_refs(fetch_map);
@@ -484,7 +484,7 @@ static int read_remote_branches(const char *refname,
const char *symref;
strbuf_addf(&buf, "refs/remotes/%s", rename->old);
- if(!prefixcmp(refname, buf.buf)) {
+ if (!prefixcmp(refname, buf.buf)) {
item = string_list_append(xstrdup(refname), rename->remote_branches);
symref = resolve_ref(refname, orig_sha1, 1, &flag);
if (flag & REF_ISSYMREF)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 6a3812e..4d4a3c8 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -56,7 +56,7 @@ static void insert_one_record(struct shortlog *log,
/* copy author name to namebuf, to support matching on both name and email */
memcpy(namebuf, author, boemail - author);
len = boemail - author;
- while(len > 0 && isspace(namebuf[len-1]))
+ while (len > 0 && isspace(namebuf[len-1]))
len--;
namebuf[len] = 0;
diff --git a/connect.c b/connect.c
index 76e5427..7945e38 100644
--- a/connect.c
+++ b/connect.c
@@ -513,7 +513,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
signal(SIGCHLD, SIG_DFL);
host = strstr(url, "://");
- if(host) {
+ if (host) {
*host = '\0';
protocol = get_protocol(url);
host += 3;
diff --git a/diff.c b/diff.c
index cd35e0c..e1be189 100644
--- a/diff.c
+++ b/diff.c
@@ -2691,7 +2691,7 @@ static int parse_num(const char **cp_p)
num = 0;
scale = 1;
dot = 0;
- for(;;) {
+ for (;;) {
ch = *cp;
if ( !dot && ch == '.' ) {
scale = 1;
diff --git a/pack-redundant.c b/pack-redundant.c
index 48a12bc..a3fad74 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -55,7 +55,7 @@ static inline struct llist_item *llist_item_get(void)
} else {
int i = 1;
new = xmalloc(sizeof(struct llist_item) * BLKSIZE);
- for(;i < BLKSIZE; i++) {
+ for (;i < BLKSIZE; i++) {
llist_item_put(&new[i]);
}
}
@@ -64,7 +64,7 @@ static inline struct llist_item *llist_item_get(void)
static void llist_free(struct llist *list)
{
- while((list->back = list->front)) {
+ while ((list->back = list->front)) {
list->front = list->front->next;
llist_item_put(list->back);
}
@@ -146,7 +146,7 @@ static inline struct llist_item *llist_insert_sorted_unique(struct llist *list,
if (cmp > 0) { /* we insert before this entry */
return llist_insert(list, prev, sha1);
}
- if(!cmp) { /* already exists */
+ if (!cmp) { /* already exists */
return l;
}
prev = l;
@@ -168,7 +168,7 @@ redo_from_start:
int cmp = hashcmp(l->sha1, sha1);
if (cmp > 0) /* not in list, since sorted */
return prev;
- if(!cmp) { /* found */
+ if (!cmp) { /* found */
if (prev == NULL) {
if (hint != NULL && hint != list->front) {
/* we don't know the previous element */
@@ -218,7 +218,7 @@ static inline struct pack_list * pack_list_insert(struct pack_list **pl,
static inline size_t pack_list_size(struct pack_list *pl)
{
size_t ret = 0;
- while(pl) {
+ while (pl) {
ret++;
pl = pl->next;
}
@@ -396,7 +396,7 @@ static size_t get_pack_redundancy(struct pack_list *pl)
return 0;
while ((subset = pl->next)) {
- while(subset) {
+ while (subset) {
ret += sizeof_union(pl->pack, subset->pack);
subset = subset->next;
}
@@ -427,7 +427,7 @@ static void minimize(struct pack_list **min)
pl = local_packs;
while (pl) {
- if(pl->unique_objects->size)
+ if (pl->unique_objects->size)
pack_list_insert(&unique, pl);
else
pack_list_insert(&non_unique, pl);
@@ -479,7 +479,7 @@ static void minimize(struct pack_list **min)
*min = min_perm;
/* add the unique packs to the list */
pl = unique;
- while(pl) {
+ while (pl) {
pack_list_insert(min, pl);
pl = pl->next;
}
@@ -516,7 +516,7 @@ static void cmp_local_packs(void)
struct pack_list *subset, *pl = local_packs;
while ((subset = pl)) {
- while((subset = subset->next))
+ while ((subset = subset->next))
cmp_two_packs(pl, subset);
pl = pl->next;
}
@@ -608,23 +608,23 @@ int main(int argc, char **argv)
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- if(!strcmp(arg, "--")) {
+ if (!strcmp(arg, "--")) {
i++;
break;
}
- if(!strcmp(arg, "--all")) {
+ if (!strcmp(arg, "--all")) {
load_all_packs = 1;
continue;
}
- if(!strcmp(arg, "--verbose")) {
+ if (!strcmp(arg, "--verbose")) {
verbose = 1;
continue;
}
- if(!strcmp(arg, "--alt-odb")) {
+ if (!strcmp(arg, "--alt-odb")) {
alt_odb = 1;
continue;
}
- if(*arg == '-')
+ if (*arg == '-')
usage(pack_redundant_usage);
else
break;
diff --git a/remote.c b/remote.c
index c3ada2d..4b5b905 100644
--- a/remote.c
+++ b/remote.c
@@ -1038,7 +1038,7 @@ static int match_explicit(struct ref *src, struct ref *dst,
case 0:
if (!memcmp(dst_value, "refs/", 5))
matched_dst = make_linked_ref(dst_value, dst_tail);
- else if((dst_guess = guess_ref(dst_value, matched_src)))
+ else if ((dst_guess = guess_ref(dst_value, matched_src)))
matched_dst = make_linked_ref(dst_guess, dst_tail);
else
error("unable to push to unqualified destination: %s\n"
diff --git a/upload-pack.c b/upload-pack.c
index 4d8be83..dacbc76 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -427,7 +427,7 @@ static int get_common_commits(void)
save_commit_buffer = 0;
- for(;;) {
+ for (;;) {
int len = packet_read_line(0, line, sizeof(line));
reset_timeout();
diff --git a/var.c b/var.c
index 7362ed8..a807dea 100644
--- a/var.c
+++ b/var.c
@@ -21,7 +21,7 @@ static struct git_var git_vars[] = {
static void list_vars(void)
{
struct git_var *ptr;
- for(ptr = git_vars; ptr->read; ptr++) {
+ for (ptr = git_vars; ptr->read; ptr++) {
printf("%s=%s\n", ptr->name, ptr->read(IDENT_WARN_ON_NO_NAME));
}
}
@@ -31,7 +31,7 @@ static const char *read_var(const char *var)
struct git_var *ptr;
const char *val;
val = NULL;
- for(ptr = git_vars; ptr->read; ptr++) {
+ for (ptr = git_vars; ptr->read; ptr++) {
if (strcmp(var, ptr->name) == 0) {
val = ptr->read(IDENT_ERROR_ON_NO_NAME);
break;
diff --git a/wt-status.c b/wt-status.c
index 63598ce..3395456 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -326,7 +326,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
setup_standard_excludes(&dir);
fill_directory(&dir, NULL);
- for(i = 0; i < dir.nr; i++) {
+ for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
if (!cache_name_is_other(ent->name, ent->len))
continue;
--
1.6.3.3
^ permalink raw reply related
* stash --dwim safety (was Re: What's cooking in git.git (Aug 2009, #06; Sun, 30))
From: Junio C Hamano @ 2009-09-01 5:58 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <7viqg48nxi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> [Stalled]
>
> * js/stash-dwim (2009-07-27) 1 commit.
> * tr/reset-checkout-patch (2009-08-27) 9 commits.
>
> There was a discussion on better DWIMmery for the above two topics to (1)
> forbid "git stash save --anything-with-dash" and (2) redirect with any
> option "git stash --opt" to "git stash save --opt", to keep it flexible
> and safe at the same time. I think it is a sane thing to do, but nothing
> has happened lately.
Actually, I was at fault giving up on Matthieu's patch without studying it
after seeing the phrase "this series replaces", when the two topics the
series tried to replace were already in 'next'.
It turns out that the rework was simple enough, so I did it myself. Among
his 3 patch series, an equivalent to the first one ("save -keep" can be
written as "save -k" for brevity) were already in, and the second one
(default to "save" if we see any option before command word) was unsafe
without the third one (reject unknown option to "save"), so it ended up as
a single patch that is a combination of the latter two patches.
This applies on top of tr/reset-checkout-patch branch, 14c674e (Make test
case number unique, 2009-08-27).
-- >8 --
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Tue, 18 Aug 2009 23:38:40 +0200
Subject: [PATCH] stash: simplify defaulting to "save" and reject unknown options
With the earlier DWIM patches, certain combination of options defaulted
to the "save" command correctly while certain equally valid combination
did not. For example, "git stash -k" were Ok but "git stash -q -k" did
not work.
This makes the logic of defaulting to "save" much simpler. If the first
argument begins with a '-', it is clear that there is no command word,
and we default to "save" subcommand.
This also teaches "git stash save" to reject an unknown option. This is
to keep a mistyped "git stash save --quite" from creating a stash with a
message "--quite", and this safety is more important with the new logic
to default to "save" with any option-looking argument without an explicit
comand word.
[jc: this is based on Matthieu's 3-patch series, and he takes all the
credit; if I have introduced bugs while reworking they are mine]
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-stash.txt | 1 -
git-stash.sh | 22 ++++++++++++++++++----
t/t3903-stash.sh | 11 +++++++++++
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 1c4ed41..5d4cce3 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -14,7 +14,6 @@ SYNOPSIS
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]]
-'git stash' [-p|--patch|-k|--keep-index]
'git stash' clear
'git stash' create
diff --git a/git-stash.sh b/git-stash.sh
index 9fd7289..ff71507 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -8,7 +8,6 @@ USAGE="list [<options>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: $dashless branch <branchname> [<stash>]
or: $dashless [save [-k|--keep-index] [-q|--quiet] [<message>]]
- or: $dashless [-k|--keep-index]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -146,6 +145,14 @@ save_stash () {
-q|--quiet)
GIT_QUIET=t
;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ echo "error: unknown option for 'stash save': $1"
+ usage
+ ;;
*)
break
;;
@@ -355,6 +362,13 @@ apply_to_branch () {
drop_stash $stash
}
+# The default command is "save"
+case "$1" in
+-*)
+ set "save" "$@"
+ ;;
+esac
+
# Main command set
case "$1" in
list)
@@ -406,9 +420,9 @@ branch)
apply_to_branch "$@"
;;
*)
- case $#,"$1","$2" in
- 0,,|1,-k,|1,--keep-index,|1,-p,|1,--patch,|2,-p,--no-keep-index|2,--patch,--no-keep-index)
- save_stash "$@" &&
+ case $# in
+ 0)
+ save_stash &&
say '(To restore them type "git stash apply")'
;;
*)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index e16ad93..5514f74 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -208,4 +208,15 @@ test_expect_success 'stash -k' '
test bar,bar4 = $(cat file),$(cat file2)
'
+test_expect_success 'stash --invalid-option' '
+ echo bar5 > file &&
+ echo bar6 > file2 &&
+ git add file2 &&
+ test_must_fail git stash --invalid-option &&
+ test_must_fail git stash save --invalid-option &&
+ test bar5,bar6 = $(cat file),$(cat file2) &&
+ git stash -- -message-starting-with-dash &&
+ test bar,bar2 = $(cat file),$(cat file2)
+'
+
test_done
--
1.6.4.2.295.g9bcb
^ permalink raw reply related
* Re: from local to github
From: Matthieu Moy @ 2009-09-01 6:14 UTC (permalink / raw)
To: sigbackup; +Cc: git
In-Reply-To: <48b054040908311346y853b917l44a7e5d4310501b@mail.gmail.com>
sigbackup <sigbackup@gmail.com> writes:
> Hello guys,
> I'm a git newbie and I'm looking for some good references about using
> git locally (on Mac) and synchronize my repositories to my github
> account and from there to a Win2003 production server.
github probably told you how to clone your github repo on your local
machine. Then, use "git pull" and "git push" to get changes from
github and to send your changes there.
This is very much the standard way to use Git, so I guess reading the
doc can help ;-).
--
Matthieu
^ 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