* Re: [GSoC] Google Summer of Code 2009 - new ideas
From: Jan Janak @ 2009-03-07 1:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn Pearce
In-Reply-To: <200903070144.17457.jnareb@gmail.com>
On 07-03 01:44, Jakub Narebski wrote:
> Time to submit application as mentoring organization to
> Google Summer of Code 2009 is close: March 9 -- March 13.
>
> I'd like to add a few ideas to SoC2009Ideas wiki page, but before I do
> this I'd like to ask for comments. (The proposals also lacks proposed
> mentor).
>
> I am wondering if it would be worth it to make a separate class between
> "New to Git?" easy tasks, and "Larger Projects" hard tasks...
>
> BTW. some of ideas didn't make it from SoC2008Ideas wiki page to current
> year page, namely:
> * Apply sparse To Fix Errors
> * Lazy clone / remote alternates
> * Implement git-submodule using .gitlink file
> * Teach git-apply the 3-way merge fallback git-am knows
> * Better Emacs integration
There are already two (IMHO good) emacs modes for git, magit and egg:
http://zagadka.vm.bytemark.co.uk/magit/
http://github.com/bogolisk/egg/tree/master
Jan.
^ permalink raw reply
* Re: [PATCH 3/3] builtin-merge: add support for default merge options
From: Junio C Hamano @ 2009-03-07 0:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, jean-luc malet
In-Reply-To: <76718490903061516l62869424q4bd4cfa64fe2195e@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Fri, Mar 6, 2009 at 5:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> When you are on branch "frotz", your config have both merge.options and
>> branch.frotz.mergeoptions, and you give some other options from the
>> command line, how should they interact? I'd expect the branch.*.options
>> to take effect, ignoring merge.options entirely.
>
> Really? I didn't think that would be consistent with the fact that the
> the command line options override branch.*.options, but don't replace
> them.
I think cumulative option in configuration is bad in practice, but I'll
explain why after talking about something else.
I think it would be much better if you did not introduce a new
configuration merge.options which is not consistent with everything else
to begin with.
Instead, if your addition was literally to allow saying things like this,
it would be much easier to understand.
[branch "*"]
mergeoptions = ...
remote = origin
rebase = true
[branch "frotz"]
mergeoptions = ; nothing
rebase = false
[branch "nitfol"]
remote = xyzzy
When on branch 'nitfol', because there is an overriding "remote" defined,
we would not look at branch.*.remote and fetch from xyzzy instead of
fetching from the default origin. Because there is no "rebase" defined
for that branch, we would use branch.*.rebase=true from the fall-back
default.
When on branch 'frotz', because you have an explicit mergeoptions that
says "I do not want any", it would override whatever is defined for the
corresponding fall-back default branch.*.mergeoptions.
Having explained that I think branch.*.mergeoptions is syntactically nicer
and more extensible as the UI to the end user, let's discuss the
"cumulative" aspect. In the following, I'll keep using branch.*.$option,
but you can read it as if I said merge.options and the discussion is the
same.
There are two reasons why you as an end user specify a concrete value
(e.g. "empty") for a concrete branch name (e.g. branch.frotz.mergeoptions).
One is because you know the current value set to the fall-back default
(e.g. branch.*.mergeoptions) is not suitable for this particular branch.
Another is because you know you may want to change the fall-back default
sometime in the future, and you do not want that to affect your setting
you are making for this particular branch today.
For the purpose of the first reason above, if you allowed cumulative
option, the end user needs to inspect branch.*.$option and come up with a
countermanding set of options to set to branch.frotz.$option. If there is
no cumulative option, the end user does not have to worry about what
branch.*.$option says. Non-cumulative is simply easier to understand.
For the purpose of the second reason above, when the user has to update
branch.frotz.$option because some external situation changed (e.g. the
user used to be an e-mail contributor, but now gained "push privilege";
the user became the primary maintainer; etc.), the same argument on
maintenance burden as above holds. To update branch.*.$option, you need
to inspect every branch.$specific.$option (or lack thereof) as well in
either way.
So overall, cumulative configuration tend to be more cumbersome for the
end user to manage.
You cannot draw a direct analogy with the command line options, which is
used as a single-shot override by nature. The user knows what usually
happens when he says "git pull" while on branch 'frotz' without options,
and countermanding specific aspects (but not necessarily others) of the
operation for this single invocation. Because the configuration values
are set so that the user can set-and-forget the exact syntax to invoke
each feature, cumulativeness between configured default and command line
override makes more sense.
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Jakub Narebski @ 2009-03-07 0:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <m3myc2ucfb.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Dear fans of Git,
> >
> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > how to
> >
> > Use Git For What It Is Not Indended
> >
> > As most of you probably did not find my blog yet, this may come as a
> > surprise to you, but it will not be the only surprise in this email.
[...]
> Another candidate for UGFWIINI contest: Gitorial. Here is explanation
> And similar thing: Homoiconic. Here is explanation
And here is yet another UGFWINII candidate: Flashbake.
Here is explanation:
Flashbake is a set of Python scripts that check your hot files for
changes every 15 minutes, and checks in any changed files to a local
git repository. Flashbake records any changes made since the last
check, annotating them with the current timezone on the
system-clock, the weather in that timezone as fetched from Google,
and the last three headlines with your by-line under them in your
blog's RSS feed (I've been characterizing this as "Where am I,
what's it like there, and what am I thinking about?"). It also
records your computer's uptime.
It is intendend illuminate the creative process in a way that often
reveals the hidden stories behind the books we care about.
References:
===========
[1] "Flashbake: Free version-control for writers using git"
by Cory Doctorow describes insporation for Flashbake
http://www.boingboing.net/2009/02/13/flashbake-free-versi.html
http://craphound.com/?p=2171
[2] "Cory Doctorow on Lifestreaming Contextual Snapshots Using New
Tool Flashbake" by Mark Krynsky
http://lifestreamblog.com/cory-doctorow-on-lifestreaming-contextual-snapshots-using-new-tool-flashbake/
[3] Flashbake announcement on its author blog
http://thecommandline.net/2009/02/13/flashbake/
[3] Flashbake home page
http://bitbucketlabs.net/flashbake/
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH v2 3/3] builtin-merge: add support for default merge options
From: Jay Soffian @ 2009-03-07 0:44 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, jean-luc malet, Junio C Hamano
In-Reply-To: <76718490903061516l62869424q4bd4cfa64fe2195e@mail.gmail.com>
This patch teaches merge a new setting, merge.options, which is
processed before any of the other merge configuration settings. It may
be used to establish a default which can then be overridden by more
specific branch.<name>.mergeoptions (or, obviously, command-line
switches).
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
On Fri, Mar 6, 2009 at 5:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If for some reason you would want to have cumulative options across
> branch.*.merge, merge.options and the command line, then you would instead
> keep two separate strings, and call git_config_option_string() for both of
> them, before processing the real command line options.
Which is what this version does. I also made the explanation of this behavior
in the man page more explicit.
Documentation/git-merge.txt | 12 +++++--
builtin-merge.c | 22 +++++++++++--
t/t7600-merge.sh | 69 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 96 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index f7be584..5d80a78 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -47,10 +47,16 @@ CONFIGURATION
-------------
include::merge-config.txt[]
+merge.options::
+ Sets default options for merging. The syntax and supported options are
+ equal to that of 'git-merge'. Arguments are split by spaces, and may be
+ quoted in the same way as alias.* config options.
+
branch.<name>.mergeoptions::
- Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of 'git-merge', but option values
- containing whitespace characters are currently not supported.
+ Sets default options for merging into branch <name>. This setting is
+ handled after and is cumulative to `merge.options`. So it may override,
+ but does replace, any settings appearing there. The syntax is identical
+ to `merge.options`.
HOW MERGE WORKS
---------------
diff --git a/builtin-merge.c b/builtin-merge.c
index 504f2be..d4dc4fe 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,8 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static const char *branch_option_string = NULL;
+static const char *default_option_string = NULL;
static int verbosity;
static struct strategy all_strategy[] = {
@@ -451,10 +453,8 @@ static int git_merge_config(const char *k, const char *v, void *cb)
{
if (branch && !prefixcmp(k, "branch.") &&
!prefixcmp(k + 7, branch) &&
- !strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
- if (git_config_option_string(builtin_merge_options, 0, k, v))
- die("Bad branch.%s.mergeoptions string", branch);
- }
+ !strcmp(k + 7 + strlen(branch), ".mergeoptions"))
+ return git_config_string(&branch_option_string, k, v);
if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
show_diffstat = git_config_bool(k, v);
@@ -462,6 +462,8 @@ static int git_merge_config(const char *k, const char *v, void *cb)
return git_config_string(&pull_twohead, k, v);
else if (!strcmp(k, "pull.octopus"))
return git_config_string(&pull_octopus, k, v);
+ else if (!strcmp(k, "merge.options"))
+ return git_config_string(&default_option_string, k, v);
else if (!strcmp(k, "merge.log") || !strcmp(k, "merge.summary"))
option_log = git_config_bool(k, v);
return git_diff_ui_config(k, v, cb);
@@ -839,6 +841,18 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
head_invalid = 1;
git_config(git_merge_config, NULL);
+ if (default_option_string) {
+ if (git_config_option_string(builtin_merge_options, 0,
+ "merge.options", default_option_string))
+ die("Bad merge.options string");
+ }
+ if (branch_option_string) {
+ strbuf_addf(&buf, "branch.%s.mergeoptions", branch);
+ if (git_config_option_string(builtin_merge_options, 0,
+ buf.buf, branch_option_string))
+ die("Bad %s string", buf.buf);
+ strbuf_reset(&buf);
+ }
/* for color.ui */
if (diff_use_color_default == -1)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 9db8bb4..aaecdab 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -367,6 +367,16 @@ test_expect_success 'merge c1 with c2 (no-commit in config)' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 (no-commit in merge.options)' '
+ git reset --hard c1 &&
+ with_config merge.options --no-commit -- merge c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_mergeheads $c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 (squash in config)' '
git reset --hard c1 &&
with_config branch.master.mergeoptions --squash -- \
@@ -379,6 +389,17 @@ test_expect_success 'merge c1 with c2 (squash in config)' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 (squash in merge.options)' '
+ git reset --hard c1 &&
+ with_config merge.options --squash -- merge c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_no_mergehead &&
+ verify_diff squash.1-5 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'override config option -n with --summary' '
git reset --hard c1 &&
test_tick &&
@@ -425,6 +446,54 @@ test_expect_success 'override config option --stat' '
test_debug 'gitk --all'
+test_expect_success 'override merge.options -n with branch mergeoptions --summary' '
+ git reset --hard c1 &&
+ test_tick &&
+ with_config merge.options -n branch.master.mergeoptions --summary -- \
+ merge c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if ! grep "^ file | *2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was not generated with --summary"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'override merge.options -n with branch mergeoptions --stat' '
+ git reset --hard c1 &&
+ test_tick &&
+ with_config merge.options -n branch.master.mergeoptions --stat -- \
+ merge c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if ! grep "^ file | *2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was not generated with --stat"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'override merge.options --stat' '
+ git reset --hard c1 &&
+ test_tick &&
+ with_config merge.options --stat branch.master.mergeoptions -n -- \
+ merge c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if grep "^ file | *2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was generated"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 (override --no-commit)' '
git reset --hard c1 &&
test_tick &&
--
1.6.2.rc2.332.g5d21b
^ permalink raw reply related
* [GSoC] Google Summer of Code 2009 - new ideas
From: Jakub Narebski @ 2009-03-07 0:44 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce
Time to submit application as mentoring organization to
Google Summer of Code 2009 is close: March 9 -- March 13.
I'd like to add a few ideas to SoC2009Ideas wiki page, but before I do
this I'd like to ask for comments. (The proposals also lacks proposed
mentor).
I am wondering if it would be worth it to make a separate class between
"New to Git?" easy tasks, and "Larger Projects" hard tasks...
BTW. some of ideas didn't make it from SoC2008Ideas wiki page to current
year page, namely:
* Apply sparse To Fix Errors
* Lazy clone / remote alternates
* Implement git-submodule using .gitlink file
* Teach git-apply the 3-way merge fallback git-am knows
* Better Emacs integration
Was this ommision deliberate or accidental?
-- >8 --
= New To Git? New To Open Source Development? =
== Packfile caching for git-daemon ==
Even with delta reuse, enumerating objects to be present in packfile
generates significant load on server for pack-generating protocols,
such as git:// protocol used by git-daemon. Many of requests result in
the same packfile to be generated and sent; examples include full
clone, or fetch of all branches since last update. It would make sense
then to save (cache) packfiles, and if possible avoid regenerating
packfiles by sending them from cache. (Possible extension would be to
send slightly larger pack than needed if one can reuse cached packfile
instead).
The goal is for git-daemon to cache packfiles, use cached packfiles if
possible, and to manage packfile cache. Note that one would need in
the final version some way to specify upper limit on packfile cache
size and some cache entry expire policy.
'''Goal:''' Support for packfile cache in git-daemon,
benchmark server load
'''Language:''' C
== Single credentials ==
Currently if you don't save your username and password in plain-text
`.netrc` file (for HTTP transport), or avoid need for interactive
credentials using public key / private key pair (for SSH), you need to
repeat credentials many times during single git-fetch or git-clone
command. The goal is to reuse existing connections if possible, so the
whole transaction occurs using single connection and single
credentials; if that is not possible cache credentials (in secure way)
so user need to provide username and password at most once.
'''Goal:''' git-fetch and git-clone over HTTPS and git://
requiring providing username and password at most once
'''Language:''' C (perhaps also shell script)
= Larger Projects =
== Directory renames ==
Git deals quite well with renames when merging. One of the corner cases
is when one side renamed some directory, and other side created ''new
files'' in the old-name directory. Git currently creates new files in
resurrected old-name directory, while it could create new files under
new-name directory instead.
There is a bit of controversy about this feature, as for example in
some programming languages (e.g. Java) or in some project build tool
info it is not posible to simply move a file (or create new file in
different directory) without changing file contents. Some say that
is better to fail than to do wrongly clean merge.
'''Goal:''' At minimum option enabling wholesame directory rename
detection. Preferred to add dealing with directory renames also to
merge. At last, one can try to implement "git log --follow" for
directories.
'''Language:''' C
'''See:''' [http://thread.gmane.org/gmane.comp.version-control.git/99529
|RFC PATCH v2 0/2| Detection of directory renames] thread on git
mailing list (via GMane)
'''See also:'''
*
[http://thread.gmane.org/gmane.comp.version-control.git/80912/focus=81362
merge renamed files/directories?] subthread on git mailing list
* [http://thread.gmane.org/gmane.comp.version-control.git/108106
Comments on "Understanding Version Control" by Eric S. Raymond] thread
contains some thoughts on wholesame directory rename detection
* [http://blog.teksol.info/2008/01/16/directory-renames-under-git
Directory renames under Git] blog post notice the issue
* [http://www.markshuttleworth.com/archives/123 Renaming is the killer
app of distributed version control] blog post by Mak Shuttleworth
(pro-Bazaar).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH JGIT] Add "compare with Git Index" action.
From: Robin Rosenberg @ 2009-03-07 0:31 UTC (permalink / raw)
To: Yann Simon; +Cc: Shawn O. Pearce, git
In-Reply-To: <49AD38EE.5090509@gmail.com>
tisdag 03 mars 2009 15:04:30 skrev Yann Simon <yann.simon.fr@gmail.com>:
> In the Compare With... menu, the "Git Index" action opens
> a diff editor that compares the workspace version of a file and its
> index version.
>
> The local file can be modified and saved.
>
> The staged version can be modified and saved. This updates the index.
> For this, add methods into GitIndex to allow to specify a content
> different from the file.
Saving the index version does not work here. No effect whatsoever.
-- robin
^ permalink raw reply
* Re: git-forest on msysgit
From: Matthieu Moy @ 2009-03-06 23:53 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115F15@EXCHANGE.trad.tradestation.com>
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> I downloaded git-forest, and when I run it I get:
Not answering the question, but did ou know that you get mostly the
same with git log --graph (without installing anthing)?
--
Matthieu
^ permalink raw reply
* Re: allowing aliases to override builtins to support default options
From: Jay Soffian @ 2009-03-06 23:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vhc26qls3.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 6, 2009 at 6:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Because sane shells do not expand aliases when used in a script, and gives
> a handy way to defeat the alias even from the command line.
>
> $ alias ls='ls -aF'
> $ echo ls >script
> $ chmod +x script
>
> and compare:
>
> $ ./script
> $ ls
> $ /bin/ls
Understood. And if git could do the same, still no?
j.
^ permalink raw reply
* Re: allowing aliases to override builtins to support default options
From: Junio C Hamano @ 2009-03-06 23:22 UTC (permalink / raw)
To: Jay Soffian; +Cc: Git Mailing List
In-Reply-To: <76718490903061430s2fbea2dfibe06282fd22b1588@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Currently git does not allow aliases to override builtins. I
> understand the reasoning behind this, but I wonder if it's overly
> conservative.
It is not.
> Most shells support overriding commands with aliases, and I'm not sure
> why git needs to be more conservative than the shell.
Because sane shells do not expand aliases when used in a script, and gives
a handy way to defeat the alias even from the command line.
$ alias ls='ls -aF'
$ echo ls >script
$ chmod +x script
and compare:
$ ./script
$ ls
$ /bin/ls
^ permalink raw reply
* Re: [PATCH 3/3] builtin-merge: add support for default merge options
From: Jay Soffian @ 2009-03-06 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jean-luc malet
In-Reply-To: <7vr61aqngu.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 6, 2009 at 5:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> When you are on branch "frotz", your config have both merge.options and
> branch.frotz.mergeoptions, and you give some other options from the
> command line, how should they interact? I'd expect the branch.*.options
> to take effect, ignoring merge.options entirely.
Really? I didn't think that would be consistent with the fact that the
the command line options override branch.*.options, but don't replace
them. So I specifically coded it such that there are three separate
layers all merged together. (Which is also how I documented it in the
man page.)
> If for some reason you would want to have cumulative options across
Which I do, or I wouldn't have coded it that way. :-)
> branch.*.merge, merge.options and the command line, then you would instead
> keep two separate strings, and call git_config_option_string() for both of
> them, before processing the real command line options.
Ah, right that would be better.
j.
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Johannes Schindelin @ 2009-03-06 23:00 UTC (permalink / raw)
To: Jakub Narebski
Cc: Finn Arne Gangstad, Junio C Hamano, Sverre Rabbelier,
markus.heidelberg, git, John Tapsell, Andreas Ericsson
In-Reply-To: <m3r61aisdo.fsf@localhost.localdomain>
Hi,
On Fri, 6 Mar 2009, Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Fri, 6 Mar 2009, Finn Arne Gangstad wrote:
> >> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
> >>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> >>>>>
> >>>>> Right, I'd like to be able to do:
> >>>>> $ git config push.iamnotretarded true
> >>>>> $ git push
> >>>>
> >>>> LOL! Sverre, you have a way to crack me up...
> >>>
> >>> I found it amusing, too.
> >>>
> >>> It may have some correlation with how well organized your work habit is,
> >>> but I do not think it has much correlation with being retarded. It is
> >>> more about "'matching refs' is the perfect default for _my_ use pattern,
> >>> don't mess with it, please".
> >>
> >> So here is my current WIP suggestion for a new "push.default"
> >> variable, I am not sure if a single entry can express all useful
> >> choices, or if it is a good idea to introduce more default choices
> >> other than "nothing" (with the goal of making it the default in a
> >> later release).
> >
> > Speaking of which, Steffen (who cannot reply right now, since he is AFK
> > for a while) had a patch to install "remote.<branch>.push = HEAD" with
> > clone and remote. Would that be better?
>
> Errr... I thought that "remote.<remotename>.push = HEAD" works?
>
> But note that "remote.<name>.push = HEAD" (push current branch only)
> and "remote.<name>.push = :" (push matching branches, i.e. curent
> behavior) works only if you have remote configured... "git push <URL>"
> won't be affected, and people (probably) would want to either have
> 'nothing' as default, or/and be able to configure it to nothing,
> current, or matching (at least).
The question was not if remote.<remote>.push = HEAD works, but if it is
installed by default.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] http authentication via prompts
From: Fredrik Skolmli @ 2009-03-06 22:52 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49AFEC91.10009@gmail.com>
On Thu, Mar 05, 2009 at 09:15:29AM -0600, Mike Gaffney wrote:
Hi.
> Junio, I'm new to this patch game and using Thunderbird. What's the best way
> to wrap the patch?
I'm not Junio, but I'll give answering a shot anyway. ;-)
See Documentation/SubmittingPatches, line 374-456.
--
Fredrik Skolmli
^ permalink raw reply
* Re: [PATCH 3/3] builtin-merge: add support for default merge options
From: Junio C Hamano @ 2009-03-06 22:46 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, jean-luc malet
In-Reply-To: <9f755b5bae0b02c5cb3e01680acf71fe7153be04.1236377358.git.jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> @@ -838,6 +847,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> if (is_null_sha1(head))
> head_invalid = 1;
>
> + git_config(git_merge_config_default, NULL);
> git_config(git_merge_config, NULL);
The placement of this comes before parse_options(), just like the part
that slurps "branch.*.mergeoptions", so it can be overridden by the
command line just like "branch.*.mergeoptions" can, which is good.
When you are on branch "frotz", your config have both merge.options and
branch.frotz.mergeoptions, and you give some other options from the
command line, how should they interact? I'd expect the branch.*.options
to take effect, ignoring merge.options entirely.
I think the right way to structure this is to change the code in
git_merge_config() that accepts "branch.*.mergeoptions" to just store a
xstrdup() pointer away, add a similar thing in the same function for the
new "merge.options" variable. Get rid of your git_merge_config_default
function that forces git_config() to iterate over the same config file one
more time. And after the config parser returns, run the parse_options
only once.
In other words, the overall code structure would look like this:
static char *options_from_config;
static int options_from_config_taken_from_branch_config;
static int git_merge_config(...)
{
if (branch && !prefixcmp(k, "branch.") ... ) {
/*
* We may have found merge.options first;
* free it and override it with the value of
* branch.*.mergeoptions for the current branch
* we just found.
*/
free(options_from_config);
options_from_config_taken_from_branch_config = 1;
options_from_config = xstrdup(value);
return 0;
}
if (!strcmp(k, "merge.options")) {
/*
* Do not override branch.*.mergeoptions for the
* current branch if we already found one.
*/
if (!options_from_config_taken_from_branch_config)
options_from_config = xstrdup(value);
return 0;
}
...
}
int cmd_merge(...)
{
...
git_config(git_merge_config, NULL);
if (options_from_config)
/*
* There is a "prime" options given in
* the configuration file. Parse it.
*/
git_config_option_string(builtin_merge_options, ...,
options_from_config);
...
argc = parse_options(argc, argv, builtin_merge_options,...);
...
}
If for some reason you would want to have cumulative options across
branch.*.merge, merge.options and the command line, then you would instead
keep two separate strings, and call git_config_option_string() for both of
them, before processing the real command line options.
Hmm?
^ permalink raw reply
* Re: allowing aliases to override builtins to support default options
From: Sverre Rabbelier @ 2009-03-06 22:37 UTC (permalink / raw)
To: Jay Soffian; +Cc: Git Mailing List
In-Reply-To: <76718490903061430s2fbea2dfibe06282fd22b1588@mail.gmail.com>
Heya,
On Fri, Mar 6, 2009 at 23:30, Jay Soffian <jaysoffian@gmail.com> wrote:
> Most shells support overriding commands with aliases, and I'm not sure
> why git needs to be more conservative than the shell. (Although, I
> will say, I hate when vendors alias rm to "rm -i", etc...)
Hmmm, maybe we could require marking such an alias somehow, to signify
that you're aware that you're overriding a builtin? Also, what would
we do the alias 'foo' calling 'git foo'? Does it call the original
command, or itself?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* allowing aliases to override builtins to support default options
From: Jay Soffian @ 2009-03-06 22:30 UTC (permalink / raw)
To: Git Mailing List
Currently git does not allow aliases to override builtins. I
understand the reasoning behind this, but I wonder if it's overly
conservative.
Most shells support overriding commands with aliases, and I'm not sure
why git needs to be more conservative than the shell. (Although, I
will say, I hate when vendors alias rm to "rm -i", etc...)
It seems like this would be an elegant way to support default options.
Were it to be supported, it should probably have an escape hatch, such
as git --no-alias COMMAND, and it should probably only apply to
porcelains.
Thoughts?
j.
^ permalink raw reply
* [PATCH 2/3] builtin-merge: refactor to use git_config_option_string
From: Jay Soffian @ 2009-03-06 22:15 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, jean-luc malet, Junio C Hamano
In-Reply-To: <cover.1236377358.git.jaysoffian@gmail.com>
This patch teaches builtin-merge to use git_config_option_string() for
parsing branch.<name>.mergeoptions
As a side-effect, setting branch.<name>.mergeoptions to "" is no longer
supported. The tests have been modified to reflect this fact, along with
some minor refactoring to support additional tests in the next patch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
I think the side-effect is fine, since why would anyone have an empty
mergeoptions in their config? But if the list disagrees, it's trivial to
modify the preceeding patch to skip over an empty config w/o it being an
error.
Also, it seems like the with_config() utility function here might be
useful for other test scripts, so perhaps it should go into test-lib.sh?
builtin-merge.c | 14 +---------
t/t7600-merge.sh | 74 +++++++++++++++++++++++++++++++++++++----------------
2 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 6d2160d..504f2be 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -452,20 +452,8 @@ static int git_merge_config(const char *k, const char *v, void *cb)
if (branch && !prefixcmp(k, "branch.") &&
!prefixcmp(k + 7, branch) &&
!strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
- const char **argv;
- int argc;
- char *buf;
-
- buf = xstrdup(v);
- argc = split_cmdline(buf, &argv);
- if (argc < 0)
+ if (git_config_option_string(builtin_merge_options, 0, k, v))
die("Bad branch.%s.mergeoptions string", branch);
- argv = xrealloc(argv, sizeof(*argv) * (argc + 2));
- memmove(argv + 1, argv, sizeof(*argv) * (argc + 1));
- argc++;
- parse_options(argc, argv, builtin_merge_options,
- builtin_merge_usage, 0);
- free(buf);
}
if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..9db8bb4 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -188,6 +188,37 @@ verify_no_mergehead() {
fi
}
+with_config() {
+ names_to_unset=
+ retval=0
+ while test $# -gt 1
+ do
+ if test "$1" = "--"
+ then
+ shift
+ break
+ fi
+ if git config "$1" "$2"
+ then
+ names_to_unset="$names_to_unset $1"
+ shift
+ shift
+ else
+ retval=1
+ break
+ fi
+ done
+ if test $retval = 0
+ then
+ git "$@"
+ retval=$?
+ fi
+ for name in $names_to_unset
+ do
+ git config --unset "$name"
+ done
+ return $retval
+}
test_expect_success 'setup' '
git add file &&
@@ -327,8 +358,8 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c2 (no-commit in config)' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--no-commit" &&
- git merge c2 &&
+ with_config branch.master.mergeoptions --no-commit -- \
+ merge c2 &&
verify_merge file result.1-5 &&
verify_head $c1 &&
verify_mergeheads $c2
@@ -338,8 +369,8 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c2 (squash in config)' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--squash" &&
- git merge c2 &&
+ with_config branch.master.mergeoptions --squash -- \
+ merge c2 &&
verify_merge file result.1-5 &&
verify_head $c1 &&
verify_no_mergehead &&
@@ -350,9 +381,9 @@ test_debug 'gitk --all'
test_expect_success 'override config option -n with --summary' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "-n" &&
test_tick &&
- git merge --summary c2 >diffstat.txt &&
+ with_config branch.master.mergeoptions -n -- \
+ merge --summary c2 >diffstat.txt &&
verify_merge file result.1-5 msg.1-5 &&
verify_parents $c1 $c2 &&
if ! grep "^ file | *2 +-$" diffstat.txt
@@ -364,9 +395,9 @@ test_expect_success 'override config option -n with --summary' '
test_expect_success 'override config option -n with --stat' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "-n" &&
test_tick &&
- git merge --stat c2 >diffstat.txt &&
+ with_config branch.master.mergeoptions -n -- \
+ merge --stat c2 >diffstat.txt &&
verify_merge file result.1-5 msg.1-5 &&
verify_parents $c1 $c2 &&
if ! grep "^ file | *2 +-$" diffstat.txt
@@ -380,9 +411,9 @@ test_debug 'gitk --all'
test_expect_success 'override config option --stat' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--stat" &&
test_tick &&
- git merge -n c2 >diffstat.txt &&
+ with_config branch.master.mergeoptions --stat -- \
+ merge -n c2 >diffstat.txt &&
verify_merge file result.1-5 msg.1-5 &&
verify_parents $c1 $c2 &&
if grep "^ file | *2 +-$" diffstat.txt
@@ -396,9 +427,9 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c2 (override --no-commit)' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--no-commit" &&
test_tick &&
- git merge --commit c2 &&
+ with_config branch.master.mergeoptions --no-commit -- \
+ merge --commit c2 &&
verify_merge file result.1-5 msg.1-5 &&
verify_parents $c1 $c2
'
@@ -407,9 +438,9 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c2 (override --squash)' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "--squash" &&
test_tick &&
- git merge --no-squash c2 &&
+ with_config branch.master.mergeoptions --squash -- \
+ merge --no-squash c2 &&
verify_merge file result.1-5 msg.1-5 &&
verify_parents $c1 $c2
'
@@ -418,7 +449,6 @@ test_debug 'gitk --all'
test_expect_success 'merge c0 with c1 (no-ff)' '
git reset --hard c0 &&
- git config branch.master.mergeoptions "" &&
test_tick &&
git merge --no-ff c1 &&
verify_merge file result.1 &&
@@ -434,15 +464,16 @@ test_expect_success 'combining --squash and --no-ff is refused' '
test_expect_success 'merge c0 with c1 (ff overrides no-ff)' '
git reset --hard c0 &&
- git config branch.master.mergeoptions "--no-ff" &&
- git merge --ff c1 &&
+ with_config branch.master.mergeoptions --no-ff -- \
+ merge --ff c1 &&
verify_merge file result.1 &&
verify_head $c1
'
test_expect_success 'merge log message' '
git reset --hard c0 &&
- git merge --no-log c2 &&
+ with_config branch.master.mergeoptions --no-ff -- \
+ merge --no-log c2 &&
git show -s --pretty=format:%b HEAD >msg.act &&
verify_diff msg.nolog msg.act "[OOPS] bad merge log message" &&
@@ -451,8 +482,8 @@ test_expect_success 'merge log message' '
verify_diff msg.log msg.act "[OOPS] bad merge log message" &&
git reset --hard HEAD^ &&
- git config merge.log yes &&
- git merge c3 &&
+ with_config merge.log yes -- \
+ merge c3 &&
git show -s --pretty=format:%b HEAD >msg.act &&
verify_diff msg.log msg.act "[OOPS] bad merge log message"
'
@@ -461,7 +492,6 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c0, c2, c0, and c1' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "" &&
test_tick &&
git merge c0 c2 c0 c1 &&
verify_merge file result.1-5 &&
@@ -472,7 +502,6 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c0, c2, c0, and c1' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "" &&
test_tick &&
git merge c0 c2 c0 c1 &&
verify_merge file result.1-5 &&
@@ -483,7 +512,6 @@ test_debug 'gitk --all'
test_expect_success 'merge c1 with c1 and c2' '
git reset --hard c1 &&
- git config branch.master.mergeoptions "" &&
test_tick &&
git merge c1 c2 &&
verify_merge file result.1-5 &&
--
1.6.2.rc2.332.g5d21b
^ permalink raw reply related
* Re: fetch and pull
From: Junio C Hamano @ 2009-03-06 22:21 UTC (permalink / raw)
To: John Dlugosz; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115F5D@EXCHANGE.trad.tradestation.com>
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> Here is what I'm "cooking":
>
> ======excerpt======
>
> To keep apprised of other people's work, including updates to the main
> dev branch, start the day with:
>
> git fetch
>
> This will update your "remote tracking branches", letting you see what
> everyone else is working on, and letting you see the central
> repository's dev (as remotes/origin/dev) compared to your own local dev,
> so you can see what has been added.
>
> This does not change your local dev, or any other branches you are
> using. As for your own topic branches, you are the only one who changes
> them. This is a perfectly safe command and can be performed any time to
> update your view of what's happening throughout the team.
> You will, in particular, see your local dev where you last left it, and
> the current remotes/origin/dev pointing ahead of it. E.g.
>
> A <== dev
> \
> B--C--D <== remotes/origin/dev
>
> In this example, you see plain "dev" still pointing to A, and
> "remotes/origin/dev" pointing to D. So, you can tell that B, C, D were
> added. Review the nodes B, C, and D, by reading the comments and seeing
> which files were affected, and look deeper if it seems to affect what
> you are doing. Finally, issue the command
>
> ???
>
> And this will update your local dev to match the origin.
>
> ======
I already answered that question in a separate message (that is
different from what you are replying to), didn't I?
^ permalink raw reply
* [PATCH 3/3] builtin-merge: add support for default merge options
From: Jay Soffian @ 2009-03-06 22:15 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, jean-luc malet, Junio C Hamano
In-Reply-To: <cover.1236377358.git.jaysoffian@gmail.com>
This patch teaches merge a new setting, merge.options, which is
processed before any of the other merge configuration settings. It may
be used to establish a default which can then be overridden by more
specific branch.<name>.mergeoptions (or, obviously, command-line
switches).
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Documentation/git-merge.txt | 11 +++++--
builtin-merge.c | 10 ++++++
t/t7600-merge.sh | 69 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index f7be584..3cb06e7 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -47,10 +47,15 @@ CONFIGURATION
-------------
include::merge-config.txt[]
+merge.options::
+ Sets default options for merging. The syntax and supported options are
+ equal to that of 'git-merge'. Arguments are split by spaces, and may be
+ quoted in the same way as alias.* config options.
+
branch.<name>.mergeoptions::
- Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of 'git-merge', but option values
- containing whitespace characters are currently not supported.
+ Sets default options for merging into branch <name>. This setting is
+ handled after `merge.options`, so it may be used to override any
+ settings appearing there. The syntax is identical to `merge.options`.
HOW MERGE WORKS
---------------
diff --git a/builtin-merge.c b/builtin-merge.c
index 504f2be..1f124b3 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -447,6 +447,15 @@ cleanup:
strbuf_release(&bname);
}
+static int git_merge_config_default(const char *k, const char *v, void *cb)
+{
+ if (!strcmp(k, "merge.options")) {
+ if (git_config_option_string(builtin_merge_options, 0, k, v))
+ die("Bad merge.options string");
+ }
+ return 0;
+}
+
static int git_merge_config(const char *k, const char *v, void *cb)
{
if (branch && !prefixcmp(k, "branch.") &&
@@ -838,6 +847,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (is_null_sha1(head))
head_invalid = 1;
+ git_config(git_merge_config_default, NULL);
git_config(git_merge_config, NULL);
/* for color.ui */
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 9db8bb4..aaecdab 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -367,6 +367,16 @@ test_expect_success 'merge c1 with c2 (no-commit in config)' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 (no-commit in merge.options)' '
+ git reset --hard c1 &&
+ with_config merge.options --no-commit -- merge c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_mergeheads $c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 (squash in config)' '
git reset --hard c1 &&
with_config branch.master.mergeoptions --squash -- \
@@ -379,6 +389,17 @@ test_expect_success 'merge c1 with c2 (squash in config)' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 (squash in merge.options)' '
+ git reset --hard c1 &&
+ with_config merge.options --squash -- merge c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_no_mergehead &&
+ verify_diff squash.1-5 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'override config option -n with --summary' '
git reset --hard c1 &&
test_tick &&
@@ -425,6 +446,54 @@ test_expect_success 'override config option --stat' '
test_debug 'gitk --all'
+test_expect_success 'override merge.options -n with branch mergeoptions --summary' '
+ git reset --hard c1 &&
+ test_tick &&
+ with_config merge.options -n branch.master.mergeoptions --summary -- \
+ merge c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if ! grep "^ file | *2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was not generated with --summary"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'override merge.options -n with branch mergeoptions --stat' '
+ git reset --hard c1 &&
+ test_tick &&
+ with_config merge.options -n branch.master.mergeoptions --stat -- \
+ merge c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if ! grep "^ file | *2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was not generated with --stat"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'override merge.options --stat' '
+ git reset --hard c1 &&
+ test_tick &&
+ with_config merge.options --stat branch.master.mergeoptions -n -- \
+ merge c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if grep "^ file | *2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was generated"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 (override --no-commit)' '
git reset --hard c1 &&
test_tick &&
--
1.6.2.rc2.332.g5d21b
^ permalink raw reply related
* [PATCH 1/3] config: add git_config_option_string()
From: Jay Soffian @ 2009-03-06 22:15 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, jean-luc malet, Junio C Hamano
In-Reply-To: <cover.1236377358.git.jaysoffian@gmail.com>
This patch teaches config a new function, git_config_option_string(),
which parses a string using parse-options.
This is useful for any command that allows command-line options to
appear in a config.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Originally I had just factored this into its own function in
builtin-merge, but it seemed that it might be generally useful, so I
moved it to config.c
cache.h | 2 ++
config.c | 39 +++++++++++++++++++++++++++++++++++++++
parse-options.c | 2 ++
3 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 189151d..c6d3f05 100644
--- a/cache.h
+++ b/cache.h
@@ -854,6 +854,8 @@ extern unsigned long git_config_ulong(const char *, const char *);
extern int git_config_bool_or_int(const char *, const char *, int *);
extern int git_config_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
+struct option;
+extern int git_config_option_string(const struct option *, int, const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
diff --git a/config.c b/config.c
index 0c8c76f..29cfd5b 100644
--- a/config.c
+++ b/config.c
@@ -7,6 +7,7 @@
*/
#include "cache.h"
#include "exec_cmd.h"
+#include "parse-options.h"
#define MAXNAME (256)
@@ -353,6 +354,44 @@ int git_config_string(const char **dest, const char *var, const char *value)
return 0;
}
+int git_config_option_string(const struct option *options, int flags,
+ const char *var, const char *value)
+{
+ int argc, ret;
+ const char **argv;
+ char *buf;
+ struct parse_opt_ctx_t ctx;
+
+ if (!value)
+ return config_error_nonbool(var);
+
+ buf = xstrdup(value);
+ if ((argc = split_cmdline(buf, &argv)) < 0) {
+ free(buf);
+ return error("Malformed value for %s", var);
+ }
+ argv = xrealloc(argv, sizeof(*argv) * (argc + 2));
+ memmove(argv + 1, argv, sizeof(*argv) * (argc + 1));
+ argc++;
+
+ parse_options_start(&ctx, argc, argv, flags);
+ switch (parse_options_step(&ctx, options, NULL)) {
+ case PARSE_OPT_DONE:
+ ret = parse_options_end(&ctx);
+ break;
+ case PARSE_OPT_HELP: /* not supported in a config */
+ default: /* PARSE_OPT_UNKNOWN */
+ if (ctx.argv[0][1] == '-') {
+ ret = error("unknown option `%s'", ctx.argv[0] + 2);
+ } else {
+ ret = error("unknown switch `%c'", *ctx.opt);
+ }
+ break;
+ }
+ free(buf);
+ return ret;
+}
+
static int git_default_core_config(const char *var, const char *value)
{
/* This needs a better name */
diff --git a/parse-options.c b/parse-options.c
index 4c5d09d..7996b50 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -356,6 +356,8 @@ int parse_options(int argc, const char **argv, const struct option *options,
int usage_with_options_internal(const char * const *usagestr,
const struct option *opts, int full)
{
+ if (!usagestr)
+ return PARSE_OPT_HELP;
fprintf(stderr, "usage: %s\n", *usagestr++);
while (*usagestr && **usagestr)
fprintf(stderr, " or: %s\n", *usagestr++);
--
1.6.2.rc2.332.g5d21b
^ permalink raw reply related
* [PATCH 0/3] Re: how to have --no-ff be the default for all branch
From: Jay Soffian @ 2009-03-06 22:15 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, jean-luc malet, Junio C Hamano
2009/3/6 jean-luc malet <jeanluc.malet@gmail.com>:
> I would like that it is the default for all branch and that I use --ff
> when I want to do fast forward merge
> I know that I can set it up for one branch
> git config add branch.master.mergeoption --no-ff
> but I want it to be the default no just for one branch but for all branch
> git config add branch.*.mergeoption --no-ff
> don't work....
This series should do it for you. It teaches merge to support
merge.options, which is the default for all merge operations.
Jay Soffian (3):
config: add git_config_option_string()
builtin-merge: refactor to use git_config_option_string
builtin-merge: add support for default merge options
Documentation/git-merge.txt | 11 +++-
builtin-merge.c | 24 +++----
cache.h | 2 +
config.c | 39 ++++++++++++
parse-options.c | 2 +
t/t7600-merge.sh | 143 ++++++++++++++++++++++++++++++++++++-------
6 files changed, 182 insertions(+), 39 deletions(-)
^ permalink raw reply
* RE: fetch and pull
From: John Dlugosz @ 2009-03-06 22:11 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <7vd4cus7ez.fsf@gitster.siamese.dyndns.org>
===Re:===
> There was patch series adding support --ff=only, but I think it didn't
> made into git... Hmmm...
I do not think it has much to do with the main point of what John wants
to
do which is to muck with local branch without checking it out, which is
only possible when it happens to fast forward to the new tip of the
corresponding branch obtained from the the remote.
===end===
It occurs to me that maybe my concept is off, if it is being so
difficult.
Here is what I'm "cooking":
======excerpt======
To keep apprised of other people's work, including updates to the main
dev branch, start the day with:
git fetch
This will update your "remote tracking branches", letting you see what
everyone else is working on, and letting you see the central
repository's dev (as remotes/origin/dev) compared to your own local dev,
so you can see what has been added.
This does not change your local dev, or any other branches you are
using. As for your own topic branches, you are the only one who changes
them. This is a perfectly safe command and can be performed any time to
update your view of what's happening throughout the team.
You will, in particular, see your local dev where you last left it, and
the current remotes/origin/dev pointing ahead of it. E.g.
A <== dev
\
B--C--D <== remotes/origin/dev
In this example, you see plain "dev" still pointing to A, and
"remotes/origin/dev" pointing to D. So, you can tell that B, C, D were
added. Review the nodes B, C, and D, by reading the comments and seeing
which files were affected, and look deeper if it seems to affect what
you are doing. Finally, issue the command
???
And this will update your local dev to match the origin.
======
Basically, instead of mysterious "can't push" messages, the idea is that
people can feel good about 'fetch' as refreshing their view of the
central repo, so gitk can show them how the central dev (and other
branches) differs from their own.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* git-forest on msysgit
From: John Dlugosz @ 2009-03-06 21:08 UTC (permalink / raw)
To: git
I downloaded git-forest, and when I run it I get:
Can't locate loadable object for module Encode in @INC (@INC contains:
/usr/lib/perl5/5.8.8/msys /usr/lib/perl5/5.8.8 /usr/lib/perl5
/site_perl/5.8.8/msys /usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl .) at /usr/lib/perl5/5.8.8/msys/encoding.pm
line 5
The line 5 in encoding.pm reads "use Encode;" and there is an Encode.pm
on the path, and in Encode.pm it uses XSLoader. However, in the XS
subdirectory in the same directory as Encode.pm, I see only 2 files and
neither of them has to do with encoding. So I'm guessing I'm missing a
file.
I wonder if I can just copy it from somewhere, like someone's Linux
build?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: fetch and pull
From: Junio C Hamano @ 2009-03-06 20:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: John Dlugosz, git
In-Reply-To: <m3iqmmidlf.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> "John Dlugosz" <JDlugosz@TradeStation.com> writes:
>
>> So, after inspecting the changes, how do you fast-forward your local dev
>> to sync up with origin/dev?
>>
>> I'm worried that
>>
>> git pull origin dev
>>
>> will try to merge into the current head. The documentation indicates
>> "The remote ref that matches <src> is fetched, and if <dst> is not empty
>> string, the local ref that matches it is fast forwarded using <src>."
>> which is what I want, but it does NOT say that the normal behavior of
>> merging origin/dev into the =current= HEAD, if it happens to not be the
>> local dev.
>>
>> So, does it indeed suppress that behavior if you give it an explicit
>> destination? Or will I have to checkout dev first before doing the
>> pull, to prevent strange things from happening? Hmm, or perhaps I
>> should be using merge, not pull? After all, pull is really just a
>> wrapper around fetch and then merge, right? So is it OK to call merge
>> when I really want to fast-forward, and is there an option to give an
>> error if it isn't ff?
>
> There was patch series adding support --ff=only, but I think it didn't
> made into git... Hmmm...
I do not think it has much to do with the main point of what John wants to
do which is to muck with local branch without checking it out, which is
only possible when it happens to fast forward to the new tip of the
corresponding branch obtained from the the remote.
^ permalink raw reply
* Re: fetch and pull
From: Jakub Narebski @ 2009-03-06 20:44 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115E0D@EXCHANGE.trad.tradestation.com>
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> So, after inspecting the changes, how do you fast-forward your local dev
> to sync up with origin/dev?
>
> I'm worried that
>
> git pull origin dev
>
> will try to merge into the current head. The documentation indicates
> "The remote ref that matches <src> is fetched, and if <dst> is not empty
> string, the local ref that matches it is fast forwarded using <src>."
> which is what I want, but it does NOT say that the normal behavior of
> merging origin/dev into the =current= HEAD, if it happens to not be the
> local dev.
>
> So, does it indeed suppress that behavior if you give it an explicit
> destination? Or will I have to checkout dev first before doing the
> pull, to prevent strange things from happening? Hmm, or perhaps I
> should be using merge, not pull? After all, pull is really just a
> wrapper around fetch and then merge, right? So is it OK to call merge
> when I really want to fast-forward, and is there an option to give an
> error if it isn't ff?
There was patch series adding support --ff=only, but I think it didn't
made into git... Hmmm...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: More examples for git bisect
From: Christian Couder @ 2009-03-06 20:08 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <1236332255-15712-1-git-send-email-johnflux@gmail.com>
Le vendredi 6 mars 2009, John Tapsell a écrit :
> Including passing parameters to the programs, and running more
> complicated checks without requiring a seperate shell script.
>
> Signed-off-by: John Tapsell <johnflux@gmail.com>
> ---
> Documentation/git-bisect.txt | 27 ++++++++++++++++++++++++++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 147ea38..7b8cfdd 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -212,7 +212,7 @@ If you have a script that can tell if the current
> source code is good or bad, you can automatically bisect using:
>
> ------------
> -$ git bisect run my_script
> +$ git bisect run my_script arguments
> ------------
>
> Note that the "run" script (`my_script` in the above example) should
> @@ -251,6 +251,22 @@ EXAMPLES
> $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
> $ git bisect run make # "make" builds the app
> ------------
> ++
> +This looks for the first revision that fails to build between HEAD and
> +the tag 'v1.2'.
There are a few trailing spaces in the above line but otherwise the patch
looks good to me.
Acked-by: Christian Couder <chriscool@tuxfamily.org>
By the way, it would be nice if you could put me in CC.
Thanks,
Christian.
^ 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