On 12/10/19 2:51 am, Jeff King wrote:
On Sat, Oct 12, 2019 at 02:42:49AM +1100, Daniel Axtens wrote:
where a possible solution was to get senders to use in-body From
headers even when sending their own patches.
[...]
I'm not sure this solution is correct.
If I take a patch from A
On 11/10/19 3:36 pm, Andrew Donnellan wrote:
It would be nice if Mailman could adopt X-Original-Sender too. As it is,
(which I have gone ahead and reported as
https://gitlab.com/mailman/mailman/issues/641)
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com
For the Patchwork use case, I'm quite okay with accepting the risk of
using Reply-To, as the alternative is worse, the corner cases are rare,
and ultimately a maintainer can still fix the odd stuff-up before
applying the patch.
--
Andrew Donnellan OzLabs, ADL Canberra
a..
bust - but OTOH there's always a long tail of users
stuck on old versions of git for whatever reason and having some logic
to detect DMARC munging may thus still be useful.
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
bably just change it?
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
esses over at Git Rev
News[0] straightforward and sensible, if you're looking for ideas.
Regards,
Andrew Ardill
[0] https://git.github.io/rev_news/rev_news/
Signed-off-by: Andrew Yefanov <1134t...@gmail.com>
---
Documentation/git-p4.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 7436c64a9..aac95d0a0 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@
point the directory, because works in the current one. The result would be like:
git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 sync --detect-branches //depot@all
Signed-off-by: Andrew Yefanov <1134t...@gmail.com>
---
Documentation/git-p4.txt | 2 +-
rying to follow the instructions in
git/Documentation/SubmittingPatches and based my patches on the
"maint" branch from https://github.com/git/git.git.
- Andrew
Encoding name was erroneously referred to as UTF-16-LE-BOM in name of
test; this should in fact be UTF-16LE-BOM (no hyphen between '16' and
'LE').
---
t/t0028-working-tree-encoding.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0028-working-tree-encoding.sh b/t/t0028-wor
Encoding name was erroneously documented as UTF-16-LE-BOM; this should
in fact be UTF-16LE-BOM (no hyphen between '16' and 'LE').
---
Documentation/gitattributes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.tx
On 4/22/19 1:47 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Apr 22 2019, Andrew Janke wrote:
>
>> On 4/21/19 8:35 PM, Duy Nguyen wrote:
>>> On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke wrote:
>>>>
>>>> Hi, Git folks,
>>>
On 4/21/19 9:27 AM, Andrew Janke wrote:
>
> On 4/21/19 8:59 AM, Philip Oakley wrote:
>> Hi Andrew,
>>
>> On 21/04/2019 12:08, Andrew Janke wrote:
>> https://public-inbox.org/git/d001a2b5-57c3-1eb3-70fd-679919bb2...@apjanke.net/
>>
>>> I don&
On 4/21/19 8:35 PM, Duy Nguyen wrote:
> On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke wrote:
>>
>> Hi, Git folks,
>>
>> This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.
>
> This says the problem with "en" detecti
On 4/21/19 8:59 AM, Philip Oakley wrote:
> Hi Andrew,
>
> On 21/04/2019 12:08, Andrew Janke wrote:
> https://public-inbox.org/git/d001a2b5-57c3-1eb3-70fd-679919bb2...@apjanke.net/
>
>> I don't think it would even have
>> to be actively maintained, because for
I'm not
sure if the appropriate thing to do is make a PR for this to the
git-l10n/git-po GitHub repo or not.
Cheers,
Andrew Janke
On Fri, 8 Feb 2019 09:10:33 +
and...@adoakley.name wrote:
> From: Andrew Oakley
>
> Perforce allows you commit files and directories with the same name,
> so you could have files //depot/foo and //depot/foo/bar both checked
> in. A p4 sync of a repository in this state f
From: Andrew Oakley
Perforce allows you commit files and directories with the same name, so
you could have files //depot/foo and //depot/foo/bar both checked in. A
p4 sync of a repository in this state fails. Deleting one of the files
recovers the repository.
When this happens we want git-p4
On Thu, 7 Feb 2019 08:04:20 +
Luke Diamand wrote:
> On Wed, 6 Feb 2019 19:42:19 +
> and...@adoakley.name wrote:
>
> > From: Andrew Oakley
> >
> > Perforce allows you commit files and directories with the same
> > name, so you could have files //d
From: Andrew Oakley
Perforce allows you commit files and directories with the same name, so
you could have files //depot/foo and //depot/foo/bar both checked in. A
p4 sync of a repository in this state fails. Deleting one of the files
recovers the repository.
When this happens we want git-p4
Hi
Thanks for reply, but sorry I don't know how to do that - I don't have the git
source code or know how to debug it.
Is there another way I can capture logging/debugging information while running
"git svn clone" and send it to you?
Thanks
Andrew Shearer / Web Devel
Hi
Thanks for reply, but sorry I don't know how to do that - I don't have the git
source code or know how to debug it.
Is there another way I can capture logging/debugging information while running
"git svn clone" and send it to you?
Thanks
Andrew Shearer / Web Developer
D
nothing particularly special about svn changeset 50739 that I can see
compared to any other.
Anyone know why this might be failing or how I could resolve it?
Thanks
Andrew
any
message.
It was found, that Git version 2.17.1 still works as expected.
—
Sincerely,
Andrew Kharchenko
the 'git flow' development methodology
(but doesn't require it).
A pretty good discussion of these ideas can be found at
https://stackoverflow.com/questions/7175869/managing-hotfixes-when-develop-branch-is-very-different-from-master
Regards,
Andrew Ardill
--
Andrew A. Schachter
Attorney At Law
General Parts Inc
2808 Falbrook Dr. NE
Cedar Rapids, IA 52402
E-mail; andrewazaz...@aol.com
My name is Andrew A. Schachter Attorney “Agricultural Development Bank.
I’m writing on behalf of Mrs. Tracy Mills of West Side Auto Parts 604
Libby Lane
scripts to a built-in. I'm sure other people are too, and I'll
bet the ones who have been there before will have feedback for you as
well.
I'd find it interesting even if it was a 5-line bullet list of what's
going through your mind with respect to the project! Looking forward
to following along.
Regards,
Andrew Ardill
put the current commit/branch into the
output directories as documentation; I usually do this in my build scripts.
This also makes it simple to detect when the branch is changed and clean the
outputs.
- Andrew
> On Apr 22, 2018, at 3:59 PM, Kevin Daudt wrote:
>
> On Sun, Apr 22,
ar because they haven't been committed to master.
Instead, under my proposal, each will get the timestamp of its prior commit.
If you're doing a merge, it will entail a commit and, again, the modified files
will be newer.
I don't think your use case breaks my proposal.
- Andrew Wol
ted.
When repository servers have different clocks - which is normal - each
clone/merge/push should record the time offset. Each timestamp on each commit
should be corrected to the repository's specific time, and that should be a
marking on the history.
Sincere regards,
Andrew Wolfe
rosoft/vscode/issues/48211 if anyone wants
to chime in with advice over there :-)
Thanks,
Andy
> -Original Message-
> From: Bryan Turner [mailto:btur...@atlassian.com]
> Sent: 19 April 2018 23:14
> To: Andrew Ducker
> Cc: git@vger.kernel.org
> Subject: Re: Bug Report - Pull
What happens:
When I create a new tag on the remote (changing nothing else)
"git pull origin master" produces the following:
From git.internal.company.com:team/testrepo
* branchmaster -> FETCH_HEAD
Already up-to-date.
If I instead do a "git pull" I get:
From git.internal.c
ks like it might work for stash pop conflicts.
This one[1] shows how to create hooks that catch any conflicts that
are being committed, and would also probably work with stash
conflicts.
Teaching the tool to handle stash conflicts, or making any of the
above changes to the base distribution of git wo
sk. See more at
https://en.wikipedia.org/wiki/Yes_(Unix)
I agree it's a little weird if you have no idea what it's doing, but
it is very useful and very old, used by many many different scripts
etc, and so unlikely to change.
Regards,
Andrew Ardill
, Dec 29, 2017 at 4:04 AM, Andrew Tsykhonya
> wrote:
>> git stash pop resulted in crash:
>> /usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470:
>> 14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree
>> $w_tree
>> although, the changes h
git stash pop resulted in crash:
/usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470:
14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree
$w_tree
although, the changes have been applied successfully.
FROM: ANDREW LAWSON.
Dear Sir,
My name is Mr. Andrew Lawson. I work as a procurement assistant. I got your
contact details during my search for a reliable and neutral company or
individual to partner with in the area of investment.
I need your assistance to manage an investment fund in a
t (2.15.0); this was also present in a
prior version.
Cheers,
Andrew
[1] https://stackoverflow.com/questions/47084672
Hi,
I am Andrew McCabe the United States FBI director charge, am hereby announcing
to you that your ATM Card fund from Benin Republic government authorities, and
Mrs. Jane Frederick, came forward and claimed that they are having problem in
the process of your Card.
This is to bring to your
vise not using & in branch names,
specifically because it is a special character in shells.
Regards,
Andrew Ardill
Hi Anatoli,
On 21 August 2017 at 07:57, Anatolii Borodin wrote:
> On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill
> wrote:
>> Maybe I am missing something obvious, but if that's the case then
>> can't we just do the identity check when trying to make new commits,
&g
mits
> with bogus ident information, we changed it in 2012.
Maybe I am missing something obvious, but if that's the case then
can't we just do the identity check when trying to make new commits,
in which case you should be able to pull without setting your
identity?
Regards,
Andrew Ardill
gards,
Andrew Ardill
On 16 August 2017 at 16:47, Kim Birkelund wrote:
> Apologies. I should obviously have mentioned which OSes the machines I
> tested on ran.
>
> One Windows 10 (fully updated) and one Windows Server 2016 (also
> updated). I've also seen it in a real repos
ions, and might
have an idea about how it could be localised if that was something
your community wanted to support.
Regards,
Andrew Ardill
[0] https://git.github.io/rev_news/
On 25 July 2017 at 04:11, Jeff King wrote:
> On Mon, Jul 24, 2017 at 02:58:38PM +1000, Andrew Ardill wrote:
>
>> On 24 July 2017 at 13:45, Farshid Zavareh wrote:
>> > I'll probably test this myself, but would modifying and committing a 4GB
>> > text file actual
EAD^ # 44.658s
$ time git checkout master # 38.267s
$ git gc
$ du -h --max-depth=1
1.3G./.git
3.4G.
$ time git checkout HEAD^ # 34.743s
$ time git checkout HEAD^ # 41.226s
Regards,
Andrew Ardill
replicated later on, but I don't want to add 4GB
of data to the repo every single time the dataset gets updated (also
every quarter). Storing that in LFS would be a good solution then.
Regards,
Andrew Ardill
ing on how you do the revert.
Does that page describe what you're trying to do?
Regards,
Andrew Ardill
On 8 July 2017 at 07:07, Martin Langhoff wrote:
> Hi git-folk!
>
> long time no see! I'm trying to do one of those "actually, please
> don't" things
t
has happened to it.
Really enjoying your updates, by the way, they are very clear and show
what looks like great progress!
Regards,
Andrew Ardill
You are the best Peff.
It was indeed the hierarchy. So just had to change document root.
Thanks a bunch.
On Fri, Apr 28, 2017 at 11:34 AM, Jeff King wrote:
> On Fri, Apr 28, 2017 at 11:28:14AM -0400, Andrew Watson wrote:
>
>> $ GIT_CURL_VERBOSE=1 git clone http://git.site.do
GMT
< ETag: "17-54defc6469818"
< Accept-Ranges: bytes
< Content-Length: 23
<
* Connection #0 to host git.site.domain.com left intact
warning: You appear to have cloned an empty repository.
Content length is again 0.
On Fri, Apr 28, 2017 at 11:20 AM, Jeff King wrote:
> On
o my httpd.conf just to be safe.
I'm not sure what /info/refs is supposed to look like, but it is
empty. Could that be the issue?
Do you see anything in my apache configuration that looks wrong?
Andrew
On Thu, Apr 27, 2017 at 4:18 PM, Jeff King wrote:
> On Thu, Apr 27, 2017 at 02:37:19P
Hi,
I'm trying to setup git with Smart HTTP so we can move off of SVN.
I've used the blog post: https://git-scm.com/blog/2010/03/04/smart-http.html
I'm getting "error: Cannot access URL ... return code 22" when I try
to push. Clone works fine.
I verified authentication by replacing my LDAP stuf
.
The P4Submit command has been simplified to not call P4Sync itself, it
lets P4Rebase do it instead (now that the branch can be handled). This
fixes an issue where P4Submit does a sync of the requested branch and
then does a rebase which does a sync of all branches.
Signed-off-by: Andrew Oakley
have
occurred. Likewise, if we had added "temp" anywhere other than the top
level of "project" the subtree pull would not have caused problems.
Anyhow, I'm not sure if you guys are aware of the problem or not, but
I figured I'd bring it to your attention just in case.
Thanks so much,
- Andrew
, and it worked quite well, but nothing
further has been done to my knowledge.
[0] http://public-inbox.org/git/7vvc3d1o01@alter.siamese.dyndns.org/
Regards,
Andrew Ardill
Lieber Freund,
Wie geht es Ihnen heute? Ich habe eine Investitionsmöglichkeit mit Ihnen
zu teilen, die die Übertragung einer großen Geldsumme zum gegenseitigen
Nutzen für beide von uns betreffen.
Mein Name ist Andrew Hau Chung, ich in einem Finanzinstitut arbeiten
hier in Hong Kong.
Wenn Sie
--
Lieber Freund,
Wie geht es Ihnen heute? Ich habe eine Investitionsmöglichkeit mit Ihnen
zu teilen, die die Übertragung einer großen Geldsumme zum gegenseitigen
Nutzen für beide von uns betreffen.
Mein Name ist Andrew Hau Chung, ich in einem Finanzinstitut arbeiten
hier in Hong Kong
r than
+ application.
Perhaps mention the phrase "Request For Comment" for the benefit of
those who aren't familiar (which admittedly, among users of
git-format-patch, are probably rather few, but still).
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
.
Respectfully,
Andrew Johnson
--
Lieber Freund,
Wie geht es Ihnen heute? Ich habe eine Investitionsmöglichkeit mit Ihnen
zu teilen, die die Übertragung einer großen Geldsumme zum gegenseitigen
Nutzen für beide von uns betreffen.
Mein Name ist Andrew Hau Chung, ich in einem Finanzinstitut arbeiten
hier in Hong Kong
-f to rename files on
case insensitive file systems.
Details at
https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git
Regards,
Andrew Ardill
Hi,
Jakub Narębski wrote:
> Andrew Ardill pisze:
> > Jakub Narębski wrote:
> >> 25. What [channel(s)] do you use to request/get help about Git [(if any)]
> >
> > It may also be useful to ask how people hear news about git, such as
> > when a new release com
the same time as they update
other packages, but it would be interesting to know if people, for
example, only upgrade their managed environments every year/6 months
or something to avoid introducing changes to their users.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the l
Am 04.08.2016 um 12:45 nachm. schrieb Junio C Hamano :
> Andrew Keller writes:
>
>> In summary, I think I prefer #2 from a usability point of view, however I’m
>> having
>> trouble proving that #1 is actually *bad* and should be disallowed.
>
> Yeah, I agr
age
template
[2] and possibly create a patch that teaches builtin/commit.c to detect changes
to the
index after the pre-commit hook runs
Thanks,
- Andrew Keller
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.o
On Fri, Jul 15, 2016 at 10:33:42PM +0200, Johannes Sixt wrote:
> Am 15.07.2016 um 09:46 schrieb Andrey Vagin:
> > On Thu, Jul 14, 2016 at 10:56 PM, Johannes Sixt wrote:
> > > IOW: These special files are invisible for Git unless it already knows the
> > > names. The latter case is outside 'git cle
Am 15.07.2016 um 6:03 nachm. schrieb Junio C Hamano :
> Junio C Hamano writes:
>> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>>
>>>> I pulled out the source for version 2.9.1 and b
Am 15.07.2016 um 5:19 nachm. schrieb Junio C Hamano :
>
> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>
>>> I pulled out the source for version 2.9.1 and briefly skimmed how
>>> run_commit
Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
> I pulled out the source for version 2.9.1 and briefly skimmed how run_commit
> and
> prepare_to_commit work. It seems that Git already understands that a
> pre-commit
> hook can change the index, and it rereads the index
Definitely interested — Sounds like a great learning experience.
Thanks,
- Andrew Keller
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
changes that the user didn't tell "git commit" to make.
Ah! Good to know, then. I’ll rewrite my hook to behave more correctly.
Thanks,
- Andrew Keller
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
ior is not intentional. I’d wager that
this
change is for the better, but since this behavior has been around so long (I
stopped
checking at 1.6.0), it doesn’t hurt to make sure.
Any comments, concerns, or advice?
Thanks,
- Andrew Keller
nlikely that that is all that is going on is
due to you seeing the behaviour on a completely fresh OS and git
install.
If you are able to give more details in the bug report about how to
reproduce the behaviour that will help a lot too.
Regards,
Andrew Ardill
--
To unsubscribe from this list:
Having difficulty understanding how to invoke 'git log' to track the history of
a file that was imported into a different location through a subtree merge.
I had thought just '--follow' was needed, but I don't seem to be getting any
results with that.
Example bel
The logic here was inverted, you got a message saying the file is
ignored for each file that is not ignored.
Signed-off-by: Andrew Oakley
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index b6593cf..b123aa2 100755
--- a/git-p4.py
+++ b
On 21/06/16 19:16, Junio C Hamano wrote:
> Thanks. This needs sign-off, though.
Sorry, didn't realise I needed to do that! Will resend with sign off.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
The logic here was inverted, you got a message saying the file is
ignored for each file that is not ignored.
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index b6593cf..b123aa2 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2674,7 +2674,7 @@ c
2434)|
This compatibility problem was noted before back in 2012, in
http://www.mail-archive.com/git%40vger.kernel.org/msg14496.html.
Would you consider switching from lime to a hex value color, for
compatibility with users of older versions of Tk? A patch to do so is
below; only the file gitk-g
slightly different, and I think the
> bug Andrew saw lies in that codepath. It is likely that the code is
> forgetting to make sure that there is no top of enclosed working
> tree in the common leading directory part of the path.
Actually, the very simplest case succeeds in adding a fil
w, Chromium is comprised of many hundreds of nested
repos, so that aided in manifesting this issue.
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
sn't happen to live in a
nested repository ("testfile" in this example).
If someone could help me understand what's going on here, I'd appreciate it.
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
s etc, but if so you could
make it implied only if we detect a terminal or something like is done
in other places.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
may well cause more problems then
it fixes.
What I wonder is, in what situation is the current behaviour is desirable?
While I agree that the option works as designed, I think its behaviour
is more surprising to the end user then it should be.
Regards,
Andrew Ardill
--
To unsubscribe from this
the
commits?
My practical knowledge of notes is severely lacking so excuse me if I
missed anything obvious.
Regards,
Andrew Ardill
(sorry for the double post Junio, gmail ate my plain text encoding at
some point...)
--
To unsubscribe from this list: send the line "unsubscribe git"
- Original Message -
> From: "Jeff King"
> To: "Andrew Martin"
> Cc: "Matthieu Moy" , git@vger.kernel.org
> Sent: Tuesday, February 2, 2016 10:34:12 PM
> Subject: Re: git object-count differs between clones
>
> On Tue, Feb 02, 2016 at 1
- Original Message -
> From: "Jeff King"
> To: "Andrew Martin"
> Cc: "Matthieu Moy" , git@vger.kernel.org
> Sent: Tuesday, February 2, 2016 10:52:46 AM
> Subject: Re: git object-count differs between clones
>
> On Tue, Feb 02, 2016 at
- Original Message -
> From: "Matthieu Moy"
> To: "Andrew Martin"
> Cc: git@vger.kernel.org
> Sent: Tuesday, February 2, 2016 10:09:31 AM
> Subject: Re: git object-count differs between clones
>
> Andrew Martin writes:
>
> > I
o problems. Moreover, I ran "git gc"
and made sure there were no objects pending garbage collection, but still I
cannot account for this difference. Can someone explain why these numbers
differ, and if this is a problem or not?
Thanks,
Andrew
--
To unsubscribe from this list: send the
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref
> These all look OK (I am not sure about message i18n, though).
>
> Do we not test a case where --force-with-lease push is rejected due
> to REF_STATUS_REJECT_STALE?
Good idea, new patch on the way.
-andrew
--
To unsubscribe from this list: send the line "unsubscribe git&
Ignore -- I left an extra blank line. v3 is sent.
On Thu, Jan 28, 2016 at 2:20 PM, Andrew Wheeler wrote:
> From: Andrew Wheeler
>
> The --force--with-lease push option leads to less
> detailed status information than --force. In particular,
> the output indicates that a ref
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref
rying to do as many microprojects as possible, leaving few
for other people.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
a few tests, perhaps to t/t5533?
>
> Thanks.
>
Great idea. I'll add some tests to t/t5533, remove that blank line
above, and share a new patch.
Thanks for the review!
-andrew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
problem seems to be that ref.forced_update is never set in
remote.c. I have a patch below that works-around the problem, but it
may be not the right approach.
commit 81d8b713ee83161dbd7eb3dafd22718d1fa992a1
Author: Andrew Wheeler
Date: Tue Jan 19 15:23:32 2016 -0600
push --force-wit
n in the same second? If so, trying running it slowly by hand,
> or inserting "sleep 1" between the commands.
I ran my tests by hand, taking more than 1s between commands.
I also used `stat README` and `ls -l README` on occasion to confirm that
`touch` was updating the file'
1.2 (as well as
10.10.something) with git 2.5.4 and everything worked as expected.
Any help would be much appreciated. Thanks in advance!
Yours,
Andrew Stewart
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref
1 - 100 of 318 matches
Mail list logo
