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
On 01/06/2014 07:32 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
On 01/06/2014 07:18 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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 mhag...@alum.mit.edu
---
On 01/06/2014 06:54 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
On 01/06/2014 07:21 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
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 majordomo
On Thu, Jan 2, 2014 at 9:46 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
Francesco Pretto cez...@gmail.com 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
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 = upstream
Jonathan Nieder jrnie...@gmail.com 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
On Mon, Jan 06, 2014 at 07:35:04PM -0800, Brodie Rao wrote:
On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao bro...@sf.io 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
Brodie Rao bro...@sf.io 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
Michael Haggerty mhag...@alum.mit.edu 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
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 mhag...@alum.mit.edu 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
2014/1/7 Junio C Hamano gits...@pobox.com:
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
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: teach
On Thu, Jan 02, 2014 at 11:08:51AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Hi,
On Tue, 7 Jan 2014, Erik Faye-Lund wrote:
On Thu, Jan 2, 2014 at 9:46 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
Am 06.01.2014 23:40, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de 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
Junio C Hamano gits...@pobox.com 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
Francesco Pretto cez...@gmail.com writes:
2014/1/7 Francesco Pretto cez...@gmail.com:
To not break the existing behavior what it's really needed here, IMO,
is a submodule.name.attached property that says two things:
- at the first clone on git submodule update stay attached to
W. Trevor King wk...@tremily.us writes:
From: W. Trevor King wk...@tremily.us
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
Øystein Walle oys...@gmail.com 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
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 cloned,
Francesco Pretto cez...@gmail.com 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. I
Francesco Pretto cez...@gmail.com 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
2014/1/7 Junio C Hamano gits...@pobox.com:
Unless you decide to go with the proposed approach of Trevor, where
submodule.name.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
W. Trevor King wk...@tremily.us 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
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
2014/1/7 Junio C Hamano gits...@pobox.com:
Francesco Pretto cez...@gmail.com 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
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote:
+---+
| master | --
+---++---+| Merges to/from master
| CEDET | | done only by CEDET developers
+---+ |
Jeff King p...@peff.net writes:
On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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?
Jeff King p...@peff.net writes:
On Thu, Jan 02, 2014 at 11:08:51AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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).
2014/1/7 Junio C Hamano gits...@pobox.com:
Francesco Pretto cez...@gmail.com 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
On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
2014/1/7 Junio C Hamano gits...@pobox.com:
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
2014/1/7 W. Trevor King wk...@tremily.us:
Junio, for what it concerns me I fully support this patch as, IMO, it
makes cleaner the role of the property submodule.name.branch.
No.
Trevor, maybe it was not clear. But I wanted to say:
I fully support *Trevor's* patch... :)
--
To unsubscribe
On Tue, Jan 07, 2014 at 11:21:28AM -0800, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us 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
2014/1/7 Francesco Pretto cez...@gmail.com:
2014/1/7 Junio C Hamano gits...@pobox.com:
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,
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 ambiguous refs
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. It
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
[Fixed typo in Junio's address]
On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra artag...@gmail.com 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
Jeff King p...@peff.net 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 that we would
Ramkumar Ramachandra artag...@gmail.com 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
On Wed, Jan 08, 2014 at 02:00:44AM +0530, Ramkumar Ramachandra wrote:
On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra artag...@gmail.com
wrote:
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
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
and
Ramkumar Ramachandra artag...@gmail.com 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
Jeff King p...@peff.net 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
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.
My issue
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.*.merge)
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), and
Jeff King p...@peff.net 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
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 a dumb
On Tue, Jan 07, 2014 at 01:07:08PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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 own
Am 07.01.2014 18:57, schrieb Jens Lehmann:
Am 06.01.2014 23:40, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de 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
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 rebase $upstream
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
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
On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:
2014/1/7 W. Trevor King wk...@tremily.us:
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*
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
On Tue, Jan 7, 2014 at 6:56 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
2014/1/7 W. Trevor King wk...@tremily.us:
I'd be happy to hear ideas about superproject-branch-specific local
overrides to a hypothetical submodule.name.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
Jeff King p...@peff.net 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
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 my
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 p...@peff.net
---
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index
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
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 p...@peff.net
---
Just making the subsequent diffs less
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
Junio C Hamano gits...@pobox.com writes:
Øystein Walle oys...@gmail.com 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
On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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.
Thomas Rast t...@thomasrast.ch writes:
Junio C Hamano gits...@pobox.com writes:
Øystein Walle oys...@gmail.com 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
On Tue, Jan 07, 2014 at 10:51:34PM +0100, Francesco Pretto wrote:
2014/1/7 W. Trevor King wk...@tremily.us:
I'd be happy to hear ideas about superproject-branch-specific local
overrides to a hypothetical submodule.name.local-branch, in the
event that a developer doesn't like a default set
-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.
*
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 currently
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
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 a series to
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 p...@peff.net
---
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index
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 p...@peff.net
---
builtin/cat-file.c | 11 +--
1
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 gets
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
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
Junio C Hamano gitster at pobox.com writes:
Thomas Rast tr at thomasrast.ch writes:
Junio C Hamano gitster at 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
2014/1/7 Heiko Voigt hvo...@hvoigt.net:
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
On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
# Attach the submodule HEAD to branch.
# Also set .git/config 'submodule.module.branch' to branch
$ git submodule head -b branch --attach module
I prefer submodule.name.local-branch for the submodule's local
branch name. I also
2014/1/8 W. Trevor King wk...@tremily.us:
Note that I've moved away from “submodule.name.branch
set means attached” towards “we should set per-superproject-branch
submodule.name.local-branch explicitly” [1].
Honestly, I'm having an hard time to follow this thread. Also, you
didn't update the
On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:
2014/1/8 W. Trevor King wk...@tremily.us:
Note that I've moved away from “submodule.name.branch
set means attached” towards “we should set per-superproject-branch
submodule.name.local-branch explicitly” [1].
Honestly, I'm
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 =
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.name.local-branch without further
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
95 matches
Mail list logo
