* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: J. Bruce Fields @ 2007-11-19 0:48 UTC (permalink / raw)
To: Michael Smith; +Cc: git, gitster
In-Reply-To: <11949569992214-git-send-email-msmith@cbnco.com>
On Tue, Nov 13, 2007 at 07:29:59AM -0500, Michael Smith wrote:
> +You can view all your local changes--b, d, h, and i--with the
> +gitlink:git-diff[1] command:
> +
> +------------------------------------------
> +$ git diff origin/master...master
> +------------------------------------------
> +
> +The three-dot `\...` tells gitlink:git-diff[1] to show the changes on the
> +master branch since the last common ancestor with origin/master. (If you
> +used two dots instead of three, you'd see the entire patch to go from
> +origin/master to master, including reversing commits "f" and "g".)
I missed the "..." thing when on my first attempt at the manual. It
really should be mentioned in the "Generating diffs" section; I've added
the following to my
git://linux-nfs.org/~bfields/git.git maint
--b.
>From 5b98d9bca16e19710380d2d03f704de9eb98621d Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 18 Nov 2007 19:18:27 -0500
Subject: [PATCH] user-manual: mention "..." in "Generating diffs", etc.
We should mention the use of the "..." syntax for git-diff here. The
note about the difference between diff and the combined output of
git-format-patch then no longer fits so well, so remove it. Add a
reference to the git-format-patch[1] manpage.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e399685..c027353 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -658,16 +658,23 @@ gitlink:git-diff[1]:
$ git diff master..test
-------------------------------------------------
-Sometimes what you want instead is a set of patches:
+That will produce the diff between the tips of the two branches. If
+you'd prefer to find the diff from their common ancestor to test, you
+can use three dots instead of two:
+
+-------------------------------------------------
+$ git diff master...test
+-------------------------------------------------
+
+Sometimes what you want instead is a set of patches; for this you can
+use gitlink:git-format-patch[1]:
-------------------------------------------------
$ git format-patch master..test
-------------------------------------------------
will generate a file with a patch for each commit reachable from test
-but not from master. Note that if master also has commits which are
-not reachable from test, then the combined result of these patches
-will not be the same as the diff produced by the git-diff example.
+but not from master.
[[viewing-old-file-versions]]
Viewing old file versions
--
1.5.3.5.561.g140d
^ permalink raw reply related
* git-daemon fatal error running with monit
From: Glenn Rempe @ 2007-11-19 1:09 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
hello git masters.
I am having a problem running git-daemon from within 'monit' (http://www.tildeslash.com/monit/index.php
). I can run git-daemon every time without error if I manually issue
the command to run it in a terminal. However, if I have monit execute
the exact same command I get an error from git-daemon in syslog and
the client request fails every time. Running on Ubuntu 7.04. Can you
take a look?
Unfortunately the error info in the logs is minimal. All details of
my config and the error can be found here in this pastie: http://git.pastebin.com/m20fab0a9
Thanks in advance.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2411 bytes --]
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: J. Bruce Fields @ 2007-11-19 1:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Smith, git
In-Reply-To: <7vtznqrlrb.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 13, 2007 at 11:25:12AM -0800, Junio C Hamano wrote:
> Michael Smith <msmith@cbnco.com> writes:
>
> > +You can fix situations like these by doing a merge that isn't really a
> > +merge, using the "ours" merge strategy. Look through the history on the
> > +third-party branch and try to find the exact commit that matches the
> > +last snapshot you imported. Often there's a tag close to the commit, or
> > +on the commit, if you're lucky--but don't trust it blindly; check the
> > +diffs. Check out your local branch and tell Git about the relationship:
> > +
> > +------------------------------------------------
> > +$ git remote add upstreamgit git://upstream.org/project.git
> > +$ git fetch upstreamgit
> > +$ git tag
> > +v1.0
> > +v1.1
> > +v1.2
> > +$ git checkout master
> > +$ git merge --strategy=ours \
> > + -m "Tie old v1.1 into our history by merging with strategy=ours." \
> > + v1.1
> > +------------------------------------------------
> > +
> > +You'll see the branches merge together in `gitk --all` or `git
> > +show-branch master upstreamgit/master`. Now you'll be able to merge any
> > +changes from the remote branch since v1.1 with `git merge
> > +upstreamgit/master`.
> > +
>
> This would work only when your 'master' happens to be at v1.1
> (and identical to it) isn't it? Which means that as an example
> it will be of very limited scope.
>
> People would want to know "But my 'master' is _not_ at v1.1 but
> is _based_ on v1.1. How would I handle that case?" and the
> above does not answer that question.
>
> Even worse, most people are probably not careful enough to ask
> the above question, but just say "Heh, my 'master' is based on
> v1.1, so I'll blindly follow that example to bind the histories
> together".
>
> I did not find any technical problem in the other parts of your
> description, but I did not read the resulting document from
> cover to cover, so I do not know if your change fits in the
> entire organization of the document very well.
A mention of git-cherry or --left-right someplace might make sense,
maybe in chapter 2 somewhere (maybe in "Browsing revisions"?), but it
might also be useful to discuss this kind of stuff in the "sharing
development with others" section. (E.g. at the end of "Submitting
patches to a project", it might help to have some hints about how to
recognize when they've been accepted and what to do then.)
The trick of using a merge (possibly with -s ours) to tie together two
independent paths to the same state is more generally useful. (I've
been using it sometimes to keep track of the revision history of a patch
series, for example). I'm not sure where that should go.
I like the tips on importing snapshots or other history. I've long been
wanting an "interoperating with other SCM's" section (rough beginnings
at git://linux-nfs.org/~bfields/git.git docwork-foreign-scms), and maybe
some of this would fit here.
All of these things seem more generally useful even to an audience that
hasn't worked with CVS vendor branches before, so I'd prefer
explanations that didn't reference the CVS stuff. (With CVS-specific
stuff moved somewhere else, maybe to cvs-migration.txt.)
--b.
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 1:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <119540238994-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Often you want to push only the current branch to the default
> remote. This was awkward to do in the past.
While I think --current is a handy shorthand to have, I do not
think the above description is correct.
Wouldn't your earlier patch have allowed the configuration setting:
[remote "$there"]
push = HEAD
[branch "$current"]
remote = $there
to work very well already?
I do not think it is "Often you want" that makes it awkward.
Instead, the awkward case is if you do the "only the current"
push NOT often enough. If it is often enough, you set the
configuration once and the awkwardness is behind you.
If however it is not often enough, you cannot afford to have the
configuration above, because that would force you to tell from
the command line which branches, not just the current one, to
push, and that is inconvenient because it is not rare enough.
Together with your [PATCH 1/2], I like the general direction
these patckes are taking us, but it feels a bit too hasty. I
personally am not convinced that switching to --current for
everybody is a good move.
> ...
> Maybe in two years (that's twice an eternity in git time scales):
>
> 4) make "git push --current" the default.
If these, both the uncertainly expressed by "Maybe" and "twice
an eternity" are true, which they are, the new warning in the
current patch are inappropriate. Many people's settings depend
on a working "push the matching refs" behaviour, and we need a
very good excuse to annoy the existing happy users with such a
warning.
Remember, how much vocal the dissenters might have been on the
list in the recent discussions, we need to consider the needs of
the silent majority that has been content with the current
behaviour for a long time.
The "warning" to annoy them may be a way to get their attention
and get them involved in a discussion to decide what the default
should be. But changing the default without giving the people
who do not like the _new_ default a way to avoid inconvenience
of always typing --matching or --current is not nice. And
honestly, I do not think there is one single default that is
good for everybody.
We should be doing better.
A smoother transition route would be:
- Keep "matching" the built-in default for now;
- Take your patches (but drop "warning" bits at this point) to
introduce 'matching' and 'current' behaviours, and a way to
override the built-in default from the command line;
- Introduce a configuration 'push.defaultRefs' ('matching' or
'current') to override that built-in default, so people who
prefer 'current' can override the built-in default, without
having to type --current every time.
After all that happens, we can start discussing what the
built-in default should be. When it is changed after the
discussion concludes (which may never happen), people who want
to keep 'matching' behaviour would have had the configuration
mechanism to override that built-in default for some time during
the discussion period. So the beginning of that discussion
period is when we should start talking about "We might change
the default soon; set the configuration to your liking if you do
not want to get affected" in the warning.
Then after that, we may or may not decide to change the default.
Even if we end up not changing the default, 'current' people
will then have a way (push.matching = false) to tailor their git
for their liking, so everybody wins.
> DESCRIPTION
> @@ -63,6 +63,12 @@ the remote repository.
> Instead of naming each ref to push, specifies that all
> refs under `$GIT_DIR/refs/heads/` be pushed.
>
> +\--matching::
> + Instead of naming each ref to push, specifies that matching
> + refs under `$GIT_DIR/refs/heads/` be pushed. Matching means
> + the branch exists locally and at the remote under the same name.
> + Currently, this is the default. But this will change in the future.
For the above reason, "But this will..." is a bit premature.
^ permalink raw reply
* Re: [PATCH] Documentation: Fix references to deprecated commands
From: J. Bruce Fields @ 2007-11-19 1:54 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <20071112003251.GB21970@diku.dk>
On Mon, Nov 12, 2007 at 01:32:51AM +0100, Jonas Fonseca wrote:
> Subject: [PATCH] Documentation: Fix references to deprecated commands
>
> ... by changing git-tar-tree reference to git-archive and removing
> seemingly unrelevant footnote about git-ssh-{fetch,upload}.
Makes sense to me, but for some reason git-am complains about a corrupt
patch when I feed it this email. I reconstructed it by hand, fixed up
one more reference to git-tar-tree, and applied to my tree.
--b.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> Documentation/core-tutorial.txt | 5 -----
> Documentation/git-get-tar-commit-id.txt | 4 ++--
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> Now with SOB and ...
>
> Jonas Fonseca <fonseca@diku.dk> wrote Mon, Nov 12, 2007:
> > diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
> > index 9b5f86f..ef1b19c 100644
> > --- a/Documentation/git-get-tar-commit-id.txt
> > +++ b/Documentation/git-get-tar-commit-id.txt
> > @@ -14,12 +14,12 @@ SYNOPSIS
> > return code of 1. This can happen if <tarfile> had not been created
> > -using git-tar-tree or if the first parameter of git-tar-tree had been
> > +using git-archive or if the first parameter of git-tar-tree had been
> > a tree ID instead of a commit ID or tag.
>
> ... s//g
>
> diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
> index ebd2492..401d1de 100644
> --- a/Documentation/core-tutorial.txt
> +++ b/Documentation/core-tutorial.txt
> @@ -1090,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
> that does not even support directory index would suffice. But
> you must prepare your repository with `git-update-server-info`
> to help dumb transport downloaders.
> -+
> -There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
> -programs, which are 'commit walkers'; they outlived their
> -usefulness when git Native and SSH transports were introduced,
> -and are not used by `git pull` or `git push` scripts.
>
> Once you fetch from the remote repository, you `merge` that
> with your current branch.
> diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
> index 9b5f86f..ef1b19c 100644
> --- a/Documentation/git-get-tar-commit-id.txt
> +++ b/Documentation/git-get-tar-commit-id.txt
> @@ -14,12 +14,12 @@ SYNOPSIS
> DESCRIPTION
> -----------
> Acts as a filter, extracting the commit ID stored in archives created by
> -git-tar-tree. It reads only the first 1024 bytes of input, thus its
> +gitlink:git-archive[1]. It reads only the first 1024 bytes of input, thus its
> runtime is not influenced by the size of <tarfile> very much.
>
> If no commit ID is found, git-get-tar-commit-id quietly exists with a
> return code of 1. This can happen if <tarfile> had not been created
> -using git-tar-tree or if the first parameter of git-tar-tree had been
> +using git-archive or if the <treeish> parameter of git-archive had been
> a tree ID instead of a commit ID or tag.
>
> --
> Jonas Fonseca
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git merge no longer handles add/add
From: Martin Langhoff @ 2007-11-19 3:18 UTC (permalink / raw)
To: git list
git used to be really good at merging 2 branches that had gotten the
same code added independently. Right now, both master
(1.5.3.5.737.gdee1b)
and next (9445b41) are telling me that the exact same file (same
sha1), with the same mode added on 2 branches is a merge conflict. On
_one_ of the branches there is an extra commit.
Hmmm.
I am pretty sure that early git (pre 1.0) could handle this correctly.
I remember sending git-archimport to Junio and immediately doing 3 or
4 commits on top, and having the next pull work correctly without
conflict because the merge machinery spotted the "last common sha1"
for that file and saw that only one side had changed since then.
Happens with recursive and resolve. Happy to provide a minimal repro
case, but I think this is fairly obvious...
cheers,
martin
^ permalink raw reply
* Re: git merge no longer handles add/add
From: Martin Langhoff @ 2007-11-19 3:29 UTC (permalink / raw)
To: git list
In-Reply-To: <46a038f90711181918s2743137amc6a827db6d1a6a0@mail.gmail.com>
On Nov 19, 2007 4:18 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Happens with recursive and resolve. Happy to provide a minimal repro
> case, but I think this is fairly obvious...
Steps to repro...
mkdir repro
cd repro/
cp /etc/resolv.conf ./resolv.conf
git init
git add resolv.conf
git commit -m 'a' resolv.conf
cp resolv.conf resolv-1.conf
git add resolv-1.conf
git commit -m 'a1' resolv-1.conf
echo blabla >> resolv-1.conf
git commit -m 'a2' resolv-1.conf
git-branch other HEAD^^
git checkout other
cp resolv.conf resolv-1.conf
git add resolv-1.conf
git commit -m 'b'
git checkout master
git merge other
...
Auto-merged resolv-1.conf
CONFLICT (add/add): Merge conflict in resolv-1.conf
Automatic merge failed; fix conflicts and then commit the result.
m
^ permalink raw reply
* [PATCH v2] git-send-email: show all headers when sending mail
From: David D. Kilzer @ 2007-11-19 4:14 UTC (permalink / raw)
To: gitster; +Cc: git, David D. Kilzer
In-Reply-To: <7vbq9ywqmq.fsf@gitster.siamese.dyndns.org>
As a git newbie, it was confusing to set an In-Reply-To header but then
not see it printed when the git-send-email command was run.
This patch prints all headers that would be sent to sendmail or an SMTP
server instead of only printing From, Subject, Cc, To. It also removes
the now-extraneous Date header after the "Log says" line.
Added test to t/t9001-send-email.sh.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
---
Updated t/t9001-send-email.sh per feedback from Junio C Hamano.
git-send-email.perl | 4 ++--
t/t9001-send-email.sh | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2b1f1b5..f4539a0 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -575,7 +575,7 @@ X-Mailer: git-send-email $gitversion
if ($quiet) {
printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
} else {
- print (($dry_run ? "Dry-" : "")."OK. Log says:\nDate: $date\n");
+ print (($dry_run ? "Dry-" : "")."OK. Log says:\n");
if ($smtp_server !~ m#^/#) {
print "Server: $smtp_server\n";
print "MAIL FROM:<$raw_from>\n";
@@ -583,7 +583,7 @@ X-Mailer: git-send-email $gitversion
} else {
print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
}
- print "From: $sanitized_sender\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
+ print $header, "\n";
if ($smtp) {
print "Result: ", $smtp->code, ' ',
($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 83f9470..659f9c7 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -41,4 +41,41 @@ test_expect_success \
'Verify commandline' \
'diff commandline expected'
+cat >expected-show-all-headers <<\EOF
+0001-Second.patch
+(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
+Dry-OK. Log says:
+Server: relay.example.com
+MAIL FROM:<from@example.com>
+RCPT TO:<to@example.com>,<cc@example.com>,<author@example.com>,<bcc@example.com>
+From: Example <from@example.com>
+To: to@example.com
+Cc: cc@example.com, A <author@example.com>
+Subject: [PATCH 1/1] Second.
+Date: DATE-STRING
+Message-Id: MESSAGE-ID-STRING
+X-Mailer: X-MAILER-STRING
+In-Reply-To: <unique-message-id@example.com>
+References: <unique-message-id@example.com>
+
+Result: OK
+EOF
+
+test_expect_success 'Show all headers' '
+ git send-email \
+ --dry-run \
+ --from="Example <from@example.com>" \
+ --to=to@example.com \
+ --cc=cc@example.com \
+ --bcc=bcc@example.com \
+ --in-reply-to="<unique-message-id@example.com>" \
+ --smtp-server relay.example.com \
+ $patches |
+ sed -e "s/^\(Date:\).*/\1 DATE-STRING/" \
+ -e "s/^\(Message-Id:\).*/\1 MESSAGE-ID-STRING/" \
+ -e "s/^\(X-Mailer:\).*/\1 X-MAILER-STRING/" \
+ >actual-show-all-headers &&
+ diff -u expected-show-all-headers actual-show-all-headers
+'
+
test_done
--
1.5.3.4
^ permalink raw reply related
* [PATCH/RFC] parse-options: allow to define hidden synonym options
From: Junio C Hamano @ 2007-11-19 6:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
By setting the help member to NULL, you can implement an option
that is not shown in the "git-cmd -h" help output. This is
useful to support backward compatible synonyms without
cluttering the help text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
parse-options.c | 2 ++
parse-options.h | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index d3e608a..1ee2c81 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -284,6 +284,8 @@ void usage_with_options(const char * const *usagestr,
if (*opts->help)
fprintf(stderr, "%s\n", opts->help);
continue;
+ } else if (!opts->help) {
+ continue;
}
pos = fprintf(stderr, " ");
diff --git a/parse-options.h b/parse-options.h
index a8760ac..de249a0 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -49,7 +49,7 @@ typedef int parse_opt_cb(const struct option *, const char *arg, int unset);
*
* `help`::
* the short help associated to what the option does.
- * Must never be NULL (except for OPTION_END).
+ * option with this field set to NULL does not appear in the help listing.
* OPTION_GROUP uses this pointer to store the group header.
*
* `flags`::
--
1.5.3.6.1779.ga3ed
^ permalink raw reply related
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Steffen Prohaska @ 2007-11-19 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vwssfqb0w.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 6202 bytes --]
On Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Often you want to push only the current branch to the default
>> remote. This was awkward to do in the past.
>
> While I think --current is a handy shorthand to have, I do not
> think the above description is correct.
>
> Wouldn't your earlier patch have allowed the configuration setting:
>
> [remote "$there"]
> push = HEAD
> [branch "$current"]
> remote = $there
>
> to work very well already?
No. This was the case in the verst first version of the patch
series. Someone, I don't remember who, proposed to put the
resolution of HEAD into builtin-push.c. This simplified code
a lot. Now, HEAD is resolved when parsing the command line.
At that time it is replaced with the full local refname.
The refspec parsing code never sees HEAD, and it won't
understand it. Try the above setup, and you'll see that it
doesn't work.
Anyway it's not needed if we proceed as outlined below.
> I do not think it is "Often you want" that makes it awkward.
>
> Instead, the awkward case is if you do the "only the current"
> push NOT often enough. If it is often enough, you set the
> configuration once and the awkwardness is behind you.
>
> If however it is not often enough, you cannot afford to have the
> configuration above, because that would force you to tell from
> the command line which branches, not just the current one, to
> push, and that is inconvenient because it is not rare enough.
Will try to rephrase the commit message.
> Together with your [PATCH 1/2], I like the general direction
> these patckes are taking us, but it feels a bit too hasty. I
> personally am not convinced that switching to --current for
> everybody is a good move.
>
>> ...
>> Maybe in two years (that's twice an eternity in git time scales):
>>
>> 4) make "git push --current" the default.
>
> If these, both the uncertainly expressed by "Maybe" and "twice
> an eternity" are true, which they are, the new warning in the
> current patch are inappropriate. Many people's settings depend
> on a working "push the matching refs" behaviour, and we need a
> very good excuse to annoy the existing happy users with such a
> warning.
I think 3) is the interesting case. "git push" should do
nothing by default. Either you can configure "git push" to do
something by setting a remote.$remote.push line or you need
to provide a command line switch. But if you do not tell
explicitly what you want, "git push" will not do anything
for you.
I'm not sure if we ever switch to 4). But already with 3) the
default changed. So a warning seems to be appropriate. But if
we go as outlined below, it's probably a different warning.
I attached a patch that illustrates what "do nothing by default"
means. This patch should _not_ be applied. It's only an
illustration what I'm working on.
> Remember, how much vocal the dissenters might have been on the
> list in the recent discussions, we need to consider the needs of
> the silent majority that has been content with the current
> behaviour for a long time.
>
> The "warning" to annoy them may be a way to get their attention
> and get them involved in a discussion to decide what the default
> should be. But changing the default without giving the people
> who do not like the _new_ default a way to avoid inconvenience
> of always typing --matching or --current is not nice. And
> honestly, I do not think there is one single default that is
> good for everybody.
Personally, I'd switch to the do-nothing default immediately.
But you are right. More work is needed to have a smooth transition.
> We should be doing better.
>
> A smoother transition route would be:
>
> - Keep "matching" the built-in default for now;
>
> - Take your patches (but drop "warning" bits at this point) to
> introduce 'matching' and 'current' behaviours, and a way to
> override the built-in default from the command line;
>
> - Introduce a configuration 'push.defaultRefs' ('matching' or
> 'current') to override that built-in default, so people who
> prefer 'current' can override the built-in default, without
> having to type --current every time.
Sounds like a plan.
If we have the configuration variable, maybe we could switch
off the default behaviour immediately. Setting a single global
config variable once would be sufficient to get it back. So,
we could change the default and print a recommendation to run
'git config --global push.defaultRefs matching' to get it back.
...
> After all that happens, we can start discussing what the
> built-in default should be. When it is changed after the
> discussion concludes (which may never happen), people who want
> to keep 'matching' behaviour would have had the configuration
> mechanism to override that built-in default for some time during
> the discussion period. So the beginning of that discussion
> period is when we should start talking about "We might change
> the default soon; set the configuration to your liking if you do
> not want to get affected" in the warning.
... And we'd not even start the discussion. Because there's no
need to. Every user should make a choice, once. We do not
provide a default (which obviously will trigger another discussion ;)
> Then after that, we may or may not decide to change the default.
> Even if we end up not changing the default, 'current' people
> will then have a way (push.matching = false) to tailor their git
> for their liking, so everybody wins.
>
>> DESCRIPTION
>> @@ -63,6 +63,12 @@ the remote repository.
>> Instead of naming each ref to push, specifies that all
>> refs under `$GIT_DIR/refs/heads/` be pushed.
>>
>> +\--matching::
>> + Instead of naming each ref to push, specifies that matching
>> + refs under `$GIT_DIR/refs/heads/` be pushed. Matching means
>> + the branch exists locally and at the remote under the same name.
>> + Currently, this is the default. But this will change in the
>> future.
>
> For the above reason, "But this will..." is a bit premature.
I'll change the plan and will come back with a full
implementation.
Thanks for the helpful comments.
Steffen
[-- Attachment #2: 0001-push-do-nothing-by-default.patch --]
[-- Type: application/octet-stream, Size: 3054 bytes --]
From a97c117794c631f556f87419a3dbaa702b858d95 Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Sun, 18 Nov 2007 19:22:30 +0100
Subject: [PATCH] push: do nothing by default
We used to push all matching branches. This behaviour
was suitable in many situations, but sometimes confusing.
This commit switches off the default. push now dies instead.
WORK IN PROGRESS. NOT-SIGNED-OFF.
---
builtin-push.c | 9 +++++++--
t/t5516-fetch-push.sh | 13 ++++---------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index e5646d4..e637540 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -143,8 +143,13 @@ int cmd_push(int argc, const char **argv, const char *prefix)
fprintf(stderr, "--all, --matching, and --current are mutual exclusive.\n");
usage_with_options(push_usage, options);
}
- if ((all || matching || current) && refspec)
- usage_with_options(push_usage, options);
+ if (all || matching || current) {
+ if (refspec)
+ usage_with_options(push_usage, options);
+ } else {
+ if (!refspec)
+ die("No default action found.");
+ }
if (!all && !matching && !current && !refspec)
fprintf(stderr, "Warning: assuming '--matching'."
" This default will change in the future.\n");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 20e0796..48689b9 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -108,11 +108,6 @@ test_expect_code 129 'push command line options (2)' '
git push --matching testrepo master
'
-test_expect_success 'push command line options (3)' '
- git push testrepo 2>stderr.txt &&
- grep -q "Warning: assuming.*--matching" stderr.txt
-'
-
test_expect_code 129 'push command line options (4)' '
git push --all --current testrepo
'
@@ -154,7 +149,7 @@ test_expect_success 'push with wildcard' '
test_expect_success 'push with matching heads' '
mk_test heads/master &&
- git push testrepo &&
+ git push --matching testrepo &&
check_push_result $the_commit heads/master
'
@@ -319,7 +314,7 @@ test_expect_success 'push with dry-run' '
cd testrepo &&
old_commit=$(git show-ref -s --verify refs/heads/master) &&
cd .. &&
- git push --dry-run testrepo &&
+ git push --dry-run --matching testrepo &&
check_push_result $old_commit heads/master
'
@@ -331,7 +326,7 @@ test_expect_success 'push updates local refs' '
cd .. &&
git clone parent child && cd child &&
echo two >foo && git commit -a -m two &&
- git push &&
+ git push --matching &&
test $(git rev-parse master) = $(git rev-parse remotes/origin/master)
'
@@ -346,7 +341,7 @@ test_expect_success 'push does not update local refs on failure' '
cd .. &&
git clone parent child && cd child &&
echo two >foo && git commit -a -m two || exit 1
- git push && exit 1
+ git push --matching && exit 1
test $(git rev-parse master) != $(git rev-parse remotes/origin/master)
'
--
1.5.3.5.750.gc43b
[-- Attachment #3: Type: text/plain, Size: 1 bytes --]
^ permalink raw reply related
* Re: git merge no longer handles add/add
From: Junio C Hamano @ 2007-11-19 6:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <46a038f90711181929x4bf0794eue73a5dbac8e2688a@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On Nov 19, 2007 4:18 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>> Happens with recursive and resolve. Happy to provide a minimal repro
>> case, but I think this is fairly obvious...
>
> Steps to repro...
>
> mkdir repro
> cd repro/
> cp /etc/resolv.conf ./resolv.conf
> git init
> git add resolv.conf
> git commit -m 'a' resolv.conf
> cp resolv.conf resolv-1.conf
> git add resolv-1.conf
> git commit -m 'a1' resolv-1.conf
> echo blabla >> resolv-1.conf
**************
> git commit -m 'a2' resolv-1.conf
> git-branch other HEAD^^
> git checkout other
> cp resolv.conf resolv-1.conf
> git add resolv-1.conf
> git commit -m 'b'
> git checkout master
> git merge other
> ...
> Auto-merged resolv-1.conf
> CONFLICT (add/add): Merge conflict in resolv-1.conf
> Automatic merge failed; fix conflicts and then commit the result.
As far as the point of the merge is concerned, that's an add/add
of _different_ contents, and we have always left the conflict to
resolve for you since day one. The only case we handle without
complaining is the accidental *clean* merge. Both branches adds
the path *identically* compared to the common ancestor.
The very initial implementation of merge may have used the total
emptyness as the common ancestor for the merge, and later we
made it a bit more pleasant to resolve by computing the common
part of the file from the two branches to be used as a fake
ancestor contents. But the fact we left the result as conflict
for you to validate hasn't changed and will not change.
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 7:27 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <EA5C3227-12E1-43C4-96E8-43BABF26792B@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
>> Together with your [PATCH 1/2], I like the general direction
>> these patckes are taking us, but it feels a bit too hasty. I
>> personally am not convinced that switching to --current for
>> everybody is a good move.
>>
>>> ...
>>
> I think 3) is the interesting case. "git push" should do
> nothing by default.
NO WAY.
Making things cumbersome to everybody does not achieve anything
useful except for a false sense of equality, does it?
Drop that step (3). That is not useful to anybody.
^ permalink raw reply
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Johannes Sixt @ 2007-11-19 7:39 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1195407366-1610-1-git-send-email-pkufranky@gmail.com>
Ping Yin schrieb:
> When 'FILE *fp' is assigned to child_process.out and then start_command or
> run_command is run, the standard output of the child process is expected to
> be outputed to fp. However, sometimes fp is not expected to be closed since
> further IO may be still performmed on fp.
> ---
> run-command.c | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/run-command.c b/run-command.c
> index 476d00c..4e5f58d 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
>
> if (need_in)
> close(fdin[0]);
> - else if (cmd->in)
> - close(cmd->in);
>
> if (need_out)
> close(fdout[1]);
> - else if (cmd->out > 1)
> - close(cmd->out);
>
> if (need_err)
> close(fderr[1]);
This is dangerous! You have to audit all current callers whether they close
cmd->in or cmd->out (if they don't need the fd anymore). Otherwise you risk
to keep a writable pipe end open and then the reader hangs, waiting for
input that will never arrive.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Documentation: Fix references to deprecated commands
From: Jonas Fonseca @ 2007-11-19 7:44 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Junio C Hamano, Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <20071119015411.GA4978@fieldses.org>
J. Bruce Fields <bfields@fieldses.org> wrote Sun, Nov 18, 2007:
> On Mon, Nov 12, 2007 at 01:32:51AM +0100, Jonas Fonseca wrote:
> > Subject: [PATCH] Documentation: Fix references to deprecated commands
> >
> > ... by changing git-tar-tree reference to git-archive and removing
> > seemingly unrelevant footnote about git-ssh-{fetch,upload}.
>
> Makes sense to me, but for some reason git-am complains about a corrupt
> patch when I feed it this email. I reconstructed it by hand, fixed up
> one more reference to git-tar-tree, and applied to my tree.
It should have been merged in a4e57e75c95c66c32da6b106313bc847110794ba.
And yes, as Junio also pointed out, I deleted some context lines at the
end of the patch.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 7:50 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <7vejempudf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Steffen Prohaska <prohaska@zib.de> writes:
> ...
>> I think 3) is the interesting case. "git push" should do
>> nothing by default.
>
> NO WAY.
>
> Making things cumbersome to everybody does not achieve anything
> useful except for a false sense of equality, does it?
>
> Drop that step (3). That is not useful to anybody.
Thinking about it a bit more, I think my wording was a bit too
strong and needs clarifying explanations.
In a case like this, a fix of a "misfeature" for somebody is a
regression for somebody else. Because there is no single right
default that is appropriate for everybody.
At least having _one_ default (and picking arbitrarily the
historical default as that one default) is better than no
default at all. The former will not inconvenience anybody by
forcing what has been necessary from before. The latter will
hurt the lucky ones whose preferred way happened to be the
historical default.
Keeping the status quo, however, will inconvinience unfortunate
people whose preferred way was not the historical default.
That's where we start to tackle the problem, by introducing the
configuration variable.
If we can come up with a way to tell projects that use the
workflow better served with --current, perhaps when a remote is
added to the repository (either the initial clone or "git remote
add") and/or when a new branch is created. If we automatically
set up the configuration "push.defaultRefs = current" in such a
case, I suspect that we do not have to have the built-in default
(at least, the value of the built-in default would not matter
much).
^ permalink raw reply
* [PATCH Illustration] branch --contains=<commit>
From: Junio C Hamano @ 2007-11-19 8:04 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <7v4pfircka.fsf@gitster.siamese.dyndns.org>
This renames the --with=<commit> option to --contains=<commit>, but still
supports the earlier --with=<commit> variant as a hidden synonym.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* An example usage of the ".help = NULL" member in the options
structure.
builtin-branch.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index fd36e4f..5dc0c57 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -562,9 +562,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"),
OPT_SET_INT('r', NULL, &kinds, "act on remote-tracking branches",
REF_REMOTE_BRANCH),
- OPT_CALLBACK(0, "with", &with_commit, "commit",
+ OPT_CALLBACK(0, "contains",&with_commit, "commit",
"print only branches that contain the commit",
opt_parse_with_commit),
+ OPT_CALLBACK(0, "with", &with_commit, "commit",
+ NULL,
+ opt_parse_with_commit),
OPT__ABBREV(&abbrev),
OPT_GROUP("Specific git-branch actions:"),
--
1.5.3.6.1788.gcc5c4
^ permalink raw reply related
* [PATCH] Further clarify clean.requireForce changes
From: Wincent Colaiuta @ 2007-11-19 8:06 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
Mention the -f switch in the release notes for clean.requireForce to avoid
possible misunderstandings.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/RelNotes-1.5.4.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index 96ec55e..a4a2a7f 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -33,8 +33,9 @@ Updates since v1.5.3
too many loose objects.
* You need to explicitly set clean.requireForce to "false" to allow
- git-clean to do any damage (lack of the configuration variable
- used to mean "do not require", but we now use the safer default).
+ git-clean without -f to do any damage (lack of the configuration
+ variable used to mean "do not require", but we now use the safer
+ default).
* git-push has been rewritten in C.
--
1.5.3.5.737.gdee1b
^ permalink raw reply related
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Steffen Prohaska @ 2007-11-19 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vejempudf.fsf@gitster.siamese.dyndns.org>
On Nov 19, 2007, at 8:27 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>>> Together with your [PATCH 1/2], I like the general direction
>>> these patckes are taking us, but it feels a bit too hasty. I
>>> personally am not convinced that switching to --current for
>>> everybody is a good move.
>>>
>>>> ...
>>>
>> I think 3) is the interesting case. "git push" should do
>> nothing by default.
>
> NO WAY.
>
> Making things cumbersome to everybody does not achieve anything
> useful except for a false sense of equality, does it?
If forces people to make a decision. And it will hopefully reduce
the amount of questions
"What does '! [rejected] master -> master (non-fast forward)' mean"?
At least I am pretty sure that it will reduce the number of
times I'll be asked this question. Because I'll ask people to
set a reasonable default. But if they forget to do so, they'll be
reminded by "git push", before calling me.
And with "push.defaultRefs = matching" it's easy to tell push
once and forever which decision you made.
> Drop that step (3). That is not useful to anybody.
From you follow-up mail:
> Thinking about it a bit more, I think my wording was a bit too
> strong and needs clarifying explanations.
>
> In a case like this, a fix of a "misfeature" for somebody is a
> regression for somebody else. Because there is no single right
> default that is appropriate for everybody.
>
> At least having _one_ default (and picking arbitrarily the
> historical default as that one default) is better than no
> default at all. The former will not inconvenience anybody by
> forcing what has been necessary from before. The latter will
> hurt the lucky ones whose preferred way happened to be the
> historical default.
Well, here we disagree. My point is: if there's no single
right default, then it's better to force the user to make
the decision.
> Keeping the status quo, however, will inconvinience unfortunate
> people whose preferred way was not the historical default.
> That's where we start to tackle the problem, by introducing the
> configuration variable.
>
> If we can come up with a way to tell projects that use the
> workflow better served with --current, perhaps when a remote is
> added to the repository (either the initial clone or "git remote
> add") and/or when a new branch is created. If we automatically
> set up the configuration "push.defaultRefs = current" in such a
> case, I suspect that we do not have to have the built-in default
> (at least, the value of the built-in default would not matter
> much).
That's beyond what I plan to implement.
Anyway, I'll not change the default behaviour.
But then, if I think a bit more, I don't see a point in
providing the push.defaultRefs configuration. The default
_is_ and _will forever be_ '--matching'. That's it. If a
user wants to have something different, either he needs to
tell on the command line (e.g. '--all', '--current'); or he
can use the a remote.*.push configuration.
That's easier to explain than a configuration variable
"push.defaultRefs", which he can set to "current". Or he is
allowed to set it to "matching" without triggering an error. But
this wouldn't change anything, because it's the default anyway.
Then why should someone ever set it to "matching"?
And further, if we have no plans for changing the default, it's
useless to introduce a switch "--matching". So if the plan is
to stick with the current default forever, then I'll withdraw
my patch that introduces "--matching".
What's left is a new switch "--current". Less code, easy
to explain.
Steffen
^ permalink raw reply
* Re: [PATCH v2] git-send-email: show all headers when sending mail
From: Junio C Hamano @ 2007-11-19 8:17 UTC (permalink / raw)
To: David D. Kilzer; +Cc: git
In-Reply-To: <1195445695-27262-1-git-send-email-ddkilzer@kilzer.net>
Thanks. Looks nice and obviously correct.
One thing that has been bugging me for a long time now stands
out like a sore thumb much more: empty Cc: is shown.
$ git-send-email --dry-run --to=junio@my.isp.net 0001-branch-contains.txt
Who should the emails appear to be from? [Junio C Hamano <gitster@pobox.com>]
Emails will be sent from: Junio C Hamano <gitster@pobox.com>
Message-ID to be used as In-Reply-To for the first email?
0001-branch-contains.txt
Dry-OK. Log says:
Date: Mon, 19 Nov 2007 00:10:04 -0800
Server: my.isp.net
MAIL FROM:<gitster@pobox.com>
RCPT TO:<junio@my.isp.net>
From: Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] branch --contains=<commit>
Cc:
To: junkio@cox.net
Result: OK
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 8:35 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <53F12F4D-73C5-446E-9A97-9D2D4CA9DF9F@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> What's left is a new switch "--current". Less code, easy
> to explain.
But won't that force the "current" people always type that from
the command line, as your previous point was that your earlier
patch to say "remote.$there.push = HEAD" does not work that way?
If that configuration works as expected, then I'd 100% agree
that we would not need push.defaultRefs. Either you do not have
"push" at all if your preference is --matching, or you do have
"push = HEAD" if your preference is --current. But if it
doesn't (which was what I gathered from your earlier response),
having a configuration would help them, wouldn't it?
Changing the default, if it will ever happen, is _NOT_ to help
people who are already using git and want "current" NOW. The
current users cannot be helped _unless_ we switch overnight, but
that is not an option as it introduces a regression to people's
established workflow.
Changing the default is to help new users who will come in the
future, if majority of the existing users find --current easier
to explain to new people _they_ need to train.
^ permalink raw reply
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Junio C Hamano @ 2007-11-19 8:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ping Yin, git
In-Reply-To: <47413DB9.9030306@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Ping Yin schrieb:
>> When 'FILE *fp' is assigned to child_process.out and then start_command or
>> run_command is run, the standard output of the child process is expected to
>> be outputed to fp. However, sometimes fp is not expected to be closed since
>> further IO may be still performmed on fp.
>> ---
>> run-command.c | 4 ----
>> 1 files changed, 0 insertions(+), 4 deletions(-)
>>
>> diff --git a/run-command.c b/run-command.c
>> index 476d00c..4e5f58d 100644
>> --- a/run-command.c
>> +++ b/run-command.c
>> @@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
>> if (need_in)
>> close(fdin[0]);
>> - else if (cmd->in)
>> - close(cmd->in);
>> if (need_out)
>> close(fdout[1]);
>> - else if (cmd->out > 1)
>> - close(cmd->out);
>> if (need_err)
>> close(fderr[1]);
>
> This is dangerous! You have to audit all current callers whether they
> close cmd->in or cmd->out (if they don't need the fd
> anymore).
I am reasonably sure that they are already relying on these auto
closing of the file descriptors.
Funny that somebody falls into the trap the day after we
discussed it on another thread.
^ permalink raw reply
* Re: [PATCH/RFC] parse-options: allow to define hidden synonym options
From: Pierre Habouzit @ 2007-11-19 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pfircka.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4852 bytes --]
On lun, nov 19, 2007 at 06:09:41 +0000, Junio C Hamano wrote:
> By setting the help member to NULL, you can implement an option
> that is not shown in the "git-cmd -h" help output. This is
> useful to support backward compatible synonyms without
> cluttering the help text.
Sorry I'm not very present those days, but oh well...
The idea looks nice, though if we are doing this, I'd like to see it
fix other problems at the same time. We sometimes have "internal"
commands switches and other cases of alias.
I wonder if it wouldn't be better that we have some kind of --help-all
switch that would show them _all_ and a way (through another flag ?) to
hide those additional options by default.
And defining an alias would then be:
{ OPTION_SOME_TYPE, 0, "alias-name", &some_value, "some-arg",
"backward compatibility alias for \"foo\"", PARSE_OPT_HIDE, ... }
or:
{ OPTION_SOME_TYPE, 0, "plumbing-dark-think", &some_value, "some-arg",
"internal plumbing switch used in", PARSE_OPT_HIDE, ... }
I personnaly don't like that parse-opt sees more options than what it
says it sees, else with your patch, if the user gives ambiguous
abbreviated long switches, he'll get "--w is ambiguous, could be
`--whith` or `--wibble`" whereas he never knew that --with existed in
the first place.
That gives something more along the lines of :
From 860a5bf335e44dd2bbe5f30620c99d174b697f69 Mon Sep 17 00:00:00 2001
From: Pierre Habouzit <madcoder@debian.org>
Date: Mon, 19 Nov 2007 10:21:44 +0100
Subject: [PATCH] parse-options: Allow to hide options from the default usage.
This is useful for backward-compatibility aliases, or very advanced command
line switches introduced for internal git usages and have no real use for a
user.
parse-options still shows them if the user asks for --help-all.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
parse-options.c | 17 +++++++++++++++--
parse-options.h | 3 +++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index d3e608a..807e443 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -216,6 +216,9 @@ is_abbreviated:
return error("unknown option `%s'", arg);
}
+static NORETURN void usage_with_options_internal(const char * const *,
+ const struct option *, int);
+
int parse_options(int argc, const char **argv, const struct option *options,
const char * const usagestr[], int flags)
{
@@ -249,6 +252,8 @@ int parse_options(int argc, const char **argv, const struct option *options,
break;
}
+ if (!strcmp(arg + 2, "help-all"))
+ usage_with_options_internal(usagestr, options, 1);
if (!strcmp(arg + 2, "help"))
usage_with_options(usagestr, options);
if (parse_long_opt(&args, arg + 2, options))
@@ -263,8 +268,8 @@ int parse_options(int argc, const char **argv, const struct option *options,
#define USAGE_OPTS_WIDTH 24
#define USAGE_GAP 2
-void usage_with_options(const char * const *usagestr,
- const struct option *opts)
+void usage_with_options_internal(const char * const *usagestr,
+ const struct option *opts, int full)
{
fprintf(stderr, "usage: %s\n", *usagestr++);
while (*usagestr && **usagestr)
@@ -285,6 +290,8 @@ void usage_with_options(const char * const *usagestr,
fprintf(stderr, "%s\n", opts->help);
continue;
}
+ if (!full & (opts->flags & PARSE_OPT_HIDDEN))
+ continue;
pos = fprintf(stderr, " ");
if (opts->short_name)
@@ -335,6 +342,12 @@ void usage_with_options(const char * const *usagestr,
exit(129);
}
+void usage_with_options(const char * const *usagestr,
+ const struct option *opts)
+{
+ usage_with_options_internal(usagestr, opts, 0);
+}
+
/*----- some often used options -----*/
#include "cache.h"
diff --git a/parse-options.h b/parse-options.h
index a8760ac..102ac31 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -24,6 +24,7 @@ enum parse_opt_option_flags {
PARSE_OPT_OPTARG = 1,
PARSE_OPT_NOARG = 2,
PARSE_OPT_NONEG = 4,
+ PARSE_OPT_HIDDEN = 8,
};
struct option;
@@ -57,6 +58,8 @@ typedef int parse_opt_cb(const struct option *, const char *arg, int unset);
* PARSE_OPT_OPTARG: says that the argument is optionnal (not for BOOLEANs)
* PARSE_OPT_NOARG: says that this option takes no argument, for CALLBACKs
* PARSE_OPT_NONEG: says that this option cannot be negated
+ * PARSE_OPT_HIDDEN this option is skipped in the default usage, showed in
+ * the long one.
*
* `callback`::
* pointer to the callback to use for OPTION_CALLBACK.
--
1.5.3.5.1795.g5421e-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Andreas Ericsson @ 2007-11-19 9:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <EA5C3227-12E1-43C4-96E8-43BABF26792B@zib.de>
Steffen Prohaska wrote:
>
> On Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:
>
>
>
>> I do not think it is "Often you want" that makes it awkward.
>>
>> Instead, the awkward case is if you do the "only the current"
>> push NOT often enough. If it is often enough, you set the
>> configuration once and the awkwardness is behind you.
>>
>> If however it is not often enough, you cannot afford to have the
>> configuration above, because that would force you to tell from
>> the command line which branches, not just the current one, to
>> push, and that is inconvenient because it is not rare enough.
>
> Will try to rephrase the commit message.
>
>
>> Together with your [PATCH 1/2], I like the general direction
>> these patckes are taking us, but it feels a bit too hasty. I
>> personally am not convinced that switching to --current for
>> everybody is a good move.
>>
>>> ...
>>> Maybe in two years (that's twice an eternity in git time scales):
>>>
>>> 4) make "git push --current" the default.
>>
>> If these, both the uncertainly expressed by "Maybe" and "twice
>> an eternity" are true, which they are, the new warning in the
>> current patch are inappropriate. Many people's settings depend
>> on a working "push the matching refs" behaviour, and we need a
>> very good excuse to annoy the existing happy users with such a
>> warning.
>
> I think 3) is the interesting case. "git push" should do
> nothing by default. Either you can configure "git push" to do
> something by setting a remote.$remote.push line or you need
> to provide a command line switch. But if you do not tell
> explicitly what you want, "git push" will not do anything
> for you.
>
I'd really, really hate that. I often have changes on several branches
when I push. I like the behaviour as it is today.
>
>> Remember, how much vocal the dissenters might have been on the
>> list in the recent discussions, we need to consider the needs of
>> the silent majority that has been content with the current
>> behaviour for a long time.
>>
>> The "warning" to annoy them may be a way to get their attention
>> and get them involved in a discussion to decide what the default
>> should be. But changing the default without giving the people
>> who do not like the _new_ default a way to avoid inconvenience
>> of always typing --matching or --current is not nice. And
>> honestly, I do not think there is one single default that is
>> good for everybody.
>
> Personally, I'd switch to the do-nothing default immediately.
> But you are right. More work is needed to have a smooth transition.
>
>
>> We should be doing better.
>>
>> A smoother transition route would be:
>>
>> - Keep "matching" the built-in default for now;
>>
>> - Take your patches (but drop "warning" bits at this point) to
>> introduce 'matching' and 'current' behaviours, and a way to
>> override the built-in default from the command line;
>>
>> - Introduce a configuration 'push.defaultRefs' ('matching' or
>> 'current') to override that built-in default, so people who
>> prefer 'current' can override the built-in default, without
>> having to type --current every time.
>
> Sounds like a plan.
>
> If we have the configuration variable, maybe we could switch
> off the default behaviour immediately. Setting a single global
> config variable once would be sufficient to get it back. So,
> we could change the default and print a recommendation to run
> 'git config --global push.defaultRefs matching' to get it back.
>
Ugh. People who neither know nor care about git development will
wonder why the hell they now have to tell git something in order
for it to do something it's always done anyway. The majority of
git users never read release-notes. They just do "yum update" and
then go about their business the same way they've always done.
Newcomers that obviously have no such configuration will wonder
why they're getting warnings from using the standard command-set.
> ...
>
>> After all that happens, we can start discussing what the
>> built-in default should be. When it is changed after the
>> discussion concludes (which may never happen), people who want
>> to keep 'matching' behaviour would have had the configuration
>> mechanism to override that built-in default for some time during
>> the discussion period. So the beginning of that discussion
>> period is when we should start talking about "We might change
>> the default soon; set the configuration to your liking if you do
>> not want to get affected" in the warning.
>
> ... And we'd not even start the discussion. Because there's no
> need to. Every user should make a choice, once. We do not
> provide a default (which obviously will trigger another discussion ;)
>
If the default's to be changed, making it default to no-op is really
the only sensible thing to do. Otherwise I'm guessing a lot of people
that actually count on the current behaviour will get quite vexed, and
--current is definitely not the universally correct default thing to do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Andreas Ericsson @ 2007-11-19 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin
In-Reply-To: <7v4pfiptb5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> If we can come up with a way to tell projects that use the
> workflow better served with --current, perhaps when a remote is
> added to the repository (either the initial clone or "git remote
> add") and/or when a new branch is created. If we automatically
> set up the configuration "push.defaultRefs = current" in such a
> case, I suspect that we do not have to have the built-in default
> (at least, the value of the built-in default would not matter
> much).
So when someone who's been using git of today adds a new remote
with a newer git, all of a sudden the default push behaviour
changes for that repo?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Improve description of git-branch -d and -D in man page.
From: Sergei Organov @ 2007-11-19 9:49 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jakub Narebski, Steffen Prohaska, git, Junio C Hamano
In-Reply-To: <20071117195144.GF5198@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> Some users expect that deleting a remote-tracking branch would prevent
> fetch from creating it again, so be explcit about that it's not the case.
> Also be a little more explicit about what fully merged means.
>
> Signed-off-by: Jan Hudec <bulb@ucw.cz>
> ---
>
> On Sat, Nov 17, 2007 at 20:12:56 +0100, Jan Hudec wrote:
>> On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
>> > <quote Documentation/git-branch.txt>
>> > Delete unneeded branch::
>> > +
>> > ------------
>> > $ git clone git://git.kernel.org/.../git.git my.git
>> > $ cd my.git
>> > $ git branch -d -r origin/todo origin/html origin/man <1>
>> > $ git branch -D test <2>
>> > ------------
>> > +
>> > <1> Delete remote-tracking branches "todo", "html", "man"
>> > </quote>
>> >
>> > That's *exactly* what I did! And it *doesn't work*! Well, it does delete
>> > the branches, but they are automagically re-created on the next fetch,
>> > so "deleting" them this way is useless.
>>
>> Of course it *does* work. It *deletes* the branches. There is not a single
>> word about stopping fetch getting them!
>>
>> Obviously given that the example is slightly contrived, it should really
>> be mentioned that it does not affect fetch at all.
>
> Would this make the description obvious enough?
Yes, I think now it describes the actual behavior much much better, --
thanks.
--
Sergei.
^ 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