Andreas Krey writes:
> On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote:
> ...
>> What the gibbins? I don't even use git pull.
>
> I do, but I watch for the fast-forward message
> and undo as appropriate.
>
>> I use git fetch, and then, depending on my needs, I rebase or merge.
>
> I woul
On Wed, Apr 30, 2014 at 12:54:15PM -0700, Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
> > On 30.04.2014 20:36, Junio C Hamano wrote:
> >
> >> I am not intimate with the msysgit developer community, and I do not
> >> know if it is appropriate for me to respond with a
> >>
> >>Does th
On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote:
...
> What the gibbins? I don't even use git pull.
I do, but I watch for the fast-forward message
and undo as appropriate.
> I use git fetch, and then, depending on my needs, I rebase or merge.
I wouldn't mind that, but I have a century o
This is the error message git-apply emits in this case:
error: cannot apply binary patch to '' without full index line
error: : patch does not apply
Cheers,
Tolga
Any feedback is appreciated.
Cheers,
Tolga
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
On Sat, 2014-05-03 at 07:52 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 6:14 AM, wrote:
> > The index format change might be less important with the split index;
> > I haven't investigated that since at the time I wrote these patches,
> > it didn't exist.
>
> This is the worst case scenari
David Turner wrote:
> On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> > dturner@ wrote:
> > > Test repository 1: Linux
> > >
> > > Linux is about 45k files in 3k directories. The average length of a
> > > filename is about 32 bytes.
> > >
> > > Git status timing:
> > > no watchman:
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> dturner@ wrote:
> > Test repository 1: Linux
> >
> > Linux is about 45k files in 3k directories. The average length of a
> > filename is about 32 bytes.
> >
> > Git status timing:
> > no watchman: 125ms
> > watchman: 90ms
>
> That's v
Jeff King writes:
> On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
>
>> Junio C Hamano wrote:
>> > If we step back a bit, because we are forcing him to differentiate
>> > these two pulls in his mental model anyway, perhaps it may help
>> > people (both new and old) if we had a
On Sat, May 3, 2014 at 6:14 AM, wrote:
> The index format change might be less important with the split index;
> I haven't investigated that since at the time I wrote these patches,
> it didn't exist.
This is the worst case scenario of "git status" on webkit.git (182k
files, path name 74 byte lo
These have been stable and widely used for quite a long time, they even
have tests outside of the contrib area, and most distributions ship
them, so they can be considered part of the core already.
Let's move them out of contrib and install them by default.
Signed-off-by: Felipe Contreras
---
M
On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > > that are already using the current 'git pull' incorrectly.
> > >
> > > If you are going to train them to use a configuratio
On 2014-05-02 17:12, Felipe Contreras wrote:
> Richard Hansen wrote:
>> Should branch.autosetuprebase be replaced with a new
>> branch.autosetupmode setting?
>
> Maybe. But if so, I think that should be done in another series.
> Otherwise we'll never have a chance to change anything.
Sure.
>>>
Jeff King wrote:
> On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:
>
> > They can do:
> >
> > % git pull origin master
> >
> > That shouldn't revese the bases.
>
> Then they have to remember to do that every time, no? That seems a
> little error-prone versus setting a config o
Philip Oakley wrote:
> From: "Felipe Contreras"
> > So? No defaults can please absolutely everyone, the best anybody can
> > do is try to please the majority of people, and merging
> > fast-forwards only does that.
>
> That assumes that doing something is better than doing nothing,
When doing so
dturner@ wrote:
> Test repository 1: Linux
>
> Linux is about 45k files in 3k directories. The average length of a
> filename is about 32 bytes.
>
> Git status timing:
> no watchman: 125ms
> watchman: 90ms
That's very interesting. Do you get similar improvements when doing
something similar in
The most sigificant patch uses Facebook's watchman daemon[1] to monitor
the repository work tree for changes. This makes allows git status
to avoid traversing the entire work tree to find changes.
This change requires libwatchman[2], a client library that I wrote for
watchman.
While making the w
From: David Turner
Signed-off-by: David Turner
---
builtin/grep.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 69ac2d8..e9fe040 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -355,15 +355,25 @@ static void run_pag
Hi,
Philip Oakley wrote:
> That assumes that [git pull] doing something is better than doing nothing,
> which is appropriate when the costs on either side are roughly
> similar.
I think the conversation's going around in circles.
Potential next steps:
a. Documentation or test patch illustrati
Hi,
Keith Derrick wrote:
> Yes, I've since found some discussion on this, and had already changed
> to use '-' to append the classifier.
>
> But the other problem is that I can't easily find this restriction
> documented anywhere - which means it comes as a suprise to people.
That sounds like
Yes, I've since found some discussion on this, and had already changed
to use '-' to append the classifier.
But the other problem is that I can't easily find this restriction
documented anywhere - which means it comes as a suprise to people.
As it stands, the documentation implies that what I t
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:
> They can do:
>
> % git pull origin master
>
> That shouldn't revese the bases.
Then they have to remember to do that every time, no? That seems a
little error-prone versus setting a config option.
> > Such users are going to r
From: "Felipe Contreras"
Sent: Friday, May 02, 2014 8:05 PM
Philip Oakley wrote:
From: "David Kastrup"
> Marc Branchaud writes:
>
>> To that end, I suggest that pull's default behaviour should be to
>> do
>> *nothing*. It should just print out a message to the effect that
>> it
>> hasn't b
W. Trevor King wrote:
> I've renamed this sub-thread (which started around $gmane/247835) to
> avoid potential confusion/dilution.
Thanks.
> > > The goal is to train them to do:
> > >
> > > > % git config --global pull.mode none
> > > > % git fetch
> > > > % git merge --no-ff
>
> Sticking
A release candidate Git v2.0.0-rc2 is now available for testing
at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc2'
tag and the 'master' branch that the tag points at:
ur
Keith Derrick wrote:
> I can see the value in grouping branches in a directory tree under
> refs/heads, but wouldn't it make more sense to simply escape the '/'
> in the branch name so that 'hotfix/b1' is stored on disk as
> 'hotfix\/b1'?
This would be nice for remote helpers: Mercurial can have "
Hi Keith,
Keith Derrick wrote:
> $ git checkout -b hotfix
> Switched to a new branch 'hotfix'
> $ git checkout -b hotfix/b2
> error: unable to resolve reference refs/heads/hotfix/b2: Not a directory
> fatal: Failed to lock ref for update: Not a directory
> $
That's an ugl
Keith Derrick writes:
> The problem arises when a branch already exists with a name
> matching the stem of the new branch name.
> ...
> But, for the reverse reason, I can't now create the branch named 'hotfix'
All correct. Allowing '/' in branch names came about not with a
careful design but wa
From: "Marc Branchaud"
Sent: Friday, May 02, 2014 4:37 PM
(Apologies for not CCing all the folks who've participated in the
"Pull is
Evil" thread -- I couldn't find a good branch of that thread for this
message.)
OK, so maybe "git pull" is just Mostly Evil. People seem to have
found many
d
On Fri, May 02, 2014 at 07:15:44AM +0700, Duy Nguyen wrote:
> On Fri, May 2, 2014 at 6:05 AM, Jonathan Nieder wrote:
> >
> > I can make up for it in enthuasiasm. Please? It's something I've
> > wanted for a long time but never found the time to do.
>
> It's definitely better in the sense that t
Jeff King wrote:
> On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
>
> > Junio C Hamano wrote:
> > > If we step back a bit, because we are forcing him to differentiate
> > > these two pulls in his mental model anyway, perhaps it may help
> > > people (both new and old) if we had
According to
https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html a
'/' is character to use in a branch name.
git imposes the following rules on how references are named:
1. They can include slash / for hierarchical (directory) grouping, but no
slash-separated component c
Leo Razoumov writes:
> In presence of smudge/clean filters which SHA1 hash
> (clean content or smudged content) gets stored in the repository?
You are cleaning cruft in the contents before the contents are
hashed to compute the object name. The point is to keep clean
objects in the object datab
On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > > > It would matter almost exac
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
> Junio C Hamano wrote:
> > If we step back a bit, because we are forcing him to differentiate
> > these two pulls in his mental model anyway, perhaps it may help
> > people (both new and old) if we had a new command to make the
> >
W. Trevor King wrote:
> On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > > It would matter almost exactly zero.
> > >
> > > Some folks have explicit merge policies, and deciding
Richard Hansen wrote:
> On 2014-05-01 20:00, Felipe Contreras wrote:
> > Also 'branch..rebase' to 'branch..pullmode'.
> >
> > This way we can add more modes and the default can be something else,
> > namely it can be set to merge-ff-only, so eventually we can reject
> > non-fast-forward merges by
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > It would matter almost exactly zero.
> >
> > Some folks have explicit merge policies, and deciding how much
> > that matters is prob
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> >> Stepping back even further, and thinking what is different between
> >> these two pulls, we notice that the first one is pulling from the
> >> place we push back to. Perhaps a way to solve this issue, without
> >> having to introduce a new
On Fri, May 2, 2014 at 2:05 PM, Leo Razoumov wrote:
> surprisingly, searching this list and by way of Google
> I cannot find an answer to a simple question:
>
> In presence of smudge/clean filters which SHA1 hash
> (clean content or smudged content) gets stored in the repository?
The clean versio
Hi All,
surprisingly, searching this list and by way of Google
I cannot find an answer to a simple question:
In presence of smudge/clean filters which SHA1 hash
(clean content or smudged content) gets stored in the repository?
Thanks,
--Leo--
P.S. Very similar question [1] was posted here in 20
On Fri, May 02, 2014 at 01:51:55PM -0700, Junio C Hamano wrote:
> + - When splitting a long logical line, with everything else being
> + equal, it is preferrable to split after the operator at higher
dict.org says that it should be "preferable", not "preferrable".
--
brian m. carlson / brian w
Hi.
> Problem #6: push - reject - pull - push sequence sometimes transforms
> into a loop with several iterations and doesn't add happiness.
As far as I undestand, this is the most annoying thing. In
git (like other distributed systems), you cannot push your
changes unless you merge them with a v
Firstly, I apologize for sending you this sensitive information via E-mail.
In my banking department we discovered an abandoned sum of
10,000,000.00$ [Ten Million Dollars Only) in an account that belongs
to one of our Foreign customers who unfortunately lost his life with
his entire family on his
David Lang writes:
> On Fri, 2 May 2014, David Kastrup wrote:
>
>> It's just when the merge-left/merge-right/rebase-left/rebase-right
>> decision kicks in that prescribing one git-pull behavior looks like a
>> recipe for trouble.
>
> confusion at least. It's not fatal confusion, people have been
Felipe Contreras writes:
> Jeff King wrote:
>> On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote:
>>
>> > But let's follow this one:
>> >
>> > http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20call&cmpt=q
>> >
>> > which seems to say that with 'e' is more com
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 55 ++
1 file changed, 55 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 02ca67c..4dd07c3 100644
--- a/Documentation/CodingGuidelines
+++
Jeff King wrote:
> On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote:
>
> > But let's follow this one:
> >
> > http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20call&cmpt=q
> >
> > which seems to say that with 'e' is more common.
>
> Grammar by democracy. ;)
On 2014-05-01 20:00, Felipe Contreras wrote:
> Also 'branch..rebase' to 'branch..pullmode'.
>
> This way we can add more modes and the default can be something else,
> namely it can be set to merge-ff-only, so eventually we can reject
> non-fast-forward merges by default.
>
> The old configuratio
W. Trevor King wrote:
> On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > It would matter almost exactly zero.
>
> Some folks have explicit merge policies, and deciding how much that
> matters is probably best left up to the projects themselves and not
> decided in Git code.
L
Jeff King writes:
> I meant something even less in-depth. Your message says only "on
> comparison", and I did not even know what "this" in your sentence above
> would mean until I followed the link.
>
> There are arguments for writing a conditional as "a < b" rather than
> "b > a", or vice ve
On Fri, May 02, 2014 at 03:14:44PM -0500, Felipe Contreras wrote:
> brian m. carlson wrote:
> > My point is that it's unclear to me what options I need to use to
> > retain the current behavior (fast-forward if possible, merge
> > otherwise) without a warning.
>
> The current behavior is to always
On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote:
> But let's follow this one:
>
> http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20call&cmpt=q
>
> which seems to say that with 'e' is more common.
Grammar by democracy. ;)
> *1* To Americans, the form with '
On Fri, May 02, 2014 at 11:18:34AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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 yo
brian m. carlson wrote:
> My point is that it's unclear to me what options I need to use to
> retain the current behavior (fast-forward if possible, merge
> otherwise) without a warning.
The current behavior is to always merge (ff or otherwise), just what
`git merge` would do, so `git pull --merge
Felipe Contreras writes:
>> Stepping back even further, and thinking what is different between
>> these two pulls, we notice that the first one is pulling from the
>> place we push back to. Perhaps a way to solve this issue, without
>> having to introduce a new 'git update' and updating the tuto
On Fri, May 02, 2014 at 12:43:32PM -0700, Junio C Hamano wrote:
> So,... I am inclined to queue this on top of your patch at least for
> now, before I go into incommunicado-mode to finish preparing -rc2.
Yes, I'd agree with that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
Junio C Hamano writes:
> Marc Branchaud writes:
>
>> I may be mistaken, but I think "git pull" evolved to try to address the
>> detached-HEAD risk (at least in part).
>
> You are totally mistaken.
>
> "git pull" was part of the things to make git usable by Linus before
> 1.0 release, and matches
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote [1]:
> > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > > > W. Trevor King wrote:
>
Junio C Hamano writes:
> Charles Bailey writes:
>
>> I claim that any
>> platform which provides both but with differing senses is somewhat
>> broken so I cannot see the precedence mattering much.
>
> I agree with that, and that is the reason why we shouldn't change
> the order all of a sudden.
Charles Bailey writes:
> I claim that any
> platform which provides both but with differing senses is somewhat
> broken so I cannot see the precedence mattering much.
I agree with that, and that is the reason why we shouldn't change
the order all of a sudden. If it shouldn't matter, then there
On Thu, May 01, 2014 at 09:41:34PM -0500, Felipe Contreras wrote:
> brian m. carlson wrote:
> > On Thu, May 01, 2014 at 07:00:05PM -0500, Felipe Contreras wrote:
> > > Also, deprecate --no-rebase since there's no need for it any more.
> > >
> > > Signed-off-by: Felipe Contreras
> > > ---
> > > D
On Fri, 2 May 2014, David Kastrup wrote:
Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup
To: git@vger.kernel.org
Subject: Re: Pull is Mostly Evil
Marc Branchaud writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a mess
Marc Branchaud writes:
> I may be mistaken, but I think "git pull" evolved to try to address the
> detached-HEAD risk (at least in part).
You are totally mistaken.
"git pull" was part of the things to make git usable by Linus before
1.0 release, and matches the integrator workflow perfectly wel
W. Trevor King wrote:
> On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > > W. Trevor King wrote:
> > > > > My proposed --prompt behavior is for folks who think “I often run
> > >
Junio C Hamano wrote:
> If we step back a bit, because we are forcing him to differentiate
> these two pulls in his mental model anyway, perhaps it may help
> people (both new and old) if we had a new command to make the
> distinction stand out more. What if the command sequence were like
> this i
Philip Oakley wrote:
> From: "David Kastrup"
> > Marc Branchaud writes:
> >
> >> To that end, I suggest that pull's default behaviour should be to do
> >> *nothing*. It should just print out a message to the effect that it
> >> hasn't been configured, and that the user should run "git help pull"
"W. Trevor King" writes:
> On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
>> W. Trevor King wrote:
>> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
>> > > W. Trevor King wrote:
>> > > > My proposed --prompt behavior is for folks who think “I often run
>> >
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > My proposed --prompt behavior is for folks who think “I often run
> > > > this command without thinking
W. Trevor King wrote:
> On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > My proposed --prompt behavior is for folks who think “I often run
> > > this command without thinking it through all the way. I'm also
> > > not used to reading Git's output an
Jeff King writes:
> 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
On Fri, May 2, 2014 at 7:23 PM, Jonathan Nieder wrote:
> (resending with the correct address for the Git for Windows developers.
> Sorry for the noise.)
> Hi Dave,
>
> Dave Bradley wrote:
>
>> G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
>> --pretty=format:"%an %ad" -- pom.xml
>> x
Jeff King writes:
> 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 wi
Marc Branchaud writes:
> (Apologies for not CCing all the folks who've participated in the "Pull is
> Evil" thread -- I couldn't find a good branch of that thread for this
> message.)
>
> OK, so maybe "git pull" is just Mostly Evil. People seem to have found many
> different ways to make it wor
(resending with the correct address for the Git for Windows developers.
Sorry for the noise.)
Hi Dave,
Dave Bradley wrote:
> G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
> --pretty=format:"%an %ad" -- pom.xml
> Mon Nov 23 03:09:17 2009 +
> Mon Nov 23 02:42:
Hi Dave,
Dave Bradley wrote:
> G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
> --pretty=format:"%an %ad" -- pom.xml
> Mon Nov 23 03:09:17 2009 +
> Mon Nov 23 02:42:24 2009 +
>
> G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
> "--pretty=for
Erik Faye-Lund writes:
> On Fri, May 2, 2014 at 1:50 PM, Dave Bradley wrote:
>> Hi,
>>
>> I’m very new to ‘git’ github. I reported the #178 issue in github and the
>> issue has been closed, I believe this means no further discussion.
>
> When you say "the #178 issue in github", you really mean "
On Fri, May 02, 2014 at 09:48:58AM -0700, Junio C Hamano wrote:
> Charles Bailey writes:
>
> > ---
>
> Please sign-off your patches ;-)
Oops! Please consider this patch...
Signed-off-by: Charles Bailey
> This swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the
> original, which we m
Charles Bailey writes:
> ---
Please sign-off your patches ;-)
This swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the
original, which we may not want to. It is easy for me to swap the
order of if/elif to restore it, so it is not a big deal, though.
Thanks.
> compat/bswap.h | 33 ++
On Thu, May 1, 2014 at 6:35 PM, Felipe Contreras
wrote:
> 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/c
From: "David Kastrup"
Marc Branchaud writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run "git help pull"
for guidance.
Fetching is uncontentious
Marc Branchaud writes:
> To that end, I suggest that pull's default behaviour should be to do
> *nothing*. It should just print out a message to the effect that it
> hasn't been configured, and that the user should run "git help pull"
> for guidance.
Fetching is uncontentious, and I _think_ tha
(Apologies for not CCing all the folks who've participated in the "Pull is
Evil" thread -- I couldn't find a good branch of that thread for this message.)
OK, so maybe "git pull" is just Mostly Evil. People seem to have found many
different ways to make it work for them.
But in reality "git pul
On Thu, May 01, 2014 at 07:00:06PM -0500, Felipe Contreras wrote:
> 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 w
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > My proposed --prompt behavior is for folks who think “I often run
> > this command without thinking it through all the way. I'm also
> > not used to reading Git's output and using 'reset --hard' with the
Fixed. Thanks.
On Thu, May 1, 2014 at 9:22 PM, Eric Sunshine wrote:
> On Thu, May 1, 2014 at 4:37 PM, Ronnie Sahlberg wrote:
>> Allow passing a list of refs to ckip checking to name_conflict_fn.
>
> s/ckip/skip/
>
>> There are some conditions where we want to allow a temporary conflict and
>> s
Fixed. Thanks.
On Thu, May 1, 2014 at 9:11 PM, Eric Sunshine wrote:
> On Thu, May 1, 2014 at 4:37 PM, Ronnie Sahlberg wrote:
>> 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 h
On Thu, May 01, 2014 at 07:00:02PM -0500, Felipe Contreras wrote:
> Also 'branch..rebase' to 'branch..pullmode'.
Perhaps this has already been hashed out in a previous version of this
series, but we may want to use pull.update and branch..update to
match the existing submodule..update. Both setti
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley wrote:
> Hi,
>
> I’m very new to ‘git’ github. I reported the #178 issue in github and the
> issue has been closed, I believe this means no further discussion.
When you say "the #178 issue in github", you really mean "issue #178
for Git for Windows on
Hi,
I’m very new to ‘git’ github. I reported the #178 issue in github and the
issue has been closed, I believe this means no further discussion.
There are a three additional comments, thank you to the contributors. The
advise was to discuss upstream which meant nothing to me (again thanks to
Andreas Krey writes:
> On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
> ...
>> I didn't mean "replace 'pull' with 'update' everywhere". I meant
>> "Introduce 'update' that lets integrate your history into that from
>> the remote, which is to integrate in a direction opposite from how
Andreas Krey wrote:
> My personal beef with 'git pull' is still that sometimes (namely in
> the 'git pull && git push' sequence) it should reverse the order of
> the parents in the merge commit, so that *my* commits look like an
> integrated topic branch, instead of the former mainline.
I haven't
---
compat/bswap.h | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index 120c6c1..f08a9fe 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x)
#u
On Thu, May 01, 2014 at 11:58:26AM -0700, Junio C Hamano wrote:
>
> This patch seems to address two unrelated issues in that.
>
> (1) The existing support does not help a platform where the
> convention is to define either _BIG_ENDIAN (with one leading
> underscore) or _LITTLE_ENDIAN a
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
> I didn't mean "replace 'pull' with 'update' everywhere". I meant
> "Introduce 'update' that lets integrate your history into that from
> the remote, which is to integrate in a direction opposite from how
> 'pull' does".
That still
On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote:
...
>
> But these days there's hardly any risk to using a detached HEAD. Plus
> nowadays I think it's commonly accepted that using topic branches is a git
> best practice. The notion of doing work on a generically-named branch like
> "mai
95 matches
Mail list logo
