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 ago).
And for other locale,
Command `git blame --date relative` aligns the date field with a
fixed-width (defined by blame_date_width), and if time_str is shorter
than that, it adds spaces for padding. But there are two bugs in the
following codes:
time_len = strlen(time_str);
...
memset(time_buf +
Changes since v2:
* Fixed typos in commit log 1/2. Thanks, Eric.
* With the help of Junio, write a helper to get suitable blame_date_width.
Jiang Xin (2):
bugfix: fix broken time_buf paddings for git-blame
blame: use a helper to get suitable blame_date_width
builtin/blame.c | 85
On Sun, Apr 20, 2014 at 10:23 PM, Felipe Contreras
felipe.contre...@gmail.com 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
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 hughmil...@chevron.com 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
Jiang Xin worldhello@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
On Sun, Apr 20, 2014 at 1:42 PM, Richard Hansen rhan...@bbn.com 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
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*:
Felipe Contreras felipe.contre...@gmail.com writes:
They should be tested by default.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/Makefile| 14
--
t/Makefile
On Sat, Apr 19, 2014 at 12:23 PM, Michael Haggerty mhag...@alum.mit.edu 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 sahlb...@google.com
---
builtin/commit.c | 22 --
1
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, too.)
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
They should be tested by default.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/Makefile| 14
--
t/Makefile
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 gits...@pobox.com 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
Felipe Contreras felipe.contre...@gmail.com 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
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
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Sebastian Schuberth sschube...@gmail.com 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
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 went nowhere.
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
felipe.contre...@gmail.com 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
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
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,
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, construct
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
felipe.contre...@gmail.com 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
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 felipe.contre...@gmail.com
---
.gitignore | 2 ++
When the python modules are not present we get an unwanted message:
*** prove ***
test-bzr.sh .. Traceback (most recent call last):
File string, line 1, in module
File /usr/local/buildtools/current/sitecustomize/sitecu...
return real_import(name, globals, locals,
They should be tested by default.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
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
felipe.contre...@gmail.com wrote:
I have these aliases as well, except br = b, and cp = pi. 'br' is
probably
better, but not sure as 'cp'
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-1 of the
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 running in
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 parameters;
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 the
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'd like to
Felipe Contreras felipe.contre...@gmail.com 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
commit from less. This used
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 @@
+#!/bin/sh
+
Michael Haggerty mhag...@alum.mit.edu 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
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 about git reset.
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com 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 ++--
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-update-branch-hook.sh
@@
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 the other hooks
Felipe Contreras felipe.contre...@gmail.com 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,
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
--- /dev/null
+++
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 that.
Do you see the
Ilya Bobyr ilya.bo...@gmail.com 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 command line.
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, but
Richard Hansen rhan...@bbn.com 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
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 mhag...@alum.mit.edu wrote:
On 04/17/2014 09:46 PM, Ronnie Sahlberg wrote:
Switch
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com 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
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 \$@ .git/update-branch.args
Junio C Hamano wrote:
Ilya Bobyr ilya.bo...@gmail.com 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
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 sahlb...@google.com
---
builtin/update-ref.c | 10 ++
refs.c | 9 +++--
refs.h
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
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 sahlb...@google.com
---
builtin/update-ref.c | 4 +++-
refs.c | 17 +++--
refs.h
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
---
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 sahlb...@google.com
---
builtin/update-ref.c | 5 +++--
refs.c | 15 ++-
refs.h
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
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
---
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
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
+++
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
+++
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 sahlb...@google.com
---
builtin/commit.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
Change branch.c to use ref transactions when doing updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
@@
Change the update_ref helper function to use a ref transaction internally.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
On 2014-04-21 18:33, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com 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
Felipe Contreras felipe.contre...@gmail.com 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
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
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 system.
On Fri, Apr 18, 2014 at 4:36 PM, Junio C Hamano gits...@pobox.com wrote:
Luis R. Rodriguez mcg...@do-not-panic.com 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
On 18 April 2014 10:36, a...@bellandwhistle.net 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.
From: Luis R. Rodriguez mcg...@suse.com
This saves us a few branches when RUN_SETUP is set up.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
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
@@
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!
[0]
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
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::master)$
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,
and
[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 if
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
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 one to
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 they
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
actually be
88 matches
Mail list logo
