Junio C Hamano wrote:
> In short, you are saying that, assuming that missing and
> are given a sane default values (namely "HEAD"), the
> syntax:
>
> git branch []
> git branch --set-upstream-jrn []
>
> is easier to understand
I didn't propose allowing the branch argument to be om
Junio C Hamano wrote:
> Marcin Owsiany writes:
>
> >> This makes my idea to do the same to "my something else instead of
> >> master" much less attractive. In fact I don't think such behaviour would
> >> be useful.
> >>
> >> I think with the suggested patch git-svn works as I would like it to:
Jonathan Nieder writes:
> The truth is that neither one of us is right. Both conventions
> could work, and which one is more intuitive will vary from person
> to person.
It is not just person-to-person, I think.
In short, you are saying that, assuming that missing and
are given a sane defaul
Junio C Hamano wrote:
> You can think of it this way.
>
> "git branch" can not only _create_ a new branch (or list existing
> ones, but that is another entirely different mode), but also can be
> used to set attributes to an existing branch. Imagine a new option,
> say --set-description, to repla
Jonathan Nieder writes:
> [someone should have]
> | suggested an alternative syntax that avoids the mistake you quoted
> | above, perhaps something like:
> |
> | git branch --set-upstream-to=origin/master [HEAD]
>
> with which I disagree.
You can think of it this way.
"git branch" can not o
Junio C Hamano wrote:
> I think it
> is better to leave them emitted unconditionally to the standard
> error stream, in order to train users away from using the old option
> that has its arguments wrong (the option does not take an argument
'stash apply' directly calls a backend merge function
which does not automatically invoke rerere. This
confuses mergetool when leftover rerere state is left
behind from previous merges.
Invoke rerere explicitly when we encounter a conflict
during stash apply
Change the test for this flaw to expe
Add a failing test to confirm a conflicted stash apply
invokes rerere to record the conflicts and resolve the
the files it can.
mergetool may be confused by a left-over
state from previous rerere activity causing it to
think no files have conflicts even though they do.
This condition is not verifi
Jonathan Nieder writes:
> Message should go on stderr and be guarded with an advice option (see
> advice.c).
>
> Like this:
>
> const char *arg;
>
> ...
> if (argc != 1 || !advice_old_fashioned_set_upstream)
> return 0; /* ok. */
>
> arg = argv[0];
> ad
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The immediate problem that seems to trip people up is that it is very
>> tempting to run
>>
>> git branch --set-upstream junio/master
>
> I think we have discussed this already a few days ago. See my
> comment in the earlier thread before t
On Fri, Jul 06, 2012 at 02:04:10PM +0200, Ilya Ruprecht wrote:
>
> # read access
>
> require ldap-group repo.writers
> require ldap-group repo.readers
>
>
> # write access
>
Jonathan Nieder writes:
> The immediate problem that seems to trip people up is that it is very
> tempting to run
>
> git branch --set-upstream junio/master
I think we have discussed this already a few days ago. See my
comment in the earlier thread before this round.
--
To unsubscribe fro
On Tue, Jul 10, 2012 at 04:30:52PM -0400, Jeff King wrote:
> On Tue, Jul 10, 2012 at 01:14:32PM -0700, Junio C Hamano wrote:
>
> > I do not think the combination with --amend, --only and no paths
> > ever worked. We rejected such a combination before 6a74642c5, which
> > merely made us to accept
On Tue, Jul 10, 2012 at 01:14:32PM -0700, Junio C Hamano wrote:
> I do not think the combination with --amend, --only and no paths
> ever worked. We rejected such a combination before 6a74642c5, which
> merely made us to accept the combination but I do not think the
> commit did anything to re-re
Marc Strapetz writes:
> When using "git commit --amend --only --message --", I'd
> expect to have just the commit message of my last commit changed,
> according to the man page:
>
> "--only Make a commit only from the paths specified on the command line,
> disregarding any contents that have bee
On Tue, Jul 10, 2012 at 12:41:13PM +0200, Marc Strapetz wrote:
> When using "git commit --amend --only --message --", I'd
> expect to have just the commit message of my last commit changed,
> according to the man page:
>
> "--only Make a commit only from the paths specified on the command line,
Junio C Hamano wrote:
> I am not super excited about it either, but at least it is a vast
> improvement compared to the older one, with which it was entirely
> unclear if we are setting the value of upstream *to* what is given
> as an option, or setting the upstream *for* what is given on the
> co
Jonathan Nieder writes:
>> The existing --set-uptream option can cause confusion, as it uses the
>> usual branch convention of assuming a starting point of HEAD if none
>> is specified, causing
>>
>> git branch --set-upstream origin/master
>>
>> to create a new local branch 'origin/master' th
Hi,
Quick nitpicks.
Carlos Martín Nieto wrote:
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char
> *prefix)
> info and making sure new_upstream is correct */
> create_branch(head, branc
Hi,
Carlos Martín Nieto wrote:
> The existing --set-uptream option can cause confusion, as it uses the
> usual branch convention of assuming a starting point of HEAD if none
> is specified, causing
>
> git branch --set-upstream origin/master
>
> to create a new local branch 'origin/master' th
Carlos Martín Nieto writes:
> We have ways of setting the upstream information, but if we want to
> unset it, we need to resort to modifying the configuration manually.
>
> Teach branch an --unset-upstream option that unsets this information.
>
> ---
>
> create_branch() uses install_branch_config
Carlos Martín Nieto writes:
> This interface is error prone, and a better one (--set-upstream-to)
> exists. Suggest how to fix a --set-upstream invocation in case the
> user only gives one argument, which makes it likely that he meant to
> do the opposite, like with
>
> git branch --set-upstr
Junio C Hamano wrote:
[...]
>
> * rj/platform-pread-may-be-thread-unsafe (2012-06-26) 1 commit
> (merged to 'next' on 2012-06-28 at ce5f79f)
> + index-pack: Disable threading on cygwin
>
> On Cygwin, the platform pread(3) is not thread safe, just like our
> own compat/ emulation, and cannot be
Carlos Martín Nieto writes:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 0e060f2..c886fc0 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -713,6 +713,7 @@ int cmd_branch(int argc, const char **argv, const char
> *prefix)
> int verbose = 0, abbrev = -1, detached
Carlos Martín Nieto writes:
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char
> *prefix)
> info and making sure new_upstream is correct */
> create_branch(head, branch->name, new_upstrea
Carlos Martín Nieto writes:
> The new options allows us to type
>
> git branch --set-upstream-to origin/master
This is cool :-).
> Documentation/git-branch.txt |9 -
> builtin/branch.c | 15 +--
I think this deserves a few new tests (probably in t/t320
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstre
We have ways of setting the upstream information, but if we want to
unset it, we need to resort to modifying the configuration manually.
Teach branch an --unset-upstream option that unsets this information.
---
create_branch() uses install_branch_config() which may also set
branch.foo.rebase, so
This interface is error prone, and a better one (--set-upstream-to)
exists. Suggest how to fix a --set-upstream invocation in case the
user only gives one argument, which makes it likely that he meant to
do the opposite, like with
git branch --set-upstream origin/master
when they meant one of
Hello all,
This stems from comments made by Junio and Jonathan about my proposed
changes to --set-upstream.
This should probably have a few tests, but I'd like to hear comments
about the code and documentation first. The third patch is the one I'm
not so confident about. It would be simpler to re
When using "git commit --amend --only --message --", I'd
expect to have just the commit message of my last commit changed,
according to the man page:
"--only Make a commit only from the paths specified on the command line,
disregarding any contents that have been staged so far. [...] If this
opti
On 10.07.2012, at 00:38, Junio C Hamano wrote:
> Max Horn writes:
>
>> But all in all, I don't understand why this order independence
>> seems to be so important?
>
> Not so important as long as it is made clear for later people to
> patch that part of the code. I just wanted to make sure tha
The check_to_create_blob() function used to check only the case
where we are applying to the working tree. Rename the function to
check_to_create() and make it also responsible for checking the case
where we apply to the index. Also make its caller responsible for
issuing an error message.
Signe
Signed-off-by: Junio C Hamano
---
t/t4108-apply-threeway.sh | 54 +++
1 file changed, 54 insertions(+)
diff --git a/t/t4108-apply-threeway.sh b/t/t4108-apply-threeway.sh
index e6d4da6..fa5d4ef 100755
--- a/t/t4108-apply-threeway.sh
+++ b/t/t4108-apply-
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 3 +++
t/t4108-apply-threeway.sh | 25 +
2 files changed, 28 insertions(+)
diff --git a/builtin/apply.c b/builtin/apply.c
index dc52c94..cd68862 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -18,6 +18,
Now we have all the necessary logic to fall back on three-way merge when
the patch does not cleanly apply, insert the conflicted entries to the
index as appropriate. This obviously triggers only when the "--index"
option is used.
When we fall back to three-way merge and some of the merges fail, j
Signed-off-by: Junio C Hamano
---
Documentation/git-apply.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index afd2c9a..634b84e 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
When a patch wants to create a path, but we already have it in our
current state, pretend as if the patch and we independently added
the same path and cause add/add conflict, so that the user can
resolve it just like "git merge" in the same situation.
For that purpose, implement load_current() in
We will be adding another caller of this function in a later patch.
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index d84958b..682852c 100644
--- a/builtin/apply.c
+
When a patch does not apply to what we have, but we know the preimage the
patch was made against, we apply the patch to the preimage to compute what
the patch author wanted the result to look like, and attempt a three-way
merge between the result and our version, using the intended preimage as
the
Grab the preimage blob the patch claims to be based on out of the object
store, apply the patch, and then call three-way-merge function. This step
still does not plug the actual three-way merge logic yet, but we are
getting there.
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 46 +
Begin teaching the three-way merge fallback logic "git am -3" uses
to the underlying "git apply". It only implements the command line
parsing part, and does not do anything interesting yet, other than
making sure that "--reject" and "--3way" are not given together, and
making "--3way" imply "--ind
load_preimage() is very specific to grab the current contents for
the path given by patch->old_name. Split the logic that grabs the
contents for a path out of it into a separate load_patch_target()
function.
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 59
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index ee1a960..cd25e63 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3159,29 +3159,6 @@
The code to grab the result of application of a previous patch in the
input was mixed with error message generation for a case where a later
patch tries to modify contents of a path that has been removed.
The same code is duplicated elsewhere in the code. Introduce a helper
to clarify what is goi
Given a patch for a single path, the function apply_data() reads the
preimage in core, and applies the change represented in the patch.
Separate out the first part that reads the preimage into a separate
helper function load_preimage().
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 15 +++
Reading a blob out of the object store does not have to require that the
caller has a cache entry for it.
Create a read_blob_object() helper function that takes the object name and
mode, and use it to reimplement the original function as a thin wrapper to
it.
Signed-off-by: Junio C Hamano
---
b
When a patch wants to touch a path, if the path exists in the index
but is missing in the working tree, "git apply --index" checks out
the file to the working tree from the index automatically and then
applies the patch.
Split this logic out to a separate helper function.
Signed-off-by: Junio C H
The clear_image() function did not clear the line table in the image
structure; this does not matter for the current callers, as the function
is only called from the codepaths that deal with binary patches where the
line table is never populated, and the codepaths that do populate the line
table fr
This check is not only about type-change (for which it would be
sufficient to check only was_deleted()) but is also about a swap
rename. Otherwise to_be_deleted() check is not justified.
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 24 +++-
1 file changed, 15 insertio
The code is littered with to_be_deleted() whose purpose is not so clear.
Describe where it matters. Also remove an extra space before "#define"
that snuck in by mistake at 7fac0ee (builtin-apply: keep information about
files to be deleted, 2009-04-11).
Signed-off-by: Junio C Hamano
---
builtin/
With finishing touches (mostly updates to in-code comments and log
messages). Previous ones were:
http://thread.gmane.org/gmane.comp.version-control.git/197538
http://thread.gmane.org/gmane.comp.version-control.git/197637
http://thread.gmane.org/gmane.comp.version-control.git/199936
T
52 matches
Mail list logo
