Duy Nguyen pclo...@gmail.com writes:
I am not happy with the choice of main/HEAD that would squat on a
good name for remote-tracking branch (i.e. s/origin/main/), though.
$GIT_DIR/COMMON_HEAD perhaps?
It's not just about HEAD. Anything worktree-specific of the main
checkout can be accessed
Adam Spiers g...@adamspiers.org writes:
I doubt it. 75% of the work for such a person to understand the
behaviour from such an example is to understand what kind of history
the example is building.
Agreed. And that's precisely why I wanted a real repository
manifesting the given example:
Samuel Bronson naes...@gmail.com writes:
I learned of git cherry some days ago, but only learned of --cherry
and related options to git log today[1] (more-or-less by chance).
If the git-cherry(1) manpage had mentioned --cherry, I would have
learned of these options sooner.
This proposed log
Adam Spiers g...@adamspiers.org writes:
OTOH, including a sample repository embedded within the git repository
is either impossible or very ugly (e.g. having a non-default value of
GIT_DIR for the embedded repository). But I doubt you were suggesting
that ;-)
No.
By the way,
Duy Nguyen pclo...@gmail.com writes:
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote:
Do we even need to expose them as ref-like things as a part of the
external API/UI in the first place? For end-user scripts that want
to operate in a real or borrowing worktree
Jonathan Nieder jrnie...@gmail.com writes:
How about something like the following, for squashing in?
With or without the tweaks below,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks, both.
Regarding git add --refresh (no other arguments), it would say
Nothing specified, nothing
Christian Couder christian.cou...@gmail.com writes:
On Thu, Dec 19, 2013 at 7:58 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder christian.cou...@gmail.com writes:
I think this last one might be useful for people replacing objects
with objects that have another type.
... which
Junio C Hamano gits...@pobox.com writes:
Regarding git add --refresh (no other arguments), it would say
Nothing specified, nothing added., and that is unrelated to the
breakage reported and fixed in this thread, I think. It is the same
message git add (no other arguments) gives, which I
Duy Nguyen pclo...@gmail.com writes:
On Sat, Dec 21, 2013 at 4:31 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
/* here we care if we saw the prefix, as above */
if (parse_prefix(foo, prefix, the_rest))
...
/*
* and here we do not care
Jeff King p...@peff.net writes:
@@ -1824,6 +1856,22 @@ static int packed_object_info(struct packed_git *p,
off_t obj_offset,
}
}
+ if (oi-delta_base_sha1) {
+ if (type == OBJ_OFS_DELTA || type == OBJ_REF_DELTA) {
+ const unsigned
Jonathan Nieder jrnie...@gmail.com writes:
Hi,
This patch series comes from
https://github.com/jlehmann/git-submod-enhancements branch
recursive_submodule_checkout. It needed some tiny tweaks to apply to
current master and build without warnings, but nothing major, and I
haven't sanity
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
Johannes Schindelin johannes.schinde...@gmx.de writes:
Support for grafts predates Git's strbuf, and hence it is understandable
that there was a hard-coded line length limit of 1023 characters (which
was chosen a bit awkwardly, given that it is *exactly* one byte short of
aligning with the 41
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find
Konstantin Khomoutov flatw...@users.sourceforge.net writes:
On Fri, 27 Dec 2013 18:59:00 +0600
Sergey Sharybin sergey@gmail.com wrote:
Quick question is, is it possible to use git:// protocol over
SSL/TLS/other secure transport?
The Git protocol does not implement it itself but you can
Eric Wong normalper...@yhbt.net writes:
Jonathan Nieder jrnie...@gmail.com wrote:
Roman Kagan wrote:
Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when
Jonathan Nieder jrnie...@gmail.com writes:
Johannes Schindelin wrote:
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Is this easy to reproduce so some interested but lazy person could
write a test?
Yep. Make 25 orphan commits, add a graft line to make the first a merge of
the rest.
Thanks.
Christian Couder chrisc...@tuxfamily.org writes:
+# Do not remove trailing spaces below!
+cat complex_message_trailers 'EOF'
+Fixes:
+Acked-by:
+Reviewed-by:
+Signed-off-by:
+EOF
Just a hint. I think it is far safer and robust over time to do
something like this:
sed -e 's/
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
When I want to debug a failing test, I often end up doing:
cd t
./t4107-tab -v -i
cd tratab
The test names are long, so tab-completing on the trash directory is
very helpful. Lately I've noticed that there are a bunch of
Василий Макаров einmal...@gmail.com writes:
Hi there!
First of all: I'm new to mailing-lists, sorry if I'm doing it wrong.
I've found a bug in git merge-base, causing it to show not best common
ancestors and duplicates under some circumstances (example is given in
attached test case).
stephen_le...@stephe-leake.org writes:
That left the workspace unusable:
- .git/FETCH_HEAD is empty
that causes 'git rev-parse FETCH_HEAD' to fail with a confusing
error message.
This is not limited to your Cygwin environment. I can see that we
leave an empty file there after a
Roman Kagan rka...@mail.ru writes:
2013/12/28 Junio C Hamano gits...@pobox.com:
Eric Wong normalper...@yhbt.net writes:
git://git.bogomips.org/git-svn.git master
for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace:
git-svn: workaround for a bug in svn serf backend
Junio C Hamano gits...@pobox.com writes:
I do not offhand remember if it was deliberate that we do not dedup
the result from the underlying get_octopus_merge_bases() (the most
likely reason for not deduping is because the caller is expected to
do that if it wants to).
Whether
Ramkumar Ramachandra artag...@gmail.com writes:
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Interesting. As far as I can tell, no code ever used this symbol
since the command was introduced at 9f613ddd (Add git-for-each-ref:
helper for language bindings, 2006-09-15).
Christian Couder chrisc...@tuxfamily.org writes:
The only changes compared to version 3 are the following:
I'll queue this instead on top, as the series is already in 'next'.
Thanks.
-- 8 --
From: Christian Couder chrisc...@tuxfamily.org
Date: Sat, 28 Dec 2013 12:00:05 +0100
Subject: [PATCH]
Josh Triplett j...@joshtriplett.org writes:
On Mon, Dec 30, 2013 at 09:19:55AM -0800, Junio C Hamano wrote:
Christian Couder chrisc...@tuxfamily.org writes:
+# Do not remove trailing spaces below!
+cat complex_message_trailers 'EOF'
+Fixes:
+Acked-by:
+Reviewed-by:
+Signed-off
Josh Triplett j...@joshtriplett.org writes:
- The everybody will have a single SP at the end may or may not
last forever;
Trivially fixed if that ever changes, but given the nature of all of
these, that seems unlikely.
Why? Because we encourage to write tests that are expected to find
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 problem in your patch, but I wonder if it is
worth applying the patch below
Sebastian Schuberth sschube...@gmail.com writes:
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.
I think it is a good thing to check with the list of built-in's
first,
Sebastian Schuberth sschube...@gmail.com writes:
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/technical/api-builtin.txt | 2 +-
Makefile| 1 +
builtin.c | 225 ++
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi,
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
See https://github.com/msysgit/git/pull/80.
Thanks Sebastian!
However, since the git.git project is not comfortable with the concept of
pull requests (which is why you submitted
Francesco Pretto cez...@gmail.com writes:
by default git submodule performs its add or update operations on a detached
HEAD. This works well when using an existing full-fledged/indipendent project
as
the submodule, as there's less frequent need to update it or commit back
changes. When the
Bernhard R. Link brl+...@mail.brlink.eu writes:
Allows to disable the git blame optimization of assuming that if there is a
parent of a merge commit that has the exactly same file content, then
only this parent is to be looked at.
I think this is what we usually call --full-history in git log
Sebastian Schuberth sschube...@gmail.com writes:
On 02.01.2014 20:55, Junio C Hamano wrote:
Thanks; the conclusion is correct --- you need a good commit
message in the recorded history. That does not have anything to do
with integrating with pulling from subsystem maintainers, which we
Eric Sunshine sunsh...@sunshineco.com writes:
On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
[New Topics]
Would $gmane/239575 [1] be of interest
Sebastian Schuberth sschube...@gmail.com writes:
When cloning to a directory C:\foo\bar from Windows' cmd.exe where foo
does not exist yet, Git would throw an error like
fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
Fix this by not hard-coding a platform
Bernhard R. Link brl+...@mail.brlink.eu writes:
When giving git-blame the new option introduced with my patch, only
the order of parents determines which commit is blamed. Without
the option (i.e. the currently only possible behaviour) which commit
is blamed depends what else touches other
Junio C Hamano gits...@pobox.com writes:
This has a bit of conflict with another topic in flight; I think I
resolved it correctly, but please double check. The following is
how it would apply on top of 'pu'.
sha1_file.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
This has a bit of conflict with another topic in flight; I think I
resolved it correctly, but please double check. The following is
how it would apply on top of 'pu'.
sha1_file.c | 9 +
1 file
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote:
These scratch areas for sub-tests should be under the t
trash directory, but because the TEST_OUTPUT_DIRECTORY
setting from the toplevel test leaks
Ramkumar Ramachandra artag...@gmail.com writes:
There are situations where two classes of completions possible. For
example
branch.TAB
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ., and the second/ third
Ramkumar Ramachandra artag...@gmail.com writes:
branch.*.*)
local pfx=${cur%.*}. cur_=${cur##*.}
+ if [ $pfx == branch.autosetupmerge. ] ||
+ [ $pfx == branch.autosetuprebase. ]; then
+ return
+ fi
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
If we are looking at branch.autosetupmerge. followed by something,
who typed that final dot?
I admit that it's a very unlikely case. The user did:
$ branch.autosetupmerTAB
hit backspace to delete the trailing space
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
__gitcomp_nl $(__git_heads) $pfx $cur_ .
__gitcomp_nl_append $autosetupmerge\nautosetuprebase\n $pfx
$cur_
This is not a bad idea at all. I'm just afraid that we might be
leaving open ends: What
Stephen Leake stephen_le...@stephe-leake.org writes:
Junio C Hamano gits...@pobox.com writes:
stephen_le...@stephe-leake.org writes:
However, in this case, even running the fetch was a mistake; I would
have prefered that it leave FETCH_HEAD in its previous state.
I think the clearing
Jeff King p...@peff.net writes:
On Thu, Jan 02, 2014 at 11:41:05AM -0800, Junio C Hamano wrote:
- builtin/merge.c is the same, but it is conceptually even worse.
It has the end-user supplied string and wants to see if it is a
valid strategy. If the user wants to use a custom strategy
Tom Miller jacker...@gmail.com writes:
If fetch --prune is run with no new refs to fetch, but it has refs
to prune. Then, the header url is not printed as it would if there were
new refs to fetch.
Output before this patch:
$ git fetch --prune remote-with-no-new-refs
x
Vasily Makarov einmal...@gmail.com writes:
pptr is needless. Some related code got cleaned as well
Signed-off-by: Vasily Makarov einmal...@gmail.com
---
commit.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/commit.c b/commit.c
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
You seem to be calling it incorrect to give the same degree of
completion for a branch the user named autosetupmerge as another
branch topic, but I think it is incorrect not to, so I cannot tell
if we are agreeing
Ramkumar Ramachandra artag...@gmail.com writes:
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..bf358d6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,19 @@
Ramkumar Ramachandra artag...@gmail.com writes:
When attempting to complete
$ git config remote.pushTAB
'pushdefault' doesn't come up. This is because $cur is matched with
remote.* and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_nl_append ().
brian m. carlson sand...@crustytoothpaste.net writes:
On Fri, Jan 03, 2014 at 01:30:28PM +0530, Ramkumar Ramachandra wrote:
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Jeff King p...@peff.net writes:
On Fri, Jan 03, 2014 at 04:12:51PM -0500, Matt Burke wrote:
+ git init -q
+ git fetch -q -fu ../../../other '+refs/*:refs/*'
fatal: bad object 9b985fbe6a2b783c16756077a8be261c94b6c197
error: ../../../other did not send all necessary objects
I was going to
Jeff King p...@peff.net writes:
We could probably teach index-pack an --assume-refs-are-thin
option to optimize for this case, and have fetch-pack/receive-pack pass
it whenever they know that delta-base-offset was negotiated.
I thought the existing negotiation merely means I understand offset
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
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
W. Trevor King wk...@tremily.us writes:
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
+case $update_module in
+'')
+;; # Unset update mode
+checkout | rebase | merge | none)
+
Jiang Xin worldhello@gmail.com writes:
Please pull l10n update for maint branch. It can be merged to master
without conflict.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Thomas Ackermann th.ac...@arcor.de writes:
Use asciidoc style 'article' instead of 'book' and change asciidoc title
level.
This removes blank first page and superfluous Part I page (there is no
Part II)
in pdf output. Also pdf size is decreased by this from 77 to 67 pages.
In html output
Junio C Hamano gits...@pobox.com writes:
W. Trevor King wk...@tremily.us writes:
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
+ case $update_module in
+ '')
+ ;; # Unset update mode
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 as we are trying to make them. For example, git
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
---
dir.c | 22 --
1 file
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 without explanation, the
above no longer reflects
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 Haggerty mhag...@alum.mit.edu
---
This step has an
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,...
Two
Ramkumar Ramachandra artag...@gmail.com writes:
Hi,
On the latest git, I noticed that a rebase --onto doesn't abort
properly. Steps to reproduce:
# on some topic branch
$ git rebase --onto master @~10
^C # quickly!
$ git rebase --abort
# HEAD is still detached
I do not think
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
- why is a single branch name sufficient?
It does accept a revision, so any form is allowed; but why would
anyone want that in a format.defaultTo? I'm not sure we want to impose
an artificial restriction
Jeff King p...@peff.net writes:
On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote:
I was going to ask you to send your repository, but I can easily
reproduce here. I guess people don't run into it because it's uncommon
to fetch the whole refs/ namespace from a non-bare repo
Jeff King p...@peff.net writes:
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
Unless you set @{u} to this new configuration, in which case the
choice becomes dynamic depending on the current branch, but
- if that is the only sane choice based on the current branch, why
Jeff King p...@peff.net writes:
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
I wonder if it is too late to try to clarify this dual usage. It kind of
seems like the push config is this is the place I publish to. Which,
in many workflows, just so happens to be the exact
W. Trevor King wk...@tremily.us writes:
And wouldn't it make it unnecessary to have a new re-attach option
if such a mode that never have to detach is used?
I think so, but we currently don't have a never detached route for
folks that are cloning submodules via update (instead of via
John Szakmeister j...@szakmeister.net writes:
Am I missing something? If there is something other than @{u} to
represent this latter concept, I think `git push` should default to
that instead. But, at least with my current knowledge, that doesn't
exist--without explicitly saying so--or
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
I meant a single branch as opposed to depending on what branch
you are sending out, you may have to use a different upstream
starting point, and a single format.defaultTo that does not read
what your HEAD currently points
Welcome to the first issue of What's cooking report for the new
year.
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of
Jeff King p...@peff.net writes:
Then we ask fetch_refs_via_pack to get the actual objects for us. And
it checks our refs again, with this call chain:
do_fetch
fetch_refs
transport_fetch_refs
fetch_refs_via_pack
fetch_pack
do_fetch_pack
Francesco Pretto ceztk...@gmail.com writes:
2014/1/6 Junio C Hamano gits...@pobox.com:
- git-submodule.sh: support 'checkout' as a valid update mode
Need to pick up a rerolled one.
I resent it, can you see it?
I know. I saw it and that is why I left the note to self.
The thing
Jens Lehmann jens.lehm...@web.de writes:
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
Francesco Pretto cez...@gmail.com writes:
According to Documentation/gitmodules.txt, 'checkout' is a valid
'submodule.name.update' command.
As you can see in the surrounding text, we call the value of
submodule.*.update a mode, not a command.
Also git-submodule.sh refers to
it and processes
Junio C Hamano gits...@pobox.com writes:
It's really not clear to me what the check in filter_refs was trying to
do. It dates all the way back to 1baaae5 (Make maximal use of the remote
refs, 2005-10-28), but there is not much explanation. I haven't dug into
the list around that time to see
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
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
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
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
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
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
the user explicitly asks to work on
a detached HEAD, subsequent updates all happen on the specified
branch, which matches the end-user expectation much better.
Signed-off-by: W. Trevor King wk...@tremily.us
Signed-off-by: Junio C Hamano gits...@pobox.com
Please correct me if I
Ø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
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
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
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
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
@{upstream} is not a good default (unless the workflow is screwed up
and @{upstream} is set to point at somewhere that is _not_ a true
upstream, that is).
Cc: Jeff King p...@peff.net
Cc: Junio C Hamano gis...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Since -M, -C, -D
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
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
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
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
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
1 - 100 of 27729 matches
Mail list logo
