* Re: [PATCH/RFC 1/n] gitweb: Better git-unquoting and gitweb-quoting of pathnames
From: Jakub Narebski @ 2006-11-03 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodro91ye.fsf@assigned-by-dhcp.cox.net>
Dnia piątek 3. listopada 2006 12:58, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Perhaps it should be "LF ('\n') and TAB ('\t')".
>
> Official terminology seems to call \t "HT", but my feeling is
> that we would not need that comment there.
O.K. I'll remove that comment.
>> Or
>> return $es{$seq} if exists $es{$seq};
>
> Although gitweb is full of that syntax, I personally do not like
> it very much. It is really hard to read when you are trying to
> skim through the code quickly. You would have to say "why
> return it? ah -- only when it exists, then it makes sense",
> which is a hiccup that disrupts the thought process.
O.K., I'll change style from
return chr(oct($seq)) if ($seq =~ m/^[0-7]{1,3}$/);
return $es{$seq} if exists $es{$seq};
return $seq;
to the more readable form
if ($seq =~ m/^[0-7]{1,3}$/) {
return chr(oct($seq));
} elsif (exists $es{$seq}) {
return $es{$seq};
}
return $seq;
I think it is better to leave final "return $seq;" outside else block.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Add support to git-branch to show local and remote branches
From: Junio C Hamano @ 2006-11-03 12:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611031052.16095.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Instead of storing a list of refnames in append_ref, a list of
> structures is created. Each of these stores the refname and a
> symbolic constant representing its type.
>
> The creation of the list is filtered based on a command line
> switch; no switch means "local branches only", "-r" means
> "remote branches only" (as they always did); but now "-a"
> means "local branches or remote branches".
>
> As a side effect, the list is now not global, but allocated in
> print_ref_list() where it used.
>
> Also a memory leak is plugged, the memory allocated during the
> list creation was never freed. This is now done in the new
> function, tidy_ref_list()
I would not call that a "leak" given that print_ref_list() is
the last thing to be called before the command exits. I'd
rather not to spend cycles calling free().
> +static int tidy_ref_list( struct ref_list *ref_list )
Style. No spaces before or after parameter list.
I see you already parse "refs/tags" prefix. "git branch" would
not print tags, but that part might be useful when we want to
redo git-tag in C.
Other than that, I think it is equivalent to what I have in "pu"
right now.
^ permalink raw reply
* git cygwin package?
From: Nguyen Thai Ngoc Duy @ 2006-11-03 12:18 UTC (permalink / raw)
To: git
Hi,
Has anyone created a binary package for git on cygwin?
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-03 12:36 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Catalin Marinas, git
In-Reply-To: <454B30E4.8000909@shadowen.org>
On 2006-11-03 12:07:00 +0000, Andy Whitcroft wrote:
> It reached me as quoted printable, with =20 on your signature intro.
The copy of your mail cc'ed to me reached me as 8bit, but the copy I
got through the list reached me as QP.
As I said, I don't really want to know why. I just want my patches to
pass through smtp hell unmangled. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH 2/4] Rename remote_only to display_mode
From: Andy Parkins @ 2006-11-03 12:37 UTC (permalink / raw)
To: git
In-Reply-To: <7v4ptgagth.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 11:51, Junio C Hamano wrote:
> Seriously, it is perfectly Ok to send "for discussion" feelers
Thank you for all the excellent advice. Being new here I'm basically trying
not to make a nuisance of myself :-)
I'll worry less about getting these things right first time; no one here goes
mad if a patch is wrong and I'm quite enjoying myself really :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] Add support to git-branch to show local and remote branches
From: Andy Parkins @ 2006-11-03 12:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcxg91gq.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 12:08, Junio C Hamano wrote:
> > +static int tidy_ref_list( struct ref_list *ref_list )
>
> Style. No spaces before or after parameter list.
Bah! It's so hard getting my fingers to remember what style goes in which
project :-)
> I see you already parse "refs/tags" prefix. "git branch" would
> not print tags, but that part might be useful when we want to
> redo git-tag in C.
I'm going to have a look at that soon; I've got enough of a hang of things
with this git-branch work that I think I could cope with writing git-tag in
C.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: git cygwin package?
From: Tim O Callaghan @ 2006-11-03 12:43 UTC (permalink / raw)
To: git
> Hi,
> Has anyone created a binary package for git on cygwin?
I started working on one a while ago, but it started to take up too much time. In the end i had to
shelve it for a while. I was looking at it recently actually.
There are were few issues with trying to compile with a target path directory of / (root), as
cygwin uses /bin /lib etc for all of its binaries. There were some problems with the import/export
SVN tools as well IIRC.
Its not just git that needs to be added to cygwin, Asciidoc and a few other tools (i have a list
somewhere) would also need to be packaged for cygwin too, because the package system re-builds
their binaries from source for distribution.
Also whoever builds them would also have to make sure they have the time maintain them or they get
dropped.
Tim.
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 12:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061103095859.GC16721@diana.vm.bytemark.co.uk>
On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
> I believe all the mails I send with mutt are QP-encoded, and they
> don't look funny, do they? (You'd see the separator just above my
> signature as "--=20" if that was the case; it has a trailing
> whitespace.)
This e-mail, in gmail:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
In Gnus (via gmane, no "=20" displayed though Gnus can handle this
encoding correctly):
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
It looks like the mail server re-encodes the message.
> > However, I'd like the message body to still be 8bit and the QP
> > encoding optional (either command line option or [stgit] config
> > variable).
>
> Are you sure? Wouldn't it be better to teach StGIT to eat QP-encoded
> mails, and use 7bit encoding when the patch is all ascii? (And still
> have an option to force 8bit instead of QP if desired, of course.)
Well, I don't have any strong opinion here, as long as QP is more
widely available. My impression with Gnus was that it cannot handle
but I think there was an encoding problem.
The initial mail command implementation was inspired from sendpatchset
but we should probably now use the email Python package and let it
handle the encoding and decoding (for import).
--
^ permalink raw reply
* Re: [PATCH] Add git-count-packs, like git-count-objects.
From: Jakub Narebski @ 2006-11-03 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611020130r70ed6f4cnf67586deff36452e@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On 10/28/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Perhaps to not to add yet another command to already large set, rename
>> git-count-objects to git-count, and enhance it to count both loose objects
>> and packs (or not, and use git-count-objects as command name).
>
> Oh if so, I'd suggest git-stats over git-count :-)
Or even git-db-stats (as companion to git-db-init).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 12:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Petr Baudis, git
In-Reply-To: <7vslh0bwsm.fsf@assigned-by-dhcp.cox.net>
On 03/11/06, Junio C Hamano <junkio@cox.net> wrote:
> I wonder if this can be solved by simply reusing the machinery
> format-patch already has. If calling it as a standalone script
> does more unnecessary things than what StGIT wants, we should
> certainly be able to separate the only necessary part out to
> suit StGIT's needs.
I would like to keep the e-mail templates feature which is not
available via format-patch. The reason is because I also send patches
to the ARM Linux maintainer via a patch tracking system which expects
the messages formatted in a strict certain way
(http://www.arm.linux.org.uk/developer/patches/info.php). It would
probably be easier to fix StGIT than modifying format-patch.
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-03 13:02 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611030444w13e04586u185413c2562d45bc@mail.gmail.com>
On 2006-11-03 12:44:48 +0000, Catalin Marinas wrote:
> On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > Are you sure? Wouldn't it be better to teach StGIT to eat
> > QP-encoded mails, and use 7bit encoding when the patch is all
> > ascii? (And still have an option to force 8bit instead of QP if
> > desired, of course.)
>
> Well, I don't have any strong opinion here, as long as QP is more
> widely available. My impression with Gnus was that it cannot handle
> but I think there was an encoding problem.
Most probably, yes. Not supporting QP would count as a serious
deficiency in an e-mail client.
> The initial mail command implementation was inspired from
> sendpatchset but we should probably now use the email Python package
> and let it handle the encoding and decoding (for import).
Or try to use the git plumbing directly, if reasonable. Mail encoding
and decoding isn't my idea of fun -- I just want it to not break. And
I don't see much point in StGIT replicating core GIT functionality
when there's no reason to.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 13:16 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061103130259.GA20611@diana.vm.bytemark.co.uk>
On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
> Or try to use the git plumbing directly, if reasonable. Mail encoding
> and decoding isn't my idea of fun -- I just want it to not break. And
> I don't see much point in StGIT replicating core GIT functionality
> when there's no reason to.
As I said in my reply to Junio, I really like to keep the e-mail
templates functionality of StGIT. This is not available in
git-format-patch.
--
^ permalink raw reply
* Re: [PATCH 2/4] Rename remote_only to display_mode
From: Andreas Ericsson @ 2006-11-03 13:23 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611031200.27275.andyparkins@gmail.com>
Andy Parkins wrote:
> On Friday 2006 November 03 10:51, Andreas Ericsson wrote:
>
>> If you *need* to change something, change it. If you *want* to change
>> something just because it's not written the way you would write it, back
>> away. If you think some interface you're using needs clearing up
>> (codewise or with extra comments), send a separate patch for that so the
>> actual feature/bugfix you're sending in doesn't drown in cosmetic
>> changes to the interfaces the patch uses/touches.
>
> Thank you for the excellent advice. What then would you suggest in the case
> in point? I made as minimal a change as I could make; but that left the code
> a little bit bitty - I had press-ganged a variable into taking on another
> function and was using numeric literals that should really have been given
> meaning with #define?
>
> My question is perhaps different from simply git-etiquette; it's should I
> prefer my patches to be minimal or neat? If there is a more appropriate way
> of doing something should I do it or should I favour minimalism?
>
Neat, imo. Re-using old variables might be appropriate if the name of
the variable still makes sense, but rename it if there's a better name
for it.
> I've actually rewritten it now as per Junio's request, and while I'm happier
> with the code, it was much bigger change, that didn't really lend itself to
> being broken into smaller patches as did my first attempt.
>
> I guess in the end it's a judgement call and the best thing to do is post it
> and see who shoots it down :-)
>
Probably the most sensible approach. Even though the list is pretty
trigger-happy, the guns are more of the playful water-squirt type than
the high-powered big-calibre kind.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 13:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061103130259.GA20611@diana.vm.bytemark.co.uk>
On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
> Mail encoding and decoding isn't my idea of fun -- I just want it to not break.
I understand this and I think we should get this fixed. In the
meantime, you can always run git-format-patch/git-send-email on the
StGIT patches (the id would be "patches/<branch>/<patch>"). On my side
I just run git-am and "stg uncommit" or "assimilate".
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-03 13:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611030516v43a25b76y4c07f82b33411a6e@mail.gmail.com>
On 2006-11-03 13:16:08 +0000, Catalin Marinas wrote:
> On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > Or try to use the git plumbing directly, if reasonable. Mail
> > encoding and decoding isn't my idea of fun -- I just want it to
> > not break. And I don't see much point in StGIT replicating core
> > GIT functionality when there's no reason to.
>
> As I said in my reply to Junio, I really like to keep the e-mail
> templates functionality of StGIT. This is not available in
> git-format-patch.
Fair enough. How about e-mail importing -- is there a good reason to
not use the git plumbing there?
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-03 13:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611030525t5da2cce7nf7b41323411e8d2d@mail.gmail.com>
On 2006-11-03 13:25:36 +0000, Catalin Marinas wrote:
> On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > Mail encoding and decoding isn't my idea of fun -- I just want it
> > to not break.
>
> I understand this and I think we should get this fixed. In the
> meantime, you can always run git-format-patch/git-send-email on the
> StGIT patches (the id would be "patches/<branch>/<patch>").
Does that mean that "stg mail" with my QP patch generates output that
even git-am can't read? I had guessed from what you said earlier that
git-am _could_ read them.
> On my side I just run git-am and "stg uncommit" or "assimilate".
Yes, aren't they handy sometimes? :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Petr Baudis @ 2006-11-03 13:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0611030525t5da2cce7nf7b41323411e8d2d@mail.gmail.com>
Dear diary, on Fri, Nov 03, 2006 at 02:25:36PM CET, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> I just run git-am and "stg uncommit" or "assimilate".
git-am calls git-mailsplit and git-mailinfo, and those two tools will do
most of the work (basically everything except the actual committing) for
you, I use them in cg-patch -m and it should be fairly trivial to make a
stg command reusing those too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-03 13:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061103133329.GB21202@diana.vm.bytemark.co.uk>
On 2006-11-03 14:33:29 +0100, Karl Hasselström wrote:
> Does that mean that "stg mail" with my QP patch generates output that
> even git-am can't read? I had guessed from what you said earlier that
> git-am _could_ read them.
(Yes, I'm way too lazy. I tested the "stg mail" output by mailing
patches to myself and making sure that they looked good in my mail
reader. And by looking at the raw output quite a bit.)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 13:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061103133329.GB21202@diana.vm.bytemark.co.uk>
On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-11-03 13:25:36 +0000, Catalin Marinas wrote:
> > I understand this and I think we should get this fixed. In the
> > meantime, you can always run git-format-patch/git-send-email on the
> > StGIT patches (the id would be "patches/<branch>/<patch>").
>
> Does that mean that "stg mail" with my QP patch generates output that
> even git-am can't read? I had guessed from what you said earlier that
> git-am _could_ read them.
Yes, git-am was able to apply them but after using Gnus to write them
to an mbox file.
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Andy Whitcroft @ 2006-11-03 14:03 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Karl Hasselström, Catalin Marinas, git
In-Reply-To: <454B30E4.8000909@shadowen.org>
Andy Whitcroft wrote:
> Karl Hasselström wrote:
>> On 2006-11-03 10:58:59 +0100, Karl Hasselström wrote:
>>
>>> I believe all the mails I send with mutt are QP-encoded,
>> I just checked, and that one certainly was.
>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: QUOTED-PRINTABLE
>
> It reached me as quoted printable, with =20 on your signature intro.
Heh, well the copy thunderbird wrote directly to my mailbox is also
8bit. And thinking about it I've seen talk of MTA's not supporting 8bit
xfers between themselves, so thats probabally when it gets switched.
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 14:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Karl Hasselström, git
In-Reply-To: <20061103133933.GP20017@pasky.or.cz>
On 03/11/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Nov 03, 2006 at 02:25:36PM CET, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> said that...
> > I just run git-am and "stg uncommit" or "assimilate".
>
> git-am calls git-mailsplit and git-mailinfo, and those two tools will do
> most of the work (basically everything except the actual committing) for
> you, I use them in cg-patch -m and it should be fairly trivial to make a
> stg command reusing those too.
Yes, indeed, these are the commands I would use. I wouldn't go further
in calling git-am or git-applymbox directly as I try not to use too
many of the porcelain'ish git scripts.
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 14:37 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <b0943d9e0611030556v4c49868ct5e553240a5f1d63@mail.gmail.com>
On 03/11/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 03/11/06, Karl Hasselström <kha@treskal.com> wrote:
> > On 2006-11-03 13:25:36 +0000, Catalin Marinas wrote:
> > > I understand this and I think we should get this fixed. In the
> > > meantime, you can always run git-format-patch/git-send-email on the
> > > StGIT patches (the id would be "patches/<branch>/<patch>").
> >
> > Does that mean that "stg mail" with my QP patch generates output that
> > even git-am can't read? I had guessed from what you said earlier that
> > git-am _could_ read them.
>
> Yes, git-am was able to apply them but after using Gnus to write them
> to an mbox file.
I changed your patch slightly to add "Content-Disposition: inline" and
QUOTED-PRINTABLE instead of quoted-printable. It seems that Gnus can
show it properly now (but import still fails, of course).
--
^ permalink raw reply
* Re: git cygwin package?
From: Marco Roeland @ 2006-11-03 14:50 UTC (permalink / raw)
To: Tim O Callaghan; +Cc: git
In-Reply-To: <2495.145.36.45.123.1162557826.squirrel@www.dspsrv.com>
On Friday November 3rd 2006 at 12:43 Tim O Callaghan wrote:
> Its not just git that needs to be added to cygwin, Asciidoc and a few other tools (i have a list
> somewhere) would also need to be packaged for cygwin too, because the package system re-builds
> their binaries from source for distribution.
Debian has split git into different packages to avoid unnessary
dependencies if you don't need them. Might be a good idea for Cygwin.
A 'git-core' package for Cygwin would already be of great use. The
documentation can then for example be fetched from the respective
documentation branches in the git repository.
--
^ permalink raw reply
* Re: multiple branches or multiple repositories
From: Jeff King @ 2006-11-03 16:01 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <eie7ae$ib6$1@sea.gmane.org>
On Fri, Nov 03, 2006 at 02:51:30AM +0100, Han-Wen Nienhuys wrote:
> - for each module, create a separate git repository. Inside the
> repository, each subproject has its own branching
>
> - put each module as a separate branch in a shared repository.
>
> I think the first option is the most natural one, but are there any
> issues, besides namespace pollution to the second option?
I don't believe there is currently an option to git-clone to grab only a
single branch, so cloners in the second case would end up having to get
_all_ modules (though such an option would probably not be hard to
implement).
The plus side is that a single 'fetch' would grab updates for all
modules (with only a single connection to the server).
^ permalink raw reply
* Re: git bug? + question
From: Linus Torvalds @ 2006-11-03 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Miles Bader, git
In-Reply-To: <7v3b90gbfv.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Nov 2006, Junio C Hamano wrote:
>
> [remote."gitster"]
Btw, why the '.'? It doesn't even work with a dot, you have to have a
space, which is also a lot more readable..
Also, may I suggest that we just extend the format with a robust default
value thing?
It should be reasonably easy to have just the rule:
- add a new "remote.<remote>.branch" thing that lists multiple simple
branches separated by whitespace.
- a "simple branch" is just a "implicit refspec" for the relationship
"heads/<name>:remotes/<remote>/<name>"
And then you should be able to write all of your cumbersome config options
as a simple
[remote "gitster"]
url = gitster.example.com:/home/junio/git.git/
branch = maint master next +pu
and you're all done. It would imply everything you said.
This would basically require that "git-parse-remote" be re-written as a
native builtin, because quite frankly, it would be too damn painful any
other way, but it really shouldn't be that nasty. In fact, I think we
should have done that long ago, because the shell-code is just horrid for
things like this.
For example, for builtin-push (which is currently the only thing that
parses "remote" entries in C), you'd just need to do something like the
appended.. It would generate the full refspecs from the "branch" config
automatically.
Linus
---
diff --git a/builtin-push.c b/builtin-push.c
index d23974e..805ffa8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -123,15 +123,33 @@ static int get_remote_config(const char*
{
if (!strncmp(key, "remote.", 7) &&
!strncmp(key + 7, config_repo, config_repo_len)) {
- if (!strcmp(key + 7 + config_repo_len, ".url")) {
+ const char *subkey = key + 7 + config_repo_len;
+ if (!strcmp(subkey, ".url")) {
if (config_current_uri < MAX_URI)
config_uri[config_current_uri++] = xstrdup(value);
else
error("more than %d URL's specified, ignoring the rest", MAX_URI);
}
- else if (config_get_refspecs &&
- !strcmp(key + 7 + config_repo_len, ".push"))
- add_refspec(xstrdup(value));
+ else if (config_get_refspecs) {
+ if (!strcmp(subkey, ".push"))
+ add_refspec(xstrdup(value));
+ else if (!strcmp(subkey, ".branch")) {
+ while (isspace(*value))
+ value++;
+ while (*value) {
+ const char *end = value;
+ while (!isspace(*end))
+ end++;
+ add_refspec(xsprintf("heads/%.*s:remotes/%.*s/%.*s",
+ end-value, value,
+ config_repo_len, config_repo,
+ end-value, value));
+ while (isspace(*end))
+ end++;
+ value = end;
+ }
+ }
+ }
}
return 0;
^ 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