Signed-off-by: Charles Bailey
---
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 +
1 file changed,
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
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
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.
Si
Ah, I missed that dcommit entails a rebase. I thought it just
complained if one needed to take place, so I always do a rebase
"manually" before dcommit. I agree, and would not want my other refs
moved around if the change is that drastic.
The workaround is not so bad anyway: git reset on the left-
Junio C Hamano writes:
> The sentence lacked the necessary verb.
No, it didn't.
> Signed-off-by: Junio C Hamano
> ---
> Documentation/CodingGuidelines | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> ind
Junio C Hamano writes:
> The point immediately before it is about having SP after the control
> keyword. Follow it.
>
> Signed-off-by: Junio C Hamano
> ---
> Documentation/CodingGuidelines | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/CodingGuidelines b
Junio C Hamano writes:
> Signed-off-by: Junio C Hamano
> ---
> Documentation/CodingGuidelines | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 1e0c4cf..d72e912 100644
> --- a/Documentation/CodingGuideli
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
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
>> reviewed the code), but when we want to just update our local branches,
>> we always want fast-fo
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
David Kastrup writes:
> Junio C Hamano writes:
>
>> The sentence lacked the necessary verb.
>
> No, it didn't.
>
>> Signed-off-by: Junio C Hamano
>> ---
>> Documentation/CodingGuidelines | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/CodingGuidelines
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
David Kastrup 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 2.4 "
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
>>>
David Kastrup 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 g
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_RAW
Junio C Hamano writes:
> David Kastrup 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 the cond
From: Jeremy Morton
> 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:
>>> Made-on
Charles Bailey 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
> +#endif
> +
> +#if
Junio C Hamano writes:
> Charles Bailey 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 _
Junio C Hamano 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 big or l
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
> >> reviewed the code), but when we want to just update our local
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 developer-r
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 maintenance-
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 fet
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`. Ther
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 maintenan
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 ru
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 h
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 ref
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 fo
Change s_update_ref to use a ref transaction for the ref update.
Signed-off-by: Ronnie Sahlberg
---
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
--- a/builtin/fetch.c
+++ b/bu
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 code
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 c
Change rename_ref to use a single transaction to perform the ref rename.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 73 ++
1 file changed, 20 insertions(+), 53 deletions(-)
diff --git a/refs.c b/refs.c
index eb75927..810a4db 10064
Signed-off-by: Ronnie Sahlberg
---
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 *dir);
-static int w
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
---
refs.c| 3 +++
t/t3200-branch.sh | 2 +-
2 files change
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 as
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
---
refs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 8d82742..51cd41e 100644
--- a/refs.c
+++
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
u
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 w
Wrap all the ref updates inside a transaction to make the update atomic.
Signed-off-by: Ronnie Sahlberg
---
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 c323081..d580176 100
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
---
refs.c | 37 +
1 file changed, 33 inser
No external users call write_ref_sha1 any more so lets declare it static.
Signed-off-by: Ronnie Sahlberg
---
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
@@ -251,6 +251,8 @@
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
---
builtin/update
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
---
branch.c | 6 +++---
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 Sahlberg
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
---
refs.c | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
No external callers reference lock_ref_sha1 any more so lets declare it static.
Signed-off-by: Ronnie Sahlberg
---
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
+++ b/refs.c
@@ -2130,7 +2130
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
---
refs.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(
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
---
refs.c | 22 +++---
refs.h | 2 ++
2
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
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 7e58693..e1f919
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
---
refs.c | 35 +--
1 file changed, 9 insertions(+), 26 de
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 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 t
Signed-off-by: Ronnie Sahlberg
---
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 dump_tags(void)
{
Update replace.c to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
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
--- a/builtin/replace.c
+++ b/builtin/
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg
---
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
+++ b/builtin/tag.c
@@ -54
Change the update_ref helper function to use a ref transaction internally.
Signed-off-by: Ronnie Sahlberg
---
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
+++ b/refs.c
@@ -3396,11
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg
---
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
+++ b/sequencer.c
@@ -272
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, 10 insertions(+), 13 deletions(-)
diff --git a/builtin/
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
---
builtin/update
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 compl
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
---
builtin/update-ref.c | 3 +--
refs.c | 22 +++---
refs.h
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 f
Make ref_update_reject_duplicates return any error that occurs through a
new strbuf argument.
Signed-off-by: Ronnie Sahlberg
---
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
+++ b/refs.c
@@ -3393,6 +339
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
---
builtin/update-ref.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/update-ref.c b/b
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
---
builtin/u
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
---
refs.c | 9 ++---
1 file changed, 6 insertions(+),
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg
---
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
--- a/fast-import.c
+++ b/fast-impo
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 vers
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 doe
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 IO:
From: "Marc Branchaud"
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 pretty
close to
Oops..
From: "Philip Oakley"
From: "Marc Branchaud"
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
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 uns
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
Don't you often complain about submitters referencing a discussion
in a commit message without providing some context or
On Wed, Apr 30, 2014 at 02:34:59PM -0700, Junio C Hamano wrote:
> Linus Torvalds 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 the actual c
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/
plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\)
plugins/reviewnotes\ \(v1.0-rc1-8-
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/
> plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\)
> plug
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;
> > - unsign
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;
>>
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 runni
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 …'). Th
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
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 maintenan
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 l
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 th
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 configu
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 1
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.
Signed-off-by: Felipe C
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.
To
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
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
sugg
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-ref
1 - 100 of 119 matches
Mail list logo
