* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Robin Rosenberg @ 2009-03-07 10:38 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903020941120.17877@perkele.intern.softwolves.pp.se>
Slightly related; A new cygwin (not msysgit-related) version with UTF-8 support was announced. Most notably:
- New setlocale implementation allows to specify POSIX locale strings.
You can now use, for instance in bash, `export LC_ALL=en_US.UTF-8'.
The language and territory will be ignored for now, the charset
will be used by multibyte-releated functions.
- UTF-8 filenames are supported now.
- Support UTF-8 in console window.
This certainly makes it more feasable to interoperate with *nix repos that has non-ascii metadata and file names.
-- robin
^ permalink raw reply
* Re: jGit Eclipse Plugin Feature
From: Robin Rosenberg @ 2009-03-07 10:58 UTC (permalink / raw)
To: Robert Navarro; +Cc: git
In-Reply-To: <efe536470903070205w1dbff989je6dd6126d09e4a74@mail.gmail.com>
lördag 07 mars 2009 11:05:41 skrev Robert Navarro <crshman@gmail.com>:
> Hello,
>
> Sorry about my last "subscribe" email, skipped over this part in the
> wiki...."You don't even need to be subscribed to post, just send an
> email to: "
>
> Anyways.....I wasn't sure where to post this but I'll give it a shot
> here.....I know there is an eclipse jGit plugin in the works and I
> wanted to know if it would be possible to get a remember or recently
> used servers feature added to the push/pull feature.
>
> Ideas? Thoughts? Comments?
This is not unreasonable, but we don't lack ideas. Time we lack.
-- robin
^ permalink raw reply
* Re: [PATCH RESEND] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-03-07 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprh64ych.fsf@gitster.siamese.dyndns.org>
On Wed, Feb 25, 2009 at 12:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Wed, Feb 25, 2009 at 10:02 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> Sorry, but I cannot take this as is.
>>>
>>> These trivial clean-ups are welcome either as part of a preparatory
>>> clean-up before starting to work in the area of code you are touching, or
>>> as a standalone patch to files that nobody is currently working on.
>>>
>>> There is a huge overlap between "git diff --name-only master..pu" and the
>>> above list, so it is impossible for me to take the patch and I cannot
>>> afford the time to sift through gems out of stones.
>>
>> It's understandable. Would there be a better time to send this patch?
>> After 1.6.2, or in a different form?
>
> I've taken your smaller patches that touched only parts that nobody is
> touching between 'master' and 'pu'. Please take that as a hint ;-)
Sorry, where is the result of that? I can't find it.
> As a first order approximation, come up with the subset of your patch that
> applies cleanly to 'master', and make sure that the same patch applies
> cleanly to 'pu'. Remove patches to paths that have any hunk that does not
> apply and go back to 'master' to repeat the exercise.
>
> That will cover a lot of existing breakages in files that nobody else is
> working on.
>
> For example, Jay has been hyperactive around anything "remote" for the
> past several days. If you have clean-ups in the paths he touches in his
> series (still in flight), you may want to coordinate with him so that he
> can include your patches in the early part of his series. Or you wait
> until his series starts to settle down (meaning, merged to 'next'). This
> applies to anybody else's topic.
I tried to rebase the patch on top master, generated a patch and it
applies cleanly on top of both 'master' and 'pu' I didn't need to
change anything.
What am I missing?
--
Felipe Contreras
^ permalink raw reply
* jGit Eclipse Plugin Feature
From: Robert Navarro @ 2009-03-07 10:05 UTC (permalink / raw)
To: git
Hello,
Sorry about my last "subscribe" email, skipped over this part in the
wiki...."You don't even need to be subscribed to post, just send an
email to: "
Anyways.....I wasn't sure where to post this but I'll give it a shot
here.....I know there is an eclipse jGit plugin in the works and I
wanted to know if it would be possible to get a remember or recently
used servers feature added to the push/pull feature.
Ideas? Thoughts? Comments?
--
~Robert Navarro
^ permalink raw reply
* Re: [PATCH B v4 5/5] git config: don't allow --get-color* and variable type
From: Felipe Contreras @ 2009-03-07 9:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vmycez86y.fsf@gitster.siamese.dyndns.org>
On Sun, Feb 22, 2009 at 7:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>>> diff --git a/builtin-config.c b/builtin-config.c
>>>> index 8045926..9930568 100644
>>>> --- a/builtin-config.c
>>>> +++ b/builtin-config.c
>>>> @@ -359,6 +359,11 @@ int cmd_config(int argc, const char **argv, const char *unused_prefix)
>>>> if (get_colorbool_slot)
>>>> actions |= ACTION_GET_COLORBOOL;
>>>>
>>>> + if ((get_color_slot || get_colorbool_slot) && types) {
>>>> + error("--get-color and variable type are incoherent");
>>>> + usage_with_options(builtin_config_usage, builtin_config_options);
>>>> + }
>>>> +
>>>
>>> I do not think I suggested anything like this, so I'd decline to take
>>> credit for this patch.
>>>
>>> Strictly speaking, "--bool --get-colorbool diff.color 1" shouldn't error
>>> out, don't you think? And it certainly shouldn't say "--get-color".
>>
>> Huh? I misinterpreted:
>> I see "git config --bool --get-color diff.color.whitespace" is still
>> allowed, which you might want to tighten further.
>
> "--get-color" gets, escape sequence to throw at the terminal to get the
> color configured. It does not make sense to ask for bool (or int) for
> that action.
>
> "--get-colorbool" asks if it is appropriate to use such escape sequence
> (e.g. when the output is tty and config says "auto", you would get "please
> use color"). In other words, its type is always bool, so using it as
> --int does not make sense but we cannot really say using it with --bool is
> nonsense.
Now I get it, but why would somebody want to do '--bool
--get-colorbool'? That is redundant.
I think --bool should be used only for boolean variables, not color ones.
Please let me know if the original patch is ok and I'll resend it with
'--get-color*'.
--
Felipe Contreras
^ permalink raw reply
* [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Chris Johnsen @ 2009-03-07 9:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Miklos Vajna, Chris Johnsen
When a cherry-pick of an empty commit is done, release the lock
held on the index.
The fix is the same as was applied to similar code in 4271666046.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
RELEVANT HISTORY
The previous code was introduced in 6eb1b43793.
It seems to have been copied from builtin-merge.c, where it was
introduced in 18668f5319 (6eb1's parent).
The code introduced in 1866 was fixed with the addition of
rollback_lock_file (the same fix as applied here) in 4271666046.
CONTEXT
I ran into the code path that this patch modifies while using
'git rebase -i' on a branch that had empty commits. When rebase
tried to cherry-pick an empty commit, the cherry-pick returned an
error and failed to unlocking the index. While this patch does
not allow 'git rebase -i' to "correctly" process empty commits,
it does prevent 'git cherry-pick' from exiting without unlocking
the index.
T="$(mktemp -d -t empty-cherry)"
cd "$T"
git init
echo a > a
git add a
git commit -m 'add a'
git checkout -b empty
git commit --allow-empty -m 'empty'
git checkout master
git cherry-pick empty
> Finished one cherry-pick.
> fatal: Unable to create '.git/index.lock': File exists.
>
> If no other git process is currently running, this probably means a
> git process crashed in this repository earlier. Make sure no other git
> process is running and remove the file manually to continue.
I was originally appending empty commits with descriptive
messages to mark "interesting" points in a stream of otherwise
automatic commits (made by an Xcode build script). My idea was to
use these commits as markers that would flow with the rest of the
commits through a subsequent series of cleanups done with 'git
rebase -i'. After encountering this problem, however, I moved
away from using empty commits (I have since been using 'git
commit --amend' to rewrite the last (generic, automatic) commit
message), but the bug left me wondering about the the status of
emtpy commits.
UNEVEN TREATMENT OF EMPTY CHANGES
It seems that empty commits suffer uneven treatment under various
patch-transport/history-rewriting mechanisms. They seem to be
handled okay in the most of the core (fetch, push, bundle all
seem to preserve empty commits, though I have not done rigorous
testing). But there are various problems in other areas:
'format-patch', 'send-email', 'apply', 'am', 'rebase' (automatic,
non-fast-forward; and --interactive).
DISCUSSION
36863af16e (git-commit --allow-empty) says "This is primarily for
use by foreign scm interface scripts.". Is this the only case
where empty commits _should_ be used? Or is the uneven treatment
just a matter nobody having an itch to use empty commits in
situations where the above commands would interact with them?
I played with having builtin-revert.c always use 'git commit
--allow-empty ...', but I was not confident that such behavior
would match "official policy for empty commits" (if such policy
even exists). Should empty commits be preserved (by default) once
they are in the commit stream? Should commands that do "patch
manipulation" only preserve empty commits if they are explicitly
instructed to do so (with their own --allow-emtpy option)? Should
something completely different happen?
I realize that rebasing and cherry-picking need to have special
consideration for "effectively empty" patches (those that
introduce changes already present; usually because one side
already picked some changes from the other), but maybe "actually
empty, yet informational" commits also deserve some
consideration.
If such "actually empty, yet informational" commits (no content
changes, but a useful commit messages) are a valid use of empty
commits, then maybe "actually empty" commits in general deserve
treatment equal to that of normal commits.
---
builtin-revert.c | 1 +
t/t3505-cherry-pick-empty.sh | 33 +++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)
create mode 100755 t/t3505-cherry-pick-empty.sh
diff --git a/builtin-revert.c b/builtin-revert.c
index d210150..3f2614e 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -376,6 +376,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
(write_cache(index_fd, active_cache, active_nr) ||
commit_locked_index(&index_lock)))
die("%s: Unable to write new index file", me);
+ rollback_lock_file(&index_lock);
if (!clean) {
add_to_msg("\nConflicts:\n\n");
diff --git a/t/t3505-cherry-pick-empty.sh b/t/t3505-cherry-pick-empty.sh
new file mode 100755
index 0000000..9aaeabd
--- /dev/null
+++ b/t/t3505-cherry-pick-empty.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+test_description='test cherry-picking an empty commit'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo first > file1 &&
+ git add file1 &&
+ test_tick &&
+ git commit -m "first" &&
+
+ git checkout -b empty-branch &&
+ test_tick &&
+ git commit --allow-empty -m "empty"
+
+'
+
+test_expect_code 1 'cherry-pick an empty commit' '
+
+ git checkout master &&
+ git cherry-pick empty-branch
+
+'
+
+test_expect_success 'index lockfile was removed' '
+
+ test ! -f .git/index.lock
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Rebasing local patches
From: Nicolas Morey-Chaisemartin @ 2009-03-07 9:01 UTC (permalink / raw)
To: git@vger.kernel.org
Hello everyone,
I have a few questions about the workflow we sue at work.
On one of our project, we depend on an external source which uses git.
On our side of the project, we create some patches (this part is not the problem), but only some of them are intended to be pushed (ie pulled by) the external source.
So basically, we have a set of patches on local branch that we rebase every so and then against master to keep our version up-to-date with the external one.
Is this the right way to do it?
Then, internally we have a centralized repository and many personal ones. When the need to go to the next version, one of the developper rebases the company patches branch afaisnt master and push it into the centralized repo.
What is the best way for the other developpers to get up-to-date with the rebased branch?
git pull --rebase seems to me like a good way to keep local modifications.
If all our patches were already pushed on the centralized repo, we tend top use git reset --hard origin/our_patches
Final question:
I noticed that when the branch was rebased on the centralized and repo and origin/our_patches is up-to-date in mine.
If I checkout another branch and then ckecout our_branches, I got a message telling my our_patches and the one from the server have diverged (or you are two commits behind...).
How can you get this info directly without leaving/rejoining your branch?
Regards
Nicolas
^ permalink raw reply
* Re: fetch and pull
From: Bryan Donlan @ 2009-03-07 8:00 UTC (permalink / raw)
To: John Dlugosz; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115F5D@EXCHANGE.trad.tradestation.com>
On Fri, Mar 6, 2009 at 5:11 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
> ===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.
If the local "dev" is a topic branch, you'd want to either merge or
rebase with the origin's dev branch. Rebasing is probably best if
you've not published the branch yet (unless you'd prefer proper merge
history on it).
If the local "dev" is meant to just track the remote, you really ought
to avoid doing anything very involved in it (unless you're planning on
merging something into it and pushing the result, that is!). If
there's no local changes, then you can just pull with impunity, and
let it fast-forward - or use git merge or git rebase if you've already
fetched and don't want to spend the few seconds it takes to ask the
server if there's anything new :)
Finally, if you really, truly, definitely want to blow away the
current branch and replace it with another one, you can use git reset
--hard. This will throw away (irretrievably) local uncommitted
changes, and force the current branch to point to the specified one.
Remember, you can undo most things using the reflog if you mess up,
including unwanted merges, git reset --hard (committed changes only)
etc.
^ permalink raw reply
* Re: [PATCH 3/3] builtin-merge: add support for default merge options
From: Junio C Hamano @ 2009-03-07 7:18 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, jean-luc malet
In-Reply-To: <76718490903061756g4ca88c21h8bf786048d4ad05@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Fri, Mar 6, 2009 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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
>
> Okay. That's probably a more invasive patch, because a lot more code
> paths look at [branch ...], but I'll look into it.
Note that you do not have to cover branch.*.remote and other things in the
same patch. The first one could just handle branch.*.mergeoptions and you
can let later patches to implement the fallbacks for other variables.
^ permalink raw reply
* [PATCH v2 5/5] Support '*' in the middle of a refspec
From: Daniel Barkalow @ 2009-03-07 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903052356010.19665@iabervon.org>
In order to keep the requirements strict, each * has to be a full path
component, and there may only be one * per side. This requirement is
enforced entirely by check_ref_format(); the matching implementation
will substitute the whatever matches the * in the lhs for the * in the
rhs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Rebased on the new version of the earlier patches
refs.c | 11 +++++++----
remote.c | 24 +++++++++++++++++-------
t/t5511-refspec.sh | 12 ++++++++++++
3 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/refs.c b/refs.c
index a50ba79..fef7c9f 100644
--- a/refs.c
+++ b/refs.c
@@ -694,6 +694,7 @@ static inline int bad_ref_char(int ch)
int check_ref_format(const char *ref)
{
int ch, level, bad_type;
+ int ret = CHECK_REF_FORMAT_OK;
const char *cp = ref;
level = 0;
@@ -709,9 +710,11 @@ int check_ref_format(const char *ref)
return CHECK_REF_FORMAT_ERROR;
bad_type = bad_ref_char(ch);
if (bad_type) {
- return (bad_type == 2 && !*cp)
- ? CHECK_REF_FORMAT_WILDCARD
- : CHECK_REF_FORMAT_ERROR;
+ if (bad_type == 2 && (!*cp || *cp == '/') &&
+ ret == CHECK_REF_FORMAT_OK)
+ ret = CHECK_REF_FORMAT_WILDCARD;
+ else
+ return CHECK_REF_FORMAT_ERROR;
}
/* scan the rest of the path component */
@@ -729,7 +732,7 @@ int check_ref_format(const char *ref)
if (!ch) {
if (level < 2)
return CHECK_REF_FORMAT_ONELEVEL;
- return CHECK_REF_FORMAT_OK;
+ return ret;
}
}
}
diff --git a/remote.c b/remote.c
index d596a48..90203e2 100644
--- a/remote.c
+++ b/remote.c
@@ -511,12 +511,12 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
if (rhs) {
size_t rlen = strlen(++rhs);
- is_glob = (2 <= rlen && !strcmp(rhs + rlen - 2, "/*"));
+ is_glob = (1 <= rlen && strchr(rhs, '*'));
rs[i].dst = xstrndup(rhs, rlen);
}
llen = (rhs ? (rhs - lhs - 1) : strlen(lhs));
- if (2 <= llen && !memcmp(lhs + llen - 2, "/*", 2)) {
+ if (1 <= llen && memchr(lhs, '*', llen)) {
if ((rhs && !is_glob) || (!rhs && fetch))
goto invalid;
is_glob = 1;
@@ -718,22 +718,32 @@ static int match_name_with_pattern(const char *key, const char *name,
{
const char *kstar = strchr(key, '*');
size_t klen;
+ size_t ksuffixlen;
+ size_t namelen;
int ret;
if (!kstar)
die("Key '%s' of pattern had no '*'", key);
klen = kstar - key;
- ret = !strncmp(key, name, klen);
+ ksuffixlen = strlen(kstar + 1);
+ namelen = strlen(name);
+ ret = !strncmp(name, key, klen) && namelen >= klen + ksuffixlen &&
+ !memcmp(name + namelen - ksuffixlen, kstar + 1, ksuffixlen);
if (ret && value) {
const char *vstar = strchr(value, '*');
size_t vlen;
+ size_t vsuffixlen;
if (!vstar)
die("Value '%s' of pattern has no '*'", value);
vlen = vstar - value;
- *result = xmalloc(vlen +
+ vsuffixlen = strlen(vstar + 1);
+ *result = xmalloc(vlen + vsuffixlen +
strlen(name) -
- klen + 1);
- strcpy(*result, value);
- strcpy(*result + vlen, name + klen);
+ klen - ksuffixlen + 1);
+ strncpy(*result, value, vlen);
+ strncpy(*result + vlen,
+ name + klen, namelen - klen - ksuffixlen);
+ strcpy(*result + vlen + namelen - klen - ksuffixlen,
+ vstar + 1);
}
return ret;
}
diff --git a/t/t5511-refspec.sh b/t/t5511-refspec.sh
index 22ba380..c289322 100755
--- a/t/t5511-refspec.sh
+++ b/t/t5511-refspec.sh
@@ -72,4 +72,16 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me'
test_refspec push ':refs/remotes/frotz/delete me' invalid
test_refspec fetch ':refs/remotes/frotz/HEAD to me' invalid
+test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid
+test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid
+
+test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid
+test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid
+
+test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
+test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
+
+test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*'
+test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*'
+
test_done
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH v2 4/5] Keep '*' in pattern refspecs
From: Daniel Barkalow @ 2009-03-07 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903052355480.19665@iabervon.org>
In order to do anything more capable with refspecs, the first step is
to keep the entire input. Additionally, validate patterns by checking
for the ref matching the rules for a pattern as given by
check_ref_format(). This requires a slight change to
check_ref_format() to make it enforce the requirement that the '*'
immediately follow a '/'.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Don't arbitrarily swap argument order; check for missing '*' in pattern
sides.
refs.c | 4 +---
remote.c | 35 +++++++++++++++++++----------------
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/refs.c b/refs.c
index 6eb5f53..a50ba79 100644
--- a/refs.c
+++ b/refs.c
@@ -718,9 +718,7 @@ int check_ref_format(const char *ref)
while ((ch = *cp++) != 0) {
bad_type = bad_ref_char(ch);
if (bad_type) {
- return (bad_type == 2 && !*cp)
- ? CHECK_REF_FORMAT_WILDCARD
- : CHECK_REF_FORMAT_ERROR;
+ return CHECK_REF_FORMAT_ERROR;
}
if (ch == '/')
break;
diff --git a/remote.c b/remote.c
index 5638766..d596a48 100644
--- a/remote.c
+++ b/remote.c
@@ -10,8 +10,8 @@ static struct refspec s_tag_refspec = {
0,
1,
0,
- "refs/tags/",
- "refs/tags/"
+ "refs/tags/*",
+ "refs/tags/*"
};
const struct refspec *tag_refspec = &s_tag_refspec;
@@ -451,16 +451,11 @@ static void read_config(void)
*/
static int verify_refname(char *name, int is_glob)
{
- int result, len = -1;
+ int result;
- if (is_glob) {
- len = strlen(name);
- assert(name[len - 1] == '/');
- name[len - 1] = '\0';
- }
result = check_ref_format(name);
- if (is_glob)
- name[len - 1] = '/';
+ if (is_glob && result == CHECK_REF_FORMAT_WILDCARD)
+ result = CHECK_REF_FORMAT_OK;
return result;
}
@@ -517,7 +512,7 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
if (rhs) {
size_t rlen = strlen(++rhs);
is_glob = (2 <= rlen && !strcmp(rhs + rlen - 2, "/*"));
- rs[i].dst = xstrndup(rhs, rlen - is_glob);
+ rs[i].dst = xstrndup(rhs, rlen);
}
llen = (rhs ? (rhs - lhs - 1) : strlen(lhs));
@@ -525,7 +520,6 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
if ((rhs && !is_glob) || (!rhs && fetch))
goto invalid;
is_glob = 1;
- llen--;
} else if (rhs && is_glob) {
goto invalid;
}
@@ -720,12 +714,21 @@ int remote_has_url(struct remote *remote, const char *url)
}
static int match_name_with_pattern(const char *key, const char *name,
const char *value, char **result)
{
- size_t klen = strlen(key);
- int ret = !strncmp(key, name, klen);
+ const char *kstar = strchr(key, '*');
+ size_t klen;
+ int ret;
+ if (!kstar)
+ die("Key '%s' of pattern had no '*'", key);
+ klen = kstar - key;
+ ret = !strncmp(key, name, klen);
if (ret && value) {
- size_t vlen = strlen(value);
+ const char *vstar = strchr(value, '*');
+ size_t vlen;
+ if (!vstar)
+ die("Value '%s' of pattern has no '*'", value);
+ vlen = vstar - value;
*result = xmalloc(vlen +
strlen(name) -
klen + 1);
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH v2 3/5] Use the matching function to generate the match results
From: Daniel Barkalow @ 2009-03-07 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903052355240.19665@iabervon.org>
This puts all of the interpretation of the pattern representation in a
single function for easy manipulation.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Again, better name for the function.
remote.c | 45 +++++++++++++++++++++++----------------------
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/remote.c b/remote.c
index 2816723..5638766 100644
--- a/remote.c
+++ b/remote.c
@@ -719,9 +719,19 @@ int remote_has_url(struct remote *remote, const char *url)
return 0;
}
-static int match_name_with_pattern(const char *key, const char *name)
+static int match_name_with_pattern(const char *key, const char *name,
+ const char *value, char **result)
{
- int ret = !prefixcmp(key, name);
+ size_t klen = strlen(key);
+ int ret = !strncmp(key, name, klen);
+ if (ret && value) {
+ size_t vlen = strlen(value);
+ *result = xmalloc(vlen +
+ strlen(name) -
+ klen + 1);
+ strcpy(*result, value);
+ strcpy(*result + vlen, name + klen);
+ }
return ret;
}
@@ -748,13 +758,7 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
if (!fetch->dst)
continue;
if (fetch->pattern) {
- if (match_name_with_pattern(key, needle)) {
- *result = xmalloc(strlen(value) +
- strlen(needle) -
- strlen(key) + 1);
- strcpy(*result, value);
- strcpy(*result + strlen(value),
- needle + strlen(key));
+ if (match_name_with_pattern(key, needle, value, result)) {
refspec->force = fetch->force;
return 0;
}
@@ -1026,7 +1030,8 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
continue;
}
- if (rs[i].pattern && match_name_with_pattern(rs[i].src, src->name))
+ if (rs[i].pattern && match_name_with_pattern(rs[i].src, src->name,
+ NULL, NULL))
return rs + i;
}
if (matching_refs != -1)
@@ -1080,11 +1085,9 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
} else {
const char *dst_side = pat->dst ? pat->dst : pat->src;
- dst_name = xmalloc(strlen(dst_side) +
- strlen(src->name) -
- strlen(pat->src) + 2);
- strcpy(dst_name, dst_side);
- strcat(dst_name, src->name + strlen(pat->src));
+ if (!match_name_with_pattern(pat->src, src->name,
+ dst_side, &dst_name))
+ die("Didn't think it matches any more");
}
dst_peer = find_ref_by_name(dst, dst_name);
if (dst_peer) {
@@ -1160,19 +1163,17 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
struct ref *ret = NULL;
struct ref **tail = &ret;
- int remote_prefix_len = strlen(refspec->src);
- int local_prefix_len = strlen(refspec->dst);
+ char *expn_name;
for (ref = remote_refs; ref; ref = ref->next) {
if (strchr(ref->name, '^'))
continue; /* a dereference item */
- if (match_name_with_pattern(refspec->src, ref->name)) {
- const char *match;
+ if (match_name_with_pattern(refspec->src, ref->name,
+ refspec->dst, &expn_name)) {
struct ref *cpy = copy_ref(ref);
- match = ref->name + remote_prefix_len;
- cpy->peer_ref = alloc_ref_with_prefix(refspec->dst,
- local_prefix_len, match);
+ cpy->peer_ref = alloc_ref(expn_name);
+ free(expn_name);
if (refspec->force)
cpy->peer_ref->force = 1;
*tail = cpy;
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH v2 2/5] Use a single function to match names against patterns
From: Daniel Barkalow @ 2009-03-07 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903052355110.19665@iabervon.org>
This will help when the matching changes.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Improved the function name for its eventual use.
remote.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index d7079c6..2816723 100644
--- a/remote.c
+++ b/remote.c
@@ -719,6 +719,12 @@ int remote_has_url(struct remote *remote, const char *url)
return 0;
}
+static int match_name_with_pattern(const char *key, const char *name)
+{
+ int ret = !prefixcmp(key, name);
+ return ret;
+}
+
int remote_find_tracking(struct remote *remote, struct refspec *refspec)
{
int find_src = refspec->src == NULL;
@@ -742,7 +748,7 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
if (!fetch->dst)
continue;
if (fetch->pattern) {
- if (!prefixcmp(needle, key)) {
+ if (match_name_with_pattern(key, needle)) {
*result = xmalloc(strlen(value) +
strlen(needle) -
strlen(key) + 1);
@@ -1020,7 +1026,7 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
continue;
}
- if (rs[i].pattern && !prefixcmp(src->name, rs[i].src))
+ if (rs[i].pattern && match_name_with_pattern(rs[i].src, src->name))
return rs + i;
}
if (matching_refs != -1)
@@ -1160,7 +1166,7 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
for (ref = remote_refs; ref; ref = ref->next) {
if (strchr(ref->name, '^'))
continue; /* a dereference item */
- if (!prefixcmp(ref->name, refspec->src)) {
+ if (match_name_with_pattern(refspec->src, ref->name)) {
const char *match;
struct ref *cpy = copy_ref(ref);
match = ref->name + remote_prefix_len;
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* Re: allowing aliases to override builtins to support default options
From: Johannes Schindelin @ 2009-03-07 3:10 UTC (permalink / raw)
To: Jay Soffian; +Cc: Git Mailing List
In-Reply-To: <76718490903061857y5446098by3633559697508c2e@mail.gmail.com>
Hi,
On Fri, 6 Mar 2009, Jay Soffian wrote:
> For example, what if:
>
> 1. The aliases applied only to porcelain commands, not to plumbing.
Inconsistency like this is bad for a couple of reasons. Just 3 out of
them:
- it makes it hard for users to understand,
- it is prone for subtle breakages,
- the code will be complicated, and therefore ugly.
> 2. The aliases worked only if stdout was a terminal, using the same
> method that git uses for detecting when it is okay to start a pager.
This would be even more complicated to understand for the regular Git user
who just wants to use the darned thing and not care about its internals.
> 3. git took --alias-builtins and --no-alias-builtins just like it takes
> --paginate and --no-pager to override (2).
And this makes it even more complicated.
I'd rather stay with our current notion that aliases cannot override Git
programs. This is _very_ easy to explain, and also _very_ easy to defend.
Ciao,
Dscho
^ permalink raw reply
* Re: allowing aliases to override builtins to support default options
From: Jay Soffian @ 2009-03-07 2:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903070336200.10279@pacific.mpi-cbg.de>
On Fri, Mar 6, 2009 at 9:37 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> What you dream about breaks a lot of scripts.
I said I understood the implications.
> So while it might be nice for you, you would make life of others much,
> much, much harder. Not nice at all.
This is not something I am dreaming about, and I'm only interested to
the extent that it improves git w/o hindering existing users. I'm
certainly not aiming to be not nice to anyone!
For example, what if:
1. The aliases applied only to porcelain commands, not to plumbing.
2. The aliases worked only if stdout was a terminal, using the same
method that git uses for detecting when it is okay to start a pager.
3. git took --alias-builtins and --no-alias-builtins just like it
takes --paginate and --no-pager to override (2).
j.
^ permalink raw reply
* Re: [GSoC] Google Summer of Code 2009 - new ideas
From: Tay Ray Chuan @ 2009-03-07 2:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn Pearce
In-Reply-To: <200903070144.17457.jnareb@gmail.com>
Hi,
On 3/7/09, Jakub Narebski <jnareb@gmail.com> wrote:
> == 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)
Perhaps you might want to look at this:
http://marc.info/?l=git&m=123599968929476&w=4
At that time, I was thinking more of removing git's reliance on curl's
multi interface so that it could use older versions of libcurl. But,
on this point, Daniel convinced me otherwise. In fact, it doesn't make
sense if you could have a up-to-date git, but not an up-to-date curl.
I didn't really get a reply on my point of "minimized credential
prompting", though, and I think this GSoC proposal kinda gives support
to it.
>From a learning standpoint, I don't think this project would be too
challenging, nor can it sustain for a whole summer -- the basic
strategy to allow non-curl multi usage (ie. single connections) would
be to "fork" the current http slot methods and make them
non-curl_multi, then finding and replacing instances of them
throughout the code base.
I already have a patch series that does that, plus a --persistent
option for push. I'm fairly sure that it takes place on a single
connection (I'm relying on my firewall log though I'm doubting it's
reliability on this issue).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git-forest on msysgit
From: Johannes Schindelin @ 2009-03-07 2:54 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115F15@EXCHANGE.trad.tradestation.com>
Hi,
Note: this is pretty much obviously the wrong mailing list for
msysGit-related issues.
On Fri, 6 Mar 2009, John Dlugosz wrote:
> 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.
You can try recompiling git-svn. Maybe I forgot to commit a file.
> I wonder if I can just copy it from somewhere, like someone's Linux
> build?
How do you expect a Linux-specific binary object to be usable on Windows?
Hth,
Dscho
^ permalink raw reply
* Re: Using Git with windows
From: Johannes Schindelin @ 2009-03-07 2:50 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, tariq.hassanen
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115E18@EXCHANGE.trad.tradestation.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 623 bytes --]
Hi,
On Fri, 6 Mar 2009, John Dlugosz wrote:
> I can think of two differences: Line endings have been mentioned already.
And I have addressed that already, did I not?
> But, and I was wondering this already anyway, does the Windows git know
> that the file system is case insensitive but case preserving? That is,
> does it just ignore the issue, is there logic to cope with that better?
> If so, that would be missing if you ran it in the Linux VM. (Unless it
> checks the file system capabilities rather than the OS it is running
> under)
AFAIR Git recognizes case-insensitive file systems as such.
Hth,
Dscho
^ permalink raw reply
* Re: msysgit corrupting commit messages?
From: Johannes Schindelin @ 2009-03-07 2:48 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090306171117.GD12880@zoy.org>
Hi,
On Fri, 6 Mar 2009, Sam Hocevar wrote:
> On Fri, Mar 06, 2009, Brandon Casey wrote:
>
> > I get the impression that you do not intend for the comments above to be
> > part of the commit message. If that is true, then they should be placed
> > further down after the '---' and before the diff-stat, or in some other
> > way partitioned from the commit message (maybe using --->8--- notation).
> > Otherwise they will _become_ part of the commit message if Junio applies
> > this patch as-is.
>
> Okay. I'm definitely having a problem with git on MSYS. Is anyone
> else seeing it butcher commits it exports? They appear fine in git log
> or git log -p, but not in git format-patch. I've never had the problem
> on a Linux system.
I have never had problems with msysGit's format-patch. From Brandon's
description however, it appears as if the offending changes were done
manually...
Note: I missed the original message.
Ciao,
Dscho
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-07 2:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3eixai1xv.fsf@localhost.localdomain>
Hi,
On Fri, 6 Mar 2009, Jakub Narebski wrote:
> 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.
Thanks. Accepted.
Ciao,
Dscho
^ permalink raw reply
* Re: allowing aliases to override builtins to support default options
From: Johannes Schindelin @ 2009-03-07 2:37 UTC (permalink / raw)
To: Jay Soffian; +Cc: Git Mailing List
In-Reply-To: <76718490903061430s2fbea2dfibe06282fd22b1588@mail.gmail.com>
Hi,
On Fri, 6 Mar 2009, Jay Soffian wrote:
> 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.
What you dream about breaks a lot of scripts.
So while it might be nice for you, you would make life of others much,
much, much harder. Not nice at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Johannes Schindelin @ 2009-03-07 2:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, Finn Arne Gangstad, Sverre Rabbelier,
markus.heidelberg, git, John Tapsell, Andreas Ericsson
In-Reply-To: <7vr61ash8o.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 6 Mar 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > ...
> >> 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).
>
> When you and Dscho contradict with each other, I seem to end up agreeing
> with Dscho most of the time, but for this particular one, I completely
> agree with you.
A word of caution. Quite a few people (or at least a few people who write
loud-enough emails) do not like me. So even if you agree with my
reasoning, you might want to point out that you are not agreeing with
"Dscho", but rather mention that you happened to agree with a particular
line of argument.
Certain people might mistake your being convinced by arguments for pure
politics otherwise.
> I personally think Finn's suggested list is overengineered, and we
> should start with only three: "nothing", "current" (aka HEAD), and
> "matching". It is Ok to have a separate discussion to figure out what
> other default behaviours are desireable, but I think that should come
> after the dust settled from the transition, and more importantly, I
> think the other kinds of fine-tuned behaviour needs to be per-remote,
> and is not something the repository (or user) wide default push.default
> can cover.
As long as the default does not change without warning, I am sure we are
safe there.
Me mentioning Steffen's patch was more meant to kickstart people who
missed the discussion into the intricacies, not to say that one or the
other default makes most sense.
Personally, I am torn between the current default, which appears massively
reasonable to me (probably due to being exposed to Git for quite some
time), but I can also see why Steffen's approach appeals to some people.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] builtin-merge: add support for default merge options
From: Jay Soffian @ 2009-03-07 1:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jean-luc malet
In-Reply-To: <7v63imqhcz.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 6, 2009 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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
Okay. That's probably a more invasive patch, because a lot more code
paths look at [branch ...], but I'll look into it.
> So overall, cumulative configuration tend to be more cumbersome for the
> end user to manage.
Okay, you've convinced me.
j.
^ permalink raw reply
* 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
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