On Wed, Jan 08, 2014 at 02:59:37PM +0800, Li Zhang wrote:
> I tried to add url xxx insteadof xxx in .gitconfig. If the length of
> url exceed 125, git will not work.
> I am using Ubuntu. The default version is 1.7.9.5. Maybe the latest
> version solve this already.
Yes, this was fixed in 0971e99
I tried to add url xxx insteadof xxx in .gitconfig. If the length of
url exceed 125, git will not work.
I am using Ubuntu. The default version is 1.7.9.5. Maybe the latest
version solve this already.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to major
On Tue, Jan 07, 2014 at 07:47:08PM -0800, W. Trevor King wrote:
> #git checkout --recurse-submodules master
> ( # 'git checkout --recurse-submodules' doesn't exist yet [2,3].
> # Even with that patch, 'git checkout' won't respect
> # submodule..local-branch without further work.
On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
> + if (flags & DO_FOR_EACH_NO_RECURSE) {
> + struct ref_dir *subdir = get_ref_dir(entry);
> + sort_ref_dir(subdir);
> + retval = do_fo
On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:
> 2014/1/8 W. Trevor King :
> > Note that I've moved away from “submodule..branch
> > set means attached” towards “we should set per-superproject-branch
> > submodule..local-branch explicitly” [1].
>
> Honestly, I'm having an hard t
2014/1/8 W. Trevor King :
> Note that I've moved away from “submodule..branch
> set means attached” towards “we should set per-superproject-branch
> submodule..local-branch explicitly” [1].
>
Honestly, I'm having an hard time to follow this thread. Also, you
didn't update the patch. If you were en
On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
> # Attach the submodule HEAD to .
> # Also set ".git/config" 'submodule..branch' to
> $ git submodule head -b --attach
I prefer submodule..local-branch for the submodule's local
branch name. I also prefer 'checkout' to 'head',
2014/1/7 Heiko Voigt :
> One thing is missing though (and I think thats where Francesco came
> from): What if the developer already has a detached HEAD in the
> submodule?
>
> How does he attach to a branch? For this we need something similar to
> Francescos attach/detach or Trevors submodule check
Junio C Hamano pobox.com> writes:
>
> Thomas Rast thomasrast.ch> writes:
>
> > Junio C Hamano pobox.com> writes:
> >
> >>
> >> This is brittle. If new tests are added before this, the test_tick
> >> will give you different timestamp and this test will start failing.
> >>
> >> Perhaps grab th
Since 798c35f (get_sha1: warn about full or short object
names that look like refs, 2013-05-29), a 40-hex sha1 causes
us to call dwim_ref on the result, on the off chance that we
have a matching ref. This can cause a noticeable slow-down
when there are a large number of objects. E.g., on
linux.git
Now that our object/refname ambiguity test is much faster
(thanks to the previous commit), there is no reason for code
like "cat-file --batch-check" to turn it off. Here are
before and after timings with this patch (on git.git):
$ git rev-list --objects --all | cut -d' ' -f1 >objects
[with fl
The normal for_each_ref traversal descends into
subdirectories, returning each ref it finds. However, in
some cases we may want to just iterate over the top-level of
a certain part of the tree.
The introduction of the "flags" option is a little
mysterious. We already have a "flags" option that get
This just pulls the return value for the function out of the
inner loop, so we can break out of the loop rather than do
an early return. This will make it easier to put any cleanup
for the function in one place.
Signed-off-by: Jeff King
---
builtin/cat-file.c | 11 +--
1 file changed, 5
We should always have been freeing our strbuf, but doing so
consistently was annoying until the refactoring in the
previous patch.
Signed-off-by: Jeff King
---
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 971cdde..ce79103 10
On Tue, Jan 07, 2014 at 05:08:56PM -0500, Jeff King wrote:
> > OK. I agree with that line of thinking. Let's take it one step at
> > a time, i.e. do c. and also use warn_on_object_refname_ambiguity in
> > "rev-list --stdin" first and leave the simplification (i.e. b.) for
> > later.
>
> Here's
On Tue, Jan 07, 2014 at 02:36:25PM -0800, W. Trevor King wrote:
> There are three branches that submodule folks usually care about:
>
> 1. The linked $sha1 in the superproject (set explicitly for every
>superproject commit, and thus for every superproject branch).
> 2. The remote-tracking subm
On Tue, Jan 07, 2014 at 11:51:28PM +0100, Heiko Voigt wrote:
> On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> > Here's an attempted summary of our desires, and my ideal route
> > forward:
> >
> > * Preferred local submodule branches for each superproject branch.
> > * Not curr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> Here's an attempted summary of our desires, and my ideal route
> forward:
>
> * Preferred local submodule branches for each superproject branch.
> * Not currently supported by Git.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
here my current thoughts in a kind of summary email.
On Tue, Jan 07, 2014 at 11:45:03AM -0800, W. Trevor King wrote:
> On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> > 2014/1/7 Junio C Hamano :
> > > It is not immediately obv
On Tue, Jan 07, 2014 at 10:51:34PM +0100, Francesco Pretto wrote:
> 2014/1/7 W. Trevor King :
> >
> > I'd be happy to hear ideas about superproject-branch-specific local
> > overrides to a hypothetical submodule..local-branch, in the
> > event that a developer doesn't like a default set in .gitmodu
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Øystein Walle writes:
>>
>>> + git stash &&
>>> + test_tick &&
>>> + echo cow > file &&
>>> + git stash &&
>>> + git stash apply "stash@{Thu Apr 7 15:17:13 2005 -0700}" &&
>>
>> This is brittle. If new tests are added before this, the
Jeff King writes:
> And even in a centralized workflow, I see "upstream" creating problems.
> E.g., you fork a feature branch in the centralized repo; it should not
> get pushed straight back to "master"! And that is why we invented
> "simple", to prevent such things.
Oh, don't get me wrong. I
Junio C Hamano writes:
> Øystein Walle writes:
>
>> +git stash &&
>> +test_tick &&
>> +echo cow > file &&
>> +git stash &&
>> +git stash apply "stash@{Thu Apr 7 15:17:13 2005 -0700}" &&
>
> This is brittle. If new tests are added before this, the test_tick
> will give you di
On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think that is sensible, and only heightens my sense of the "upstream"
> > push.default as useless. :)
>
> Yes, it only is good for centralized world (it was designed back in
> the centralized days after
We currently check that any 40-hex object name we receive is
not also a refname, and output a warning if this is the
case. When "rev-list --stdin" is used to receive object
names, we may receive a large number of inputs, and the cost
of checking each name as a ref is relatively high.
Commit 25fba
This just pulls the return value for the function out of the
inner loop, so we can break out of the loop rather than do
an early return. This will make it easier to put any cleanup
for the function in one place.
Signed-off-by: Jeff King
---
Just making the subsequent diffs less noisy...
builtin
Since commit 25fba78, we turn off the object/refname
ambiguity warning using a global flag. However, we never
restore it. This doesn't really matter in the current code,
since the program generally exits immediately after the
function is done, but it's good code hygeine to clean up
after ourselves.
We should always have been freeing our strbuf, but doing so
consistently was annoying until the refactoring in the
previous patch.
Signed-off-by: Jeff King
---
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 971cdde..ce79103 10
On Tue, Jan 07, 2014 at 12:31:57PM -0800, Junio C Hamano wrote:
> > c. Just leave it at Brodie's patch with nothing else on top.
> >
> > My thinking in favor of (b) was basically "does anybody actually care
> > about ambiguous refs in this situation anyway?". If they do, then I
> > think (c) is
Jeff King writes:
> I think that is sensible, and only heightens my sense of the "upstream"
> push.default as useless. :)
Yes, it only is good for centralized world (it was designed back in
the centralized days after all, wasn't it?).
--
To unsubscribe from this list: send the line "unsubscribe
2014/1/7 W. Trevor King :
>
> I'd be happy to hear ideas about superproject-branch-specific local
> overrides to a hypothetical submodule..local-branch, in the
> event that a developer doesn't like a default set in .gitmodules. If
> I could think of a way to do that, we could avoid this heuristic
On Tue, Jan 7, 2014 at 6:56 PM, Johannes Schindelin
wrote:
>> > Well, you and I both know how easy GitHub's pull request made things
>> > for us as well as for contributors. I really cannot thank Erik enough
>> > for bullying me into using and accepting them.
>>
>> Huh? I don't think you refer to
Jeff King wrote:
> I definitely respect the desire to reuse the existing tooling we have
> for @{u}. At the same time, I think you are warping the meaning of
> @{u} somewhat. It is _not_ your upstream here, but rather another
> version of the branch that has useful changes in it. That might be
> sp
On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:
> 2014/1/7 W. Trevor King :
> >> Trevor, maybe it was not clear. But I wanted to say:
> >>
> >> " I fully support *Trevor's* patch..." :)
> >
> > Which I appreciate ;). I still though I should point out that my
> > patch *confuses*
The "Submodules" section of the "git rm" documentation mentions what will
happen when a submodule with a gitfile gets removed with newer git. But it
doesn't talk about what happens when the user changes between commits
before and after the removal, which does not remove the submodule from the
work
The "Submodules" section of the "git mv" documentation mentions what will
happen when a submodule with a gitfile gets moved with newer git. But it
doesn't talk about what happens when the user changes between commits
before and after the move, which does not update the work tree like using
the mv c
On Wed, Jan 08, 2014 at 02:55:04AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > My daily procedure is something like:
> >
> > all_topics |
> > while read topic; do "echo $topic $(git rev-parse $topic@{u})"; done |
> > topo_sort |
> > while read topic upstream; do
> > git r
Am 07.01.2014 18:57, schrieb Jens Lehmann:
> Am 06.01.2014 23:40, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>> Does this new paragraph make it clearer?
>>
>> Don't we have bugs section that we can use to list the known
>> limitations like this?
>
> Right, will change accordingly in v2.
Ch
Jeff King wrote:
> My daily procedure is something like:
>
> all_topics |
> while read topic; do "echo $topic $(git rev-parse $topic@{u})"; done |
> topo_sort |
> while read topic upstream; do
> git rebase $upstream $topic || exit 1
> done
Ah, I was perhaps over-specializing for my o
On Tue, Jan 07, 2014 at 01:07:08PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, "pushbranch" is probably a better name for what I am referring to.
> > I agree that pushremote is probably enough for sane cases. I seem to
> > recall that people advocating the "upstream" push-default
On Wed, Jan 08, 2014 at 02:32:10AM +0530, Ramkumar Ramachandra wrote:
> > we should leave @{upstream} as (1), and add a new option to represent
> > (2). Not the other way around.
>
> I have a local branch 'forkedfrom' that has two "sources": 'master'
> and 'ram/forkedfrom'. 'ram/forkedfrom' isn't
Jeff King writes:
> Yes, "pushbranch" is probably a better name for what I am referring to.
> I agree that pushremote is probably enough for sane cases. I seem to
> recall that people advocating the "upstream" push-default thought that
> branch name mapping was a useful feature, but I might be
>
On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:.
> > As I said in the different subthread, I am not convinced that you
> > would need the complexity of branch.*.forkedFrom. If you set your
> > "upstream" to the true upstream (not your publishing point
Jeff King wrote:
> I have not carefully read some of the later bits of the discussion from
> last night / this morning, so maybe I am missing something, but this
> seems backwards to me from what Junio and I were discussing earlier.
>
> The point was that the meaning of "@{upstream}" (and "branch.*
On Tue, Jan 07, 2014 at 03:40:56AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Yeah, I had similar thoughts. I personally use "branch.*.merge" as
> > "forkedFrom", and it seems like we are going that way anyway with things
> > like "git rebase" and "git merge" defaulting to upstream.
Jeff King writes:
> The point was that the meaning of "@{upstream}" (and "branch.*.merge")
> is _already_ "forked-from", and "push -u" and "push.default=upstream"
> are the odd men out. If we are going to add an option to distinguish the
> two branch relationships:
>
> 1. Where you forked from
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I do not mind allowing laziness by defaulting to something, but I am
>> not enthused by an approach that adds the new variable whose value
>> is questionable. The description does not justify at all why
>> @{upstream} is not a good default
Junio C Hamano wrote:
> I do not mind allowing laziness by defaulting to something, but I am
> not enthused by an approach that adds the new variable whose value
> is questionable. The description does not justify at all why
> @{upstream} is not a good default (unless the workflow is screwed up
>
On Wed, Jan 08, 2014 at 02:00:44AM +0530, Ramkumar Ramachandra wrote:
> On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra
> wrote:
> > A very common workflow for preparing patches involves working off a
> > topic branch and generating patches against 'master' to send off to the
> > maintainer
Ramkumar Ramachandra writes:
> A very common workflow for preparing patches involves working off a
> topic branch and generating patches against 'master' to send off to the
> maintainer. However, a plain
>
> $ git format-patch -o outgoing
>
> is a no-op on a topic branch, and the user has to re
Jeff King writes:
> On Tue, Jan 07, 2014 at 11:38:15AM -0800, Junio C Hamano wrote:
>
>> >> > Alternatively, I guess "cat-file
>> >> > --batch" could just turn off warn_ambiguous_refs itself.
>> >>
>> >> Sounds like a sensible way to go, perhaps on top of this change?
>> >
>> > The downside is t
[Fixed typo in Junio's address]
On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra wrote:
> A very common workflow for preparing patches involves working off a
> topic branch and generating patches against 'master' to send off to the
> maintainer. However, a plain
>
> $ git format-patch -o ou
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' explicitly every
On Tue, Jan 07, 2014 at 11:44:00AM -0800, Junio C Hamano wrote:
> > test-terminal only handles stdout and stderr streams as fake terminals.
> > We could pretty easily add stdin for input, as it uses fork() to work
> > asynchronously. But the credential code does not actually read from
> > stdin.
On Tue, Jan 07, 2014 at 11:38:15AM -0800, Junio C Hamano wrote:
> >> > Alternatively, I guess "cat-file
> >> > --batch" could just turn off warn_ambiguous_refs itself.
> >>
> >> Sounds like a sensible way to go, perhaps on top of this change?
> >
> > The downside is that we would not warn about a
2014/1/7 Francesco Pretto :
> 2014/1/7 Junio C Hamano :
>> It is not immediately obvious to me why anybody who specifies the
>> submodule.*.branch variable to say "I want _that_ branch" not to
>> want to be on that branch but in a detached state, so from that
>> perspective, submodule.*.attach feel
On Tue, Jan 07, 2014 at 11:21:28AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
> >> Having writing all the above and then looking at the patch again, it
> >> is not immediately obvious to me where you use "rebase" when
2014/1/7 W. Trevor King :
>> Junio, for what it concerns me I fully support this patch as, IMO, it
>> makes cleaner the role of the property "submodule..branch".
>
> No.
Trevor, maybe it was not clear. But I wanted to say:
" I fully support *Trevor's* patch..." :)
--
To unsubscribe from this list
On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> 2014/1/7 Junio C Hamano :
> > It is not immediately obvious to me why anybody who specifies the
> > submodule.*.branch variable to say "I want _that_ branch" not to
> > want to be on that branch but in a detached state, so from tha
2014/1/7 Junio C Hamano :
> Francesco Pretto writes:
>> The developer does it voluntarily, at his responsibility, because he
>> may decide to partecipate more actively to the development of the
>> submodule and still want to use a simple "git submodule update" to
>> updates his submodules, overrid
Jeff King writes:
> On Thu, Jan 02, 2014 at 11:08:51AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > ... But the test suite, of course, always uses askpass because it
>> > cannot rely on accessing a terminal (we'd have to do some magic with
>> > lib-terminal, I think).
>> >
>> > S
Jeff King writes:
> On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Alternatively, I guess "cat-file
>> > --batch" could just turn off warn_ambiguous_refs itself.
>>
>> Sounds like a sensible way to go, perhaps on top of this change?
>
> The downs
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote:
> +---+
> | master | <--
> +---++---+| Merges to/from master
> | CEDET | | done only by CEDET developers
> +---+ |
> +---
2014/1/7 Junio C Hamano :
> Francesco Pretto writes:
>
>> My bottom line:
>> - For what I understand, detached HEAD it's a way to say "hey, you
>> have to stay on this commit. Also don't even think you can push to the
>> upstream branch". This sometimes can't be spurious, as in the use case
>> I w
This change ensures get_sha1_basic() doesn't try to resolve full hashes
as refs when ambiguous ref warnings are disabled.
This provides a substantial performance improvement when passing many
hashes to a command (like "git rev-list --stdin") when
core.warnambiguousrefs is false. The check incurs 6
"W. Trevor King" writes:
> On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
>> submodule: respect requested branch on all clones
>>
>> The previous code only checked out the requested branch in cmd_add
>> but not in cmd_update; this left the user on a detached HEAD aft
2014/1/7 Junio C Hamano :
>> Unless you decide to go with the proposed approach of Trevor, where
>> "submodule..branch" set means attached (if it's not changed:
>> this thread is quite hard to follow...). To this end, Junio could sync
>> with more "long-timers" (Heiko?) submodule users/devs to unde
Francesco Pretto writes:
> My bottom line:
> - For what I understand, detached HEAD it's a way to say "hey, you
> have to stay on this commit. Also don't even think you can push to the
> upstream branch". This sometimes can't be spurious, as in the use case
> I wrote above: access control on the
Francesco Pretto writes:
>>> > - In which situations does the developer or maintainer switch between
>>> >your attached/detached mode?
>>>
>>> The developer/maintainer does so optionally and voluntarily and it
>>> effects only its private working tree.
>>
>> This does not answer my question.
On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
> submodule: respect requested branch on all clones
>
> The previous code only checked out the requested branch in cmd_add
> but not in cmd_update; this left the user on a detached HEAD after
> an update initially clon
Øystein Walle writes:
> When trying to pop/apply a stash specified with an argument containing
> spaces git-stash will throw an error:
>
> $ git stash pop 'stash@{two hours ago}'
> Too many revisions specified: stash@{two hours ago}
>
> This happens because word splitting is used to count
Francesco Pretto writes:
> 2014/1/7 Francesco Pretto :
>> To not break the existing behavior what it's really needed here, IMO,
>> is a "submodule..attached" property that says two things:
>> - at the first clone on "git submodule update" stay attached to
>> "submodule..branch";
>> - implies "--r
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the initial
> checkout command to use 'reb
Junio C Hamano writes:
> - Scripted Porcelains get LESS=-FRSX while C Porcelains get
>LESS=FRSX as the default (the leading dash being the
>difference), which looks somewhat inconsistent. Not a new
>problem, though.
Even the less manpage is inconsistent about whether $LESS should s
Am 06.01.2014 23:40, schrieb Junio C Hamano:
> Jens Lehmann writes:
>> Does this new paragraph make it clearer?
>
> Don't we have bugs section that we can use to list the known
> limitations like this?
Right, will change accordingly in v2.
>> Documentation/git-mv.txt | 10 ++
>> t/t700
Hi,
On Tue, 7 Jan 2014, Erik Faye-Lund wrote:
> On Thu, Jan 2, 2014 at 9:46 PM, Johannes Schindelin
> wrote:
>
> > Well, you and I both know how easy GitHub's pull request made things
> > for us as well as for contributors. I really cannot thank Erik enough
> > for bullying me into using and acc
On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Alternatively, I guess "cat-file
> > --batch" could just turn off warn_ambiguous_refs itself.
>
> Sounds like a sensible way to go, perhaps on top of this change?
The downside is that we would not warn ab
Jeff King writes:
> Alternatively, I guess "cat-file
> --batch" could just turn off warn_ambiguous_refs itself.
Sounds like a sensible way to go, perhaps on top of this change?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
On Thu, Jan 02, 2014 at 11:08:51AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... But the test suite, of course, always uses askpass because it
> > cannot rely on accessing a terminal (we'd have to do some magic with
> > lib-terminal, I think).
> >
> > So it doesn't detect the proble
Am 06.01.2014 23:36, schrieb Junio C Hamano:
> * jl/submodule-recursive-checkout (2013-12-26) 5 commits
> - Teach checkout to recursively checkout submodules
> - submodule: teach unpack_trees() to update submodules
> - submodule: teach unpack_trees() to repopulate submodules
> - submodule: teac
2014/1/7 Junio C Hamano :
> It is not about preference but what we want to convey to the
> readers. When you start the sentence with "Oh, it already works
> correctly", the readers need to see this sentence finished: "It
> already works, it is handled correctly, but we change the code
> neverthele
Michael Haggerty writes:
> I agree that it would be reasonable to use is_dir_sep() in the
> implementation of this function, at least unless/until somebody does the
> work to figure out whether callers should really only be passing it
> forward-slash-normalized paths.
>
> Please be careful, thoug
On Mon, Jan 06, 2014 at 10:14:30PM +, Ben Maurer wrote:
> It looks like for my repo the size win wasn't as big (~10%). Is it
> possible that with the kernel test you got extremely lucky and there
> was some huge binary blob that thin packing turned into a tiny delta?
I don't think so. When I
Michael Haggerty writes:
> I'm not sure I understand your point. Please note that the
> REMOVE_DIR_KEEP_TOPLEVEL bit is cleared from flags before this function
> recurses. So in recursive invocations, keep_toplevel will always be
> false, and the rmdir(path->buf) codepath will be permitted. Do
Brodie Rao writes:
> This change ensures get_sha1_basic() doesn't try to resolve full hashes
> as refs when ambiguous ref warnings are disabled.
>
> This provides a substantial performance improvement when passing many
> hashes to a command (like "git rev-list --stdin") when
> core.warnambiguousr
On Mon, Jan 06, 2014 at 07:35:04PM -0800, Brodie Rao wrote:
> On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao wrote:
> > This change ensures get_sha1_basic() doesn't try to resolve full hashes
> > as refs when ambiguous ref warnings are disabled.
> >
> > This provides a substantial performance improve
Jonathan Nieder writes:
> On systems with lv configured as the preferred pager (i.e.,
> DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the
> environment) git commands that use color show control codes instead of
> color in the pager:
>
> $ git diff
> ^[[1mdiff --git a/.mailfi
John Szakmeister wrote:
> I guess it's not a good idea to
> set 'push.default' to 'upstream' in this triangle workflow then,
> otherwise the branch name being pushed to will be 'branch.*.merge'.
> Is that correct? I just want to make sure I understand what's
> happening here.
push.default = upstr
Francesco Pretto writes:
> Like you said, "it already refers to checkout and handles it
> correctly". I think the use of the simple present tense here is
> correct: it's a fact. Feel free to advice another wording if you
> prefer.
It is not about preference but what we want to convey to the
read
On Thu, Jan 2, 2014 at 9:46 PM, Johannes Schindelin
wrote:
> Hi Sebastian,
>
> On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
>
>> On 02.01.2014 18:33, Johannes Schindelin wrote:
>>
>> > -- snip --
>> > On Linux, we can get away with assuming that the directory separator is a
>> > forward slash, b
Ramkumar Ramachandra wrote:
> contrib/completion/git-completion.bash | 1 +
> 1 file changed, 1 insertion(+)
Junio: Please push this part via 'maint' independently.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordo
On 01/06/2014 07:21 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> If safe_create_leading_directories() fails because a file along the
>> path unexpectedly vanished, try again from the beginning. Try at most
>> 3 times.
>
> As the previous step bumped it from 3 to 4 without explanati
On 01/06/2014 06:54 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> If safe_create_leading_directories() fails because a file along the
>> path unexpectedly vanished, try again (up to 3 times).
>>
>> This can occur if another process is deleting directories at the same
>> time as we are
On 01/06/2014 07:18 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> If a file or directory that we are trying to remove disappears (e.g.,
>> because another process has pruned it), do not consider it an error.
>>
>> Signed-off-by: Michael Haggerty
>> ---
>> dir.c | 22
On 01/06/2014 07:32 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Keep track of the position of the slash character independently of
>> "pos", thereby making the purpose of each variable clearer and
>> working towards other upcoming changes.
>>
>> Signed-off-by: Michael Haggerty
>> -
When trying to pop/apply a stash specified with an argument containing
spaces git-stash will throw an error:
$ git stash pop 'stash@{two hours ago}'
Too many revisions specified: stash@{two hours ago}
This happens because word splitting is used to count non-option
arguments. Make use of r
96 matches
Mail list logo
