On Sun, Apr 20, 2014 at 10:23 PM, Felipe Contreras
wrote:
> This hook is invoked whenever a branch is updated, either when a branch
> is created or updated with 'git branch', or when it's rebased with 'git
> rebase'. It receives two parameters; the name of the branch, and the
> SHA-1 of the latest
I am interested in exploring the possibility of using versioning for "data",
that is versioning non-text, non-code file sets. Typical examples are the data
files or "project files" used by some application. These file sets typically
contain binary files; these files can be somewhat large, 1GB to
On Mon, Apr 21, 2014 at 3:17 PM, Miller, Hugh wrote:
> I am interested in exploring the possibility of using versioning for "data",
> that is versioning non-text, non-code file sets. Typical examples are the
> data files or "project files" used by some application. These file sets
> typically c
Jiang Xin writes:
> When show date in relative date format for git-blame, the max display
> width of datetime is set as the length of the string "Thu Oct 19
> 16:00:04 2006 -0700" (30 characters long). But actually the max width
> for C locale is only 22 (the length of string "x years, xx months
Felipe Contreras writes:
> There doesn't seem to be any reason to keep these remote-helpers in the
> contrib
> area.
Yay.
I wouldn't phrase it "doesn't seem to be any reason", though. The
decision to include is not done due to lack of negatives, but
because adding them would be useful.
And I
On Sun, Apr 20, 2014 at 1:42 PM, Richard Hansen wrote:
> I have discovered a minor security vulnerability. I could send the
> patch to the mailing list, but I wanted someone else to take a look
> first just to make sure it's minor enough that folks will think it's OK
> to publicly announce.
>
> W
On 21.04.2014 00:10, Johannes Schindelin wrote:
tests do not pass yet. (I also would like to look into getting the
performance improvement Hannes Sixt achieved by his patch [*1*] into
mingwGitDevEnv's Git installation, too.)
Whoops. Footnote *1*: https://github.com/msysgit/msysgit/commit/a0f5d4
Felipe Contreras writes:
> They should be tested by default.
>
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/Makefile| 14
> --
> t/Makefile | 8 +++-
> .../remote-helpers/test-bzr.s
On Sat, Apr 19, 2014 at 12:23 PM, Michael Haggerty wrote:
> On 04/17/2014 09:46 PM, Ronnie Sahlberg wrote:
>> Change commit.c to use ref transactions for all ref updates.
>>
>> Signed-off-by: Ronnie Sahlberg
>> ---
>> builtin/commit.c | 22 --
>> 1 file changed, 12 insertions
Hi Sebastian,
On Mon, 21 Apr 2014, Sebastian Schuberth wrote:
> On 21.04.2014 00:10, Johannes Schindelin wrote:
>
> > tests do not pass yet. (I also would like to look into getting the
> > performance improvement Hannes Sixt achieved by his patch [*1*] into
> > mingwGitDevEnv's Git installation,
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > They should be tested by default.
> >
> > Signed-off-by: Felipe Contreras
> > ---
> > contrib/remote-helpers/Makefile| 14
> > --
> > t/Makefile | 8 +
Johannes Schindelin wrote:
> Now, clearly you have all the motivation that is needed to get 64-bit
> builds of Git for Windows going, and all the motivation required to make
> sure that the MSVC support of the msysGit project works.
s/msysGit/Git/
Personally I don't see why ideally I shouldn't be
Junio C Hamano writes:
> What I am wondering is if we can do something
> like this:
> ...
Nah, that is a lot more stupid than just doing
> In code:
>
> blame_date_width = strtoul(_("4 years, 11 months ago"), NULL, 10) + 1;
>
> In git.pot:
>
> #. This string is used to te
Felipe Contreras writes:
>> This step needs a bit more work, I am afraid, to at least have these
>> three test scripts follow the same numbering scheme. Especially given
>> that there were recent discussions on allowing a range of tests to
>> be run (or omitted) via notations like "5000,5020,980
On 21.04.2014 00:41, Felipe Contreras wrote:
= Default aliases =
Every single version control tool out there has default aliases (e.g.
co = checkout) except Git.
Every argument against default aliases was basically refuted, yet my
patches went nowhere. And the users still expect these aliases.
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> >> This step needs a bit more work, I am afraid, to at least have these
> >> three test scripts follow the same numbering scheme. Especially given
> >> that there were recent discussions on allowing a range of tests to
> >> be run (or omitted)
Sebastian Schuberth writes:
>> Every argument against default aliases was basically refuted, yet my
>> patches went nowhere. And the users still expect these aliases.
>
> +1 about having default aliases in general, and I'd also add these:
I think it might be OK to implement them as the lowest pr
Sebastian Schuberth wrote:
> On 21.04.2014 00:41, Felipe Contreras wrote:
>
> > = Default aliases =
> >
> > Every single version control tool out there has default aliases (e.g.
> > co = checkout) except Git.
> >
> > Every argument against default aliases was basically refuted, yet my
> > patches
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
wrote:
> I have these aliases as well, except br => b, and cp => pi. 'br' is probably
> better, but not sure as 'cp' which can be confusing.
If by confusing you refer to "cp" to copy files, that's actually what
I like about it: cherry-pick is som
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running in two- or
three-argument mode, construct PS1 to reference a variable that holds
the branch name. Because the s
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> This hook is invoked whenever a branch is updated, either when a branch
> is created or updated with 'git branch', or when it's rebased with 'git
> rebase'. It receives two parameters; the name of the branch, and the
> SHA-1 of the latest commit, addi
On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
> Both bash and zsh subject the value of PS1 to parameter expansion,
> command substitution, and arithmetic expansion. Rather than include
> the raw, unescaped branch name in PS1 when running in two- or
> three-argument mode, constru
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
> wrote:
>
> > I have these aliases as well, except br => b, and cp => pi. 'br' is probably
> > better, but not sure as 'cp' which can be confusing.
>
> If by confusing you re
There doesn't seem to be any reason to keep these remote-helpers in the contrib
area.
Felipe Contreras (3):
remote-helpers: squelch python import exceptions
remote-helpers: move out of contrib
remote-helpers: move tests out of contrib
.gitignore
The remote-helpers in contrib/remote-helpers have proved to work, be
reliable, and stable. It's time to move them out of contrib, and be
distributed by default.
Signed-off-by: Felipe Contreras
---
.gitignore | 2 ++
Makefile
When the python modules are not present we get an unwanted message:
*** prove ***
test-bzr.sh .. Traceback (most recent call last):
File "", line 1, in
File "/usr/local/buildtools/current/sitecustomize/sitecu...
return real_import(name, globals, locals, fromlist, level
They should be tested by default.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/Makefile| 14 --
contrib/remote-helpers/test-hg.sh => t/t5810-remote-hg.sh | 3 +--
.../test-hg-bidi.sh => t/t5811-remote-hg-bidi.sh | 3 +--
.../test
Theodore Ts'o wrote:
> On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
> > On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
> > wrote:
> >
> > > I have these aliases as well, except br => b, and cp => pi. 'br' is
> > > probably
> > > better, but not sure as 'cp' which can b
Ilya Bobyr wrote:
> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> > This hook is invoked whenever a branch is updated, either when a branch
> > is created or updated with 'git branch', or when it's rebased with 'git
> > rebase'. It receives two parameters; the name of the branch, and the
> > SHA-
On 2014-04-21 16:24, Jeff King wrote:
> On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
>
>> Both bash and zsh subject the value of PS1 to parameter expansion,
>> command substitution, and arithmetic expansion. Rather than include
>> the raw, unescaped branch name in PS1 when runn
On 4/21/2014 1:49 PM, Felipe Contreras wrote:
> Ilya Bobyr wrote:
>> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
>>> This hook is invoked whenever a branch is updated, either when a branch
>>> is created or updated with 'git branch', or when it's rebased with 'git
>>> rebase'. It receives two par
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> [...]
>
> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh
> new file mode 100755
> index 000..d921c0e
> --- /dev/null
> +++ b/t/t5408-update-branch-hook.sh
> @@ -0,0 +1,39 @@
> +#!/bin/sh
> +
> +test_description='Test th
On 18. 4. 2014 13:53, Jens Lehmann wrote:
> Am 13.04.2014 00:45, schrieb Ronald Weiss:
>> Allow ignoring submodules (or not) by command line switch, like diff
>> and status do.
>>
>> Git add currently doesn't honor ignore from .gitmodules or .git/config,
>> which is related functionality, however I
Felipe Contreras writes:
> contrib/remote-helpers/test-bzr.sh | 2 +-
> contrib/remote-helpers/test-hg-bidi.sh | 2 +-
> contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--
> contrib/remote-helpers/test-hg.sh |
This reverts commit 88e8f908f2b0c56f9ccf8134d8ff9f689af9cc84.
Caused a usability regression for me and foul language for my coworkers.
In particular, I commonly do a "git log", with results going through
less, find a potentially interesting commit and execute "git show
" from less. This used to
Ilya Bobyr wrote:
> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> > [...]
> >
> > diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh
> > new file mode 100755
> > index 000..d921c0e
> > --- /dev/null
> > +++ b/t/t5408-update-branch-hook.sh
> > @@ -0,0 +1,39 @@
> > +#!/b
Michael Haggerty writes:
> On 04/17/2014 09:46 PM, Ronnie Sahlberg wrote:
>> Switch to using ref transactions in walker_fetch(). As part of the
>> refactoring
>> to use ref transactions we also fix a potential memory leak where in the
>> original code if write_ref_sha1() would fail we would end
Ilya Bobyr wrote:
> Also, most have names that start with either "pre-" or "post-".
> It seems reasonable for both "pre-update-branch" and
> "post-update-branch" to exist.
I don't see what would be the point in that.
> This one would be "pre-update-branch", I guess.
>
> I was also wondering abo
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > contrib/remote-helpers/test-bzr.sh | 2 +-
> > contrib/remote-helpers/test-hg-bidi.sh | 2 +-
> > contrib/remote-helpers/test-hg-hg-git.sh | 4 ++--
> > contrib/remote-helpers/tes
On 4/21/2014 2:15 PM, Felipe Contreras wrote:
> Ilya Bobyr wrote:
>> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
>>> [...]
>>>
>>> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh
>>> new file mode 100755
>>> index 000..d921c0e
>>> --- /dev/null
>>> +++ b/t/t5408-upd
On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> Ilya Bobyr wrote:
>
>> Also, most have names that start with either "pre-" or "post-".
>> It seems reasonable for both "pre-update-branch" and
>> "post-update-branch" to exist.
> I don't see what would be the point in that.
Do you see the point in th
Felipe Contreras writes:
>> Does this change relate to the moving of main scripts, and if so
>> how?
>
> Yes.
>
> Before the scripts were not generated, the shebang was '/usr/bin/env python',
> that means if the user doesn't have 'python' but 'python2' git-remote-hg would
> fail, even if the user
Ilya Bobyr wrote:
> On 4/21/2014 2:15 PM, Felipe Contreras wrote:
> > Ilya Bobyr wrote:
> >> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> >>> [...]
> >>>
> >>> diff --git a/t/t5408-update-branch-hook.sh b/t/t5408-update-branch-hook.sh
> >>> new file mode 100755
> >>> index 000..d921c0e
> >>>
Ilya Bobyr wrote:
> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> > Ilya Bobyr wrote:
> >
> >> Also, most have names that start with either "pre-" or "post-".
> >> It seems reasonable for both "pre-update-branch" and
> >> "post-update-branch" to exist.
> > I don't see what would be the point in t
Ilya Bobyr writes:
> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
>> Ilya Bobyr wrote:
>>
>>> Also, most have names that start with either "pre-" or "post-".
>>> It seems reasonable for both "pre-update-branch" and
>>> "post-update-branch" to exist.
>> I don't see what would be the point in that
On 18. 4. 2014 14:09, Jens Lehmann wrote:
> Am 13.04.2014 00:49, schrieb Ronald Weiss:
>> Allow ignoring submodules (or not) by command line switch, like diff
>> and status do.
>>
>> Git commit honors the 'ignore' setting from .gitmodules or .git/config,
>> but didn't allow to override it from comm
config.mak.uname: provide a way to explicitely request MinGW build.
This is required to perform Linux->MinGW crosscompilation.
---
> Personally I don't see why ideally I shouldn't be able to build upstream Git
> for Windows with mingw without leaving my Linux system.
One day you might be able, bu
Richard Hansen writes:
> Both bash and zsh subject the value of PS1 to parameter expansion,
> command substitution, and arithmetic expansion. Rather than include
> the raw, unescaped branch name in PS1 when running in two- or
> three-argument mode, construct PS1 to reference a variable that hold
I have updated the commit message with some text why I do not think
this change is critical for this case.
I will resend v2 of the patch series in a little while.
On Sat, Apr 19, 2014 at 12:48 PM, Michael Haggerty wrote:
> On 04/17/2014 09:46 PM, Ronnie Sahlberg wrote:
>> Switch to using ref tran
Junio C Hamano writes:
> Richard Hansen writes:
>
>> Both bash and zsh subject the value of PS1 to parameter expansion,
>> command substitution, and arithmetic expansion. Rather than include
>> the raw, unescaped branch name in PS1 when running in two- or
>> three-argument mode, construct PS1 t
Ilya Bobyr wrote:
> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras <
> felipe.contre...@gmail.com> wrote:
> > Ilya Bobyr wrote:
> > > test_expect_success 'setup' "
> > > mkdir -p .git/hooks &&
> > > cat > .git/hooks/update-branch <<-\\EOF &&
> > > #!/bin/sh
> > > echo \$@
Junio C Hamano wrote:
> Ilya Bobyr writes:
>
> > On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> >> Ilya Bobyr wrote:
> >>
> >>> Also, most have names that start with either "pre-" or "post-".
> >>> It seems reasonable for both "pre-update-branch" and
> >>> "post-update-branch" to exist.
> >> I d
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for error.
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 10 ++
refs.c | 9 +++--
refs.h | 10 +
This patch series changes most of the places where the ref functions for
locking and writing refs to instead use the new ref transaction API. There
are still three more places where write_ref_sha1() is called from outside
of refs.c but those all will require more complex work and review so those
ch
Do basic error checking in ref_transaction_create() and make it return
status. Update all callers to check the result of ref_transaction_create()
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 4 +++-
refs.c | 17 +++--
refs.h | 8
3
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/replace.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index b62420a..b91e550 100644
--- a/builtin/replace.c
+++ b/builtin/r
Update ref_transaction_commit to have a single exit path and process onerr
if an error occured during hte commit. This does mean that in case of an error
occuring for UPDATE_REFS_MSG_ON_ERR during the calls to update_ref_lock or
update_ref_write we will log errors from both those functions as well
Change ref_transaction_delete() to do basic error checking and return
status. Update all callers to check the return for ref_transaction_delete()
Signed-off-by: Ronnie Sahlberg
---
builtin/update-ref.c | 5 +++--
refs.c | 15 ++-
refs.h | 8
3 f
Switch to using ref transactions in walker_fetch(). As part of the refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would fail we would end up returning from
the function without free()ing the msg string.
This changes the lockin
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
fast-import.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index fb4738d..466dfe3 100644
--- a/fast-import.c
+++ b/fast-imp
ref_transaction_create|delete|update has no need to modify the sha1
arguments passed to it so it should use const unsigned char* instead
of unsigned char*.
Some functions, such as fast_forward_to(), already have its old/new
sha1 arguments as consts. This function will at some point need to
use ref
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg
---
sequencer.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index bde5f04..fa14ac0 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -272,17 +27
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg
---
builtin/tag.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 40356e3..3c40957 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -488,7
Change commit.c to use ref transactions for all ref updates.
Make sure we pass a NULL pointer to ref_transaction_update if have_old
is false.
Signed-off-by: Ronnie Sahlberg
---
builtin/commit.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/builtin/
Change branch.c to use ref transactions when doing updates.
Signed-off-by: Ronnie Sahlberg
---
branch.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/branch.c b/branch.c
index 660097b..45c7766 100644
--- a/branch.c
+++ b/branch.c
@@ -226,7 +226,7 @@ void c
Change the update_ref helper function to use a ref transaction internally.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index 878948a..e52b6bf 100644
--- a/refs.c
+++ b/refs.c
@@ -3390,
On 2014-04-21 18:33, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Richard Hansen writes:
>>
>>> Both bash and zsh subject the value of PS1 to parameter expansion,
>>> command substitution, and arithmetic expansion. Rather than include
>>> the raw, unescaped branch name in PS1 when runnin
Felipe Contreras writes:
> ... there are _already_ hooks without pre/post.
Like commit-msg? Yes, it would have been nicer if it were named
verify-commit-message or something.
Old mistakes are harder to change because of inertia. It is not a
good excuse to knowingly make a new mistake to add n
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running in two- or
three-argument mode, construct PS1 to reference a variable that holds
the branch name. Because the s
Marat Radchenko wrote:
> config.mak.uname: provide a way to explicitely request MinGW build.
> This is required to perform Linux->MinGW crosscompilation.
> ---
>
> > Personally I don't see why ideally I shouldn't be able to build upstream Git
> > for Windows with mingw without leaving my Linux sys
On Fri, Apr 18, 2014 at 4:36 PM, Junio C Hamano wrote:
> "Luis R. Rodriguez" writes:
>
>> I think ultimately this reveals that given that tags *can* be
>> arbitrary and subjective,...
>
> Yes; see the part at the bottom.
>
>>> Commit A can be described in terms of both v3.4 and v9.0,
>>
>> And in
On 18 April 2014 10:36, wrote:
> "Like the $GIT_DIR/info/exclude file, gitignore files specify intentionally
> untracked files that Git should ignore. The difference is that files matched
> by a pattern in a gitignore file will be untracked for all users of the
> repository."
As a data point, I
From: "Luis R. Rodriguez"
This saves us a few branches when RUN_SETUP is set up.
Signed-off-by: Luis R. Rodriguez
---
git.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git.c b/git.c
index 9efd1a3..7780572 100644
--- a/git.c
+++ b/git.c
@@ -290,7 +290,7 @@ static int run
Congrats everyone who was successful in being picked for this year's GSoC.
Fabian with "Line options for git rebase --interactive" [0]
Brian Gesiak with "Unify and Refactor Temporary File Handling" [1]
Tanay Abhra with "Git configuration API improvements" [2]
I look forward to seeing how you go!
On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:
> BTW, in my experience people tend to stick to predefined aliases instead of
> redefining them to something (completely) different. This means that having
> default aliases will very likely enable one to use the same short comman
Thank you!
I'm very excited to be participating in this year's GSoC. Google
recommends that students use the next few weeks to get to know their
mentors, read documentation, and get up to speed to begin working on
their projects. Students have also received instructions on submitting
tax forms and
Hi,
I would like to request your participation in a survey on
Open Source Organizational Culture,
which will provide valuable insight into how Open Source projects are run, how
their participants act, how they might change going forward, and how particular
Open Source projects compare with
Hi,
I would like to request your participation in a survey on
Open Source Organizational Culture,
which will provide valuable insight into how Open Source projects are run, how
their participants act, how they might change going forward, and how particular
Open Source projects compare with
On Mon, Apr 21, 2014 at 05:38:34PM -0700, Luis R. Rodriguez wrote:
> [0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep
> ^commit | wc -l
> 24878
> [1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep
> ^commit | wc -l
> 13106
> [2] mcgrof@ergon ~/linux (git::maste
On 4/21/2014 9:45 PM, Marius Storm-Olsen wrote:
> I would like to request your participation in a survey on
> Open Source Organizational Culture,
> which will provide valuable insight into how Open Source projects are
> run, how their participants act, how they might change going forward,
> an
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
> It's annoying to see the prompt:
>
> Hit return to start merge resolution tool (foo):
>
> Every time the user does 'git mergetool' even i
On Sun, Apr 20, 2014 at 07:24:20PM -0500, Felipe Contreras wrote:
> It's similar to the default, except that the other windows are hidden.
> This ensures that removed/added colors are still visible on the main
> merge window, but the other windows not visible.
>
> Specially useful with merge.confl
On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
> = Reject non-fast-forward pulls by default =
>
> Many new-comers end up making merges by mistake when they pull because
> they don't understand what is a non-fast-forward and what they should
> actually be doing. Most people, even
brian m. carlson wrote:
> On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:
> > BTW, in my experience people tend to stick to predefined aliases instead of
> > redefining them to something (completely) different. This means that having
> > default aliases will very likely enable
Marius Storm-Olsen wrote:
> On 4/21/2014 9:45 PM, Marius Storm-Olsen wrote:
> > I would like to request your participation in a survey on
> > Open Source Organizational Culture,
> > which will provide valuable insight into how Open Source projects are
> > run, how their participants act, how t
David Aguilar wrote:
> On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
> > = Reject non-fast-forward pulls by default =
> >
> > Many new-comers end up making merges by mistake when they pull because
> > they don't understand what is a non-fast-forward and what they should
> > act
On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote:
> [Cc:ing Charles in case he has an opinion, this behavior dates back to the
> original MT]
>
> On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
> > It's annoying to see the prompt:
> >
> > Hit return to start merg
On 4/21/2014 3:24 PM, Felipe Contreras wrote:
> Ilya Bobyr wrote:
>> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras <
>> felipe.contre...@gmail.com> wrote:
>>> Ilya Bobyr wrote:
test_expect_success 'setup' "
mkdir -p .git/hooks &&
cat > .git/hooks/update-branch <<-\\EO
Charles Bailey wrote:
> On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote:
> > [Cc:ing Charles in case he has an opinion, this behavior dates back to the
> > original MT]
> >
> > On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
> > > It's annoying to see the prompt:
>
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> [...]
>
> diff --git a/branch.c b/branch.c
> index 660097b..c2058d1 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -4,6 +4,7 @@
> #include "refs.h"
> #include "remote.h"
> #include "commit.h"
> +#include "run-command.h"
>
> struct tracking {
>
On 4/21/2014 1:49 PM, Felipe Contreras wrote:
> Ilya Bobyr wrote:
>> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
>>> This hook is invoked whenever a branch is updated, either when a branch
>>> is created or updated with 'git branch', or when it's rebased with 'git
>>> rebase'. It receives two par
Ilya Bobyr wrote:
> On 4/21/2014 3:24 PM, Felipe Contreras wrote:
> > Ilya Bobyr wrote:
> >> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras <
> >> felipe.contre...@gmail.com> wrote:
> >>> Ilya Bobyr wrote:
> test_expect_success 'setup' "
> mkdir -p .git/hooks &&
> cat
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
>
> This is what I get when a tool is not working:
>
> Documentation/config.txt seems unchanged.
> Was the merge successful? [y/n]
Does this happen now even with merge tools for which we do trust the
exit code? If so, my origi
93 matches
Mail list logo
