* Re: [PATCHv3] Make git-clone respect branch.autosetuprebase
From: Junio C Hamano @ 2009-03-04 6:29 UTC (permalink / raw)
To: Pat Notz; +Cc: git
In-Reply-To: <1236111825-32159-1-git-send-email-pknotz@sandia.gov>
"Pat Notz" <pknotz@sandia.gov> writes:
> When git-clone creates an initial branch it was not
> checking the branch.autosetuprebase configuration
> option (which may exist in ~/.gitconfig).
>
> Added function to branch.c to handle autorebase
> configuration setup.
>
> Signed-off-by: Pat Notz <pknotz@sandia.gov>
Thanks.
Your patch still has two codepaths that set the branch.*.merge and other
information and they can diverge with later changes. You can refactor
them even more to avoid that risk, like the attached patch.
The test is taken from your patch but runs inside a subshell, so that
later tests others may add to the script will be safer from the
environment variable settings and chdir this test does.
-- >8 --
When git-clone creates an initial branch it was not checking the
branch.autosetuprebase configuration option (which may exist in
~/.gitconfig). Refactor the code used by "git branch" to create
a new branch, and use it instead of the insufficiently duplicated code
in builtin-clone.
---
branch.c | 49 +++++++++++++++++++++++++++++++++----------------
branch.h | 7 +++++++
builtin-clone.c | 18 +++---------------
t/t5601-clone.sh | 15 +++++++++++++++
4 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/branch.c b/branch.c
index 1f00e44..d20fb04 100644
--- a/branch.c
+++ b/branch.c
@@ -32,21 +32,48 @@ static int find_tracked_branch(struct remote *remote, void *priv)
return 0;
}
-static int should_setup_rebase(const struct tracking *tracking)
+static int should_setup_rebase(const char *origin)
{
switch (autorebase) {
case AUTOREBASE_NEVER:
return 0;
case AUTOREBASE_LOCAL:
- return tracking->remote == NULL;
+ return origin == NULL;
case AUTOREBASE_REMOTE:
- return tracking->remote != NULL;
+ return origin != NULL;
case AUTOREBASE_ALWAYS:
return 1;
}
return 0;
}
+void install_branch_config(int flag, const char *local, const char *origin, const char *remote)
+{
+ struct strbuf key = STRBUF_INIT;
+ int rebasing = should_setup_rebase(origin);
+
+ strbuf_addf(&key, "branch.%s.remote", local);
+ git_config_set(key.buf, origin ? origin : ".");
+
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.merge", local);
+ git_config_set(key.buf, remote);
+
+ if (rebasing) {
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.rebase", local);
+ git_config_set(key.buf, "true");
+ }
+
+ if (flag & BRANCH_CONFIG_VERBOSE)
+ printf("Branch %s set up to track %s branch %s %s.\n",
+ local,
+ origin ? "remote" : "local",
+ remote,
+ rebasing ? "by rebasing" : "by merging");
+ strbuf_release(&key);
+}
+
/*
* This is called when new_ref is branched off of orig_ref, and tries
* to infer the settings for branch.<new_ref>.{remote,merge} from the
@@ -55,7 +82,6 @@ static int should_setup_rebase(const struct tracking *tracking)
static int setup_tracking(const char *new_ref, const char *orig_ref,
enum branch_track track)
{
- char key[1024];
struct tracking tracking;
if (strlen(new_ref) > 1024 - 7 - 7 - 1)
@@ -80,19 +106,10 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
return error("Not tracking: ambiguous information for ref %s",
orig_ref);
- sprintf(key, "branch.%s.remote", new_ref);
- git_config_set(key, tracking.remote ? tracking.remote : ".");
- sprintf(key, "branch.%s.merge", new_ref);
- git_config_set(key, tracking.src ? tracking.src : orig_ref);
- printf("Branch %s set up to track %s branch %s.\n", new_ref,
- tracking.remote ? "remote" : "local", orig_ref);
- if (should_setup_rebase(&tracking)) {
- sprintf(key, "branch.%s.rebase", new_ref);
- git_config_set(key, "true");
- printf("This branch will rebase on pull.\n");
- }
- free(tracking.src);
+ install_branch_config(BRANCH_CONFIG_VERBOSE, new_ref, tracking.remote,
+ tracking.src ? tracking.src : orig_ref);
+ free(tracking.src);
return 0;
}
diff --git a/branch.h b/branch.h
index 9f0c2a2..eed817a 100644
--- a/branch.h
+++ b/branch.h
@@ -21,4 +21,11 @@ void create_branch(const char *head, const char *name, const char *start_name,
*/
void remove_branch_state(void);
+/*
+ * Configure local branch "local" to merge remote branch "remote"
+ * taken from origin "origin".
+ */
+#define BRANCH_CONFIG_VERBOSE 01
+extern void install_branch_config(int flag, const char *local, const char *origin, const char *remote);
+
#endif
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..a5f000a 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -20,6 +20,7 @@
#include "dir.h"
#include "pack-refs.h"
#include "sigchain.h"
+#include "branch.h"
/*
* Overall FIXMEs:
@@ -350,19 +351,6 @@ static struct ref *write_remote_refs(const struct ref *refs,
return local_refs;
}
-static void install_branch_config(const char *local,
- const char *origin,
- const char *remote)
-{
- struct strbuf key = STRBUF_INIT;
- strbuf_addf(&key, "branch.%s.remote", local);
- git_config_set(key.buf, origin);
- strbuf_reset(&key);
- strbuf_addf(&key, "branch.%s.merge", local);
- git_config_set(key.buf, remote);
- strbuf_release(&key);
-}
-
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int use_local_hardlinks = 1;
@@ -553,7 +541,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
remote_head = NULL;
option_no_checkout = 1;
if (!option_bare)
- install_branch_config("master", option_origin,
+ install_branch_config(0, "master", option_origin,
"refs/heads/master");
}
@@ -583,7 +571,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
head_points_at->peer_ref->name,
reflog_msg.buf);
- install_branch_config(head, option_origin,
+ install_branch_config(0, head, option_origin,
head_points_at->name);
}
} else if (remote_head) {
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 44793f2..2335d8b 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -159,4 +159,19 @@ test_expect_success 'clone a void' '
test_cmp target-6/.git/config target-7/.git/config
'
+test_expect_success 'clone respects global branch.autosetuprebase' '
+ (
+ HOME=$(pwd) &&
+ export HOME &&
+ test_config="$HOME/.gitconfig" &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ git config -f "$test_config" branch.autosetuprebase remote &&
+ rm -fr dst &&
+ git clone src dst &&
+ cd dst &&
+ actual="z$(git config branch.master.rebase)" &&
+ test ztrue = $actual
+ )
+'
+
test_done
^ permalink raw reply related
* Re: Why isn't hook file cloned to bared repository ?
From: Bryan Donlan @ 2009-03-04 6:13 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0903032140w4d8a9415l9f7b9a0678b492cc@mail.gmail.com>
On Wed, Mar 4, 2009 at 12:40 AM, Emily Ren <lingyan.ren@gmail.com> wrote:
> Hi,
>
> I added file "update" in my git repository my_repo/.git/hooks/, then
> I run command "git clone --bare my_repo" to generate a bared
> repository my_repo.git. But there's no update in my_repo.git/hooks.
>
> Do you know why ?
Because allowing code from an untrusted third-party repository to be
executed automatically without giving a chance to examine it is not a
very good idea from a security standpoint. In addition, hooks are
often not of interest to the person cloning the repository. Because of
these reasons, git clone will not copy hooks from the source
repository (for consistency, this is the case even when the source is
local).
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jeff King @ 2009-03-04 5:42 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <76718490903031157o2938d46cl6c33e78cf64ad9d1@mail.gmail.com>
On Tue, Mar 03, 2009 at 02:57:15PM -0500, Jay Soffian wrote:
> FWIW, I like this proposal. The only issue I have which I think simply
> cannot be reconciled is this: it doesn't do anything to help a user
> that expects "git push --init ssh://..." to "just work". (And here I'm
> assuming push --init just calls init --remote under the covers.) The
> reason is that such a user is probably just using the git supplied by
> their vendor, and thus remote creation is likely disabled by default.
> The best I can come up with is a different error message:
>
> "Sorry, remote repo creation not allowed. To enable it, blah blah blah"
>
> So at least the user has a clue that git can help them here, but there
> are security reasons it does not do so by default.
Yeah, the error messages should be more descriptive. Sites that have a
web interface can even do:
Sorry, remote repo creation must be down through the web interface.
Please go to http://host/$user/create/$repo.
where the URL can be customized based on the user and repo that made the
request.
Now we just need somebody who cares enough about this feature to work on
it. ;)
-Peff
^ permalink raw reply
* Why isn't hook file cloned to bared repository ?
From: Emily Ren @ 2009-03-04 5:40 UTC (permalink / raw)
To: git
Hi,
I added file "update" in my git repository my_repo/.git/hooks/, then
I run command "git clone --bare my_repo" to generate a bared
repository my_repo.git. But there's no update in my_repo.git/hooks.
Do you know why ?
Thanks,
Emily
^ permalink raw reply
* Re: [PATCH] clone: run post-checkout hook when checking out
From: layer @ 2009-03-04 5:01 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20090303053750.GA30201@coredump.intra.peff.net>
Jeff,
Thanks very much for doing this.
Kevin
^ permalink raw reply
* Re: git-svn does not support intermediate directories?
From: Tim Stoakes @ 2009-03-04 4:30 UTC (permalink / raw)
To: Michael Lai; +Cc: git
In-Reply-To: <21fc26450903031743x4beda8a3i835ecbd428817070@mail.gmail.com>
Michael Lai(myllai@gmail.com)@030309-17:43:
> After spending some hours struggling with git svn, it would appear
> that it does not support svn projects stored in paths similar to
> "http://foo.com/svn/repos/bar/myproject", where "myproject" uses the
> standard SVN tags/trunk/branches layout. I'm currently using git
> 1.6.1, though I tried this with 1.6.2-rc2 as well. The resulting
> .git/config looks something like this:
>
> [svn-remote "svn"]
> url = http://foo.com/svn/repos/bar
> fetch = myproject/trunk:refs/remotes/trunk
> branches = bar/myproject/branches/*:refs/remotes/*
> tags = bar/myproject/tags/*:refs/remotes/tags/*
>
> Yes, that's a redundant "bar" directory under "branches =" and "tags
> =". The issue seems to lie in git-svn doing something intelligent to
> extract the appropriate trunk directory. For the branches and tags,
> however, it just takes the full URL and removes the repository root
> (http://foo.com/svn/repos/bar) to produce "bar/myproject/{branches,
> tags}/*". The second effect is that "git svn fetch" will run but exit
> quietly without actually pulling anything from the repository. I
> tracked down an existing thread on the mailing list from a while ago
> (Feb 4th, title of "git-svn doesn't fetch anything"), but there was no
> resolution.
I've just run into this exact same issue.
> There is a quick workaround, which was to make this change to match_paths:
> < $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
> ---
> > $self->{path_regex} ||= qr/\/\Q$self->{path}\E\//;
>
> The additional "bar" directory gets pulled in when git-svn tries to
> determine what paths to pull down, and tries to match
> "/myproject/trunk" to "/bar/myproject/trunk". I've merely put a
> band-aid on the situation. My perl is rudimentary at best, or I'd
> have spent additional time to try to put in a "proper" patch, but was
> wondering if anyone else had run into this problem and would be
> willing to put in a fix (or point me in the right direction, that
> works too).
I messed about with disabling $Git::SVN::_minimize_url, but that seemed
to break other things.
Made worse for me was the fact that my 'bar' in the present was renamed
from 'baz' in the past, so git-svn couldn't find it at r1. Very
confusing!
I'd like a nicer solution too.
Tim
--
Tim Stoakes
^ permalink raw reply
* git-svn does not support intermediate directories?
From: Michael Lai @ 2009-03-04 1:43 UTC (permalink / raw)
To: git
Hey all,
After spending some hours struggling with git svn, it would appear
that it does not support svn projects stored in paths similar to
"http://foo.com/svn/repos/bar/myproject", where "myproject" uses the
standard SVN tags/trunk/branches layout. I'm currently using git
1.6.1, though I tried this with 1.6.2-rc2 as well. The resulting
.git/config looks something like this:
[svn-remote "svn"]
url = http://foo.com/svn/repos/bar
fetch = myproject/trunk:refs/remotes/trunk
branches = bar/myproject/branches/*:refs/remotes/*
tags = bar/myproject/tags/*:refs/remotes/tags/*
Yes, that's a redundant "bar" directory under "branches =" and "tags
=". The issue seems to lie in git-svn doing something intelligent to
extract the appropriate trunk directory. For the branches and tags,
however, it just takes the full URL and removes the repository root
(http://foo.com/svn/repos/bar) to produce "bar/myproject/{branches,
tags}/*". The second effect is that "git svn fetch" will run but exit
quietly without actually pulling anything from the repository. I
tracked down an existing thread on the mailing list from a while ago
(Feb 4th, title of "git-svn doesn't fetch anything"), but there was no
resolution.
There is a quick workaround, which was to make this change to match_paths:
< $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
---
> $self->{path_regex} ||= qr/\/\Q$self->{path}\E\//;
The additional "bar" directory gets pulled in when git-svn tries to
determine what paths to pull down, and tries to match
"/myproject/trunk" to "/bar/myproject/trunk". I've merely put a
band-aid on the situation. My perl is rudimentary at best, or I'd
have spent additional time to try to put in a "proper" patch, but was
wondering if anyone else had run into this problem and would be
willing to put in a fix (or point me in the right direction, that
works too).
Thanks,
Mike
^ permalink raw reply
* Re: [Orinoco-users] linux-firmware binary corruption with gitweb
From: Jakub Narebski @ 2009-03-04 0:26 UTC (permalink / raw)
To: Dave; +Cc: Pavel Roskin, git, linux-kernel, orinoco-users, dwmw2
In-Reply-To: <49AD7E2B.3010101@gmail.com>
Dave <kilroyd@googlemail.com> writes:
> Adding the git mailing list.
>
> Pavel Roskin wrote:
> > On Sat, 2009-02-28 at 19:24 +0000, Dave wrote:
>>> I'm aware of at least a couple users of orinoco who have picked up
>>> corrupt firmware# from the linux-firmware tree*.
>>>
>>> I've verified that the firmware in the repository itself is correct.
>>>
>>> It appears that downloading the file using the blob/raw links from
>>> gitweb causes the corruption (0xc3 everywhere). At least it does with
>>> firefox.
>>
>> I can confirm the problem with Firefox 3.0.6. But it's not "0xc3
>> everywhere". The corrupted file is a result of recoding from iso-8859-1
>> to utf-8. The correct agere_sta_fw.bin is 65046 bytes long. The
>> corrupted agere_sta_fw.bin is 89729 bytes long.
[...]
>> My strong impression is that the recoding takes place on the server. I
>> think the bug should be reported to the gitweb maintainers unless it a
>> local breakage on the kernel.org site.
>
> Thanks Pavel.
>
> I just did a quick scan of the gitweb README - is this an issue with the
> $mimetypes_file or $fallback_encoding configurations variables?
First, what version of gitweb do you use? It should be in 'Generator'
meta header, or (in older gitweb) in comments in HTML source at the
top of the page.
Second, the file is actually sent to browser 'as is', using binmode :raw
(or at least should be according to my understanding of Perl). And *.bin
binary file gets application/octet-stream mimetype, and doesn't send any
charset info. git.kernel.org should have modern enough gitweb to use this.
Strange...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Peter Harris @ 2009-03-04 0:18 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090303223600.GB11278@raven.wolf.lan>
On Tue, Mar 3, 2009 at 5:36 PM, Josef Wolf wrote:
>
> I'd rather not let every clone talk to subversion for several reasons.
> One of them is that it is very inconvenient (e.g. the password has to
> be entered several times for every commit).
Sounds like subversion isn't properly caching your credentials, or
your admin is paranoid and turned off the svn credential cache. I
can't remember the last time I had to enter a password.
Of course, git-svn-repo can't cache credentials, since it has to
impersonate different users. You are impersonating different users so
that the svn author field is correct, aren't you? But that shouldn't
be a problem for userN working on cloneN.
> After all, the whole point
> for having git-svn-repos is for the clone to avoid working directly
> against the subversion repos. If every clone works against subversion
> anyway, I can get rid of git-svn-repos as well.
From my perspective, the main advantage of git-svn-repos is the inital
clone. Subversion is way too slow to clone an entire project's history
(days, vs minutes for git). Subsequent 'git pull --rebase's are faster
than 'git svn rebase's, too, although not by the same ratio (except
for large subtree moves, which really are that much faster).
> On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:
>> Also, this line says "rebase my changes onto those of ../clone$clone",
>> which isn't what you want. It will end up rebasing svn commits that
>> the client didn't have on top of the client's commits, and will break
>> git-svn's index. Don't use --rebase here.
>
> Hmm, I must have misunderstood Michael, then. Wasn't he suggesting
> to rebase here? Here's the citation:
>
> |> (cd git-svn-repos; git pull ../clone1) # if this line is executed,
> |
> |That's the problem. This creates a merge after which you 1-2-3-4 and
> |1-2'-3'-4' plus the merge of 4 and 4'.
> |
> |Instead, use git pull --rebase here. You don't want merges in the branch
> |from which you dcommit.
I think he meant to say "git pull ../cloneN && git rebase trunk".
>> > # Although we have resolved the conflict, spurious conflicts are
>> > # propagated to the clones
>>
>> ...and this is because you had clones all merge from each other (via
>> git-svn-repos) *before* the changes were in svn.
>
> Does that mean that the conflicts would disappear if I do
> git-svn-rebase + git-svn-dcommit after every pull from a clone?
Well, 'disappear' is a strong word. "cloneX" has to be willing to
reset to your branch if you have resolved any conflicts on behalf of
cloneX. But the other cloneNs should not see those conflicts, at
least.
Not to mention that it's not outside the realm of possibility that
various cloneNs may be working with each other without involving you.
Plus, there is a small window where clones may be pulling from each
other, and will have to resolve the same conflicts you resolve during
your "git svn dcommit". I'm sure you've heard the saying "Every
computer science problem can be solved by adding a level of
indirection." You could add a git-svn-stage that pulls from cloneN and
does the dcommit (and then pushes to git-svn-repos, or lets
git-svn-repos do its own "git svn fetch"), leaving git-svn-repos clean
for cloneN to pull from...
Peter Harris
^ permalink raw reply
* Re: How can I merge some files rather than all files modified on one branch to my branch?
From: Nicolas Sebrecht @ 2009-03-04 0:10 UTC (permalink / raw)
To: Emily Ren; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <856bfe0e0903021956l549e41d2l97d7e0997067c133@mail.gmail.com>
On Tue, Mar 03, 2009 at 11:56:03AM +0800, Emily Ren wrote:
> Boyd,
> How to rewrite the history of the branch ?
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history
--
Nicolas Sebrecht
^ permalink raw reply
* Re: How does Git know which files no longer needed during upgrade?
From: Miklos Vajna @ 2009-03-03 23:30 UTC (permalink / raw)
To: dealmaker; +Cc: git
In-Reply-To: <22318714.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
On Tue, Mar 03, 2009 at 01:51:14PM -0800, dealmaker <vinkhc@gmail.com> wrote:
> I am going to upgrade software to a newer version in my main trunk, I
> decide to download the newer version and checkout the main trunk and copy
> it over to my main trunk.
Do you mean the 'master' branch by 'main trunk'? Trunk is not in Git's
terminology.
> If the older version has some files that are no
> longer in the newer version, how does git determine whether to keep those
> files or not? Does it even notify me that those files are no longer needed?
First, I think storing upstream code (that you will never touch) in
version control is a horrible idea, but if you really do it, I would do
something like:
cd /path/to/copy
rm -rf *
cp -a /path/to/new/version/* .
git add -A
git commit -m 'update foo to 2.0'
That will add/update/delete files as you would expect.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-03-03 22:36 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840903031135o4cf72ed0oe3fffed69cb7ce03@mail.gmail.com>
Thanks for your answer, Peter!
On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:
> On Tue, Mar 3, 2009 at 1:51 PM, Josef Wolf wrote:
> > # work on clones, pull work into git-svn-repos when we're done
> > #
> > for clone in 1 2 3; do
> > (
> > cd clone$clone
> > git pull --rebase
> > for commit in 1 2 3; do
> > echo change $clone $commit >>test
> > git commit -a -m "commit $clone $commit"
> > done
> > )
> > (cd git-svn-repos; git pull --rebase ../clone$clone)
> > done
>
> Um. This has each clone basing their commits on the work of some other
> clone. This line, specifically:
>
> > (cd git-svn-repos; git pull --rebase ../clone$clone)
>
> breaks the "git-svn-repos only ever pulls from subversion" model I
> suggested elsewhere.
I'd rather not let every clone talk to subversion for several reasons.
One of them is that it is very inconvenient (e.g. the password has to
be entered several times for every commit). After all, the whole point
for having git-svn-repos is for the clone to avoid working directly
against the subversion repos. If every clone works against subversion
anyway, I can get rid of git-svn-repos as well.
> Also, this line says "rebase my changes onto those of ../clone$clone",
> which isn't what you want. It will end up rebasing svn commits that
> the client didn't have on top of the client's commits, and will break
> git-svn's index. Don't use --rebase here.
Hmm, I must have misunderstood Michael, then. Wasn't he suggesting
to rebase here? Here's the citation:
|> (cd git-svn-repos; git pull ../clone1) # if this line is executed,
|
|That's the problem. This creates a merge after which you 1-2-3-4 and
|1-2'-3'-4' plus the merge of 4 and 4'.
|
|Instead, use git pull --rebase here. You don't want merges in the branch
|from which you dcommit.
> > # Although we have resolved the conflict, spurious conflicts are
> > # propagated to the clones
>
> ...and this is because you had clones all merge from each other (via
> git-svn-repos) *before* the changes were in svn.
Does that mean that the conflicts would disappear if I do
git-svn-rebase + git-svn-dcommit after every pull from a clone?
> Worse, since the git clients don't know that their work has been
> rebased, they can wind up conflicting with themselves too. Which is
> why I suggested "git svn dcommit" from each client, not from the
> central repository.
>
> This can be made work if you do something more like (untested):
> (cd git-svn-repos; git pull ../clone$clone topic-branch;
> git svn dcommit)
> (cd clone$clone; git checkout master; git pull;
> have a human verify that changes to master are correct;
> git branch -D topic-branch)
>
> instead of
>
> > (cd git-svn-repos; git pull --rebase ../clone$clone)
>
> ie. throw away each topic branch as you push it to git-svn-repos, and
> take the changes that have gone through git-svn back via a pull of
> master.
>
> But that starts to look to me like more work for each clone than "git
> svn dcommit" - YMMV, of course.
It might be more work. But at least, I have the impression that I
understand this workflow. ;-)
^ permalink raw reply
* Re: [TopGit] Multiple concurrent sets of patches
From: Jonas Smedegaard @ 2009-03-03 22:07 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König
In-Reply-To: <20090303194232.GB18423@pengutronix.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Mar 03, 2009 at 08:42:32PM +0100, Uwe Kleine-König wrote:
>On Tue, Mar 03, 2009 at 08:22:21PM +0100, Jonas Smedegaard wrote:
>> On Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:
>> >also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:
>> >> It seems to me that TopGit is incapable of handling this. That it
>> >> can only handle patchset against a single branch, and if the need
>> >> arise for restructuring an additional patchset for e.g. a stable
>> >> or oldstable branch, then quilt needs to be used manually anyway.
>> >
>> >Let me try to understand you: you want TopGit to maintain a single
>> >feature branch against two different source branches? How should
>> >that work? Could you elaborate a bit so that your needs become a bit
>> >more obvious?
>>
>> Not quite. I want TopGit to maintain multiple feature branches,
>> preferrably related.
>>
>> With "related" I mean that I would like to be able to "fork" a chain
>> of interdependent feature branches.
>>
>> TopGit easily support one chain of branches:
>>
>> upstream + pristine-tar -> master -> build
>>
>> I want TopGit to additionally support the following:
>>
>> upstream + pristine-tar -> stable-master -> stable-build
>>
>> upstream + pristine-tar -> oldstable-master -> oldstable-build
>>
>>
>> E.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would
>> want to fork those branches as t_stable/fix_01 and t_stable/feature_01.
>>
>>
>> I know that I can create all those TopGit branches one by one, but I
>> would then need to explicitly declare a list of TopGit branches to
>> apply each time I want to (re)generate a quilt patchlist.
>For my kernel development I use topgit topic branches that collect
>topgit patch branches. Take this dependency graph:
>
> linus/master <- t/armmisc/patch1 <- t/armmisc-master <- t/armmisc-pu
> ^ ^----t/armmisc/patch2 <--' |
> `------t/armmisc/patch3 <----------------------'
>
>So t/armmisc-master collects patches that are ready for upstream, -pu
>patches that need some more work.
My head is spinning - the dependency graph in my head was upside down
compared to your ascii art here.
I think I understand it . Thanks!
I will try it out - I converted ghostscript last week to using TopGit as
an excercise: good challenge, a nice bunch of patches (but nothing near
as complex as kernel stuff, I know).
> tg create t/fixes-squeeze/CVE-2009-abcd master-squeeze t/fixes-etch/CVE-2009-abcd
> ... no need to apply patch
> ... cherry-pick .topmsg from t/fixes-lenny/CVE-2009-abcd
> git commit
Above puzzles me: Is cherry-picking .topmsg just a lazy way to write
same description for parallel topicbranch, or is it a trick to cheat
TopGit into believing that that branch never needs updating?
>But this doesn't help me for my kernel problem, because here I don't
>have that ordering on releases. I want to manage patches on top of
>linux-tip and the ARM tree, but none of these contains the other :-/
I can only begin to imagine the complexities of dealing with parallel
tracks of kernel patching... Good luck with that!
Thanks a lot for your insight,
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmtqg0ACgkQn7DbMsAkQLhMFACgkW1FYlWnEP8unk+wVgAkd0i+
UMwAoKT1mkxIRP6XmNKt+Rj3iJn2yUpM
=7x2Z
-----END PGP SIGNATURE-----
^ permalink raw reply
* RE: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: John Dlugosz @ 2009-03-03 21:56 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780903031302m5f98fe71u8bdb23f90a8df82a@mail.gmail.com>
===Re:===
If Microsoft fixed the problem with UTF-8 support in C runtime, it is
a really good
news, because setlocale did not work not so long time ago:
===end===
They totally replaced it with one written by P.J.Plauger. I'm not sure
when, but I would guess around VC++7.1, which was a "sea change" and
felt more like a different brand than a simple update. That's when
templates started following the standard.
Re:
http://blogs.msdn.com/michkap/archive/2006/03/13/550191.aspx
Interesting. So it sort-of worked, as per my overlong muse as I looked
at the source code, but they started explicitly preventing it because it
doesn't always work for everything.
// verify codepage validity
if (!iCodePage || iCodePage == CP_UTF7 || iCodePage == CP_UTF8 ||
!IsValidCodePage((WORD)iCodePage))
return FALSE;
===Re:===
As to Win32 API, it has always worked correctly with UTF-8... In fact,
the
documentation of GetOEMCP function goes as far as recommending
to use UTF-8 or UTF-16: "For the most consistent results, applications
should
use Unicode, such as UTF-8 or UTF-16, instead of a specific code page.
===end===
I remember a time when it did not. I don't recall if it was NT (as
opposed to consumer windows) or some version of NT beyond 3.5 (starting
in 4?) that it became available. But I had to supply code with the
program because it could not count on it.
===Re:===
So it would be great if Git supported UTF-8 on Windows (as an option),
but it
is not my itch right now....
===end===
someone else mentioned "most people use ASCII file names", and I would
take that to be true only if "most people" == "developers". If you look
at my wife's "explorer" view, it's all Chinese. Files are downloaded
with Asian file names. Most people =in= China are used to seemless
support within Windows. It's only with Chinese MUI on English Windows
that the "ANSI" stuff doesn't match and programs that use 8-bit API
calls suddenly croak as they see "?????" for input.
--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
* How does Git know which files no longer needed during upgrade?
From: dealmaker @ 2009-03-03 21:51 UTC (permalink / raw)
To: git
Hi,
I am going to upgrade software to a newer version in my main trunk, I
decide to download the newer version and checkout the main trunk and copy
it over to my main trunk. If the older version has some files that are no
longer in the newer version, how does git determine whether to keep those
files or not? Does it even notify me that those files are no longer needed?
Thanks.
--
View this message in context: http://www.nabble.com/How-does-Git-know-which-files-no-longer-needed-during-upgrade--tp22318714p22318714.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Daniel Barkalow @ 2009-03-03 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7vy6vnf3aw.fsf@gitster.siamese.dyndns.org>
On Mon, 2 Mar 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > If you are going to limit it in that way, wouldn't it be better to do it
> > entirely client-side? As in, "git push --create remote" will literally
> > do:
> >
> > ssh remote_host "mkdir -p remote_dir && cd remote_dir && git init --bare"
> >
> > ? Then you don't have to care about whether the remote side is recent
> > enough to support this, and there are no potential security issues; git
> > is merely saving you from typing the commands you could have done
> > yourself.
>
> As with the previous "git init --remote" patch, my design constraints
> includes keeping the door open for "git shell" users to optionally allow
> this mode of operation.
One possibility would be to allow "git init" to create the directory (and
its parents) if it is able. Then the command is "ssh remote_host
GIT_DIR=remote_dir git init --bare". The "git shell" users can't use it,
but only because "git shell" won't run "git init". But there's no reason
it couldn't be configured (per-site or per-user) to allow it. Also,
git-init could run the template's "pre-init" hook to do whatever it is
that needs to be done for a new repository.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Dmitry Potapov @ 2009-03-03 21:02 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F077AC@EXCHANGE.trad.tradestation.com>
On Tue, Mar 3, 2009 at 11:39 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
>
> Now, the default when a program starts is to use the "C" locale. The
> locale argument to setlocale can take a form ".code_page", so calling
>
> setlocale (LC_CTYPE, ".65001");
>
> should do the trick. Assuming, that is, that you don't hit macros that
> assume that characters are never multibyte. So define the preprocessor
> symbol _MBCS when you compile.
If Microsoft fixed the problem with UTF-8 support in C runtime, it is
a really good
news, because setlocale did not work not so long time ago:
http://blogs.msdn.com/michkap/archive/2006/03/13/550191.aspx
As to Win32 API, it has always worked correctly with UTF-8... In fact, the
documentation of GetOEMCP function goes as far as recommending
to use UTF-8 or UTF-16: "For the most consistent results, applications should
use Unicode, such as UTF-8 or UTF-16, instead of a specific code page.
So it would be great if Git supported UTF-8 on Windows (as an option), but it
is not my itch right now....
Dmitry
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Robin Rosenberg @ 2009-03-03 20:59 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, Peter Krefting, Thomas Rast
In-Reply-To: <20090303162917.GA8096@lars.home.noschinski.de>
Lars Noschinski <lars-2008-2@usenet.noschinski.de> writes:
> * Peter Krefting <peter@softwolves.pp.se> [09-03-03 12:54]:
> > Lars Noschinski:
> > >Changing the filename (on checkout), so that the user sees an Ü regardless of
> > >his or her locale (instead of an \0xDC, which only resolves to an Ü on
> > >latin-1) would be an absolutely broken concept here.
> >
> > Why would it? It is my view as a user on my files that define how file names
> > are looked upon. If I have three machines, one Linux box using a iso8859-1
> > locale, an OS X box (where, I would believe, file APIs use UTF-8, someone
> > please correct me if I'm wrong), and a Windows box (which uses UTF-16 on the
> > file system layer, but does provide compatibility functions that use char
> > pointers), and create a file on each of these called "Ü.txt" (which would be
> > the sequence "DC 2E 74 78 74" on the Linux box, "C3 9C 2E 74 78 74" (or
> > probably something else since I believe OS X decomposes the string) on the OS X
> > box and "00DC 002E 0074 0078 0074" on the Windows box, I see these three file
> > names as equal.
>
> Because a function in the source code refers to (e.g.) "DC 2E 74 78 74",
> not "C3 9C 2E 74 78 74" nor "00DC 0024 0074 0078 0074". And it does so
> regardless of the locale.
The only actual language I know where I've seen people use non-ascii names for
referenced files, i.e. classes, is Java and there you specify the encoding to
the compiler. Class names are not byte sequences there. XML files are another
case where references files are defined in unicode. I assume this applies to
C# and other modern languages too.
> The file name may look funny depending on your locale, but if you rename
> the file to fit your local enconding, it would not work.
In the Java case, you /have/ to "rename" or the build will break. Build systems like Ant
or Maven require you to "rename" too regardless of what you build. A C Git clone
will produce unbuildable code, but JGit will produce a working one for unicode
aware systems and documentation, the case where unicode filenames are more common
than in source, will look good.
-- robin
PS. I readded the people you forgot to Cc
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: John Dlugosz @ 2009-03-03 20:39 UTC (permalink / raw)
To: git; +Cc: dpotapov
Re: AFAIK, Microsoft C runtime library does not support UTF-8,
Actually, here is a clip from the runtime library source code:
tmode = _textmode(fh);
switch(tmode) {
case __IOINFO_TM_UTF8 :
/* For a UTF-8 file, we need 2 buffers, because after
reading we
need to convert it into UNICODE - MultiByteToWideChar
doesn't do
in-place conversions. */
/* MultiByte To WideChar conversion may double the size
of the
buffer required & hence we divide cnt by 2 */
/*
* Since we are reading UTF8 stream, cnt bytes read may
vary
* from cnt wchar_t characters to cnt/4 wchar_t
characters. For
* this reason if we need to read cnt characters, we
will
* allocate MBCS buffer of cnt. In case cnt is 0, we
will
* have 4 as minimum value. This will make sure we don't
* overflow for reading from pipe case.
*
*
* In this case the numbers of wchar_t characters that
we can
* read is cnt/2. This means that the buffer size that
we will
* require is cnt/2.
*/
/* For UTF8 we want the count to be an even number */
This is in the _read(fd, buffer, count) function, and shows that it will
in fact read UTF-8 and automatically transform it to UTF-16LE
transparently. The documentation for _open explains this feature.
Meanwhile, a quick look at _mbslen() etc. shows that they are
implemented, and will handle UTF-8 encoded text as variable-length char*
just fine as long as suitable tables are loaded in its locale. An
internal header shows macros for generating the lead-byte information as
needed by that table.
Now, the default when a program starts is to use the "C" locale. The
locale argument to setlocale can take a form ".code_page", so calling
setlocale (LC_CTYPE, ".65001");
should do the trick. Assuming, that is, that you don't hit macros that
assume that characters are never multibyte. So define the preprocessor
symbol _MBCS when you compile.
Older versions might not work right because MBCS (multibyte character
strings) was only actually implemented to DBCS (double-byte). That is,
a single lead byte would be followed by a second byte, and no other
cases are provided for. But, GB18030 has up to 4 bytes in a single
character. It might still not be completely "clean" though because
GB18030 has a "double double" nature to it. Just like assuming 16-bit
characters period mostly works with surrogate pairs even if you didn't
code full UTF-16 support, DBCS code will see a 4-byte GB18030 character
as two double byte characters. So it gets the len (in characters)
wrong, and might still break up what is supposed to be a single
character. So it really needs some improvement from the historical
DBCS-only code to work properly.
Anyway, if UTF-8 really doesn't work with MBCS functions acceptably
well, and the goal is to allow passage of all characters through the
program, then set the program to use Chinese. GB18030 is =fully=
supported and is just another (albeit strange) encoding for Unicode.
As for what
fprintf (stderr, "unable to open %s", path);
will do, it will have no problem copying the contents of path to the
output stream no matter how it is encoded. The result will be sent to
stderr, which may be autotranslating the local code page to UTF-16 or
UTF-8, but by default just feeds the stream of bytes to the console
window's 8-bit API, which has its own code page setting.
Personally, I have printf'ed UTF-8 encoded text to standard output. It
looks OK if the console is also set to UTF-8.
--John
(please excuse the footer; it's not my idea)
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
* [PATCHv3] Make git-clone respect branch.autosetuprebase
From: Pat Notz @ 2009-03-03 20:23 UTC (permalink / raw)
To: git; +Cc: Pat Notz
When git-clone creates an initial branch it was not
checking the branch.autosetuprebase configuration
option (which may exist in ~/.gitconfig).
Added function to branch.c to handle autorebase
configuration setup.
Signed-off-by: Pat Notz <pknotz@sandia.gov>
---
Sorry, the PATCHv2 email had a stray "From:..." line.
branch.c | 23 ++++++++++++++++-------
branch.h | 9 +++++++++
builtin-clone.c | 3 +++
t/t5601-clone.sh | 14 ++++++++++++++
4 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/branch.c b/branch.c
index 1f00e44..ee8b69d 100644
--- a/branch.c
+++ b/branch.c
@@ -32,21 +32,33 @@ static int find_tracked_branch(struct remote *remote, void *priv)
return 0;
}
-static int should_setup_rebase(const struct tracking *tracking)
+static int should_setup_rebase(const char * remote)
{
switch (autorebase) {
case AUTOREBASE_NEVER:
return 0;
case AUTOREBASE_LOCAL:
- return tracking->remote == NULL;
+ return remote == NULL;
case AUTOREBASE_REMOTE:
- return tracking->remote != NULL;
+ return remote != NULL;
case AUTOREBASE_ALWAYS:
return 1;
}
return 0;
}
+int setup_autorebase(const char *local, const char *remote_tracked_branch)
+{
+ if (should_setup_rebase(remote_tracked_branch)) {
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(&key, "branch.%s.rebase", local);
+ git_config_set(key.buf, "true");
+ strbuf_release(&key);
+ return 1;
+ }
+ return 0;
+}
+
/*
* This is called when new_ref is branched off of orig_ref, and tries
* to infer the settings for branch.<new_ref>.{remote,merge} from the
@@ -86,11 +98,8 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
git_config_set(key, tracking.src ? tracking.src : orig_ref);
printf("Branch %s set up to track %s branch %s.\n", new_ref,
tracking.remote ? "remote" : "local", orig_ref);
- if (should_setup_rebase(&tracking)) {
- sprintf(key, "branch.%s.rebase", new_ref);
- git_config_set(key, "true");
+ if (setup_autorebase(new_ref, tracking.remote))
printf("This branch will rebase on pull.\n");
- }
free(tracking.src);
return 0;
diff --git a/branch.h b/branch.h
index 9f0c2a2..b332c09 100644
--- a/branch.h
+++ b/branch.h
@@ -21,4 +21,13 @@ void create_branch(const char *head, const char *name, const char *start_name,
*/
void remove_branch_state(void);
+/*
+ * Used when creating a new branch to properly setup the autorebase flag
+ * in the git-config file. If the new branch ("local") is created from
+ * a remote branch then remote_tracked_branch should be non-NULL. If
+ * the new branch is being created from another local branch then
+ * remote_tracked_branch should be NULL.
+ */
+int setup_autorebase(const char *local, const char *remote_tracked_branch);
+
#endif
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..587c834 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -17,6 +17,7 @@
#include "unpack-trees.h"
#include "transport.h"
#include "strbuf.h"
+#include "branch.h"
#include "dir.h"
#include "pack-refs.h"
#include "sigchain.h"
@@ -360,6 +361,8 @@ static void install_branch_config(const char *local,
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.merge", local);
git_config_set(key.buf, remote);
+ if (setup_autorebase(local, remote))
+ printf("Default branch '%s' will rebase on pull.\n", local);
strbuf_release(&key);
}
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 44793f2..0f8b43c 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -159,4 +159,18 @@ test_expect_success 'clone a void' '
test_cmp target-6/.git/config target-7/.git/config
'
+test_expect_success 'clone respects global branch.autosetuprebase' '
+ HOME="`pwd`" &&
+ export HOME &&
+ test_config="$HOME"/.gitconfig &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ git config -f "$test_config" branch.autosetuprebase remote &&
+ rm -fr dst &&
+ git clone src dst &&
+ cd dst &&
+ expected="ztrue" &&
+ actual="z$(git config branch.master.rebase)" &&
+ test $expected = $actual
+'
+
test_done
--
1.6.1.2
^ permalink raw reply related
* [PATCHv2] Make git-clone respect branch.autosetuprebase
From: pknotz @ 2009-03-03 20:15 UTC (permalink / raw)
To: git; +Cc: Pat Notz
From: Pat Notz <pknotz@sandia.gov>
When git-clone creates an initial branch it was not
checking the branch.autosetuprebase configuration
option (which may exist in ~/.gitconfig).
Added function to branch.c to handle autorebase
configuration setup.
Signed-off-by: Pat Notz <pknotz@sandia.gov>
---
branch.c | 23 ++++++++++++++++-------
branch.h | 9 +++++++++
builtin-clone.c | 3 +++
t/t5601-clone.sh | 14 ++++++++++++++
4 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/branch.c b/branch.c
index 1f00e44..ee8b69d 100644
--- a/branch.c
+++ b/branch.c
@@ -32,21 +32,33 @@ static int find_tracked_branch(struct remote *remote, void *priv)
return 0;
}
-static int should_setup_rebase(const struct tracking *tracking)
+static int should_setup_rebase(const char * remote)
{
switch (autorebase) {
case AUTOREBASE_NEVER:
return 0;
case AUTOREBASE_LOCAL:
- return tracking->remote == NULL;
+ return remote == NULL;
case AUTOREBASE_REMOTE:
- return tracking->remote != NULL;
+ return remote != NULL;
case AUTOREBASE_ALWAYS:
return 1;
}
return 0;
}
+int setup_autorebase(const char *local, const char *remote_tracked_branch)
+{
+ if (should_setup_rebase(remote_tracked_branch)) {
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(&key, "branch.%s.rebase", local);
+ git_config_set(key.buf, "true");
+ strbuf_release(&key);
+ return 1;
+ }
+ return 0;
+}
+
/*
* This is called when new_ref is branched off of orig_ref, and tries
* to infer the settings for branch.<new_ref>.{remote,merge} from the
@@ -86,11 +98,8 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
git_config_set(key, tracking.src ? tracking.src : orig_ref);
printf("Branch %s set up to track %s branch %s.\n", new_ref,
tracking.remote ? "remote" : "local", orig_ref);
- if (should_setup_rebase(&tracking)) {
- sprintf(key, "branch.%s.rebase", new_ref);
- git_config_set(key, "true");
+ if (setup_autorebase(new_ref, tracking.remote))
printf("This branch will rebase on pull.\n");
- }
free(tracking.src);
return 0;
diff --git a/branch.h b/branch.h
index 9f0c2a2..b332c09 100644
--- a/branch.h
+++ b/branch.h
@@ -21,4 +21,13 @@ void create_branch(const char *head, const char *name, const char *start_name,
*/
void remove_branch_state(void);
+/*
+ * Used when creating a new branch to properly setup the autorebase flag
+ * in the git-config file. If the new branch ("local") is created from
+ * a remote branch then remote_tracked_branch should be non-NULL. If
+ * the new branch is being created from another local branch then
+ * remote_tracked_branch should be NULL.
+ */
+int setup_autorebase(const char *local, const char *remote_tracked_branch);
+
#endif
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..587c834 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -17,6 +17,7 @@
#include "unpack-trees.h"
#include "transport.h"
#include "strbuf.h"
+#include "branch.h"
#include "dir.h"
#include "pack-refs.h"
#include "sigchain.h"
@@ -360,6 +361,8 @@ static void install_branch_config(const char *local,
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.merge", local);
git_config_set(key.buf, remote);
+ if (setup_autorebase(local, remote))
+ printf("Default branch '%s' will rebase on pull.\n", local);
strbuf_release(&key);
}
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 44793f2..0f8b43c 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -159,4 +159,18 @@ test_expect_success 'clone a void' '
test_cmp target-6/.git/config target-7/.git/config
'
+test_expect_success 'clone respects global branch.autosetuprebase' '
+ HOME="`pwd`" &&
+ export HOME &&
+ test_config="$HOME"/.gitconfig &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ git config -f "$test_config" branch.autosetuprebase remote &&
+ rm -fr dst &&
+ git clone src dst &&
+ cd dst &&
+ expected="ztrue" &&
+ actual="z$(git config branch.master.rebase)" &&
+ test $expected = $actual
+'
+
test_done
--
1.6.1.2
^ permalink raw reply related
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 19:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20090303082318.GB3158@coredump.intra.peff.net>
On Tue, Mar 3, 2009 at 3:23 AM, Jeff King <peff@peff.net> wrote:
>
> What about the client just calling init-serve on the server as a program
> which does whatever it wants to create a repo? The shipped default would
> be:
>
> #!/bin/sh
> echo >&2 Sorry, repo creation not allowed.
> exit 1
>
> Sites who want to give their users full creation access would do (and
> obviously the --mkdir option would need to be added):
>
> #!/bin/sh
> exec git init --mkdir "$@"
>
> Sites which want to restrict can do:
>
> #!/bin/sh
> for i in "$@"; do
> case "$i" in
> --bare) ;;
> *) echo >&2 Forbidden argument: $i; exit 1 ;;
> esac
> done
> exec git init --mkdir "$@"
>
> Sites like GitHub or Gerrit can munge the arguments as appropriate. They
> could even allow site-specific options if they wanted as long as they
> were syntactically correct (i.e., "git init --gerrit-base=foo remote"
> would pass the argument through to the remote unharmed).
FWIW, I like this proposal. The only issue I have which I think simply
cannot be reconciled is this: it doesn't do anything to help a user
that expects "git push --init ssh://..." to "just work". (And here I'm
assuming push --init just calls init --remote under the covers.) The
reason is that such a user is probably just using the git supplied by
their vendor, and thus remote creation is likely disabled by default.
The best I can come up with is a different error message:
"Sorry, remote repo creation not allowed. To enable it, blah blah blah"
So at least the user has a clue that git can help them here, but there
are security reasons it does not do so by default.
j.
^ permalink raw reply
* [PATCH] Documentation: Typo / spelling / formatting fixes
From: Mike Ralphson @ 2009-03-03 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson
In-Reply-To: <1236108562-31469-2-git-send-email-mike@abacus.co.uk>
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
Documentation/howto/revert-a-faulty-merge.txt | 4 ++--
Documentation/howto/setup-git-server-over-http.txt | 2 +-
Documentation/technical/api-strbuf.txt | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 39b1da4..3b4a390 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -39,7 +39,7 @@ Such a "revert" of a merge can be made with:
$ git revert -m 1 M
-After the develpers of the side branch fixes their mistakes, the history
+After the developers of the side branch fix their mistakes, the history
may look like this:
---o---o---o---M---x---x---W---x
@@ -116,7 +116,7 @@ If you reverted the revert in such a case as in the previous example:
/ \ /
---A---B A'--B'--C'
-where Y is the revert of W, A' and B'are rerolled A and B, and there may
+where Y is the revert of W, A' and B' are rerolled A and B, and there may
also be a further fix-up C' on the side branch. "diff Y^..Y" is similar
to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"),
and "diff A'^..C'" by definition would be similar but different from that,
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index 4032748..622ee5c 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -143,7 +143,7 @@ Then, add something like this to your httpd.conf
Require valid-user
</Location>
- Debian automatically reads all files under /etc/apach2/conf.d.
+ Debian automatically reads all files under /etc/apache2/conf.d.
The password file can be somewhere else, but it has to be readable by
Apache and preferably not readable by the world.
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
index ac56d1c..7438149 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -222,7 +222,7 @@ which can be used by the programmer of the callback as she sees fit.
Read a given size of data from a FILE* pointer to the buffer.
+
-NOTE: The buffer is rewinded if the read fails. If -1 is returned,
+NOTE: The buffer is rewound if the read fails. If -1 is returned,
`errno` must be consulted, like you would do for `read(3)`.
`strbuf_read()`, `strbuf_read_file()` and `strbuf_getline()` has the
same behaviour as well.
--
1.6.0.2.229.g1293c.dirty
^ permalink raw reply related
* [PATCH] Documentation: Typos / spelling fixes in RelNotes
From: Mike Ralphson @ 2009-03-03 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
Documentation/RelNotes-1.5.2.2.txt | 2 +-
Documentation/RelNotes-1.6.0.2.txt | 2 +-
Documentation/RelNotes-1.6.1.1.txt | 4 ++--
Documentation/RelNotes-1.6.1.2.txt | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/RelNotes-1.5.2.2.txt b/Documentation/RelNotes-1.5.2.2.txt
index f6393f8..7bfa341 100644
--- a/Documentation/RelNotes-1.5.2.2.txt
+++ b/Documentation/RelNotes-1.5.2.2.txt
@@ -45,7 +45,7 @@ Fixes since v1.5.2.1
correctly when the branch name had slash in it.
- The email address of the user specified with user.email
- configuration was overriden by EMAIL environment variable.
+ configuration was overridden by EMAIL environment variable.
- The tree parser did not warn about tree entries with
nonsense file modes, and assumed they must be blobs.
diff --git a/Documentation/RelNotes-1.6.0.2.txt b/Documentation/RelNotes-1.6.0.2.txt
index 7a9646f..51b32f5 100644
--- a/Documentation/RelNotes-1.6.0.2.txt
+++ b/Documentation/RelNotes-1.6.0.2.txt
@@ -7,7 +7,7 @@ Fixes since v1.6.0.1
* Installation on platforms that needs .exe suffix to git-* programs were
broken in 1.6.0.1.
-* Installation on filesystems without symbolic links support did nto
+* Installation on filesystems without symbolic links support did not
work well.
* In-tree documentations and test scripts now use "git foo" form to set a
diff --git a/Documentation/RelNotes-1.6.1.1.txt b/Documentation/RelNotes-1.6.1.1.txt
index 88454c1..8c594ba 100644
--- a/Documentation/RelNotes-1.6.1.1.txt
+++ b/Documentation/RelNotes-1.6.1.1.txt
@@ -41,11 +41,11 @@ Fixes since v1.6.1
work tree upon delete/modify conflict.
* "git merge -s recursive" didn't leave the index unmerged for entries with
- rename/delete conflictd.
+ rename/delete conflicts.
* "git merge -s recursive" clobbered untracked files in the work tree.
-* "git mv -k" with more than one errorneous paths misbehaved.
+* "git mv -k" with more than one erroneous paths misbehaved.
* "git read-tree -m -u" hence branch switching incorrectly lost a
subdirectory in rare cases.
diff --git a/Documentation/RelNotes-1.6.1.2.txt b/Documentation/RelNotes-1.6.1.2.txt
index 230aa3d..be37cbb 100644
--- a/Documentation/RelNotes-1.6.1.2.txt
+++ b/Documentation/RelNotes-1.6.1.2.txt
@@ -4,8 +4,8 @@ GIT v1.6.1.2 Release Notes
Fixes since v1.6.1.1
--------------------
-* The logic for rename detectin in internal diff used by commands like
- "git diff" and "git blame" have been optimized to avoid loading the same
+* The logic for rename detection in internal diff used by commands like
+ "git diff" and "git blame" has been optimized to avoid loading the same
blob repeatedly.
* We did not allow writing out a blob that is larger than 2GB for no good
--
1.6.0.2.229.g1293c.dirty
^ permalink raw reply related
* [PATCH] Documentation: Expand a couple of abbreviations
From: Mike Ralphson @ 2009-03-03 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson
In-Reply-To: <1236108562-31469-1-git-send-email-mike@abacus.co.uk>
These may not be obvious to non-native English speakers
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
Documentation/git-am.txt | 2 +-
Documentation/gitk.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index ff307eb..75081d9 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -121,7 +121,7 @@ the commit, after stripping common prefix "[PATCH <anything>]".
It is supposed to describe what the commit is about concisely as
a one line text.
-The body of the message (iow, after a blank line that terminates
+The body of the message (in other words, after a blank line that terminates
RFC2822 headers) can begin with "Subject: " and "From: " lines
that are different from those of the mail header, to override
the values of these fields.
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index bd005bc..cf465cb 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -74,7 +74,7 @@ frequently used options.
<path>...::
Limit commits to the ones touching files in the given paths. Note, to
- avoid ambiguity wrt. revision names use "--" to separate the paths
+ avoid ambiguity with respect to revision names use "--" to separate the paths
from any preceding options.
Examples
--
1.6.0.2.229.g1293c.dirty
^ permalink raw reply related
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