Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
The endian detection added in 7e3dae494 isn't sufficient for the Solaris
Studio compilers. This adds some fallback logic which works for Solaris
but would also work for AIX and Linux if it were needed.
compat/bswap.h | 21
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?
Nothing. Everything. It depends.
It depends on what? I don't see how a fast-forward `git pull`
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?
Nothing. Everything. It depends.
It depends on what? I don't
Using preprocessor constants rather than hardcoded numbers is considered a
good programming practice. Provide two constants, GIT_OID_RAWSZ and
GIT_OID_HEXSZ, which are the lengths of an SHA-1 object name in bytes and
hex digits, respectively. These names are the same as those used by
libgit2.
Junio C Hamano gits...@pobox.com writes:
The sentence lacked the necessary verb.
No, it didn't.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/CodingGuidelines | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/CodingGuidelines
Junio C Hamano gits...@pobox.com writes:
The point immediately before it is about having SP after the control
keyword. Follow it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/CodingGuidelines | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Junio C Hamano gits...@pobox.com writes:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/CodingGuidelines | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1e0c4cf..d72e912 100644
---
On 14-05-01 05:46 AM, 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?
Nothing. Everything. It depends.
It depends on what? I
Felipe Contreras felipe.contre...@gmail.com 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
reviewed the code), but when we want to just update our local branches,
we
Hi,
brian m. carlson wrote:
--- a/object.h
+++ b/object.h
[...]
@@ -49,7 +56,7 @@ struct object {
unsigned used : 1;
unsigned type : TYPE_BITS;
unsigned flags : FLAG_BITS;
- unsigned char sha1[20];
+ unsigned char sha1[GIT_OID_RAWSZ];
Maybe my brain has been
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
The sentence lacked the necessary verb.
No, it didn't.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/CodingGuidelines | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to the latest from the main repo.
git pull --ff-only
git pull --no-ff developer-remote topic-branch
git
David Kastrup d...@gnu.org writes:
- We do not write the noiseword function in front of shell
s/noiseword/bashism/
That is outside the scope of this patch, but since you brought it
up...
I did consider between noiseword and bashism when I wrote this part,
and decided against bashism. XCU
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to the latest from the main repo.
git pull --ff-only
git pull
David Kastrup d...@gnu.org writes:
- - We try to avoid assignments inside if().
+ - We try to avoid assignments inside if () condition.
That's not grammatical.
OK,
... inside the condition part of an if () statement.
then?
--
To unsubscribe from this list: send the line unsubscribe
Jonathan Nieder wrote:
brian m. carlson wrote:
--- a/object.h
+++ b/object.h
[...]
@@ -49,7 +56,7 @@ struct object {
unsigned used : 1;
unsigned type : TYPE_BITS;
unsigned flags : FLAG_BITS;
-unsigned char sha1[20];
+unsigned char sha1[GIT_OID_RAWSZ];
Maybe my
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
- - We try to avoid assignments inside if().
+ - We try to avoid assignments inside if () condition.
That's not grammatical.
OK,
... inside the condition part of an if () statement.
then?
... in
From: Jeremy Morton ad...@game-point.net
On 29/04/2014 12:47, Christian Couder wrote:
Also, if there were no current branch name because you're committing
in a
detached head state, it would be nice if you could have some logic to
determine that, and instead write the trailer as:
Charles Bailey cbaile...@bloomberg.net writes:
#if !defined(__BYTE_ORDER)
+/* Known to be needed on Solaris but designed to potentially more portable */
+
+#if !defined(__BIG_ENDIAN)
+#define __BIG_ENDIAN 4321
+#endif
+
+#if !defined(__LITTLE_ENDIAN)
+#define __LITTLE_ENDIAN 1234
Junio C Hamano gits...@pobox.com writes:
Charles Bailey cbaile...@bloomberg.net writes:
#if !defined(__BYTE_ORDER)
+/* Known to be needed on Solaris but designed to potentially more portable
*/
+
+#if !defined(__BIG_ENDIAN)
+#define __BIG_ENDIAN 4321
+#endif
+
+#if
Junio C Hamano gits...@pobox.com writes:
Just a thought.
I am wondering if you may want to go the other way around. That is,
instead of using we have byte-order, big and little and the way to
determine endianness is to see byte-order matches which of the
latter two, use there may be either
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com 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
reviewed the code), but when we want to just
Marc Branchaud wrote:
What's more, it seems to me that the only real advantage git pull
provides here is a less typing compared to the non-pull equivalent:
git fetch main-repo
git checkout main-repo/maintenance-branch
git fetch developer-remote
git merge --no-ff
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 reviewed the code), but when we want to just update our local
branches, we always want fast-forward:
git checkout
On 14-05-01 03:22 PM, Felipe Contreras wrote:
Marc Branchaud wrote:
What's more, it seems to me that the only real advantage git pull
provides here is a less typing compared to the non-pull equivalent:
git fetch main-repo
git checkout main-repo/maintenance-branch
git fetch
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 communicate clearly to him that he should be running
`git merge --no-ff`. There's
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to
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
that they give users a way to set a finger-breaking configuration that
makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who
compulsively run
On 14-05-01 02:30 PM, W. Trevor King wrote:
I find a local branch useful to mark the amount of the upstream branch
that I've reviewed. The reflog helps a bit, but I may go several
fetches between reviews. For newbies, I recommend avoiding detached
HEADs, where possible, so they don't have
Allow ref_transaction_free to be called with NULL and in extension allow
ref_transaction_rollback to be called for a NULL transaction.
This allows us to write code that will
if ( (!transaction ||
ref_transaction_update(...)) ||
(ref_transaction_commit(...) !(transaction = NULL))
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
Add a new flag REF_ISPACKONLY that we can use in ref_transaction_delete.
This flag indicates that the ref does not exist as a loose ref andf only as
a packed ref. If this is the case we then change the commit code so that
we skip taking out a lock file and we skip calling delete_ref_loose.
Check
Change s_update_ref to use a ref transaction for the ref update.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/fetch.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a93c893..b41d7b7 100644
---
Change ref_transaction_commit so that it does not free the transaction.
Instead require that a caller will end a transaction by either calling
ref_transaction_rollback or ref_transaction_free.
By having the transaction object remaining valid after _commit returns allows
us to write much nicer
Move the check for check_refname_format from lock_any_ref_for_update
to lock_ref_sha1_basic. At some later stage we will get rid of
lock_any_ref_for_update completely.
This leaves lock_any_ref_for_updates as a no-op wrapper which could be removed.
But this wrapper is also called from an external
Change rename_ref to use a single transaction to perform the ref rename.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 73 ++
1 file changed, 20 insertions(+), 53 deletions(-)
diff --git a/refs.c b/refs.c
index
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/refs.c b/refs.c
index 810a4db..e59bc18 100644
--- a/refs.c
+++ b/refs.c
@@ -251,8 +251,6 @@ struct ref_entry {
};
static void read_loose_refs(const char *dirname, struct ref_dir
This means that most loose refs will no longer be present after the rename
which triggered a test failure since it assumes the file for an unrelated
ref would still be present after the rename.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c| 3 +++
t/t3200-branch.sh |
Change store_updated_refs to use a single ref transaction for all refs that
are updated during the fetch. This makes the fetch more atomic when update
failures occur.
Since ref update failures will now no longer occur in the code path for
updating a single ref in s_update_ref, we no longer have
Skip using the lock_any_ref_for_update wrapper and call lock_ref_sha1_basic
directly from the commit function.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 8d82742..51cd41e
In s_update_ref there are two calls that when they fail we return an error
based on the errno value. In particular we want to return a specific error
if ENOTDIR happened. Both these functions do have failure modes where they
may return an error without updating errno, in which case a previous and
Allow passing a list of refs to ckip checking to name_conflict_fn.
There are some conditions where we want to allow a temporary conflict and skip
checking those refs. For example if we have a transaction that
1, guarantees that m is a packed refs and there is no loose ref for m
2, the transaction
Wrap all the ref updates inside a transaction to make the update atomic.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/receive-pack.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index
Track the status of a transaction in a new status field. Check the field for
sanity, i.e. that status must be OPEN when _commit/_create/_delete or
_update is called or else die(BUG:...)
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 37 +
1
No external users call write_ref_sha1 any more so lets declare it static.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 4 +++-
refs.h | 3 ---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index fcbdf9b..020eadf 100644
--- a/refs.c
+++ b/refs.c
Change ref_transaction_delete() to do basic error checking and return
status. Update all callers to check the return for ref_transaction_delete()
There are currently no conditions in _delete that will return error but there
will be in the future.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Change the reference transactions so that we pass the reflog message
through to the create/delete/update function instead of the commit message.
This allows for individual messages for each change in a multi ref
transaction.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
branch.c
We have to free the transaction before returning in the early check for
'return early if number of updates == 0' or else the following code would
create a memory leak with the transaction never being freed :
t = ref_transaction_begin()
ref_transaction_commit(t)
Signed-off-by: Ronnie
Since we now only call update_ref_lock with onerr==QUIET_ON_ERR we no longer
need this function and can replace it with just calling lock_any_ref_for_update
directly.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 30 ++
1 file changed, 6
No external callers reference lock_ref_sha1 any more so lets declare it static.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 +-
refs.h | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 020eadf..a82d6ba 100644
--- a/refs.c
+++
Change delete_ref to use a ref transaction for the deletion. At the same time
since we no longer have any callers of repack_without_ref we can now delete
this function.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 31 ++-
1 file changed, 10
Change prune_ref to delete the ref using a ref transaction. To do this we also
need to add a new flag REF_ISPRUNING that will tell the transaction that we
do not want to delete this ref from the packed refs.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 22
lock_ref_sha1 was only called from one place in refc.c and only provided
a check that the refname was sane before adding back the initial refs/
part of the ref path name, the initial refs/ that this caller had already
stripped off before calling lock_ref_sha1.
Signed-off-by: Ronnie Sahlberg
We call read_ref_full with a pointer to flags from rename_ref but since
we never actually use the returned flags we can just pass NULL here instead.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
Since we only call update_ref_write from a single place and we only call it
with onerr==QUIET_ON_ERR we can just as well get rid of it and just call
write_ref_sha1 directly.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 35 +--
1 file changed, 9
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 create_branch to use a ref transaction when creating the new branch.
ref_transaction_create will check that the ref does not already exist and fail
otherwise meaning that we no longer need to keep a lock on the ref during the
setup_tracking. This simplifies the code since we can now do the
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
fast-import.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 3e356da..5587cf6 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1736,15 +1736,22 @@ static void
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/replace.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index b62420a..b037b29 100644
---
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/tag.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index f344002..1cf5650 100644
--- a/builtin/tag.c
+++
Change the update_ref helper function to use a ref transaction internally.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 0a4e28e..563f336 100644
--- a/refs.c
+++
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
sequencer.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 0a80c58..9282a12 100644
--- a/sequencer.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, 10 insertions(+), 13 deletions(-)
Do basic error checking in ref_transaction_create() and make it return
status. Update all callers to check the result of ref_transaction_create()
There are currently no conditions in _create that will return error but there
will be in the future.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
This patch series is based on next and expands on the transaction API. It
converts all ref updates, inside refs.c as well as external, to use the
transaction API for updates. This makes most of the ref updates to become
atomic when there are failures locking or writing to a ref.
This version
Since all callers now use QUIET_ON_ERR we no longer need to provide an onerr
argument any more. Remove the onerr argument from the ref_transaction_commit
signature.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/update-ref.c | 3 +--
refs.c | 22
Add a strbuf argument to _commit so that we can pass an error string back to
the caller. So that we can do error logging from the caller instead of from
_commit.
Longer term plan is to first convert all callers to use onerr==QUIET_ON_ERR
and craft any log messages from the callers themselves and
Make ref_update_reject_duplicates return any error that occurs through a
new strbuf argument.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 64e8feb..21a147b 100644
--- a/refs.c
+++
Call ref_transaction_commit with QUIET_ON_ERR and use the strbuf that is
returned to print a log message if/after the transaction fails.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/update-ref.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for error.
There are currently no conditions in _update that will return error but there
will be in the future.
Signed-off-by: Ronnie Sahlberg
Change update_ref_write to also update an error strbuf on failure.
This makes the error available to ref_transaction_commit callers if the
transaction failed due to update_ref_sha1/write_ref_sha1 failures.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 9 ++---
1 file
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
fast-import.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 6707a66..79d219b 100644
---
On 05/01/14 20:05, Jonathan Nieder wrote:
Hi,
Hi,
Matthias-Christian Ott wrote[1]:
git send-email uses Net::SMTP connections that use STARTTLS. Net::SMTP
does not support IPv6. I patched Net:SMTP to use IO::Socket::INET6 and
it worked.
Thanks for reporting.
1. What version of
Hi,
Steffen Ullrich wrote:
git-send-mail does not use Net::SMTP directly for SSL support, but:
- for direct connections (port 465) it uses Net::SMTP::SSL which just
replaces the superclass if Net::SMTP with IO::Socket::SSL and thus
implicitly supports IPv6 (because IO::Socket::SSL does)
Hi,
Net::SMTP does neither supports SSL nor IPv6.
git-send-mail does not use Net::SMTP directly for SSL support, but:
- for direct connections (port 465) it uses Net::SMTP::SSL which just
replaces the superclass if Net::SMTP with IO::Socket::SSL and thus
implicitly supports IPv6 (because
From: Marc Branchaud marcn...@xiplink.com
Sent: Wednesday, April 30, 2014 8:45 PM
[...]
I don't think we'll ever be able to create a One Git Pull To Rule
Them All.
At best we'll end up with something with enough knobs that it could be
configured to work in most workflows (I think we're actually
Oops..
From: Philip Oakley philipoak...@iee.org
From: Marc Branchaud marcn...@xiplink.com
Sent: Wednesday, April 30, 2014 8:45 PM
[...]
I don't think we'll ever be able to create a One Git Pull To Rule
Them All.
At best we'll end up with something with enough knobs that it could
be
configured
On Thu, May 01, 2014 at 10:51:19AM -0700, Junio C Hamano wrote:
If you want to fix something here, do s/judgement/judgment/ instead.
That too.
FWIW, neither is outright wrong; it is an America/British variation, and
apparently dictionaries disagree on which is preferred.
-Peff
--
To
On Wed, Apr 30, 2014 at 02:45:11PM -0700, Junio C Hamano wrote:
See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
Signed-off-by: Junio C Hamano gits...@pobox.com
Don't you often complain about submitters referencing a discussion
in a commit message without providing
On Wed, Apr 30, 2014 at 02:34:59PM -0700, Junio C Hamano wrote:
Linus Torvalds torva...@linux-foundation.org writes:
I just got a comment saying that
git commit --amend --date=now
doesn't work. I replied that you can use
--date=$(date)
Offhand without double-checking
When I use zsh tab-completion to complete the submodule name in 'git
submodule init', I get more than I expected.
From the gerrit repository (which has plugins):
$ git submodule init plugins/TAB
plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\)
plugins/reviewnotes\
Hi,
Phil Hord wrote:
When I use zsh tab-completion to complete the submodule name in 'git
submodule init', I get more than I expected.
Is this using zsh's native tab-completion (i.e., not the tab
completion bundled with git)? There might have been a change there.
Another place to look for
Phil Hord wrote:
When I use zsh tab-completion to complete the submodule name in 'git
submodule init', I get more than I expected.
From the gerrit repository (which has plugins):
$ git submodule init plugins/TAB
plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\)
On Thu, May 01, 2014 at 10:20:07AM -0700, Jonathan Nieder wrote:
Hi,
brian m. carlson wrote:
--- a/object.h
+++ b/object.h
[...]
@@ -49,7 +56,7 @@ struct object {
unsigned used : 1;
unsigned type : TYPE_BITS;
unsigned flags : FLAG_BITS;
- unsigned char sha1[20];
brian m. carlson wrote:
On Thu, May 01, 2014 at 10:20:07AM -0700, Jonathan Nieder wrote:
What happened to the
struct object_id {
unsigned char id[20];
};
...
struct object {
...
struct object_id id;
};
idea?
There
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 communicate clearly to him that he should be running
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
that they give users a way to set a finger-breaking configuration that
makes pull a no-op (or slows it down, like 'rm -i …'). Then
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 unsubscribe git in
the body of a
Philip Oakley wrote:
The point that there is no easy solution to an updated default pull
action that is right for everybody, straight out of the box, I think is
now fairly obvious, a summarised by Marc. I certainly avoid pull.
Yes, I avoid it too, and quite a lot of people.
My 'solution',
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to
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 list: send the
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 feature branches with a cover-letter
explaination in
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
that they give users a way to set a finger-breaking configuration
And branch.$name.pullmode.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5505-remote.sh | 2 +-
t/t5520-pull.sh | 54 +++---
2 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/t/t5505-remote.sh
Also 'branch.name.rebase' to 'branch.name.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.
Signed-off-by:
NOTE: Added a commit to throw a warning before the final switch.
It is very typical for Git newcomers to inadvertently create merges and worst:
inadvertently pushing them. This is one of the reasons many experienced users
prefer to avoid 'git pull', and recommend newcomers to avoid it as well.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
+++
It is very typical for Git newcomers to inadvertently create merges and
worst; inadvertently pushing them. This is one of the reasons many
experienced users prefer to avoid 'git pull', and recommend newcomers to
avoid it as well.
To avoid these problems and keep 'git pull' useful, it has been
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
To prepare our uses for the upcoming changes we should warn them and let
them know that they will need to specify a merge or a rebase in the
future (when a non-fast-forward situation arises). Also, let them know
we fallback to 'git pull --merge', so when the obsoletion of this mode
comes, they
1 - 100 of 116 matches
Mail list logo
