* Re: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-16 0:38 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Brandon Casey, Junio C Hamano, Brandon Casey, jk, git
In-Reply-To: <m26387voiy.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>> Right. And checking, after sending a patch containing CRs with mutt, it
>> lost those CRs. Even the local copy saved directly by mutt, which didn't
>> leave my box, lacks the CRs. So it seems basically impossible to send
>> patches to CRLF files inline.
>
> If you want to send mail containing a bare CR you need to encode it.
Btw, this mail had a stray CR added to the last line when I sent it out
(properly encoded as quoted-printable), but that didn't make it through
gmane. :-)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Junio C Hamano @ 2009-12-16 1:05 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091215164959.GA21322@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> - diff.c::run_external_diff() that runs GIT_EXTERNAL_DIFF defines that
>> the command has to take 7 parameters in a fixed order, and is not
>> designed to permute its arguments like ll_ext_merge() does, but these
>> days people don't use it directly (they use it indirectly via
>> "difftool" wrapper), so it probably is not an issue.
>
> There is also diff.*.command, which I think people _do_ set manually (I
> used to, until I wrote textconv. :) ).
I had to spend fair amount of time to find where "diff.*.command" is
described. We may want to update the documentation.
> .... I agree that people almost certainly have to write a shell-script
> wrapper anyway. But I wonder if we should pass it through the shell,
> just for the sake of consistency with the other variables (in
> particular, if textconv changes,
This covers GIT_EXTERNAL_DIFF, diff.external, and diff.<driver>.command
trio, if I am not mistaken.
If we changed run_external_diff(), in practice nobody would notice, except
for people who have installed the difftool helper in a directory with IFS
in the path. That's one downside but I don't offhand see a use case where
the change would make somebody vastly happier.
But maybe people will find good uses and we'll never know until we try.
Care to roll a patch for that as well, to be queued for 1.7.0 (which will
be the one after 1.6.6)?
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Jeff King @ 2009-12-16 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vljh3wwwf.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 05:05:52PM -0800, Junio C Hamano wrote:
> > There is also diff.*.command, which I think people _do_ set manually (I
> > used to, until I wrote textconv. :) ).
>
> I had to spend fair amount of time to find where "diff.*.command" is
> described. We may want to update the documentation.
Yeah, I think textconv is similarly hard to find. We should probably
have a pointer in "git-diff.txt" to the attributes documentation.
I also think it would be much more obvious as "diff.*.external", but it
is probably not worth changing at this point.
> > .... I agree that people almost certainly have to write a shell-script
> > wrapper anyway. But I wonder if we should pass it through the shell,
> > just for the sake of consistency with the other variables (in
> > particular, if textconv changes,
>
> This covers GIT_EXTERNAL_DIFF, diff.external, and diff.<driver>.command
> trio, if I am not mistaken.
It does cover all three. We could do them separately, I guess, but I
think that is just making things confusingly more inconsistent.
> If we changed run_external_diff(), in practice nobody would notice, except
> for people who have installed the difftool helper in a directory with IFS
> in the path. That's one downside but I don't offhand see a use case where
> the change would make somebody vastly happier.
Yeah, the only upside I can see is consistency. Which I do value, but it
will be a hard sell to somebody whose setup has been broken. ;P
> But maybe people will find good uses and we'll never know until we try.
> Care to roll a patch for that as well, to be queued for 1.7.0 (which will
> be the one after 1.6.6)?
Will do, but it will probably be a few days as I'm about to do some
holiday traveling. I'll do the textconv change with it as a series.
-Peff
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Junio C Hamano @ 2009-12-16 1:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: J.H., git, John 'Warthog9' Hawley
In-Reply-To: <200912112353.11034.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Fri, 11 Dec 2009, J.H. wrote:
>
>>>> This is also a not-so-subtle start of trying to break up gitweb into
>>>> separate files for easier maintainability, having everything in a
>>>> single file is just a mess and makes the whole thing more complicated
>>>> than it needs to be. This is a bit of a baby step towards breaking it
>>>> up for easier maintenance.
>>>
>>> The question is if easier maintenance and development by spliting
>>> gitweb for developers offsets ease of install for users.
>>
>> This would just get dropped into the same location that gitweb.cgi
>> exists in, there is no real difference in installation, and thus I can't
>> see this as an issue for users.
>
> To be more exact you have to know that you have to drop _generated files_,
> which means (for this version of patch) gitweb.cgi and gitweb_defaults.pl
> (or whatever the generated file with config variables would be named).
>
>
> ATTENTION!
You didn't have to shout.
Any progress on this front?
Not that I am anxious to queue new topics to 'next' right now (we are
frozen for 1.6.6), but I think having what is proven to work well at a
real site like k.org is much better than waiting for an unproven
reimplementation using somebody else's framework only for your theoretical
cleanliness. John has better things to do than doing such a rewrite
himself, and even if you helped the process by producing a competing
caching scheme based on existing web caching engines, the aggregated
result (not just the web caching engine you base your work on) needs to
get a similar field exposure to prove itself that it can scale to the load
k.org sees, which would be quite a lot of work, no?
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Junio C Hamano @ 2009-12-16 1:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <7vzl5mjndi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:
>>
>>> This is a sane thing to do, as "slot" is part of the name of the variable,
>>> and we generally do not warn upon seeing a misspelled variable name (it
>>> makes it worse that "func" is not even misspelled but merely unknown to
>>> older version of git in your scenario).
>>>
>>> On the other hand, I suspect that most people would apprecfiate if their
>>> git pointed out "diff.color.finc? What do you mean?" before they waste
>>> 30 minutes wondering why the new feature in 1.6.6 does not work for them.
>>
>> I would be more sympathetic to that user if this weren't the _only_ set
>> of variables with this property. They don't get warned for diff.externel
>> or color.show-branch.
>
> True and fair enough. Let's have this in 1.6.6 then.
Actually I think we should have this in 1.6.5.X as well for it to be
useful. Am I mistaken?
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Junio C Hamano @ 2009-12-16 1:29 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091212122524.GA17547@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/builtin-branch.c b/builtin-branch.c
> index 05e876e..c87e63b 100644
> --- a/builtin-branch.c
> +++ b/builtin-branch.c
> @@ -65,7 +65,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
> return BRANCH_COLOR_LOCAL;
> if (!strcasecmp(var+ofs, "current"))
> return BRANCH_COLOR_CURRENT;
> - die("bad config variable '%s'", var);
> + return -1;
> }
>
> static int git_branch_config(const char *var, const char *value, void *cb)
> @@ -76,6 +76,8 @@ static int git_branch_config(const char *var, const char *value, void *cb)
> }
> if (!prefixcmp(var, "color.branch.")) {
> int slot = parse_branch_color_slot(var, 13);
> + if (slot < 0)
> + return 0;
> if (!value)
> return config_error_nonbool(var);
> color_parse(value, var, branch_colors[slot]);
> diff --git a/builtin-commit.c b/builtin-commit.c
> index e93a647..326cd63 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -890,7 +890,7 @@ static int parse_status_slot(const char *var, int offset)
> return WT_STATUS_NOBRANCH;
> if (!strcasecmp(var+offset, "unmerged"))
> return WT_STATUS_UNMERGED;
> - die("bad config variable '%s'", var);
> + return -1;
> }
>
> static int git_status_config(const char *k, const char *v, void *cb)
> @@ -910,6 +910,8 @@ static int git_status_config(const char *k, const char *v, void *cb)
> }
> if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
> int slot = parse_status_slot(k, 13);
> + if (slot < 0)
> + return -1;
Shouldn't this return 0, to say "we handled it (by ignoring), don't
worry", instead of saying "hey it's error" by returning -1? That's what
is done on the "diff" side below...
> diff --git a/diff.c b/diff.c
> index d952686..08bbd3e 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -122,6 +122,8 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
>
> if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
> int slot = parse_diff_color_slot(var, 11);
> + if (slot < 0)
> + return 0;
> if (!value)
> return config_error_nonbool(var);
> color_parse(value, var, diff_colors[slot]);
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: J.H. @ 2009-12-16 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, John 'Warthog9' Hawley
In-Reply-To: <7v8wd3ww4d.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> On Fri, 11 Dec 2009, J.H. wrote:
>>
>>>>> This is also a not-so-subtle start of trying to break up gitweb into
>>>>> separate files for easier maintainability, having everything in a
>>>>> single file is just a mess and makes the whole thing more complicated
>>>>> than it needs to be. This is a bit of a baby step towards breaking it
>>>>> up for easier maintenance.
>>>> The question is if easier maintenance and development by spliting
>>>> gitweb for developers offsets ease of install for users.
>>> This would just get dropped into the same location that gitweb.cgi
>>> exists in, there is no real difference in installation, and thus I can't
>>> see this as an issue for users.
>> To be more exact you have to know that you have to drop _generated files_,
>> which means (for this version of patch) gitweb.cgi and gitweb_defaults.pl
>> (or whatever the generated file with config variables would be named).
>>
>>
>> ATTENTION!
>
> You didn't have to shout.
>
> Any progress on this front?
Sadly, no. Busy weekend and a need to get some of the kernel.org
servers upgraded has taken some precedence. I should be circling back
around on this tomorrow I think.
> Not that I am anxious to queue new topics to 'next' right now (we are
> frozen for 1.6.6), but I think having what is proven to work well at a
> real site like k.org is much better than waiting for an unproven
> reimplementation using somebody else's framework only for your theoretical
> cleanliness. John has better things to do than doing such a rewrite
> himself, and even if you helped the process by producing a competing
> caching scheme based on existing web caching engines, the aggregated
> result (not just the web caching engine you base your work on) needs to
> get a similar field exposure to prove itself that it can scale to the load
> k.org sees, which would be quite a lot of work, no?
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Jakub Narebski @ 2009-12-16 2:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J.H., git, John 'Warthog9' Hawley
In-Reply-To: <7v8wd3ww4d.fsf@alter.siamese.dyndns.org>
On Wed, 16 Dec 2009, Junio C Hamano wrote:
> Not that I am anxious to queue new topics to 'next' right now (we are
> frozen for 1.6.6), but I think having what is proven to work well at a
> real site like k.org is much better than waiting for an unproven
> reimplementation using somebody else's framework only for your theoretical
> cleanliness. John has better things to do than doing such a rewrite
> himself, and even if you helped the process by producing a competing
> caching scheme based on existing web caching engines, the aggregated
> result (not just the web caching engine you base your work on) needs to
> get a similar field exposure to prove itself that it can scale to the load
> k.org sees, which would be quite a lot of work, no?
I'm not against (well, not much against) custom caching that kernel.org
uses, but I am against large change to gitweb code currently accompanying
caching, namely gather then output solution, which would negatively
affect performance when caching is turned off.
Also I'd like to have caching code (the one that didn't made it to git
mailing list for some reason, probably vger anti-SPAM filter) cleaned up
for submission: remove commented-out code, reduce code duplication,
separate dealing with orthogonal issues (cache itself, adaptivity of cache,
background generation and 'in progress' info, generating key for cache
(and improve key generation to include path_info / use %input_params)),
follow the same style that gitweb itself uses.
As for the "[PATCH 6/6] GITWEB - Separate defaults from main file" patch,
it would require modifying gitweb tests to use generated gitweb/gitweb.cgi
rather than source gitweb/gitweb.perl.
As for having caching code tested by git.kernel.org: IIRC there was issue
with it not having cache expiration thus gathering GB of cached data.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-16 3:03 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1260851180.9379.88.camel@localhost>
On Mon, 14 Dec 2009, Eric Paris wrote:
> The alternative repo is slowing pushing up to that same location. That
> tar is 855838982, so just a tad bit smaller.
It doesn't appear to be complete yet, and not progressing either.
Nicolas
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-16 3:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912152201300.23173@xanadu.home>
On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> On Mon, 14 Dec 2009, Eric Paris wrote:
>
> > The alternative repo is slowing pushing up to that same location. That
> > tar is 855838982, so just a tad bit smaller.
>
> It doesn't appear to be complete yet, and not progressing either.
I ran out of quota and ask for more, but IT departments moves at the
speed of IT departments. I'll delete the first one and just push the
alternative repo. Once I get more space I'll try to get them both up at
once....
-Eric
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Jeff King @ 2009-12-16 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3a3bwvzj.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 05:25:36PM -0800, Junio C Hamano wrote:
> >> I would be more sympathetic to that user if this weren't the _only_ set
> >> of variables with this property. They don't get warned for diff.externel
> >> or color.show-branch.
> >
> > True and fair enough. Let's have this in 1.6.6 then.
>
> Actually I think we should have this in 1.6.5.X as well for it to be
> useful. Am I mistaken?
The earlier the better for making it useful, but it is still somewhat of
a lost cause for color.diff.func. The problem comes from using git
v1.6.6, setting the variable, and then going to back to some older
version (either because you are testing multiple versions, or because
your config is shared across multiple machines).
So yes, putting it in v1.6.5.x means switching back there will not be as
painful. But switching back to existing versions will still be broken
until all older versions you might want to switch to have this patch.
So we are not so much fixing this color.diff.func problem as
future-proofing against this happening again.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Jeff King @ 2009-12-16 3:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6l3vh8x.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 05:29:18PM -0800, Junio C Hamano wrote:
> > if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
> > int slot = parse_status_slot(k, 13);
> > + if (slot < 0)
> > + return -1;
>
> Shouldn't this return 0, to say "we handled it (by ignoring), don't
> worry", instead of saying "hey it's error" by returning -1? That's what
> is done on the "diff" side below...
Yes, thank you for catching it. It should definitely be "return 0" (as
the other two cases are). It was a simple think-o on my part.
-Peff
^ permalink raw reply
* Re: TortoiseGIT
From: Frank Li @ 2009-12-16 6:26 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git
In-Reply-To: <a362e8010912150741x2c39c01bh1f64e669726dafab@mail.gmail.com>
You keep cr+lf on/off on whole develop cycle. Avoid change it during
developing.
After change cr+lf setting, I perfer you remove all work copy and
recheckout all.
best regards
Frank Li
2009/12/15 Laszlo Papp <djszapi@archlinux.us>:
> Hello,
>
> I had got a problem in the past with cr + lf between windows and linux
> client(maybe now too).
> I heard that from more experienced users I need to set autocrlf +
> safecrlf on windows, and core.autocrlf false on linux (which is the
> default), but If I set core.autocrlf true on linux too, it worked
> normally, after a git pull on windows I don't see any modified file
> that should be committed, not the case in core.autocrlf false.
>
> Could someone explain this habbit of git, please ?
>
> Everybody said I need to set autocrlf for false, but it doesn't work
> so, just with true on linux client, what do I do wrong ?
> It's okay now for me, because it works without any problem, I just
> don't understand the behaviour of it, and I don't know whether it will
> cause further problems.
>
> Thanks in advance!
>
> Best Regards,
> Laszlo Papp
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Christian Couder @ 2009-12-16 6:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vskbcyot5.fsf@alter.siamese.dyndns.org>
On mardi 15 décembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > While at it, instead of disallowing "git reset --option" outside
> > a work tree only when option is "hard" or "merge", we now disallow
> > it except when option is "soft" or "mixed", as it is safer if we
> > ever add options to "git reset".
>
> I fail to see any sane logic behind this reasoning; you cannot decide if
> you need to allow or disallow the new --option with unspecified semantics
> until you have that --option, and you are saying
>
> Hmm, "reset --option" that does not work when it should work is a bug,
> just like "reset --option" that does not refuse to work when it should
> refuse is, and you cannot decide if you should allow a new --option until
> you have it. Your "disallowing everything the code does not know about
> by default" doesn't particularly sound safer to me. I'd suggest dropping
> it from this patch.
Ok, I will drop it.
> It is perfectly fine to have a change like that, if it makes the logic
> easier to follow with the updated repertoire when a new --option is
> added, but not before.
Ok.
[...]
> By "after the next patch, it will not fail in a bare repository",
> did you mean "if the next patch blindly replaced an external call to
> read-tree with an internal call to unpack_trees(), it will change the
> behaviour, and we will end up allowing '--mixed in bare'. To prevent it
> from happening, cmd_reset() should check that condition upfront"?
Yes, that's what I meant.
> Then you were not trying to hide regressions (which makes me happier).
> But then doesn't the change belong to the next patch, not this one?
I can put it in the patch that calls unpack_trees() directly, but on the
other hand it can also be seen as an improvement that could be applied
to "maint" as it improves the error message.
Best regards,
Christian.
^ permalink raw reply
* Re: git svn clone just stops
From: Eric Wong @ 2009-12-16 8:15 UTC (permalink / raw)
To: Mark Jerkovic; +Cc: git
In-Reply-To: <1260915555.6475.8.camel@mark.engr.acx>
Mark Jerkovic <mjerkovic@aconex.com> wrote:
> Hi all,
>
> I am new to Git and I am attempting to clone a SVN repository
> (containing approximately 60,000 commits) to Git.
>
> Using Git v1.6.0.4 with the following command:
>
> git svn clone https://path/to/svn/repo/trunk project.git
> --authors-file=svnauthors.txt --no-metadata
>
> the process just ends without any messages and the Git repository is
> empty. I have attempted this four times already, and each time it has
> stopped after a different revision, so I can't pin it down to a
> particular commit.
Hi Mark,
Any chance you're OOM-ing (extremely large file) or running
out of space somewhere? What exit code do you get when it exits?
> Has anyone experienced this before? Is there a log anywhere that
> records what is happening during this process?
Not without error messages of some sort. git svn was designed with poor
network conditions in mind and clone is resumable, so you can just
resume like this:
cd project.git && git svn fetch
I wouldn't use --no-metadata at this point, though, as it makes it much
harder to debug/fix things or recover from errors.
Once you're comfortable with it, you should be able to write
"git filter-branch" invocation to remove the metadata lines.
--
Eric Wong
^ permalink raw reply
* [RFC/PATCH] branch: new option --will-track
From: Dave Olszewski @ 2009-12-16 9:39 UTC (permalink / raw)
To: git; +Cc: Dave Olszewski
A common question from users creating branches in an environment where
they intend to push the branch to a shared bare repository, and then
later pull commits from upstream into the branch that they initially
created, is how do they create the branch with this tracking info
already set up.
This feature allows them to pre-specify the tracking info in their
config, so that after the branch has been pushed, no futher action is
needed to pull future commits.
Signed-off-by: Dave Olszewski <cxreg@pobox.com>
---
Documentation/git-branch.txt | 7 +++++++
Documentation/git-checkout.txt | 4 ++++
branch.c | 7 +++++--
branch.h | 2 +-
builtin-branch.c | 18 +++++++++++++++++-
builtin-checkout.c | 19 +++++++++++++++++--
cache.h | 1 +
t/t3200-branch.sh | 8 ++++++++
t/t7201-co.sh | 10 ++++++++++
9 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 0e83680..ca7b120 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -129,6 +129,13 @@ start-point is either a local or remote branch.
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
+--will-track <remote ref>::
+ Instead of tracking the starting point, a user might wish to set
+ up tracking info for a future location of the branch once it's
+ been pushed to a remote. Specifying this allows you to
+ configure the branch in such a way before the branch actually
+ exists on the remote.
+
--contains <commit>::
Only list branches which contain the specified commit.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 37c1810..c18852a 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -86,6 +86,10 @@ explicitly give a name with '-b' in such a case.
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
+--will-track <remote ref>::
+ Configure "upstream" as a yet-nonexistent remote branch. See
+ "--will-track" in linkgit:git-branch[1] for details.
+
-l::
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
diff --git a/branch.c b/branch.c
index 05ef3f5..c3f6bbe 100644
--- a/branch.c
+++ b/branch.c
@@ -126,7 +126,8 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
void create_branch(const char *head,
const char *name, const char *start_name,
- int force, int reflog, enum branch_track track)
+ int force, int reflog, enum branch_track track,
+ const char *will_track)
{
struct ref_lock *lock;
struct commit *commit;
@@ -184,7 +185,9 @@ void create_branch(const char *head,
snprintf(msg, sizeof msg, "branch: Created from %s",
start_name);
- if (real_ref && track)
+ if (will_track)
+ setup_tracking(name, will_track, track);
+ else if (real_ref && track)
setup_tracking(name, real_ref, track);
if (write_ref_sha1(lock, sha1, msg) < 0)
diff --git a/branch.h b/branch.h
index eed817a..30fd5c7 100644
--- a/branch.h
+++ b/branch.h
@@ -13,7 +13,7 @@
* branch for (if any).
*/
void create_branch(const char *head, const char *name, const char *start_name,
- int force, int reflog, enum branch_track track);
+ int force, int reflog, enum branch_track track, const char *will_track);
/*
* Remove information about the state of working on the current
diff --git a/builtin-branch.c b/builtin-branch.c
index 05e876e..b29e6cf 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -556,12 +556,15 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
+ char *will_track = NULL;
struct option options[] = {
OPT_GROUP("Generic options"),
OPT__VERBOSE(&verbose),
OPT_SET_INT('t', "track", &track, "set up tracking mode (see git-pull(1))",
BRANCH_TRACK_EXPLICIT),
+ OPT_STRING(0, "will-track", &will_track, "future remote branch",
+ "set up branch to track future remote branch"),
OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"),
OPT_SET_INT('r', NULL, &kinds, "act on remote-tracking branches",
REF_REMOTE_BRANCH),
@@ -628,6 +631,16 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!!delete + !!rename + !!force_create > 1)
usage_with_options(builtin_branch_usage, options);
+ if (will_track) {
+ will_track = xstrdup(will_track);
+ if (strncmp(will_track, "refs/remotes/", 13)) {
+ will_track = xrealloc(will_track, sizeof(char) * (strlen(will_track) + 14));
+ memmove(will_track + 13, will_track, strlen(will_track) + 1);
+ memcpy(will_track, "refs/remotes/", 13);
+ }
+ track = BRANCH_TRACK_FUTURE;
+ }
+
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
else if (argc == 0)
@@ -638,9 +651,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
rename_branch(argv[0], argv[1], rename > 1);
else if (argc <= 2)
create_branch(head, argv[0], (argc == 2) ? argv[1] : head,
- force_create, reflog, track);
+ force_create, reflog, track, will_track);
else
usage_with_options(builtin_branch_usage, options);
+ if (will_track)
+ free(will_track);
+
return 0;
}
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..f69be79 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -34,6 +34,7 @@ struct checkout_opts {
const char *new_branch;
int new_branch_log;
enum branch_track track;
+ char *will_track;
};
static int post_checkout_hook(struct commit *old, struct commit *new,
@@ -484,7 +485,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
const char *old_desc;
if (opts->new_branch) {
create_branch(old->name, opts->new_branch, new->name, 0,
- opts->new_branch_log, opts->track);
+ opts->new_branch_log, opts->track, opts->will_track);
new->name = opts->new_branch;
setup_branch_path(new);
}
@@ -621,6 +622,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT__QUIET(&opts.quiet),
OPT_STRING('b', NULL, &opts.new_branch, "new branch", "branch"),
+ OPT_STRING(0, "will-track", &opts.will_track, "future remote branch", "nonexistent branch on remote that will be tracked"),
OPT_BOOLEAN('l', NULL, &opts.new_branch_log, "log for new branch"),
OPT_SET_INT('t', "track", &opts.track, "track",
BRANCH_TRACK_EXPLICIT),
@@ -650,7 +652,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, checkout_usage,
PARSE_OPT_KEEP_DASHDASH);
- if (patch_mode && (opts.track > 0 || opts.new_branch
+ if (patch_mode && (opts.track > 0 || opts.new_branch || opts.will_track
|| opts.new_branch_log || opts.merge || opts.force))
die ("--patch is incompatible with all other options");
@@ -810,6 +812,19 @@ no_reference:
if (!get_sha1(buf.buf, rev))
die("git checkout: branch %s already exists", opts.new_branch);
strbuf_release(&buf);
+
+ if (opts.will_track) {
+ opts.will_track = xstrdup(opts.will_track);
+ if (strncmp(opts.will_track, "refs/remotes/", 13)) {
+ opts.will_track = xrealloc(opts.will_track,
+ sizeof(char) * (strlen(opts.will_track) + 14));
+ memmove(opts.will_track + 13, opts.will_track,
+ strlen(opts.will_track) + 1);
+ memcpy(opts.will_track, "refs/remotes/", 13);
+ }
+
+ opts.track = BRANCH_TRACK_FUTURE;
+ }
}
if (new.name && !new.commit) {
diff --git a/cache.h b/cache.h
index bf468e5..1dd7762 100644
--- a/cache.h
+++ b/cache.h
@@ -544,6 +544,7 @@ enum branch_track {
BRANCH_TRACK_REMOTE,
BRANCH_TRACK_ALWAYS,
BRANCH_TRACK_EXPLICIT,
+ BRANCH_TRACK_FUTURE,
};
enum rebase_setup_type {
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index d59a9b4..67e769a 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -137,6 +137,14 @@ test_expect_success 'test tracking setup via --track' \
test $(git config branch.my1.remote) = local &&
test $(git config branch.my1.merge) = refs/heads/master'
+test_expect_success 'test tracking setup via --will-track' \
+ 'git config remote.local.url . &&
+ git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
+ (git show-ref -q refs/remotes/local/master || git fetch local) &&
+ git branch --will-track local/my11 my11 local/master &&
+ test $(git config branch.my11.remote) = local &&
+ test $(git config branch.my11.merge) = refs/heads/my11'
+
test_expect_success 'test tracking setup (non-wildcard, matching)' \
'git config remote.local.url . &&
git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index ebfd34d..803bcad 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -330,6 +330,16 @@ test_expect_success \
test "$(git config branch.track2.merge)"
git config branch.autosetupmerge false'
+test_expect_success \
+ 'checkout w/--will-track sets up tracking' '
+ git config branch.autosetupmerge false &&
+ git config remote.local.url . &&
+ git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
+ git checkout master &&
+ git checkout --will-track local/track3 -b track3 &&
+ test "$(git config branch.track3.remote)" &&
+ test "$(git config branch.track3.merge)"'
+
test_expect_success 'checkout w/--track from non-branch HEAD fails' '
git checkout master^0 &&
test_must_fail git symbolic-ref HEAD &&
--
1.6.6.rc2.8.g5599df
^ permalink raw reply related
* elegant(?) debian topgit workflow?
From: Thomas Koch @ 2009-12-16 10:13 UTC (permalink / raw)
To: vcs-pkg-discuss; +Cc: git, debian-devel
CC (FYI) to git and debian-devel. see http://vcs-pkg.org
Hi,
would you be so kind to review my workflow proposal?
branches
--------
upstream
debian/*, fixes/*, features/* - topgit branches based on upstream
patches - the hero
master - contains the debian/ dir and is the branch we build from
All topgit branches are integrated in the patches branch, which is afterwards
merged into master. The magic is, that the integration is not a regular merge,
but a handcrafted merge and commit with quilt and git plumbing.
workflow
--------
Every merge starts with reseting "patches" to the state of upstream:
#> git checkout upstream
(for the first time: git checkout -b patches, otherwise:)
#> git symbolic-ref HEAD refs/heads/patches
Now we're on branch patches with the working tree and index in the pristine
state of upstream. We can now integrate the topgit branches:
#> tg export --quilt debian/patches \
-b debian/use-debian-java-libraries,debian/disable-tests-that-break-on-buildd
#> quilt push -a
#> git add debian/
#> rm -rf .pc
#> git add -u
Now let's create the commit and specify, which topgit branches were manually
merged:
#> TREE=$(git write-tree)
#> COMMIT=$(git commit-tree $TREE \
-p debian/use-debian-java-libraries \
-p debian/disable-tests-that-break-on-buildd)
#> git update-ref refs/heads/patches $COMMIT
Now I can happily merge patches into master.
advantages
----------
- The commits of all ever merged topgit branches are preserved, even after tg
delete
- easy to understand, non cluttered history
- Easy to retire topgit branches
- Easy to work on old package versions(?): just make a branch from master at
desired version, eventually also branch patches branch to work on old patches
- The quilt patches are used and therefore tested in the same way, as dpkg-
source uses them in version 3
- Integrates with git-buildpackage
- Doesn't need anything, that topgit hasn't ATM
Todo
----
discuss, test, script
Best regards,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* How do I show only log messages for commits on a specific branch?
From: bd @ 2009-12-16 10:16 UTC (permalink / raw)
To: git
Hello list,
[ git v1.6.3.3 ]
imagine this:
--A--*--B (new)
/
*--X--*--Y (master)
Now I'd like to list only log messages for A..B (X..B would be okay too).
I know of
git log master..new
however then I need to remember that I branched new of master, and to be honest,
sometimes I forget.
So how do I:
git please-tell-me-the-branch-I-started-this-branch-from new
Thanks in advance,
Stefan
--
BOFH excuse #181:
Atilla the Hub
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-16 13:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912152201300.23173@xanadu.home>
On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> On Mon, 14 Dec 2009, Eric Paris wrote:
>
> > The alternative repo is slowing pushing up to that same location. That
> > tar is 855838982, so just a tad bit smaller.
>
> It doesn't appear to be complete yet, and not progressing either.
The alternative repo is now available (but the original is down)
I tried to run git gc --aggressive last night while I slept and got this
as output, maybe it helps point to a solution/problem? The git reflog
portion ran for 5 hours and 36 minutes and appears to have finished.
$ git gc --aggressive
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
warning: reflog of 'refs/remotes/audit/master' references pruned commits
warning: reflog of 'refs/remotes/btrfs/enospc' references pruned commits
warning: reflog of 'refs/remotes/btrfs/merge' references pruned commits
warning: reflog of 'refs/remotes/btrfs/for-linus' references pruned commits
warning: reflog of 'refs/remotes/security-testing/for-linus' references pruned commits
error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
fatal: bad tree object 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
error: failed to run repack
^ permalink raw reply
* Re: Git on QNX
From: Alex Riesen @ 2009-12-16 14:20 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, Git Mailing List, mkraai
In-Reply-To: <905315640912151413g10ee5befh58fbd171237e7659@mail.gmail.com>
On Tue, Dec 15, 2009 at 23:13, Tarmigan <tarmigan+git@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 1:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Tarmigan <tarmigan+git@gmail.com> writes:
>>> diff --git a/git-compat-util.h b/git-compat-util.h
>>> index 5c59687..857e938 100644
>>> --- a/git-compat-util.h
>>> +++ b/git-compat-util.h
>>> @@ -79,6 +84,7 @@
>>> #include <stdlib.h>
>>> #include <stdarg.h>
>>> #include <string.h>
>>> +#include <strings.h>
>>> #include <errno.h>
>>> #include <limits.h>
>>> #include <sys/param.h>
>>
>> Other hunks are QNX specific enough but this hunk is worrisome; you cannot
>> tell how you are hurting other platforms with this change. Can you tell
>> declarations of which functions are missing on QNX without this change?
>
> strcasecmp()
> http://www.opengroup.org/onlinepubs/000095399/functions/strcasecmp.html
Just for completeness:
http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/s/strcasecmp.html
http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/s/strcmpi.html
> I agree that this change could affect other platforms and they've
> gotten along fine without it so far. I'm surprised no others have
> needed it. Would it be better wrapped in a #ifdef?
If you put the ifdef in git-compat-util.h
^ permalink raw reply
* Re: error: git-svn died of signal 13
From: Jason Felice @ 2009-12-16 14:56 UTC (permalink / raw)
To: git
In-Reply-To: <20091209075319.GA4201@progeny.tock>
Jonathan Nieder <jrnieder <at> gmail.com> writes:
>
> CCing those who reported the problem. There is some debugging advice below,
> for anyone who wants to take a further stab at tracking this down.
>
> Eric Wong wrote:
> > Can somebody get an strace or core dump for the "git update-index"
> > call? Or even an strace -f of the entire git svn invocation as well...
>
I am having the same issue, pulling a HTTPS repo being served with Subversion
1.4.5. Other info: The repo has many, many tags (~300?), and ~5000 revisions,
and I've been pulling it since Saturday! Each iteration of git svn fetch takes
longer and longer before producing output. It "feels" like It The tags seem to
be what's slowing it down.) I can't make this repo or shell access available
(sorry).
I got an strace:
jfelice@lx-cclamp:~/xpay-core$ strace -f -o /tmp/strace git svn fetch
r3176 = 816a8e7ffd28a2224a75037cf6a983883532c76e (refs/remotes/tags/v01_01_87)
error: git-svn died of signal 13
The strace output is at:
http://eraserhead.net/files/strace.bz2
I originally suspected that our crufty HTTPS server was closing the connection
on us due to some kind of timeout.
^ permalink raw reply
* Re: New Proposal (simple) for Metadata in Git Commits: git-meta
From: Shawn O. Pearce @ 2009-12-16 16:30 UTC (permalink / raw)
To: Sam Elliott; +Cc: git
In-Reply-To: <7349A827-41D5-434F-85FE-D49980A7D501@lenary.co.uk>
Sam Elliott <sam@lenary.co.uk> wrote:
> On 15 Dec 2009, at 23:05, Shawn O. Pearce wrote:
>> If you dropped the --git-meta-- tags above, JGit would happily
>> recognize the awesome: and Github: tags, but it might need a bit
>> more work to recognize the nested user: tag. Also, you'd be able
>> to use git-meta on the git and Linux kernel repositories to pull
>> out and work with Signed-off-by, Acked-by, etc.
>
> I'm not entirely sure about this approach. The current implementation
> also works with PGP-signed tags, where the information is not
> necessarily going to be at the bottom of the message when i use `git-
> cat-file -p`. I think it shouldn't be too hard to also have git-meta
> read any YAML-like data just before the signing message.
Ah, good point. But as you point out, it should be simple enough
to detect a PGP signature on the bottom and just clip that off the
end, and then perform the YAML-like data parsing on the footer.
--
Shawn.
^ permalink raw reply
* RE: Huge pack file from small unpacked objects
From: Nick Triantos @ 2009-12-16 16:34 UTC (permalink / raw)
To: 'git@vger.kernel.org'
In-Reply-To: <404585ED79625A40AB5A9884ECA9A63B3E02083F@VMBX125.ihostexchange.net>
Hi,
I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
thanks,
-Nick
^ permalink raw reply
* [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-16 16:45 UTC (permalink / raw)
To: git
As git rebase and git format-patch linearize commits,
having the same change in different branches causes in the
best case duplicate patches in the produced series and in the
worst case conflicts. If there are trivial merges involved
(i.e. merges that do not change the tree), then this patch
will cause git to only look at one branch, thereby avoiding
duplicates and reducing the chance of conflicts.
There are two new options --prune-tree and --no-prune-tree
added.
--prune-tree makes rev-list without paths equivalent to
"git rev-list $options -- ." (or .. or ../.. and so on,
if you are in some subdirectory).
This is the new default for format-patch and rebase
--no-prune-tree deactivates --prune-tree.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Documentation/rev-list-options.txt | 11 +++++++++++
builtin-log.c | 1 +
git-rebase--interactive.sh | 1 +
git-rebase.sh | 2 +-
revision.c | 11 ++++++++++-
revision.h | 1 +
6 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 1f57aed..6c5e90c 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -328,6 +328,17 @@ The following options select the commits to be shown:
Commits modifying the given <paths> are selected.
+--prune-tree::
+
+ No paths is equivalent to the whole tree as path.
+ That means merges with the same tree follow only one parent.
+ (Default for format-patch and rebase).
+
+--no-prune-tree::
+
+ No paths means not doing history simplification based on paths.
+ (Default for everything but format-patch and rebase).
+
--simplify-by-decoration::
Commits that are referred by some branch or tag are selected.
diff --git a/builtin-log.c b/builtin-log.c
index 1766349..efc2f40 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -960,6 +960,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.diff = 1;
rev.combine_merges = 0;
rev.ignore_merges = 1;
+ rev.prune_tree = 1;
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
rev.subject_prefix = fmt_patch_subject_prefix;
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0bd3bf7..ea23d9b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -703,6 +703,7 @@ first and then run 'git rebase --continue' again."
fi
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
--abbrev=7 --reverse --left-right --topo-order \
+ --prune-tree \
$REVISIONS | \
sed -n "s/^>//p" | while read shortsha1 rest
do
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..2186619 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -539,7 +539,7 @@ echo "$head_name" > "$dotest/head-name"
echo "$GIT_QUIET" > "$dotest/quiet"
msgnum=0
-for cmt in `git rev-list --reverse --no-merges "$revisions"`
+for cmt in `git rev-list --reverse --no-merges --prune-tree "$revisions"`
do
msgnum=$(($msgnum + 1))
echo "$cmt" > "$dotest/cmt.$msgnum"
diff --git a/revision.c b/revision.c
index a8a3c3a..3350af6 100644
--- a/revision.c
+++ b/revision.c
@@ -1112,6 +1112,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->dense = 1;
} else if (!strcmp(arg, "--sparse")) {
revs->dense = 0;
+ } else if (!strcmp(arg, "--prune-tree")) {
+ revs->prune_tree = 1;
+ } else if (!strcmp(arg, "--no-prune-tree")) {
+ revs->prune_tree = 0;
} else if (!strcmp(arg, "--show-all")) {
revs->show_all = 1;
} else if (!strcmp(arg, "--remove-empty")) {
@@ -1408,8 +1412,13 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
}
- if (prune_data)
+ if (prune_data) {
revs->prune_data = get_pathspec(revs->prefix, prune_data);
+ } else if (revs->prune_tree) {
+ /* limit whole tree (limits trivial merges to one side) */
+ static const char *whole_tree[2] = { "", NULL };
+ revs->prune_data = whole_tree;
+ }
if (revs->def == NULL)
revs->def = def;
diff --git a/revision.h b/revision.h
index d368003..d007aaa 100644
--- a/revision.h
+++ b/revision.h
@@ -38,6 +38,7 @@ struct rev_info {
/* Traversal flags */
unsigned int dense:1,
prune:1,
+ prune_tree:1,
no_merges:1,
merges_only:1,
no_walk:1,
^ permalink raw reply related
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Johannes Sixt @ 2009-12-16 16:53 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20091216164553.GA22471@pcpool00.mathematik.uni-freiburg.de>
Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list).
Bernhard R. Link schrieb:
> --prune-tree makes rev-list without paths equivalent to
> "git rev-list $options -- ." (or .. or ../.. and so on,
> if you are in some subdirectory).
> This is the new default for format-patch and rebase
Why do you need a new option when you can just add "-- ." to the rev-list
invocation?
-- Hannes
^ 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