This originally was an UTF8-BOM in user-manual.txt and notepad++ was so clever
not to show it in the patch-file :-| Pasting this into my webmail then produced
complete rubbish which I didn't noticed ...
- Original Nachricht
Von: Jonathan Nieder jrnie...@gmail.com
An: Thomas
Junio C Hamano wrote:
Is it because going this route and doing it at such a low level
would make zsh completion (which I have no clue about ;-)
unnecessarily complex?
The zsh completion only cares to override __gitcomp_nl () and
__gitcomp_nl_append (), without bothering to re-implement the
If zsh completion is being read from a location that is different from
system-wide default, it is likely that the user is trying to use a
custom version, perhaps closer to the bleeding edge, installed in her
own directory. We will more likely to find the matching bash completion
script in the same
(Hmmpth, forgot signoff...)
To whom it may interest, added some CC.
2014/1/5 Francesco Pretto cez...@gmail.com:
At the current state, the following use-case is not supported very
well in git:
- a maintainer adds a submodule, checking out a specific branch of
the repository. He doesn't track
On Sun, Jan 05, 2014 at 08:48:50PM +0100, Heiko Voigt wrote:
On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
It's not clear if this refers to the initial-clone update, future
post-clone updates, or both. Ideally, the behavior should be the
same, but in the initial-clone
2014/1/5 W. Trevor King wk...@tremily.us:
On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
Also it could break some users that rely on the current behavior.
The current code always has a detached HEAD after an initial-clone
update, regardless of submodule.name.update, which
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
Could you please extend the description of your use-case so we can
understand your goal better?
Just in case you missed the first patch iteration[1].
The following questions directly pop into my mind:
- What means the maintainer does not track the
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
2014/1/5 W. Trevor King:
Adding a check to only checkout submodule.name.branch if
submodule.name.update was 'rebase', 'merge', or 'none' would be
easy, but I don't think that makes much sense. I can't see any
reason for
On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
On Sun, Jan 05, 2014 at 08:48:50PM +0100, Heiko Voigt wrote:
On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
It's not clear if this refers to the initial-clone update, future
post-clone updates, or both.
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
Could you please extend the description of your use-case so we can
understand your goal better?
Maybe I found better words to explain you my goal: the current git
submodule use-case threats the submodule as a project independent
dependency. My use case
On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
If submodule.name.branch is set, it *always* creates a new local
branch of that name pointing to the exact sha1. If
submodule.name.branch is not set, we still create
Commit f2c681cf (send-pack: support pushing from a shallow clone
via http, 05-12-2013) adds the 'advertise_shallow_grafts_buf'
function as an external symbol.
Noticed by sparse. ('advertise_shallow_grafts_buf' was not declared.
Should it be static?)
Signed-off-by: Ramsay Jones
Commit 58babfff (shallow.c: the 8 steps to select new commits for
.git/shallow, 05-12-2013) added a function to implement step 5 of
the quoted eight steps, namely 'remove_nonexistent_ours_in_pack()'.
This function implements an optional optimization step in the new
shallow commit selection
On Mon, Jan 6, 2014 at 7:00 AM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote:
Commit 58babfff (shallow.c: the 8 steps to select new commits for
.git/shallow, 05-12-2013) added a function to implement step 5 of
the quoted eight steps, namely 'remove_nonexistent_ours_in_pack()'.
This function
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
The reason why one would set a branch option here is to share the
superproject branch with colleagues. He can make sure they can
always fetch and checkout the
On Sun, Jan 05, 2014 at 04:33:14PM -0800, W. Trevor King wrote:
The only people who would need *automatic* rebase recovery would be
superproject devs update-cloning the subproject. That's a small
enough cross-section that I don't think it deserves the ambiguity of
gitlink-to-reference. In
Hi, Junio
Please pull l10n update for maint branch. It can be merged to master
without conflict.
The following changes since commit 5512ac5840c8bcaa487806cf402ff960091ab244:
Git 1.8.5.2 (2013-12-17 11:42:12 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po
2014/1/5 Thomas Ackermann th.ac...@arcor.de:
Since f223459 status: always show tracking branch even no change
'git status' (and 'git checkout master' always says
Your branch is up-to-date with 'origin/master'
even if 'origin/master' is way ahead from local 'master'.
Hi, Thomas
Can you
18 matches
Mail list logo
