2014/1/5 Thomas Ackermann :
> 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 provide your ope
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 mai
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
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 s
On Mon, Jan 6, 2014 at 7:00 AM, Ramsay Jones 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 implements an option
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 algor
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
---
send-pac
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..branch is set, it *always* creates a new local
> > branch of that name pointing to the exact sha1. If
> > submodule..branch is not set, we still create a
2014/1/5 Heiko Voigt :
> 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 threats the subm
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 bot
On Sun, Jan 05, 2014 at 01:47:52PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> > 2014/1/5 W. Trevor King:
> > Also it covers:
> > - an "autoremote" behavior when the user wants an attached HEAD:
> > with your patch "--remote" is still needed to
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..branch if
> > submodule..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 fo
2014/1/5 Heiko Voigt :
>
> 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 submodules
2014/1/5 W. Trevor King :
> 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..update, which doesn't match
>
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-clo
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
> + case "$update_module" in
> + '')
> + ;; # Unset update mode
> + checkout | rebase | merge | none)
> + ;; # Known
On Sun, Jan 05, 2014 at 03:50:49AM +0100, Francesco Pretto wrote:
> 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 the upstream submodule revision sha1;
> - a d
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
> According to "Documentation/gitmodules.txt", 'checkout' is a valid
> 'submodule..update' command. Also "git-submodule.sh" refers to
> it and processes it correctly. Reflect commit 'ac1fbb' to support this
> syntax and also validate
(Hmmpth, forgot signoff...)
To whom it may interest, added some CC.
2014/1/5 Francesco Pretto :
> 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 the upstream
On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
> 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
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 'rebase' to preserve branches setup during
On Fri, Jan 3, 2014 at 5:49 PM, Kent R. Spillner wrote:
>> Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
>> call to list_commands_in_dir(). Avoid the file I/O by adding an early
>> check for internal commands.
>
> Considering the purpose of the series is it better to say
There are situations where multiple classes of completions possible. For
example
branch.
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ".", and the second/ third candidates
have the suffix " ". To facilitate complet
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
When attempting to complete
$ git config remote.push
'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' as a
candidate for completion too, using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra
---
Hi Junio et al,
Most significantly, [2/4] no longer duplicates __gitcompadd () in
__gitcomp_nl_append (). Other than that, the commit messages for the
other patches are improved.
Thanks.
Ramkumar Ramachandra (4):
zsh completion: find matching custom bash completion
completion: introduce __gi
When attempting to complete
$ git config branch.auto
'autosetupmerge' and 'autosetuprebase' don't come up. This is because
"$cur" is matched with "branch.*" and a list of branches are
completed. Add 'autosetupmerge', 'autosetuprebase' as candidates for
completion too, using __gitcomp_nl_append
brian m. carlson wrote:
> I'm not clear on this change. It looks like this loads
> git-completion.bash from the same directory as git-completion.zsh. Is
> this correct?
Yes, and that's what I meant to convey with the "./". Junio's message
is clearer though, so I'll use that.
Thanks.
--
To unsub
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
l
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
An: Thomas Ackermann
Datum:
30 matches
Mail list logo
