* Re: [PATCHv6] Add contrib/credentials/netrc with GPG support
From: Jeff King @ 2013-02-08 6:18 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: Junio C Hamano, git
In-Reply-To: <876226p97h.fsf_-_@lifelogs.com>
On Tue, Feb 05, 2013 at 07:38:58PM -0500, Ted Zlatanov wrote:
> Add Git credential helper that can parse netrc/authinfo files.
>
> This credential helper supports multiple files, returning the first one
> that matches. It checks file permissions and owner. For *.gpg files,
> it will run GPG to decrypt the file.
>
> Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
> + # the following check is copied from Net::Netrc, for non-GPG files
> + # OS/2 and Win32 do not handle stat in a way compatable with this check :-(
s/compatable/compatible/
You mention os/2 and Win32 here, but the check has more:
> + unless ($gpgmode || $options{insecure} ||
> + $^O eq 'os2'
> + || $^O eq 'MSWin32'
> + || $^O eq 'MacOS'
> + || $^O =~ /^cygwin/) {
Does MacOS really not handle stat? Or is this old MacOS, not OS X?
> +sub load_netrc {
> [...]
> + foreach my $nentry (@netrc_entries) {
> + my %entry;
> + my $num_port;
> +
> + if (!defined $nentry->{machine}) {
> + next;
> + }
> + if (defined $nentry->{port} && $nentry->{port} =~ m/^\d+$/) {
> + $num_port = $nentry->{port};
> + delete $nentry->{port};
> + }
> +
> + # create the new entry for the credential helper protocol
> + $entry{$options{tmap}->{$_}} = $nentry->{$_} foreach keys %$nentry;
> +
> + # for "host X port Y" where Y is an integer (captured by
> + # $num_port above), set the host to "X:Y"
> + if (defined $entry{host} && defined $num_port) {
> + $entry{host} = join(':', $entry{host}, $num_port);
> + }
So this will convert:
machine foo port smtp
in the netrc into (protocol => "smtp", host => "foo"), but:
machine foo port 25
into (protocol => undef, host => "foo:25"), right? That makes sense to
me.
> +sub net_netrc_loader {
> [...]
I won't comment here, as I know very little about netrc (I always
thought it was line-oriented, too!) and Junio has covered it.
> +# takes the search tokens and then a list of entries
> +# each entry is a hash reference
> +sub find_netrc_entry {
> + my $query = shift @_;
> +
> + ENTRY:
> + foreach my $entry (@_)
> + {
> + my $entry_text = join ', ', map { "$_=$entry->{$_}" } keys %$entry;
> + foreach my $check (sort keys %$query) {
> + if (defined $query->{$check}) {
> + log_debug("compare %s [%s] to [%s] (entry: %s)",
> + $check,
> + $entry->{$check},
> + $query->{$check},
> + $entry_text);
> + unless ($query->{$check} eq $entry->{$check}) {
> + next ENTRY;
> + }
> + } else {
> + log_debug("OK: any value satisfies check $check");
> + }
This looks right to me.
> +sub print_credential_data {
I don't know if you want to take the hit of relying on Git.pm (it is
nice for the helper to be totally standalone and copy-able), but one
obvious possible refactor would be to use the credential read/write
functions recently added there. I'm OK with not doing that, though.
> + my $entry = shift @_;
> + my $query = shift @_;
> +
> + log_debug("entry has passed all the search checks");
> + TOKEN:
> + foreach my $git_token (sort keys %$entry) {
> + log_debug("looking for useful token $git_token");
> + # don't print unknown (to the credential helper protocol) tokens
> + next TOKEN unless exists $query->{$git_token};
> +
> + # don't print things asked in the query (the entry matches them)
> + next TOKEN if defined $query->{$git_token};
> +
> + log_debug("FOUND: $git_token=$entry->{$git_token}");
> + printf "%s=%s\n", $git_token, $entry->{$git_token};
> + }
Printf? Bleh, isn't this supposed to be perl? :P
I don't see anything wrong from the credential-handling side of things.
As I said, I didn't look closely at the netrc parsing bits. From my
reading of "perldoc macos", the answer to my question above is "yes,
stat doesn't work on MacOS Classic". So I think the script itself is
fine.
In your tests:
> +++ b/contrib/credential/netrc/Makefile
> @@ -0,0 +1,12 @@
> +test_netrc:
> + @(echo "bad data" | ./git-credential-netrc -f A -d -v) || echo "Bad invocation test, ignoring
> failure"
> + @echo "=> Silent invocation... nothing should show up here with a missing file"
> + @echo "bad data" | ./git-credential-netrc -f A get
> + @echo "=> Back to noisy: -v and -d used below, missing file"
> + echo "bad data" | ./git-credential-netrc -f A -d -v get
> + @echo "=> Look for any entry in the default file set"
> + echo "" | ./git-credential-netrc -d -v get
> + @echo "=> Look for github.com in the default file set"
> + echo "host=google.com" | ./git-credential-netrc -d -v get
> + @echo "=> Look for a nonexistent machine in the default file set"
> + echo "host=korovamilkbar" | ./git-credential-netrc -d -v get
You are depending on whatever the user has in their ~/.netrc, no?
Wouldn't it make more sense to ship a sample netrc and run all of the
tests with "-f netrc.example"?
It may also be worth building on top of the regular git test harness.
It's more work, but the resulting code (and the output) will be much
more readable.
-Peff
^ permalink raw reply
* Re: How to diff 2 file revisions with gitk
From: Sitaram Chamarty @ 2013-02-08 6:21 UTC (permalink / raw)
To: R. Diez; +Cc: git@vger.kernel.org
In-Reply-To: <1360166273.33888.YahooMailNeo@web171204.mail.ir2.yahoo.com>
On Wed, Feb 6, 2013 at 9:27 PM, R. Diez <rdiezmail-buspirate@yahoo.de> wrote:
> Hi there:
>
> I asked a few days ago whether I could easily diff 2 file revisions with the mouse in gitk, but I got no reply yet, see here:
>
>
> How to diff two file revisions with the mouse (with gitk)
> https://groups.google.com/forum/#!topic/git-users/9znsQsTB0dE
>
> I am hoping that it was the wrong mailing list, and this one the right one. 8-)
>
> Here is the full question text again:
>
> --------8<--------8<--------8<--------8<--------
>
> I would like to start gitk, select with the mouse 2
> revisions of some file and then compare them, hopefully with an external
> diff tool, very much like I am used to with WinCVS.
>
> The closest I
> got is to start gitk with a filename as an argument, in order to
> restrict the log to that one file. Then I right-click on a commit (a
> file revision) and choose "Mark this commit". However, if I right-click
> on another commit and choose "Compare with marked commit", I get a full
> commit diff with all files, and not just the file I specified on the
> command-line arguments.
>
> Selecting a filename in the "Tree" view and choosing "Highlight this only", as I found on the Internet, does not seem to help.
>
> I have git 1.7.9 (on Cygwin). Can someone help?
>
> By the way, it would be nice if gitk could launch the external diff tool from the "Compare with marked commit" option too.
I don't know if I misunderstood the whole question because the answer
is very simple.
- start gitk
- left click the newer commit
- scroll to the older commit
- right click the older commit and choose "Diff this -> selected"
- in the bottom right pane, pick any file, right click, and choose
"External diff".
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Jeff King @ 2013-02-08 6:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <7vliaz49sf.fsf@alter.siamese.dyndns.org>
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:
> How best to express the triangle is somewhat tricky, but I think it
> is sensible to say you have "origin" that points to your upstream
> (i.e. me), and "peff" that points to your publishing point, in other
> words, make it explicit that the user deals with two remotes. Then
> have push.default name the remote "peff", so that "git push" goes to
> that remote by default (and have "git fetch/pull" go to "origin).
> You will have two sets of remote tracking branches (one from "origin"
> that your push will never pretend to have fetched immediately after
> finishing, the other from "peff" that keeps track of what you pushed
> the last time).
Exactly. That is what I have set up now, except that I have to type "git
push peff" because there is no such push.default (with the minor nit
that push.default does something else, so the config should be called
remote.pushDefault or something). The entirety of the feature would be
saving the user from the annoyance of:
$ git push
fatal: remote error:
You can't push to git://github.com/gitster/git.git
Use git@github.com:gitster/git.git
[doh! Stupid git, why don't you do what I mean, not what I say?]
$ git push peff
... it works ...
> Of course, some people may have "I use this and that branches to
> interact with upstream X while I use these other branches to
> interacct with upstream Y, and all of them push to different
> places", and supporting that may need complex per branch "On this
> branch fetch from and integrate with remote X, and push to remote Z"
> settings, but as you said, "I fetch from and integrate with X, and
> result is pushed out to Y" should be the most common, and it would
> be desirable to have a simple way to express it with just a single
> new configuration variable.
Right. Frankly, I do not care that much about the per-branch push remote
myself. In the rules I gave earlier, that was my complete
backwards-compatible vision, so that we do not paint ourselves into a
corner compatibility-wise when somebody wants it later. Just
implementing the default push remote part would be a fine first step.
I also indicated in my rules that we could have a branch.*.fetchRemote,
as well, but I do not think it is strictly necessary. I think the
non-specific branch.*.remote could continue to be used for fetching, and
as a backup when the push-specific variables are not set.
> *1* It also happens to work reasonably well for people like Linus
> and I with the "I pull from random places, I locally integrate and I
> publish the results" workflow, because we are trained to think that
> it is not just being lazy but simply meaningless to say "git pull"
> without saying "fetch and integrate _what_ and from _whom_", and
> that is only because we do not have a fixed upstream. Linus and I
> would practically never fetch from "origin", i.e. from ourselves.
Right, I think "git pull" is more useful in a centralized repo setting
where there is one branch and one repo, so there is no "what and whom"
to specify. Personally I do not use it much at all, as I do a separate
fetch, inspect, and merge, but that is somewhat orthogonal to your
reasons. :)
-Peff
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 6:45 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <7vliaz49sf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> .... I think the triangle
> arrangement where you want to have "this is where I fetch from and
> integrate with, and that is where I publish" is more common among
> the Git users these days.
Another thing to know about is that the recent move to change the
behaviour of "git push" to work only on one branch per default may
have to be polished and strengthened a bit.
Originally, the encouraged workflow was to perfect _everything_ that
you would push out and then with a single "git push" to publish
everything at the same time. Both the "matching" behaviour of "git
push" which was the default, and the set of push refspecs that is to
be defined per remote, were ways to discourage "Work on one branch,
think it is OK, hastily push only that branch out, switch to another
branch, rinse, repeat".
To support a triangular arrangement well, there may need some
thinking on what $branch@{upstream} means. The original intent of
the upstream mode specified for "push.default" is push the result
back to what you based your work on, but in a triangular arrangement
that is no longer true. You may be keeping up with my 'master' by
constantly rebasing and then pushing out the result to your 'frotz'
topic. You want to have a lazy "git fetch" to fetch from my
'master' (i.e. upstream), and have remotes/origin/master to keep
track of it. You want to see "git rebase" to pay attention to the
updates to remotes/origin/master when figuring out where you forked.
But at the same time, you want a lazy "git push" to go to your
push.defaultTo repository (i.e. your publish point) and update your
'frotz' branch there---remotes/origin/master should not come into
the picture at all. But the upstream and simple modes want to pay
attention to branch.$name.merge, which is all about the "fetch and
integrate" side of the equation.
^ permalink raw reply
* [RFC/PATCH] Introduce branch.<name>.pushremote
From: Ramkumar Ramachandra @ 2013-02-08 7:19 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano, Jonathan Nieder, Jeff King
This new configuration variable overrides the remote in
`branch.<name>.remote` for pushes. It is useful in the typical
scenario, where the remote I'm pulling from is not the remote I'm
pushing to. Although `remote.<name>.pushurl` is similar, it does not
serve the purpose as the URL would lack corresponding remote tracking
branches.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
This is a first cut. There's code duplication at the moment, but I'm
currently trying to figure out which other remote_get() calls to
replace with pushremote_get(). Comments are welcome.
I will leave it to future patches to do the following things:
1. Fix the status output to be more meaningful when pushremote is
set. At the moment, I'm thinking statuses like [pull: 4 behind,
push: 3 ahead] will make sense.
2. Introduce a remote.pushDefault (peff)
3. Introduce a remote.default (peff)
Documentation/config.txt | 6 ++++++
builtin/push.c | 2 +-
remote.c | 41 +++++++++++++++++++++++++++++++++++++++++
remote.h | 2 ++
4 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9b11597..0b3b1f8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -727,6 +727,12 @@ branch.<name>.remote::
remote to fetch from/push to. It defaults to `origin` if no remote is
configured. `origin` is also used if you are not on any branch.
+branch.<name>.pushremote::
+ When in branch <name>, it tells 'git push' which remote to
+ push to. It falls back to `branch.<name>.remote`, and
+ defaults to `origin` if no remote is configured. `origin` is
+ also used if you are not on any branch.
+
branch.<name>.merge::
Defines, together with branch.<name>.remote, the upstream branch
for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
diff --git a/builtin/push.c b/builtin/push.c
index 42b129d..d447a80 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -322,7 +322,7 @@ static int push_with_options(struct transport *transport, int flags)
static int do_push(const char *repo, int flags)
{
int i, errs;
- struct remote *remote = remote_get(repo);
+ struct remote *remote = pushremote_get(repo);
const char **url;
int url_nr;
diff --git a/remote.c b/remote.c
index e53a6eb..d6fcfc0 100644
--- a/remote.c
+++ b/remote.c
@@ -48,6 +48,7 @@ static int branches_nr;
static struct branch *current_branch;
static const char *default_remote_name;
+static const char *pushremote_name;
static int explicit_default_remote_name;
static struct rewrites rewrites;
@@ -363,6 +364,12 @@ static int handle_config(const char *key, const char *value, void *cb)
default_remote_name = branch->remote_name;
explicit_default_remote_name = 1;
}
+ } else if (!strcmp(subkey, ".pushremote")) {
+ if (!value)
+ return config_error_nonbool(key);
+ branch->pushremote_name = xstrdup(value);
+ if (branch == current_branch)
+ pushremote_name = branch->pushremote_name;
} else if (!strcmp(subkey, ".merge")) {
if (!value)
return config_error_nonbool(key);
@@ -700,6 +707,40 @@ struct remote *remote_get(const char *name)
return ret;
}
+struct remote *pushremote_get(const char *name)
+{
+ struct remote *ret;
+ int name_given = 0;
+
+ read_config();
+ if (name)
+ name_given = 1;
+ else {
+ if (pushremote_name) {
+ name = pushremote_name;
+ name_given = 1;
+ } else {
+ name = default_remote_name;
+ name_given = explicit_default_remote_name;
+ }
+ }
+
+ ret = make_remote(name, 0);
+ if (valid_remote_nick(name)) {
+ if (!valid_remote(ret))
+ read_remotes_file(ret);
+ if (!valid_remote(ret))
+ read_branches_file(ret);
+ }
+ if (name_given && !valid_remote(ret))
+ add_url_alias(ret, name);
+ if (!valid_remote(ret))
+ return NULL;
+ ret->fetch = parse_fetch_refspec(ret->fetch_refspec_nr, ret->fetch_refspec);
+ ret->push = parse_push_refspec(ret->push_refspec_nr, ret->push_refspec);
+ return ret;
+}
+
int remote_is_configured(const char *name)
{
int i;
diff --git a/remote.h b/remote.h
index 251d8fd..aa42ff5 100644
--- a/remote.h
+++ b/remote.h
@@ -51,6 +51,7 @@ struct remote {
};
struct remote *remote_get(const char *name);
+struct remote *pushremote_get(const char *name);
int remote_is_configured(const char *name);
typedef int each_remote_fn(struct remote *remote, void *priv);
@@ -130,6 +131,7 @@ struct branch {
const char *refname;
const char *remote_name;
+ const char *pushremote_name;
struct remote *remote;
const char **merge_name;
--
1.8.1.2.545.g2f19ada.dirty
^ permalink raw reply related
* Re: [PATCH v4] Add utf8_fprintf helper which returns correct columns
From: Jiang Xin @ 2013-02-08 7:20 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy, Git List,
Nguyễn Thái Ngọc Duy
In-Reply-To: <51149542.8060307@web.de>
2013/2/8 Torsten Bögershausen <tboegi@web.de>:
> On 08.02.13 03:10, Jiang Xin wrote:
>> + /* If no error occurs, returns columns really required with utf8_strwidth. */
>> + if (0 <= columns)
>> + columns = utf8_strwidth(buf.buf);
>> + strbuf_release(&buf);
>> + return columns;
>> +}
>> +
>
> I don't think we handle the return code from fputs() correctly.
>
> Please dee below for specifications on fprintf(),
> something like the following could do:
>
> int utf8_fprintf(FILE *stream, const char *format, ...)
> {
> struct strbuf buf = STRBUF_INIT;
> va_list arg;
> int columns = 0;
>
> va_start (arg, format);
> strbuf_vaddf(&buf, format, arg);
> va_end (arg);
>
> if (EOF != fputs(buf.buf, stream))
> columns = utf8_strwidth(buf.buf);
> strbuf_release(&buf);
> return columns;
> }
As fputs() returns a non-negative number (as opposed to 0) on
successful completion,
Test fputs() return value as "fputs() >=0" is correct, while "fputs()
== 0", "fputs() != 0"
are wrong. I think it's OK, must I send a new re-roll for this?
EOF is defined as (-1) in stdio.h:
#define EOF (-1)
> And as a side note: would fprintf_strwidth() be a better name?
This is a nice candidate.
--
Jiang Xin
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Jonathan Nieder @ 2013-02-08 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Michael Schubert, Git List
In-Reply-To: <7v38x766b2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I'd actually see this as Gerrit being weird.
>
> If it wants to quarantine a commit destined to the "master" branch,
> couldn't it just let people push to "master" and then internally
> update "for/master" instead?
It is because pushing doesn't update refs/heads/master. Instead, it
starts a code review.
Suppose Gerrit allows starting a new code review by pushing to
refs/heads/master. It sounds okay if I squint --- it's just a very
slow asynchronous ref update, right? Let's see:
$ git clone <gerrit server> test
Cloning into 'test'...
$ echo hi >greeting
$ git add greeting
$ git commit -q -m 'hello'
$ git push origin master
[...]
remote: New Changes:
remote: <gerrit server>/r/1234
remote:
To <url>
ea4cb77b..9117390e master -> master
$ : walk away, forget what I was doing
$ git fetch origin
From <url>
+ 9117390...ea4cb77 master -> origin/master (forced update)
"Wait, why did the remote rewind?"
Regards,
Jonathan
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 8:16 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Michael Schubert, Git List
In-Reply-To: <20130208074813.GA7337@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> "Wait, why did the remote rewind?"
Oh, I am very well aware of that glitch.
"git push" has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.
It shouldn't have been made to do so unconditionally; instead it
should have been designed to give the pushee a way to optionally
tell you "I acccept this push, but you may not see it to be updated
to that exact value you pushed when you fetched from me right now".
The hack is not my design; it was not even something I accepted
without complaints, so I can badmouth about it all I want without
hesitation ;-)
More importantly, we could fix it if we wanted to.
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Junio C Hamano @ 2013-02-08 8:21 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder, Jeff King
In-Reply-To: <1360307982-20027-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Comments are welcome.
As the first cut, I would have expected the series to start from
more general (not "only this branch"), with later follow-up to let
more specific configuration.
Also I'd prefer to see the "push" semantics (e.g. "what does
upstream mean in this new world order?") designed better first.
^ permalink raw reply
* [RFC/PATCH] Introduce remote.pushdefault
From: Ramkumar Ramachandra @ 2013-02-08 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder, Jeff King
In-Reply-To: <7v1ucr43mk.fsf@alter.siamese.dyndns.org>
This new configuration variable overrides branch-specific
configuration `branch.<name>.remote` for pushes. It is useful in the
typical scenario, where the remote I'm pulling from is not the remote
I'm pushing to.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Junio C Hamano wrote:
> As the first cut, I would have expected the series to start from
> more general (not "only this branch"), with later follow-up to let
> more specific configuration.
Doesn't that follow trivially from my previous patch? I'm looking
for comments on how best to share code between pushremote_get()/
remote_get(), and on other remote_get() callsites.
> Also I'd prefer to see the "push" semantics (e.g. "what does
> upstream mean in this new world order?") designed better first.
Why should the meaning of upstream change? We'd probably like to
introduce something like a branch@{downstream} pointing to the push
remote ref sometime in the future though. Wait, should it always be
called downstream?
Documentation/config.txt | 4 ++++
builtin/push.c | 2 +-
remote.c | 45 +++++++++++++++++++++++++++++++++++++++++++--
remote.h | 1 +
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9b11597..82a4a78 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1884,6 +1884,10 @@ receive.updateserverinfo::
If set to true, git-receive-pack will run git-update-server-info
after receiving data from git-push and updating refs.
+remote.pushdefault::
+ The remote to push to by default. Overrides the
+ branch-specific configuration `branch.<name>.remote`.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
diff --git a/builtin/push.c b/builtin/push.c
index 42b129d..d447a80 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -322,7 +322,7 @@ static int push_with_options(struct transport *transport, int flags)
static int do_push(const char *repo, int flags)
{
int i, errs;
- struct remote *remote = remote_get(repo);
+ struct remote *remote = pushremote_get(repo);
const char **url;
int url_nr;
diff --git a/remote.c b/remote.c
index e53a6eb..08bb803 100644
--- a/remote.c
+++ b/remote.c
@@ -48,6 +48,7 @@ static int branches_nr;
static struct branch *current_branch;
static const char *default_remote_name;
+static const char *pushremote_name;
static int explicit_default_remote_name;
static struct rewrites rewrites;
@@ -349,6 +350,14 @@ static int handle_config(const char *key, const char *value, void *cb)
const char *subkey;
struct remote *remote;
struct branch *branch;
+ if (!prefixcmp(key, "remote.")) {
+ name = key + 7;
+ if (!strcmp(name, "pushdefault")) {
+ if (!value)
+ return config_error_nonbool(key);
+ pushremote_name = xstrdup(value);
+ }
+ }
if (!prefixcmp(key, "branch.")) {
name = key + 7;
subkey = strrchr(name, '.');
@@ -388,8 +397,6 @@ static int handle_config(const char *key, const char *value, void *cb)
add_instead_of(rewrite, xstrdup(value));
}
}
- if (prefixcmp(key, "remote."))
- return 0;
name = key + 7;
if (*name == '/') {
warning("Config remote shorthand cannot begin with '/': %s",
@@ -700,6 +707,40 @@ struct remote *remote_get(const char *name)
return ret;
}
+struct remote *pushremote_get(const char *name)
+{
+ struct remote *ret;
+ int name_given = 0;
+
+ read_config();
+ if (name)
+ name_given = 1;
+ else {
+ if (pushremote_name) {
+ name = pushremote_name;
+ name_given = 1;
+ } else {
+ name = default_remote_name;
+ name_given = explicit_default_remote_name;
+ }
+ }
+
+ ret = make_remote(name, 0);
+ if (valid_remote_nick(name)) {
+ if (!valid_remote(ret))
+ read_remotes_file(ret);
+ if (!valid_remote(ret))
+ read_branches_file(ret);
+ }
+ if (name_given && !valid_remote(ret))
+ add_url_alias(ret, name);
+ if (!valid_remote(ret))
+ return NULL;
+ ret->fetch = parse_fetch_refspec(ret->fetch_refspec_nr, ret->fetch_refspec);
+ ret->push = parse_push_refspec(ret->push_refspec_nr, ret->push_refspec);
+ return ret;
+}
+
int remote_is_configured(const char *name)
{
int i;
diff --git a/remote.h b/remote.h
index 251d8fd..99a437f 100644
--- a/remote.h
+++ b/remote.h
@@ -51,6 +51,7 @@ struct remote {
};
struct remote *remote_get(const char *name);
+struct remote *pushremote_get(const char *name);
int remote_is_configured(const char *name);
typedef int each_remote_fn(struct remote *remote, void *priv);
--
1.8.1.3.535.ga923c31.dirty
^ permalink raw reply related
* Re: Proposal: branch.<name>.remotepush
From: Jeff King @ 2013-02-08 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <7vd2wb483w.fsf@alter.siamese.dyndns.org>
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
> To support a triangular arrangement well, there may need some
> thinking on what $branch@{upstream} means. The original intent of
> the upstream mode specified for "push.default" is push the result
> back to what you based your work on, but in a triangular arrangement
> that is no longer true.
I don't think that "upstream" or "simple" push settings really make
sense in such a triangular arrangement. And IMHO, that's OK. They
reflect a much simpler view of the world than git is capable of
supporting. So "simple" works OK as a default, and people can move to
"matching" (or "current", or even a custom refspec) once they have are
ready to take advantage of a more advanced topology/workflow.
We have the problem now that new users do not necessarily understand the
matching strategy, or why it is useful, and get confused. When we move
to "simple", we may be switching to a world where the early part of the
learning curve is more gentle for those users, but they eventually run
across the steeper part when they want to adjust their workflow (i.e.,
they will eventually learn about non-symmetric repo topologies because
those are part of many useful workflows).
But I think it's a good thing to push that part of the learning curve
out, because:
1. Some people may stay in the centralized view their whole lives and
never care.
2. It will make more sense to them, because they'll understand how it
fits into what they're trying to do, rather than viewing it as an
arcane and senseless default.
There may be some confusion as people hit that learning point. I won't
be surprised if we end up adding more advice.* messages in certain cases
to guide people to adjusting their push.default. But I'm just as happy
to wait until people start hitting the confusion point in practice, and
we can see more clearly when that advice should trigger, and what it
should say.
Unless you have ideas now, of course, in which case I'm happy to hear
them. :)
-Peff
^ permalink raw reply
* Re: [Request] Git export with hardlinks
From: Jeff King @ 2013-02-08 9:58 UTC (permalink / raw)
To: Thomas Koch; +Cc: git
In-Reply-To: <201302061619.07765.thomas@koch.ro>
On Wed, Feb 06, 2013 at 04:19:07PM +0100, Thomas Koch wrote:
> I'd like to script a git export command that can be given a list of already
> exported worktrees and the tree SHA1s these worktrees correspond too. The git
> export command should then for every file it wants to export lookup in the
> existing worktrees whether an identical file is already present and in that
> case hardlink to the new export location instead of writing the same file
> again.
>
> Use Case: A git based web deployment system that exports git trees to be
> served by a web server. Every new deployment is written to a new folder. After
> the export the web server should start serving new requests from the new
> folder.
>
> It might be possible that this is premature optimization. But I'd like to
> learn more Python and dulwich by hacking this.
>
> Do you have any additional thoughts or use cases about this?
If you can handle losing the generality of N deployments, you can do it
in a few lines of shell.
Let's assume for a moment that you keep two trees at any given time:
the existing tree being used, and the tree you are setting up to deploy.
To save space, you want the new deployment to reuse (via hardlinks) as
many of the files from the old deployment as possible.
So imagine you have a bare repository storing the actual data:
$ git clone --bare /some/test/repo repo.git
$ du -sh *
49M repo.git
and then you have one deployment you've set up previously by checking
out the repo contents:
$ export GIT_DIR=$PWD/repo.git
$ mkdir old
$ (cd old && GIT_WORK_TREE=$PWD git checkout HEAD)
$ du -sh *
24M old
49M repo.git
So a full checkout is 24M. For the next deploy, we'll start by asking
"cp" to duplicate the old, using hard links:
$ cp -rl old new
$ du -sh *
24M new
768K old
49M repo.git
and we use hardly any extra space (it should just be directory inodes).
And now we can ask git to make "new" look like some other commit. It
will only touch files which have changed, so the rest remain hardlinked,
and we use only a small amount of extra space:
$ (cd new && GIT_WORK_TREE=$PWD git checkout HEAD~10)
$ du -sh *
24M new
1.3M old
49M repo.git
Now you point your deployment at "new", and you are free to leave "old"
sitting around or remove it at your leisure. You save space while the
two co-exist, and you saved the I/O of copying any files from "old" to
"new".
This breaks down, of course, if you want to keep N trees around and
hard-link to whichever one has the content you want. For that you'd have
to write some custom code.
-Peff
^ permalink raw reply
* [PATCH v3] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Nguyễn Thái Ngọc Duy @ 2013-02-08 10:09 UTC (permalink / raw)
To: git
Cc: Matthieu Moy, Jonathan Niedier, Junio C Hamano,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359870520-22644-1-git-send-email-pclouds@gmail.com>
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Keep "no branch" in all cases. Just append "rebasing/bisecting [%s]"
when applicable.
builtin/branch.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 6371bf9..26c0c3d 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -550,6 +550,48 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct stat st;
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf result = STRBUF_INIT;
+ int bisect = 0;
+ int ret;
+ if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
+ ret = strbuf_read_file(&sb, git_path("rebase-merge/head-name"), 0);
+ else if (!access(git_path("rebase-apply/rebasing"), F_OK))
+ ret = strbuf_read_file(&sb, git_path("rebase-apply/head-name"), 0);
+ else if (!access(git_path("BISECT_LOG"), F_OK)) {
+ ret = strbuf_read_file(&sb, git_path("BISECT_START"), 0);
+ bisect = 1;
+ } else
+ return xstrdup(_("(no branch)"));
+
+ if (ret <= 0) {
+ if (bisect)
+ return xstrdup(_("(no branch, bisecting)"));
+ else
+ return xstrdup(_("_(no branch, rebasing)"));
+ }
+
+ while (sb.len && sb.buf[sb.len - 1] == '\n')
+ strbuf_setlen(&sb, sb.len - 1);
+
+ if (bisect) {
+ unsigned char sha1[20];
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(&result, _("(no branch, bisecting)"));
+ else
+ strbuf_addf(&result, _("(no branch, bisecting %s)"), sb.buf);
+ } else {
+ if (!prefixcmp(sb.buf, "refs/heads/"))
+ strbuf_addf(&result, _("(no branch, rebasing %s)"), sb.buf + 11);
+ else
+ strbuf_addstr(&result, _("(no branch, rebasing)"));
+ }
+ strbuf_release(&sb);
+ return strbuf_detach(&result, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +599,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
struct ref_item item;
- item.name = xstrdup(_("(no branch)"));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..9b6f0d0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
cp .git/BISECT_START saved &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
- test_i18ngrep "* (no branch)" branch.output > /dev/null &&
+ test_i18ngrep "* (no branch, bisecting other)" branch.output > /dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* Re: Proposal: branch.<name>.remotepush
From: Michael J Gruber @ 2013-02-08 10:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <7v622343uy.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> "Wait, why did the remote rewind?"
>
> Oh, I am very well aware of that glitch.
>
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
>
> It shouldn't have been made to do so unconditionally; instead it
> should have been designed to give the pushee a way to optionally
> tell you "I acccept this push, but you may not see it to be updated
> to that exact value you pushed when you fetched from me right now".
>
> The hack is not my design; it was not even something I accepted
> without complaints, so I can badmouth about it all I want without
> hesitation ;-)
>
> More importantly, we could fix it if we wanted to.
And this seems to be more natural, too. It can keep the internals (the
auxiliary ref on the server side) hidden from the user.
As for the triangle remote, I really think we should clean up the
situation regarding push, pushurlinsteadof and the various different and
inconclusive output formats of "git remote" (with or without "-v", with
or without a remote name) first, before introducing yet another way to
twist things around. "git push downstream" does not hurt any kittens
(while git remote ouput does, somehwat).
Michael
^ permalink raw reply
* Re: [RFC/PATCH 4/4] grep: obey --textconv for the case rev:path
From: Michael J Gruber @ 2013-02-08 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List
In-Reply-To: <7v4nho9f28.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 07.02.2013 19:03:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>>> (cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
>>>> ../HEAD:../cache.h:#define GET_SHA1_QUIETLY 01
>>>
>>> Yuck.
>>
>> And even more yuck:
>>
>> (cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:../cache.h)
>> HEAD:../cache.h:#define GET_SHA1_QUIETLY 01
>>
>> Someone does not expect a "rev:" to be in there, it seems ;)
>
> I think stepping outside of $(cwd) is an afterthought the code does
> not anticipate.
>
Well, we do resolve relative paths correctly, and there are even some
"chdir" in the code path. It's just that the output label is incorrect.
Michael
^ permalink raw reply
* [PATCH] Use __VA_ARGS__ for all of error's arguments
From: Matt Kraai @ 2013-02-08 15:09 UTC (permalink / raw)
To: git, Max Horn, Jeff King, Junio C Hamano; +Cc: Matt Kraai
In-Reply-To: <20130208043915.GB4525@ftbfs.org>
From: Matt Kraai <matt.kraai@amo.abbott.com>
QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
comma if the error macro's variable argument is left out.
Instead of testing for a sufficiently recent version of GCC, make
__VA_ARGS__ match all of the arguments.
Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com>
---
git-compat-util.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cc2abee..b7eaaa9 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -305,13 +305,13 @@ extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)))
/*
* Let callers be aware of the constant return value; this can help
- * gcc with -Wuninitialized analysis. We have to restrict this trick to
- * gcc, though, because of the variadic macro and the magic ## comma pasting
- * behavior. But since we're only trying to help gcc, anyway, it's OK; other
- * compilers will fall back to using the function as usual.
+ * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,
+ * because some compilers may not support variadic macros. Since we're only
+ * trying to help gcc, anyway, it's OK; other compilers will fall back to
+ * using the function as usual.
*/
#if defined(__GNUC__) && ! defined(__clang__)
-#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
+#define error(...) (error(__VA_ARGS__), -1)
#endif
extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params));
--
1.8.1.2.546.g90a97a4
^ permalink raw reply related
* git filter-branch --prune-empty not removing commits
From: Martijn van Oosterhout @ 2013-02-08 15:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]
Hoi,
Found a small issue with git filter-branch not removing empty commits
if they are the first commit in the tree. Find test script attached
and example output below.
I think the issue is in the function git_commit_non_empty_tree, which
doesn't handle this case. I think something like the following should
work:
git_commit_non_empty_tree()
{
+ if test $# = 1 && test -z "$(git ls-tree $1)" ; then
+ skip_commit "$@"
+ fi
if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
map "$3"
else
git commit-tree "$@"
fi
}
If you're wondering how I got here, it was by using git svn to import
a tree once converted by cvs2svn, which added empty commits to the svn
repo to indicate the creation of branches.
Have a nice day,
---- Test script output (note: destroys the foo subdirectory) ----
+ git version
git version 1.7.9.5
+ echo ======== Setup ========
+ git init foo
Initialized empty Git repository in /tmp/foo/.git/
+ export GIT_AUTHOR_NAME=foo
+ export GIT_AUTHOR_EMAIL=foo@example.com
+ export GIT_COMMITTER_NAME=foo
+ export GIT_COMMITTER_EMAIL=foo@example.com
+ cd foo
+ git write-tree
+ git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 -m Commit 1
+ COMMIT1=1dc65b84c016320ce0599f2bd78bcbb5e532658f
+ export GIT_AUTHOR_NAME=bar
+ export GIT_AUTHOR_EMAIL=bar@example.com
+ echo Hello World
+ git add file
+ git write-tree
+ git commit-tree 34b512cb05f8b709198d18d916ea6395c237ae0d -m Commit 2
-p 1dc65b84c016320ce0599f2bd78bcbb5e532658f
+ COMMIT2=11af492decae1284cd2d27af4c5a92b4aab46510
+ git branch -f master 11af492decae1284cd2d27af4c5a92b4aab46510
+ git log master --stat
commit 11af492decae1284cd2d27af4c5a92b4aab46510
Author: bar <bar@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 2
file | 1 +
1 file changed, 1 insertion(+)
commit 1dc65b84c016320ce0599f2bd78bcbb5e532658f
Author: foo <foo@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 1
+ echo ======== Bug: filter-branch --prune-empty not working ========
+ git filter-branch --prune-empty master
Rewrite 11af492decae1284cd2d27af4c5a92b4aab46510 (2/2)
WARNING: Ref 'refs/heads/master' is unchanged
+ git log master --stat
commit 11af492decae1284cd2d27af4c5a92b4aab46510
Author: bar <bar@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 2
file | 1 +
1 file changed, 1 insertion(+)
commit 1dc65b84c016320ce0599f2bd78bcbb5e532658f
Author: foo <foo@example.com>
Date: Fri Feb 8 16:12:13 2013 +0100
Commit 1
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
[-- Attachment #2: test --]
[-- Type: application/octet-stream, Size: 671 bytes --]
#!/bin/sh -x
git version
echo "======== Setup ========"
git init foo
export GIT_AUTHOR_NAME="foo"
export GIT_AUTHOR_EMAIL="foo@example.com"
export GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL
cd foo
COMMIT1=$(git commit-tree $(git write-tree) -m "Commit 1")
export GIT_AUTHOR_NAME="bar"
export GIT_AUTHOR_EMAIL="bar@example.com"
echo "Hello World" > file
git add file
COMMIT2=$(git commit-tree $(git write-tree) -m "Commit 2" -p $COMMIT1)
git branch -f master $COMMIT2
git log master --stat
echo "======== Bug: filter-branch --prune-empty not working ========"
git filter-branch --prune-empty master
git log master --stat
^ permalink raw reply
* Fwd: Git remote possible feature request
From: Javier Domingo @ 2013-02-08 15:30 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CALZVapkxbY_sQucxznTQ-SJ6-YkxZvFH2TDjRtfL8Qsai1ZsWQ@mail.gmail.com>
Hi,
Just wanted to check if that when you add a remote with
--mirror=fetch, it means that you just want to fetch from that mirror.
Would that avoid accidentally pushing to that mirror?
I would like to be able to mark some remotes as read-only...
Thank you,
Javier Domingo
^ permalink raw reply
* Re: [PATCH] Use __VA_ARGS__ for all of error's arguments
From: Jeff King @ 2013-02-08 15:54 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Max Horn, Junio C Hamano, Matt Kraai
In-Reply-To: <1360336168-27740-1-git-send-email-kraai@ftbfs.org>
On Fri, Feb 08, 2013 at 07:09:28AM -0800, Matt Kraai wrote:
> From: Matt Kraai <matt.kraai@amo.abbott.com>
>
> QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
> comma if the error macro's variable argument is left out.
>
> Instead of testing for a sufficiently recent version of GCC, make
> __VA_ARGS__ match all of the arguments.
>
> [...]
>
> /*
> * Let callers be aware of the constant return value; this can help
> - * gcc with -Wuninitialized analysis. We have to restrict this trick to
> - * gcc, though, because of the variadic macro and the magic ## comma pasting
> - * behavior. But since we're only trying to help gcc, anyway, it's OK; other
> - * compilers will fall back to using the function as usual.
> + * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,
> + * because some compilers may not support variadic macros. Since we're only
> + * trying to help gcc, anyway, it's OK; other compilers will fall back to
> + * using the function as usual.
> */
> #if defined(__GNUC__) && ! defined(__clang__)
> -#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
> +#define error(...) (error(__VA_ARGS__), -1)
Acked-by: Jeff King <peff@peff.net>
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH v4] Add utf8_fprintf helper which returns correct columns
From: Torsten Bögershausen @ 2013-02-08 16:19 UTC (permalink / raw)
To: Jiang Xin
Cc: Torsten Bögershausen, Junio C Hamano,
Nguyễn Thái Ngọc Duy, Git List,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CANYiYbGZEJXDjzBJa_qbQCgw9tcTMfOChNr6ANwaLvo=fB=bcQ@mail.gmail.com>
On 08.02.13 08:20, Jiang Xin wrote:
> 2013/2/8 Torsten Bögershausen <tboegi@web.de>:
>> On 08.02.13 03:10, Jiang Xin wrote:
>>> + /* If no error occurs, returns columns really required with utf8_strwidth. */
>>> + if (0 <= columns)
>>> + columns = utf8_strwidth(buf.buf);
>>> + strbuf_release(&buf);
>>> + return columns;
>>> +}
>>> +
>>
>> I don't think we handle the return code from fputs() correctly.
>>
>> Please dee below for specifications on fprintf(),
>> something like the following could do:
>>
>> int utf8_fprintf(FILE *stream, const char *format, ...)
>> {
>> struct strbuf buf = STRBUF_INIT;
>> va_list arg;
>> int columns = 0;
>>
>> va_start (arg, format);
>> strbuf_vaddf(&buf, format, arg);
>> va_end (arg);
>>
>> if (EOF != fputs(buf.buf, stream))
>> columns = utf8_strwidth(buf.buf);
>> strbuf_release(&buf);
>> return columns;
>> }
>
> As fputs() returns a non-negative number (as opposed to 0) on
> successful completion,
> Test fputs() return value as "fputs() >=0" is correct, while "fputs()
> == 0", "fputs() != 0"
> are wrong. I think it's OK, must I send a new re-roll for this?
>
> EOF is defined as (-1) in stdio.h:
>
> #define EOF (-1)
>
>> And as a side note: would fprintf_strwidth() be a better name?
>
> This is a nice candidate.
>
>
Doing a slurp(coffe) followed by a re-read,
I think we are save with the existng code.
However, I feel that the commit message can be improved,
as it fixes problems not only for CJK but e.g. european languages
(and all systems using utf-8)
>Since command usages can be translated, they may not align well especially
>when they are translated to CJK. A wrapper utf8_fprintf can help to return
>the correct columns required.
Since command usages can be translated, they may include utf-8 encoded strings,
and strlen() is different from strwidth().
A wrapper utf8_fprintf() helps to return the correct columns required.
Thanks for working on this.
^ permalink raw reply
* [PATCH] user-manual: Rewrite git-gc section for automatic packing
From: W. Trevor King @ 2013-02-08 16:43 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This should have happened back in 2007, when `git gc` learned about
auto:
commit e9831e83e063844b90cf9e525d0003715dd8b395
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Sep 17 00:39:52 2007 -0700
git-gc --auto: add documentation.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
I'd also be happy just dropping the whole git-gc section ;).
Documentation/user-manual.txt | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..d14e3c7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1562,17 +1562,13 @@ Ensuring good performance
-------------------------
On large repositories, Git depends on compression to keep the history
-information from taking up too much space on disk or in memory.
+information from taking up too much space on disk or in memory. Some
+git commands may automatically run linkgit:git-gc[1], so you don't
+have to worry about running it manually. However, compressing large
+repositories may take some time, so you might want to disable
+automatic comression and run it explicitly when you are not doing
+other work.
-This compression is not performed automatically. Therefore you
-should occasionally run linkgit:git-gc[1]:
-
--------------------------------------------------
-$ git gc
--------------------------------------------------
-
-to recompress the archive. This can be very time-consuming, so
-you may prefer to run `git gc` when you are not doing other work.
[[ensuring-reliability]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: git filter-branch --prune-empty not removing commits
From: Martijn van Oosterhout @ 2013-02-08 16:53 UTC (permalink / raw)
To: git
In-Reply-To: <CADWG95sHx6Z2Ukon8FAHKa1qUOj4shd4MbCwahwX++FVWJPDDg@mail.gmail.com>
On 8 February 2013 16:23, Martijn van Oosterhout <kleptog@gmail.com> wrote:
> git_commit_non_empty_tree()
> {
> + if test $# = 1 && test -z "$(git ls-tree $1)" ; then
> + skip_commit "$@"
> + fi
> if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
> map "$3"
> else
> git commit-tree "$@"
> fi
> }
This bit is a but bunk, the fi should be an else, otherwise it does nothing.
Have a nice day,
--
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
^ permalink raw reply
* Re: [PATCH 3/4] Makefile: factor common configuration in git-default-config.mak
From: Matthieu Moy @ 2013-02-08 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobfv7wkl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I really think this is going in a wrong direction. Whatever you
> happen to have chosen in this patch will be available to others,
> while whatever are left out will not be. When adding new things,
> people need to ask if it needs to be sharable or not, and the right
> answer to that question will even change over time.
My feeling is that Git's toplevel Makefile has become too large to
remain completely monolithic, and splitting is good to organize it (and
yes, splitting code into several files imply that future added code will
have to be added in the right file, but that's not very different from
splitting C code into several .c files to me). But that is another
matter, and ...
Junio C Hamano <gitster@pobox.com> writes:
> Then do something like
>
> all::
> $(MAKE) -C ../.. \
> PERL_SCRIPT=contrib/mw-to-git/git-remote-mediawiki.perl \
> build-perl-script
This ended up being very simple to implement (essentially, the Makefile
already knows how to do this, so this just means adding convenience
build-perl-script target to the toplevel), so 2 new patches follow doing
this, with a ridiculously small new version of mw-to-git/Makefile.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:06 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <20130208092204.GA15490@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they eventually run
> across the steeper part when they want to adjust their workflow (i.e.,
> they will eventually learn about non-symmetric repo topologies because
> those are part of many useful workflows).
>
> But I think it's a good thing to push that part of the learning curve
> out, because:
>
> 1. Some people may stay in the centralized view their whole lives and
> never care.
>
> 2. It will make more sense to them, because they'll understand how it
> fits into what they're trying to do, rather than viewing it as an
> arcane and senseless default.
>
> There may be some confusion as people hit that learning point. I won't
> be surprised if we end up adding more advice.* messages in certain cases
> to guide people to adjusting their push.default. But I'm just as happy
> to wait until people start hitting the confusion point in practice, and
> we can see more clearly when that advice should trigger, and what it
> should say.
Oh, I agree with you that adding new support for triangular workflow
will not hurt the centralized folks. I was more interested about
helping the "fetch from here, push to there" people.
Centralized people do not have to configure anything for each branch
for "git push" to push their current branch to where they fetch from
and to the same name (you start building on their 'master', your
result go to their 'master', because as a centralized person, you
are part of 'them'). They have branch.$name.merge that names what
their $name branch merges with, and that is sufficient to decide to
which branch the result is to be pushed back.
With the "push.defaultTo = peff" to name what remote the "git push"
will push to, or even with the "branch.master.remotepush = peff" to
decide that per branch, would "fetch from here, push to there"
people have a way similar to what branch.$name.merge gives to the
centralized people to decide what branch is updated?
It almost seems to me that we may want to extend the semantics given
to the remote.$name.push refspecs. They are primarily for "perfect
all branches you are going to push out, and push them in one go with
'git push'" workflow, but if it is clear that you are not following
that (e.g. you are doing an equivalent of what the centralized folks
would do with "push.default = simple/upstream/current") and pushing
only the current branch, perhaps we should look at these refspecs to
see where the current branch goes?
In your case, 'refs/heads/master' would likely to go to
'refs/heads/master', and we could treat a missing remote.peff.push
an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*
In a Gerrit user's case brought up by Michael Schubert in a message
earlier in the near-by subthread, 'refs/heads/frotz' would likely to
go to 'refs/for/frotz' and they can express it with something like
[remote "origin"]
url = ... ;# pushurl is the same or just s/git/ssh/;
fetch = refs/heads/*:refs/heads/*
push = refs/heads/*:refs/for/*
[push]
default = "???"
where "???" says "I push out only the currently checked-out branch;
figure out where it goes using remote.origin.push refspec".
Having to set both branch.$name.remotepush to name what remote this
branch should be pushed, and branch.$name.branchpush to name what
branch at the remote this branch should update with a push, and
doing so for each and every branch, sounds like an unnecessary
complexity.
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:11 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing yet another way to
> twist things around. "git push downstream" does not hurt any kittens
> (while git remote ouput does, somehwat).
As people tend to fetch more often than they push if they are
working on a real project where the others as a whole will be far
more productive than any single individual, I agree that keeping
"git fetch" (or "git pull") lazy by having "origin" point at where
they fetch from and be a bit more explicit in "git push" would
actually make sense.
^ 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