Re: Recording the current branch on each commit?

he solution should be clash with what the > community view is, you're not going to be able to convince > the community to go hunting. I'm not going to convince them to buy bread either. The community wants to starve to death, and you couldn't convince them otherwise either. --

[PATCH 0/8] remote-helper: fixes

A few trivial updates, a few important fixes. Daniel Liew (1): git-remote-hg: use internal clone's hgrc Felipe Contreras (7): remote-hg: fix parsing of custom committer remote-hg: update to 'public' phase when pushing remote-{hg,bzr}: store marks only on success remo

[PATCH 6/8] git-remote-hg: use internal clone's hgrc

ned-off-by: Dan Liew Signed-off-by: Felipe Contreras --- git-remote-hg.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-remote-hg.py b/git-remote-hg.py index 1972f7f..cd3d79e 100755 --- a/git-remote-hg.py +++ b/git-remote-hg.py @@ -422,7 +422,7 @@ def get_repo(url, ali

[PATCH 1/8] remote-hg: fix parsing of custom committer

Other tools use the 'committer' extra field differently, so let's make the parsing more reliable and don't assume it's in a certain format. Reported-by: Kevin Cox Signed-off-by: Felipe Contreras --- git-remote-hg.py | 8 ++-- 1 file changed, 6 insertions(+), 2 d

[PATCH 2/8] remote-hg: update to 'public' phase when pushing

This is what Mercurial does. Reported-by: Nathan Palmer Signed-off-by: Felipe Contreras --- git-remote-hg.py | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/git-remote-hg.py b/git-remote-hg.py index c849abb..204ceeb 100755 --- a/git-remote-hg.py +++ b/git

[PATCH 5/8] t: remote-hg: split into setup test

Signed-off-by: Felipe Contreras --- t/t5810-remote-hg.sh | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/t/t5810-remote-hg.sh b/t/t5810-remote-hg.sh index 594a0a1..ba8b2d8 100755 --- a/t/t5810-remote-hg.sh +++ b/t/t5810-remote-hg.sh @@ -105,17 +105,18 @@ setup

[PATCH 8/8] remote-hg: trivial cleanups

Cleanup 51be46e (remote-hg: do not fail on invalid bookmarks). Having a 40-characters string is not ideal, and having three tests for basically the same relatively rare situation is overkill. Signed-off-by: Felipe Contreras --- git-remote-hg.py | 2 +- t/t5810-remote-hg.sh | 56

[PATCH 4/8] remote-hg: properly detect missing contexts

This can happen when there's a synchronization issue between marks-git and marks-hg; a key is missing in marks-hg, and when we receive a reset command the value of ctx basically comes from None. Signed-off-by: Felipe Contreras --- git-remote-hg.py | 5 + 1 file changed, 5 inser

[PATCH 3/8] remote-{hg,bzr}: store marks only on success

should only be written after both have finished successfully. Signed-off-by: Felipe Contreras --- git-remote-bzr.py | 8 +++- git-remote-hg.py | 8 +++- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/git-remote-bzr.py b/git-remote-bzr.py index 9abb58e..71b138e 100755 --- a

[PATCH 7/8] remote-hg: make sure we omit multiple heads

require repo.revs() which is only available after Mercurial v2.1. Also, we would need special considerations for when there's no base revision (importing from root). It's much better to implement our own function to get a range of revisions. The new gitrange() is inspired by Mercurial&#

Re: Recording the current branch on each commit?

David Kastrup wrote: > Felipe Contreras writes: > > > Contributors don't have any responsibility to champion their > > patches. It is pro bono work. > > No, that's just the appearance that should be upheld in the higher > society. It's ok to get

Re: Recording the current branch on each commit?

David Kastrup wrote: > Felipe Contreras writes: > > > David Kastrup wrote: > > > >> Even while the ones getting the benefits from your work will not > >> feel an obligation to make it worth your while, there is a > >> difference in satisfaction betwe

Re: Recording the current branch on each commit?

David Kastrup wrote: > Felipe Contreras writes: > > > David Kastrup wrote: > > > >> Well, there you have it. The ones that do any kind of relevant change > >> are the ones that need thinking about and consideration. And when you > >> are so verbose

[PATCH v5 3/6] pull: refactor $rebase variable into $mode

Signed-off-by: Felipe Contreras --- git-pull.sh | 65 - 1 file changed, 34 insertions(+), 31 deletions(-) diff --git a/git-pull.sh b/git-pull.sh index d4e25f1..3dfd856 100755 --- a/git-pull.sh +++ b/git-pull.sh @@ -57,16 +57,11 @@ then

[PATCH v5 2/6] pull: migrate all the tests to pull.mode

And branch.$name.pullmode. Signed-off-by: Felipe Contreras --- t/t5505-remote.sh | 2 +- t/t5520-pull.sh | 54 +++--- 2 files changed, 24 insertions(+), 32 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index ac79dd9..76376e4

[PATCH v5 4/6] pull: add --merge option

Also, deprecate --no-rebase since there's no need for it any more. Signed-off-by: Felipe Contreras --- Documentation/git-pull.txt | 8 ++-- git-pull.sh| 6 +- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentatio

[PATCH v5 6/6] pull: only allow ff merges by default

Signed-off-by: Felipe Contreras --- Documentation/git-pull.txt | 18 ++ git-pull.sh | 2 +- t/t4013-diff-various.sh | 2 +- t/t5500-fetch-pack.sh| 2 +- t/t5524-pull-msg.sh | 2 +- t/t5700-clone-reference.sh | 4 ++-- t/t6022-merge

[PATCH v5 0/6] Reject non-ff pulls by default

pull.mode = merge-ff-only branch..pullmode = merge-ff-only This patch series does all the steps mentioned, but in reverse order, and in addition updates the tests to use the new configurations instead. Felipe Contreras (6): pull: rename pull.rename to pull.mode pull: migrate all the tes

[PATCH v5 1/6] pull: rename pull.rename to pull.mode

Also 'branch..rebase' to 'branch..pullmode'. This way 'pull.mode' can be set to 'merge', and the default can be something else. The old configurations still work, but get deprecated. Signed-off-by: Felipe Contrer

[PATCH v5 5/6] pull: add merge-ff-only option

ode = merge-ff-only. Later on this mode can be enabled by default (e.g. in v2.0). For the full discussion you can read: http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305 Signed-off-by: Felipe Contreras --- Documentation/config.txt | 7 +-- git-pull.sh

Re: Recording the current branch on each commit?

David Kastrup wrote: > Felipe Contreras writes: > > > David Kastrup wrote: > > > >> The default behavior of "git push". > > > > This is a minor change that not many people would notice, and it has not > > actually happend. But fine, let

Re: Recording the current branch on each commit?

really is the best choice as you > say. I already made a fork: http://felipec.wordpress.com/2013/10/28/git-fc/ -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: Recording the current branch on each commit?

James Denholm wrote: > So that we can all have egg on our faces when it takes off and is > proven superior... Right? I don't know what you mean by "we", but it certainly doesn't include you. % git log --author=nod.h...@gmail.com master empty -- Felipe Contreras -

Re: [PATCH v5 1/6] pull: rename pull.rename to pull.mode

Marat Radchenko wrote: > Felipe Contreras wrote > > [PATCH v5 1/6] pull: rename pull.rename to pull.mode > > s/pull.rename/pull.rebase/ Right. Will fix. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: Recording the current branch on each commit?

James Denholm wrote: > On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras > wrote: > >James Denholm wrote: > >> So that we can all have egg on our faces when it takes off and is > >> proven superior... Right? > > > >I don't know what you mean b

[PATCH 1/3] config: avoid yoda conditions

Signed-off-by: Felipe Contreras --- config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config.c b/config.c index a30cb5c..bd69ad7 100644 --- a/config.c +++ b/config.c @@ -616,7 +616,7 @@ static int git_config_maybe_bool_text(const char *name, const char *value

[PATCH 0/3] Trivial cleanups

Felipe Contreras (3): config: avoid yoda conditions add: avoid yoda condition add: remove dead code builtin/add.c | 6 +- config.c | 4 ++-- 2 files changed, 3 insertions(+), 7 deletions(-) -- 1.9.2+fc1.3.gade8541 -- To unsubscribe from this list: send the line "unsubscrib

[PATCH 3/3] add: remove dead code

addremove is already 1 by default. Signed-off-by: Felipe Contreras --- builtin/add.c | 4 1 file changed, 4 deletions(-) diff --git a/builtin/add.c b/builtin/add.c index ac10bab..980e247 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -329,10 +329,6 @@ int cmd_add(int argc, const char

[PATCH 2/3] add: avoid yoda condition

18 is younger than person's age. Signed-off-by: Felipe Contreras --- builtin/add.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/add.c b/builtin/add.c index 459208a..ac10bab 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -321,7 +321,7 @@ int cmd_add(int

Re: [PATCH v5 1/6] pull: rename pull.rename to pull.mode

Philip Oakley wrote: > From: "Felipe Contreras" > > Also 'branch..rebase' to 'branch..pullmode'. > > Sorry I haven't commented earlier. Because the 0/6 explanation isn't a > commit, a few extra words would be useful to capture what the

Re: Recording the current branch on each commit?

hoose to starve to death. > > I'm the meantime, the community decides that some of your proposals > aren't good ideas, and decide to consider others in due course. Wrong. The problems are ackowledged, no other proposals are put forward, nothing gets done. -- Felipe Cont

Re: git cascade and git forward-merge

, I'm going to try to make this into a patch for > core. I like this, but I think it should be an option to `git merge`. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordo

Re: Recording the current branch on each commit?

James Denholm wrote: > Felipe Contreras wrote: > > James Denholm wrote: > >> > Either way your analogy is completely wrong as I already explained > >> > multiple times. I'm not trying to convince vegetarians to go > >> > hunting, I'm saying th

[PATCH] rerere: fix for merge.conflictstyle

-off-by: Felipe Contreras --- builtin/rerere.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/rerere.c b/builtin/rerere.c index 4e51add..98eb8c5 100644 --- a/builtin/rerere.c +++ b/builtin/rerere.c @@ -60,6 +60,8 @@ int cmd_rerere(int argc, const char **argv, const char *prefix

RE: [PATCH] git-completion.zsh: do not clobber complete()

problems. I run 'type -f _complete' and I get bashcompinit's complete, and the internal _complete() function is used only by the _git completion. How have you configured this completion? Are you using the recommended instructions? -- Felipe Contreras -- To unsubscribe from this l

RE: [PATCH] zsh completion: 5.0.3 compat, use emulate

there. [1] http://felipec.wordpress.com/2010/08/03/avoid-reply-to-munging-mail-as-mail-was-meant-to-be/ -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rerere: fix for merge.conflictstyle

Jeff King wrote: > On Tue, Apr 29, 2014 at 11:08:29PM -0500, Felipe Contreras wrote: > > > If we use a different conflict style `git rerere forget` is not able to > > find the matching conflict SHA-1 because the diff generated is actually > > different from what `git me

RE: [PATCH] zsh completion: 5.0.3 compat, use emulate

Felipe Contreras wrote: > Phil Pennock wrote: > > The bash completion pulled into zsh was being pulled in _as_ zsh, but > > used patterns which relied on falling through as unhandled. In zsh > > 5.0.3 this no longer works, resulting in: > > > > __git_c

RE: [PATCH] git-completion.zsh: do not clobber complete()

Felipe Contreras wrote: > Mark Lodato wrote: > > Previously, git-completion.zsh redefined complete() to make > > __git_complete() a no-op. This broke zsh's built-in bash completion > > compatibility layer (bashcompinit), which defines its own complete(). > > How

[PATCH 6/6] completion: bash: cleanup cygwin check

Avoid Yoda conditions, use test, and cleaner statement. Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.bash | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index f1ce962

[PATCH 2/6] completion: bash: remove zsh wrapper

It has been deprecated for one year and a half. It's time to move on. Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.bash | 64 -- 1 file changed, 64 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/compl

[PATCH 4/6] completion: remove zsh hack

We don't want to override the 'complete()' function in zsh, which can be used by bashcomp. Reported-by: Mark Lodato Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.bash | 1 + contrib/completion/git-completion.zsh | 6 -- 2 files changed, 1 insertion(

[PATCH 1/6] completion: bash: remove old wrappers

Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.bash | 12 1 file changed, 12 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 9525343..6e331d2 100644 --- a/contrib/completion/git-completion.bash

[PATCH 5/6] completion: zsh: trivial cleanups

We don't need to override IFS, zsh has a native way of splitting by new lines: the expansion flag (f). Also, we don't need to split files by ':' or '='; that's only for words. Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.zsh

[PATCH 3/6] completion: zsh: don't hide ourselves

There's no need to hide the fact that we are on zsh any more. Signed-off-by: Felipe Contreras --- contrib/completion/git-completion.zsh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh

[PATCH 0/6] completion: fixes

A bunch of cleanups and fixes. Felipe Contreras (6): completion: bash: remove old wrappers completion: bash: remove zsh wrapper completion: zsh: don't hide ourselves completion: remove zsh hack completion: zsh: trivial cleanups completion: bash: cleanup cygwin check co

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

anches I constanly keep rebasing, and the main master branch always mergering and cherry-picking, never rebasing. [1] https://github.com/felipec/git-reintegrate -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

RE: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

his change, and even then an appropriate error message like: The pull was not fast-forward, please either merge or rebase. If unsure, run 'git pull --merge'. Should do the trick. [1] http://article.gmane.org/gmane.comp.version-control.git/247567 -- Felipe Contreras -- To unsubscrib

Re: Pull is Evil

Matthieu Moy wrote: > Felipe Contreras writes: > > > Marc Branchaud wrote: > >> But I'm definitely biased because I think pull is pretty much broken: > >> > >> * New users are encouraged to use pull, but all too often the default > >> fetch-

Re: [PATCH v5 0/6] Reject non-ff pulls by default

Junio C Hamano wrote: > Felipe Contreras writes: > > > These are the steps needed to achieve this: > > The overall progression (this comment is only about the design, not > the implementation) looks almost sensible, but I may have missed > some issues because the

Re: [PATCH v5 0/6] Reject non-ff pulls by default

Junio C Hamano wrote: > Felipe Contreras writes: > > >> - With the endgame of "out of box Git without any configuration > >> refuses 'git pull' (without --merge/--rebase) that does not > >> fast forward" in mind, start warning

Re: Pull is Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > Matthieu Moy wrote: > >> Felipe Contreras writes: > >> ... > >> > Yes, this has been discussed many times in the past, and everyone agrees > >> > the default behavior is not correct. > >

Re: Pull is Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > Junio C Hamano wrote: > >> Felipe Contreras writes: > >> > Matthieu Moy wrote: > >> >> Felipe Contreras writes: > >> >> ... > >> >> > Yes, this has been discusse

Re: Pull is Evil

l` merges a fast-forward? The problems with `git pull` come when you can't do a fast-forward merge, right? -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: Pull is Evil

Marc Branchaud wrote: > On 14-04-30 04:14 PM, Felipe Contreras wrote: > > Marc Branchaud wrote: > >> All that said, I don't object to any attempts at improving the command > >> either. But I also don't see any kind of improvement that would lead > &

Re: Pull is Evil

brian m. carlson wrote: > On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: > > Marc Branchaud wrote: > > > On 14-04-30 04:14 PM, Felipe Contreras wrote: > > > > What is wrong when `git pull` merges a fast-forward? > > > > > > Nothin

Re: Pull is Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > > brian m. carlson wrote: > >> .. > >> At work, we have a workflow where we merge topic branches as > >> non-fast-forward, so that we have a record of the history (including who > >> reviewe

Re: Pull is Evil

e > git merge --no-ff developer-remote/topic-branch > git push main-repo HEAD You mean `git push main-repo HEAD:maintenance-branch`, right? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.o

Re: Pull is Evil

-no-ff if that's what you really want. > git push main-repo HEAD main-repo/maintenance-branch should be the upstream of maintenance-branch, in which hase: % git push -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message t

RE: Zsh submodule name completion borked

anyone else? Is it something in my local configuration causing > this? Define 'works' in bash. From what I can see from the bash completion, it's not doing anything special, so the completion you see are simply files. -- Felipe Contreras -- To unsubscribe from this list: send the li

Re: [git] Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote: > > The only problem would be when it's not desirable, however, that's a > > problem of the user's ignorance, and the failure of the project's > > policity to com

Re: [git] Re: Pull is Evil

ommits from git://example.net/main.git master into my-feature? > > because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. -- Felipe Contreras-- 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 http://vger.kernel.org/majordomo-info.html

Re: [git] Re: Pull is Evil

Marc Branchaud wrote: > So what benefit does "git pull" provide? The same that 'hg update' provies: a way for the user fetch/pull the latest changes and check them out into the working directory. -- Felipe Contreras -- To unsubscribe from this list: send the line "

Re: Pull is Evil

by mistake. Nobody ever complained about somebody doing a fast-forward by mistake. I think a non-fast-forward warning by default, and eventually rejecting them is the most sensible approach. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the

Re: [git] Re: Pull is Evil

brian m. carlson wrote: > I just used this to illustrate the fact that there isn't actually one > completely correct case with pull. Nobody is arguing otherwise. The argument is that `git pull` by default can be made more sensible. -- Felipe Contreras -- To unsubscribe from this lis

[PATCH v6 2/7] pull: migrate all the tests to pull.mode

And branch.$name.pullmode. Signed-off-by: Felipe Contreras --- t/t5505-remote.sh | 2 +- t/t5520-pull.sh | 54 +++--- 2 files changed, 24 insertions(+), 32 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index ac79dd9..76376e4

[PATCH v6 1/7] pull: rename pull.rebase to pull.mode

Also 'branch..rebase' to 'branch..pullmode'. This way we can add more modes and the default can be something else, namely it can be set to merge-ff-only, so eventually we can reject non-fast-forward merges by default. The old configurations still work, but get deprecated. S

[PATCH v6 0/7] Reject non-ff pulls by default

amp; git add new && @@ -389,9 +389,9 @@ test_expect_success 'git pull non-fast-forward' ' test_must_fail git pull ' -test_expect_success 'git pull non-fast-forward (merge)' ' +test_expect_success 'git pull non-fast-forward with me

[PATCH v6 3/7] pull: refactor $rebase variable into $mode

Signed-off-by: Felipe Contreras --- git-pull.sh | 64 +++-- 1 file changed, 33 insertions(+), 31 deletions(-) diff --git a/git-pull.sh b/git-pull.sh index 3dbf9cf..50c612f 100755 --- a/git-pull.sh +++ b/git-pull.sh @@ -53,16 +53,11 @@ then

[PATCH v6 5/7] pull: add merge-ff-only option

ode = merge-ff-only. Later on this mode can be enabled by default. For the full discussion you can read: http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305 Signed-off-by: Felipe Contreras --- Documentation/config.txt | 7 +-- git-pull.sh | 15 ++

[PATCH v6 7/7] pull: only allow ff merges by default

Signed-off-by: Felipe Contreras --- Documentation/git-pull.txt | 2 +- git-pull.sh | 15 +++ t/t4013-diff-various.sh | 2 +- t/t5500-fetch-pack.sh| 2 +- t/t5520-pull.sh | 5 + t/t5524-pull-msg.sh | 2 +- t/t5700-clone

[PATCH v6 6/7] pull: add warning on non-ff merges

omes, they know what to type without interrupting or changing their workflow. Signed-off-by: Felipe Contreras --- Documentation/git-pull.txt | 18 ++ git-pull.sh| 15 --- t/t5520-pull.sh| 14 ++ 3 files changed, 44 insertions(+), 3

[PATCH v6 4/7] pull: add --merge option

Also, deprecate --no-rebase since there's no need for it any more. Signed-off-by: Felipe Contreras --- Documentation/git-pull.txt | 8 ++-- git-pull.sh| 10 +- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/Documentation/git-pull.txt b/Document

Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote: > > Nobody ever complained about somebody doing a fast-forward by mistake. > > Unless they fast-forward merged a feature branch into master, but the > project prefers explicitly-merged fea

Re: [git] Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: > > > > My interest in all of the proposed git-pull-training-wheel patches is >

Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote: > > If that was the case the user wouls have run `git merge > > --no-ff`. Only expereinced users would answer 'no'. > > Folks who are setting any ff options don't need any

Re: [PATCH v6 4/7] pull: add --merge option

brian m. carlson wrote: > On Thu, May 01, 2014 at 07:00:05PM -0500, Felipe Contreras wrote: > > Also, deprecate --no-rebase since there's no need for it any more. > > > > Signed-off-by: Felipe Contreras > > --- > > Documentation/git-pull.txt | 8 ++-

Re: Pull is Evil

stead of the former mainline. I haven't really thought much about this but it does make sense. How about changing the behavior so `git pull` by default changes the order of the parents, but `git pull repo branch` doesn't. -- Felipe Contreras -- To unsubscribe from this list: send the

Re: Pull is Evil

W. Trevor King wrote: > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > My proposed --prompt behavior is for folks who think “I often run > > > this command without thinking it through all the way. I'm also > &

Re: Pull is Mostly Evil

aybe > contentious for some. So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: Pull is Mostly Evil

updating the tutorials, > may be disallow fetch+merge by default only when pulling from the > place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. -- Felipe Contreras -- To unsu

Re: Pull is Evil

W. Trevor King wrote: > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: > > > > W. Trevor King wrote: > > > > > My proposed --prompt

Re: [PATCH v6 4/7] pull: add --merge option

, so `git pull --merge`. I don't see what's confusing about that. -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: Pull is Evil

W. Trevor King wrote: > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > It would matter almost exactly zero. > > Some folks have explicit merge policies, and deciding how much that > matters is probably best left up to the projects themselves and not >

Re: [PATCH 1/8] CodingGuidelines: typofix

'e' is more common. > > Grammar by democracy. ;) Languages are a democracy. There's no authority that decides if "unibrow" should become part of the English language. We all do. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git&qu

Re: Pull is Mostly Evil

Junio C Hamano wrote: > Felipe Contreras writes: > > >> Stepping back even further, and thinking what is different between > >> these two pulls, we notice that the first one is pulling from the > >> place we push back to. Perhaps a way to solve this issue, witho

Re: [PATCH v6 1/7] pull: rename pull.rebase to pull.mode

Richard Hansen wrote: > On 2014-05-01 20:00, Felipe Contreras wrote: > > Also 'branch..rebase' to 'branch..pullmode'. > > > > This way we can add more modes and the default can be something else, > > namely it can be set to merge-ff-only, so eventual

Re: Pull is Evil

W. Trevor King wrote: > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > > > It would matter almost exactly zero. > > > > > &

Re: Pull is Mostly Evil

Jeff King wrote: > On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: > > > Junio C Hamano wrote: > > > If we step back a bit, because we are forcing him to differentiate > > > these two pulls in his mental model anyway, perhaps it may help > > &

RE: BUG or FEATURE? Use of '/' in branch names

be nice for remote helpers: Mercurial can have "hotfix" and "hotifx/b1", so importing such a Mercurial repository creates problems. -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)

erent modes: 1) git pull 2) git pull origin topic Maybe it would actually make sense to have a configuration specific to 2): pull.topicmode. This way they could do "pull.topicmode = merge-no-ff". Or maybe we need arguments: "pull.topicargs = --merge --no-ff". -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

RE: Watchman support for git

en doing something similar in Merurial (watchman vs . no watchman). -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: Pull is Mostly Evil

Philip Oakley wrote: > From: "Felipe Contreras" > > So? No defaults can please absolutely everyone, the best anybody can > > do is try to please the majority of people, and merging > > fast-forwards only does that. > > That assumes that doing something is b

Re: Pull is Mostly Evil

Jeff King wrote: > On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote: > > > They can do: > > > > % git pull origin master > > > > That shouldn't revese the bases. > > Then they have to remember to do that every time, no? That seems

[PATCH] completion: move out of contrib

These have been stable and widely used for quite a long time, they even have tests outside of the contrib area, and most distributions ship them, so they can be considered part of the core already. Let's move them out of contrib and install them by default. Signed-off-by: Felipe Cont

RE: Watchman support for git

David Turner wrote: > On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote: > > dturner@ wrote: > > > Test repository 1: Linux > > > > > > Linux is about 45k files in 3k directories. The average length of a > > > filename is about 32 bytes. >

Re: Pull is Mostly Evil

greement > > about what 'git pull' should do. > > Should a screwdriver be turning clockwise or counterclockwise by > default? There are valid arguments for either. If you don't have anything to contribute don't disturb the people that actually care and are trying to im

Re: Pull is Mostly Evil

ath represents a series of completed tasks It is very rare that an integrator is even able to do a fast-forward merge anyway. So being explicit about --no-ff might better, but it would hardly make a difference. Either way, a good integrator would configure pull.ff = false. I'd say `git pull origin master` already works fine for this case. -- Felipe Contreras -- 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 http://vger.kernel.org/majordomo-info.html

Re: pull.prompt or other way to slow/disable 'git pull'

W. Trevor King wrote: > On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks > > > > > that are already using the curren

Re: Pull is Mostly Evil

Philip Oakley wrote: > From: "Felipe Contreras" > > When doing something is better for the vast majority of people, that's > > what should be done by default, unless the results are catastrophic > > for > > the minority. > > > > Since d

<    1   2   3   4   5   6   7   8   9   10   >